Subject: FVWM: Parsing window_flags in perl

From: Mark Gray <[email-masked]>
Date: 14 Sep 2004 19:25:39 -0400

I am writing a fvwm perl module and anticipate wanting to parse the
window_flags data upon receiving each M_ADD_WINDOW event.  Looking
through the FVWM perl modules I did not see any function for doing
this, and before going to the trouble to translate the bit-fields in
fvwm.h to perl I thought I would ask if it has already been done (and
I just didn't look hard enough:-)  This will be my first FVWM perl
module so I apologize if this is a FAQ.

TIA.

--
Visit the official FVWM web page at <URL: http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Salvatore Domenick Desiano <[email-masked]>
Date: Tue, 14 Sep 2004 20:22:39 -0400 (EDT)

Unfortunately, the flag locations differs from platform to platform and
from compiler to compiler. If you (or anyone) wanted to write a robust
version, it would have to do a compile of a C program during the build of
fvwm, and produce some perl code from the result.

I've done it for individual flags, but my process is entirely manual
because I'm only using two or three flags.

-- Sal
smile.

On 14 Sep 2004, Mark Gray wrote:

o I am writing a fvwm perl module and anticipate wanting to parse the
o window_flags data upon receiving each M_ADD_WINDOW event.  Looking
o through the FVWM perl modules I did not see any function for doing
o this, and before going to the trouble to translate the bit-fields in
o fvwm.h to perl I thought I would ask if it has already been done (and
o I just didn't look hard enough:-)  This will be my first FVWM perl
o module so I apologize if this is a FAQ.
o
o TIA.
o
o
o --
o Visit the official FVWM web page at <URL: http://www.fvwm.org/>.
o To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
o message to [email-masked].
o To report problems, send mail to [email-masked].
o
o
o

--------------
  Salvatore Domenick Desiano
    Research Scientist
      NASA Ames Research Center (QSS Group, Inc.)

--------------
  Salvatore Domenick Desiano
    Research Scientist
      NASA Ames Research Center (QSS Group, Inc.)

---

From: Mikhael Goikhman <[email-masked]>
Date: Wed, 15 Sep 2004 11:05:37 +0000

> because I'm only using two or three flags.

The proper solution is to serialize the flags without dumping C
structures. Here is a discussion:
http://www.hpc.uh.edu/fvwm/archive/0407/msg00186.html

It is not very hard to implement what is suggested in the link without
removing the current complier dependent flags. The hard part is to decide
on the 50 most useful flags to be packed in two integers; I don't think
we need to pass more flags, no modules use them. But I currently don't
have a time to implement this in fvwm. Unfortunately.

If someone implements this, I will try to find the time to support these
packed flags in perl stuff, including FvwmDebug and WindowList tracker.

Regards,
Mikhael.

---

From: Mark Gray <[email-masked]>
Date: 15 Sep 2004 10:50:40 -0400

> because I'm only using two or three flags.

Yes, I realized the difficulties involved in a Perl only solution,
which is why I had hopes it was already done for me :-) While I was
sleeping I came upon a simpler, but less general solution to the
problem I was trying to fix: Since I know the names and classes of the
Windows I want to treat in a special manner, there is no need to base
my decision on the flags of the windows, I can just put a hash naming
the "special" windows in my perl module, and just update it as I
encounter new "problem" applications.

---

From: Mark Gray <[email-masked]>
Date: 15 Sep 2004 11:20:10 -0400

> packed flags in perl stuff, including FvwmDebug and WindowList tracker.

What are your feelings about adding a C Perl module to the FVWM perl
modules which would do this?  My only experience with writing C/C++
Perl modules consists of working through the examples and exercises in
books on Perl, but it sounds like it might be a faster route to a
solution (faster than for me to learn the internal operations of the
fvwm code well enough to hack in another event to fvwm as
msg00186.html suggests.)  The biggest problem I can see with adding a
C Perl module to fvwm's perllib, is in the build process on unknown
platforms -- not everyone is going to even have their systems in a
state that is capable of compiling a C Perl module (old Redhat Linux
systems come to mind).

---

From: Salvatore Domenick Desiano <[email-masked]>
Date: Wed, 15 Sep 2004 12:54:26 -0400 (EDT)

Ah, yes. The correct solution is always to work with both code bases (C
and Perl) to get an efficient cross-platform solution. As JAPH, however, I
tend to fix things in Perl because it means I don't have to risk breaking
other people's code. Nonetheless, Mikhael is right. If someone's going to
do this, and they have the support of the rest of the community, it should
be in the C code base.

That said, I would vote to see the export of all of the flags, or we might
regret our choices later.

Another possibility is to have Fvwm do a dump of flag names and bit
offsets to all modules on startup. This would allow us to use all 384 bits
with a small amount of startup overhead, and would even ensure that
modules work if they are running on different platforms from fvwm (a
situation that I don't personally foresee, but I haven't been thinking
about these things long).

-- Sal
smile.

On Wed, 15 Sep 2004, Mikhael Goikhman wrote:

o On 14 Sep 2004 20:22:39 -0400, Salvatore Domenick Desiano wrote:
o >
o > On 14 Sep 2004, Mark Gray wrote:
o >
o > o I am writing a fvwm perl module and anticipate wanting to parse the
o > o window_flags data upon receiving each M_ADD_WINDOW event.  Looking
o > o through the FVWM perl modules I did not see any function for doing
o > o this, and before going to the trouble to translate the bit-fields in
o > o fvwm.h to perl I thought I would ask if it has already been done (and
o > o I just didn't look hard enough:-)  This will be my first FVWM perl
o > o module so I apologize if this is a FAQ.
o >
o > Unfortunately, the flag locations differs from platform to platform and
o > from compiler to compiler. If you (or anyone) wanted to write a robust
o > version, it would have to do a compile of a C program during the build of
o > fvwm, and produce some perl code from the result.
o >
o > I've done it for individual flags, but my process is entirely manual
o > because I'm only using two or three flags.
o
o The proper solution is to serialize the flags without dumping C
o structures. Here is a discussion:
o http://www.hpc.uh.edu/fvwm/archive/0407/msg00186.html
o
o It is not very hard to implement what is suggested in the link without
o removing the current complier dependent flags. The hard part is to decide
o on the 50 most useful flags to be packed in two integers; I don't think
o we need to pass more flags, no modules use them. But I currently don't
o have a time to implement this in fvwm. Unfortunately.
o
o If someone implements this, I will try to find the time to support these
o packed flags in perl stuff, including FvwmDebug and WindowList tracker.
o
o Regards,
o Mikhael.
o --
o Visit the official FVWM web page at <URL: http://www.fvwm.org/>.
o To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
o message to [email-masked].
o To report problems, send mail to [email-masked].
o
o
o

--------------

---

From: Mikhael Goikhman <[email-masked]>
Date: Thu, 16 Sep 2004 13:55:55 +0000

On 15 Sep 2004 11:20:10 -0400, Mark Gray wrote:
> >> o window_flags data upon receiving each M_ADD_WINDOW event.
> 
> msg00186.html suggests.)

The suggestion was not to add a new event, but new M_ADD_WINDOW fields,
as said in the reply to that message.

> The biggest problem I can see with adding a

There are multiple reasons why I don't like to compile anything Perl
specific, but if you want to go this path, you may try. The "make" step
may compile and run some C program that generates Perl class
FVWM::WindowFlags. There is a problem then of maintaining this program,
it would be a lot of annoying code that duplicates the huge non-flat
window_flags structure in C. I prefer the solution with 50 most useful
flags to be packed and sent to modules, so that it would not be perl
specific, this does not really require maintainance, since the most
useful flags are not likely to be removed. But I don't care to support
all 300 flags if someone wants to maintain this generating program.

Just please keep in mind that currently the Perl stuff is fully
transparent, it is not even required that Perl is installed before
installing fvwm. I want to continue with this.

Regards,
Mikhael.

---

From: Mark Gray <[email-masked]>
Date: 16 Sep 2004 10:38:16 -0400

> as said in the reply to that message.

Ah -- I misunderstood: I saw the reference to the M_OLD_ADD_WINDOW and
thought you wanted to revive it, and did not think to read the
followups to that post.

>> The biggest problem I can see with adding a C Perl module to fvwm's
>> perllib, is in the build process on unknown platforms -- not
>> everyone is going to even have their systems in a state that is
>> capable of compiling a C Perl module (old Redhat Linux systems come
>> to mind).

> installing fvwm. I want to continue with this.

I agree with everything you say.  Arranging for the building of perl
c-modules on unknown and unseen systems is a daunting task -- I have
often had to modify modules I have downloaded from CPAN in order to
get them to build, even on the most up to date and correctly
configured systems.

But I really like your suggestion about a C program which will
generate a perl only FVWM::WindowFlags, and I will look into doing so.

---

From: Salvatore Domenick Desiano <[email-masked]>
Date: Thu, 16 Sep 2004 15:11:56 -0400 (EDT)

o But I really like your suggestion about a C program which will
o generate a perl only FVWM::WindowFlags, and I will look into doing so.

I reiterate the suggestion that this be done on module startup, rather
than by file generation. Then, rather than adding a file to the
distribution, you simply generate a set of M_CONFIG_INFO messages

M_CONFIG_INFO FlagBit WINDOW_HAS_TITLE 134
M_CONFIG_INFO FlagBit WINDOW_IS_STICKY_ACROSS_DESKS 0
M_CONFIG_INFO FlagBit STYLE_IS_TRANSIENT 150

The Perl code to record and decode things this way is obscenly short:

$module->addHandler(M_CONFIG_INFO,\&config_info_handler);

sub config_info_handler($)
{
  my ($self, $event) = @_;
  my @tokens = getTokens($event->_text);
  $flag_bits{$tokens[1]} = $tokens[2] if ($tokens[0] eq 'FlagBit');
}

sub flag_bit($$)
{
  my ($event,$flag_name) = @_;
  return undef if (!exists($flag_bits{$flag_name}));
  my $bit = $flag_bits{$flag_name};
  return ord(substr($event->_window_flags,int($bit/8),1))>>($bit%8))&0x1;
}

