Subject: Re: FVWM: Parsing window_flags in perl

From: Scott Smedley <[email-masked]>
Date: Thu, 16 Sep 2004 00:20:53 +1000

> > 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

> 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

Let's see if I understand this thread properly. (Tell me if I say
something incorrect.)

At the moment, whenever FVWM sends an M_ADD_WINDOW or M_CONFIGURE_WINDOW
packet, the last field in the packet is (effectively) a memcpy() of the
window_flags data-member from the ConfigWinPacket struct. The bit-value
of the window_flags data-member varies from compiler to compiler because
of byte alignment/padding, endianess, etc.

So the solution is to define precisely what each bit in a flags
field (of a packet) pertains to. This means that FVWM will carefully
"build" each bit in the flags field (selectively choosing only 50 or
so interesting flags from the window_flags struct). FVWM modules
that receive these packets now have to treat the flags field as
a specially-defined set of bits (relating directly to flags) instead
of a bundle of bits that fill a window_flags C struct.

Presumably we have to ensure that the 50 (or so) flags we decide to
export satisfy all the C FVWM modules. (Currently, the modules have
access to all 384 bits (on my platform) of the window_flags struct
& could potentially be using any of them.)

Re: perllib "breakage is auto-detected"

I'm not sure how perllib would detect the addition or removal of flags.

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

---

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

> of byte alignment/padding, endianess, etc.

Yes.

> of a bundle of bits that fill a window_flags C struct.

Replace the last "instead of" with "together with" and you get what I
meant.

> & could potentially be using any of them.)

No, C modules still have the access to all flags. This is an intermediate
solution that would be relatively easy and cheap to implement, until the
real solution of actual replacing of the currently compiler dependent
flags is implemented (if at all).

Now, when I say 50, it may mean 40 or 60, anything less than 64; some
flags are 2 or more bits. And there is no reason not to also send the
third integer in addition to these two, that includes 32 window states.

> I'm not sure how perllib would detect the addition or removal of flags.

When I spoke about breakage in that thread, I didn't refer to flags (they
were not changed), but to arguments of events (Dominik changed the order
and type/number of arguments). This may be partially auto-detected in
some tests. Anyway, this is not a big problem; as long as everyone writes
meaningful cvs log messages, the changes to module interface may be
detected by a man (me, you) and applied to perllib promptly.

Regards,
Mikhael.