On 11 Jul 2004 16:54:18 +0200, Dominik Vogt wrote: > > On Sun, Jul 11, 2004 at 10:47:28AM +0000, Mikhael Goikhman wrote: > > > > > > If you ever change any event arguments, please update file > > > > perllib/FVWM/EventNames.pm (including format, names and types of the > > > > event args), or tell me to update. Testing all modules that use that > > > > event would be nice too. > > > > > > What's an event argument? Do you mean module messages? > > > > No, event argument is a positioned fixed-size (or variable-size if last) > > field. Here is the terminology I and perllib/FVWM/EventNames.pm use: > > I see. Testing the modules when the order of fields in > ConfigWinPacket changes should not be necessary as all modules > have been rewritten to use that structure when it was introduced > in 2000. If the perllib does not use it, it's a bug in the > perllib.
The bug part is questionable. There are currently 32+ events, not just 2. Currently perllib (EventNames.pm specifically) defines the complete event scheme. The C library does not even come close, modules simply parse the events on their own, so there is no really enough info to generate from. One solution would be to write a parser of ConfigWinPacket structure to generate the scheme of these two events only. But given that someone should maintain such parser, and this structure is not changed often (maybe once per year), it is just much *much* easier to manually synchronize EventNames.pm with it. Testing the modules is not really necessary unless arguments are removed. What is not questionable is that perllib should have tests, so any breakage is auto-detected. > Currently, the only reliable way I see to access the > structure from perl is to write a bit of C code that translates it > to a format perl can read. This may be done when the C module library is established and stabilized. But then again, there is currently only problem with flags that are hard to be parsed reliably, and you want to solve this problem anyway. > > I think it is a good idea to think about the set of maybe 50 of most > > useful flags (each of one or two bits) and create such compiler > > independent two-arguments-of-32-bit compact event, similar to M_OLD_*. > > I think the right way to fix this is to define a machine > independent representation of the data that is currently sent in > ConfigWinPacket structures. I always whought it was a mistake to > just blindly export the whole window_flags structure anyway. This may be a good goal, but it requires more effort and mainainance than the intermediate solution I suggested. But I am all for the complete solution in the long run. 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]
