Window flags is the most problematic structure passed to modules. Several years ago we moved from passing one-word flags (32 bits) in M_CONFIGURE_WINDOW and M_ADD_WINDOW to the whole window_flags structure, currently 11 words! (but this depends on a compiler). Although it is easy to maintain it is not useful and portable for 2 reasons.
First, previously it was not important that modules and fvwm itself were compiled using the same compiler using the exactly same options. Moreover it was possible to run modules from other versions (compiled differently), because module protocol was not dependant on a compiler. Additionally, window_flags were available to any module, not just the ones linked with libfvwm, i.e. not just C or other compiled modules. I wanted to implement window_flags parsing (about 250 flags) in perllib, but then though it is just imposible, because (I think) even gcc stores bitfield sub-structures differently with word align option or without it, and I am not a big fun for compiling anything at the perllib build time. I think a better solution is to transmit only compiler independent arguments in the module interface. A lot of flags are pretty internal and a module should not rely on them. On the other hand there are some pretty known window flags (mostly the ones that have equivalent window commands or style options) that may be of general use, like sticky, iconified, maximized, shaded, placed_by_fvwm and so on. I am not against passing the whole window_flags (although it is big), but since they may be changed at any time relying on them in modules is bad. I want to define the most useful 32 (or 64) window flags and compose one word from them, similarly to what we do with M_OLD_CONFIGURE_WINDOW now. What do you think should be the most useful window flags? I guess, ewmh flags should be included otherwise ewmh arguments passed in the same packet would be not very useful. Probably the user defined states (32) should be transmitted in another word too. Any thoughts? 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]
