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:
Event is a synonym of packet from fvwm.
Event name: M_ICON_NAME
Event type (or rather mask): 1<<11
Event arguments:
win_id of type window (it is long int in C)
frame_id of type window (it is long int in C)
ptr of type number (it is pointer in C)
name of type string (variable size)
> > 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_*.
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
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]
