On Sun, Jul 11, 2004 at 10:47:28AM +0000, Mikhael Goikhman wrote: > On 11 Jul 2004 02:46:50 +0200, Dominik Vogt wrote: > > > > On Sat, Jul 10, 2004 at 12:42:52AM +0000, Mikhael Goikhman wrote: > > > At least one change (order of arguments in CONFIGURE_WINDOW) is bad. > > > The flags are of the variable size and thus should be last. > > > > I can change that. But why are the flags "variable size"? > > How can you know in advance the number of bytes flags occupies? You can > know in advance sizeof(long int) on that platform, but not sizeof(flags). > Of course, if we only speak about C-modules compiled together with fvwm, > this does not matter. But other modules should at least get other > fixed-size event arguments correctly. > > In the similar way, all name arguments in window/icon name events are of > the variable size and thus should be last. There is one difference, you > can calculate the size of flags in compile time, but you can't calculate > the size of window names at compile time. Still for modules in pure perl > there is no such difference. > > > > 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. 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. [snip] > > > BTW, I am really unhappy with the new flags method that is pretty much > > > C-only. Modules that can't embed the .h data structure simply can't use > > > window flags. The old method with positioned word-based properties rather > > > than compiler dependent bit-based flags was more robust. > > > > Yes, the compiler dependent structure layout is a bad idea. One > > should never map C structures to the network. > > > > > Currently a > > > module should be in C and should be compiled by the same compiler with > > > the same options, otherwise it may not get window flags correctly... > > > I don't have a good solution here. > > Although I didn't actually use M_OLD_ADD_WINDOW/M_OLD_CONFIGURE_WINDOW, > I think I could use them to obtain certain flags. > > Did you remove them because you need more event slots? > There are plenty of MX_*. The M_OLD_..._WINDOW code has been commented out for years. All I did was to remove the dead code. > 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_*. > > And BTW, perllib does not currently support 64 bits platforms, because > I have neither LLP64 nor LP64 nor ILP64 platforms to test the fix. > See this url for the C type table: > > http://yarchive.net/comp/longlong.html 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. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED]
pgp1iCejN61J6.pgp
Description: PGP signature