The C code is the same as what Mark has been talked about for a C -> Perl
module, and I've written it already for another project, although it's not
to Fvwm coding standards. It's not elegant, but brute force is all we can
get because of the implementation-dependent style of the C standard.

#define FIND_BIT(x) \
   { SET_##x(with,1);  \
     find_bit(##x,with,without); \
     SET_##x(with,0); }

unsigned find_bit(char         * name,
                  window_flags * with,
                  window_flags * without)
{
  for (i = 0; i < (sizeof(wf) * 8); ++i)
  {
    unsigned bitIndex = i % 8;
    unsigned byteIndex = i / 8;
    unsigned char byte = ((unsigned char *)&wf)[byteIndex];
    unsigned char bit = (byte >> bitIndex) & 0x1;
    unsigned char bytet = ((unsigned char *)&wft)[byteIndex];
    unsigned char bitt = (bytet >> bitIndex) & 0x1;
    if (bit != bitt)
      printf("M_CONFIG_INFO FlagBit %s %d\n",name,bit);
  }
}

unsigned dump_window_flags()
{
  FvwmWindow with;
  FvwmWindow without;
  FIND_BIT(DO_SHRINK_WINDOWSHADE);
  FIND_BIT(DO_LOWER_TRANSIENT);
  FIND_BIT(DO_STACK_TRANSIENT_PARENT);

  ...

}

-- Sal
smile.

--------------