On 16 Sep 2004 00:20:53 +1000, Scott Smedley 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 > > > 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.
Yes. > 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. Replace the last "instead of" with "together with" and you get what I meant. > 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.) 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. > Re: perllib "breakage is auto-detected" > > 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. -- 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 PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
