argb visual patch against recent cvs
Hi! The new argb visuals introduced by xorg have a serious drawback, namely, they don't work correctly unless the toplevel window has an ARGB visual. With my limited knowledge, I'd say this is a design problem within Xorg, but I seem to be alone with that notion. This means that each and every window manager needs special support just to support ARGB in client windows. Here is a small patch I wrote that implements such support for fvwm: http://data.plan9.de/fvwm-2.5-argb-visual.patch What it does is simply check wether the client window has an ARGB visual and, if yes, creates the frame window in the same visual. Nothing else should be changed by this patch. The only relevant problem I see is the detecting part, as xlib gives no indication about alpha channels (would need to use XRender just for that), so it assumes that 32 bit TrueColour means there is an alpha channel (one could check bits_per_rgb or so to be = 8, which means something weird is certainly going on, as 3*8 leave s8 bits unaccounted for). The other small uncleanlieness is the hardwired -1 for the pixel values, but that should hardly create any problems (all bits set boil down to opaque white - its not visible anyways, and is guarenteed to exist in such visuals). I was not sure what to do with the patch, I wrote it mainly for testing some things (not being a transparency geek myself), so I thought I'd send it to you to decide what to do with it :) Thanks for your attention, and thanks for maintaining fvwm2 :) -- The choice of a -==- _GNU_ ==-- _ generation Marc Lehmann ---==---(_)__ __ __ [EMAIL PROTECTED] --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE
Re: argb visual patch against recent cvs
On 2/1/06, Marc Lehmann [EMAIL PROTECTED] wrote: Hi! The new argb visuals introduced by xorg have a serious drawback, namely, they don't work correctly unless the toplevel window has an ARGB visual. With my limited knowledge, I'd say this is a design problem within Xorg, but I seem to be alone with that notion. This means that each and every window manager needs special support just to support ARGB in client windows. Here is a small patch I wrote that implements such support for fvwm: http://data.plan9.de/fvwm-2.5-argb-visual.patch What it does is simply check wether the client window has an ARGB visual and, if yes, creates the frame window in the same visual. Nothing else should be changed by this patch. The only relevant problem I see is the detecting part, as xlib gives no indication about alpha channels (would need to use XRender just for that), so it assumes that 32 bit TrueColour means there is an alpha channel (one could check bits_per_rgb or so to be = 8, which means something weird is certainly going on, as 3*8 leave s8 bits unaccounted for). The other small uncleanlieness is the hardwired -1 for the pixel values, but that should hardly create any problems (all bits set boil down to opaque white - its not visible anyways, and is guarenteed to exist in such visuals). I was not sure what to do with the patch, I wrote it mainly for testing some things (not being a transparency geek myself), so I thought I'd send it to you to decide what to do with it :) If your patch does its work, I will gladly use it :) I'm an xorg extension geek ;)
CVS domivogt: * Backed out an accidentally committed change.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt06/02/02 01:40:57 Modified files: libs : Module.c Log message: * Backed out an accidentally committed change.
Re: Module.h bug and sugestion
On Wed, Feb 01, 2006 at 02:58:27PM +, seventh guardian wrote: Hi. First of all, there's a minor bug in libs/Module.h: the funcion SendFinishedStartupNotification() is declared twice (on lines 147 and 166). With that asside, I'm writing a module for Fvwm to support the xorg's Xevie extension. I really don't like to reinvent the wheel, so I'm creating it inside the building tree, using Module.h and other helping libs. (that's the reason why I found that bug). I also found that there's a nice parsing function which is rarely used by any of the other modules, ParseModuleArgs(). Actually it is not used at all. It returns a struct with the module args, including the two communication pipes. The problem here is that the structure itself is strange to use, because the other all the other functions genericaly require a pipe array, fd*, with the first element as transmit pipe and the other as a receive. So there are two alternatives here. Um, I can't think of any function that needs a pipe array in any module or the module library. Can you give examples? Either to ALLWAYS pass them the to_fvwm pipe, which works because of their order in the struct (but makes the code a little cryptic, like Receive(to_fvwm)), There is no guarantee that this works. or to copy them to an array fd[2], which uses twice as much memory (not a real problem most of the times, but definitelly a bug). With that said, my suggestion is this: to use a struct to store the interface data (file descriptors, name, etc) and to make the functions use that struct instead of the particular elements. But ParseModuleArgs already allows this. It parses the module arguments and passes back a structure that contains the number and an array of options not yet parsed. It's easy to write more parsing functions with this information, but it's actually not a very good idea because modules should be configured by the config file, not the command line (with some exceptions). That way more helper functions would come up, such as a function that requests the config info and calls a user defined parsing function to handle the lines as they come up. Or a function to wait on the pipe for packets and also passing them to a user defined parsing function. Having a struct instead of scatered global vars makes that task easyer, as they are all passed at once inside the struct. Also, that way if someday (fvwm 3 maybe?) the module interface changes, the modules themseves woudn't need to change that much. The module packet interface changes once in a while, but I don't see the command line changing anytime soon. It woudn't be that difficult to change the current modules to use the new functions. Besides, all already compiled modules would work without any change, and unofficial ones would compile perfectly as long as they don't use the new Module.h. Also there could be an adaptation time where both libs were supplied.. Those were my thoughts. Please comment.. Streamlining the module interface code is definitely worthwhile. It's just that there are so many modules and so much work to do. The first step would be to just *use* ParseModuleArguments everywhere (without breaking all the existing code). Any further changes can be made after that. I'm open to any patches. PS: there's a real bug on top of all this text ;) Hint: Write two mails for two different topics to minimize the risk the bad issue is forgotten. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
CVS domivogt: * Removed duplicate declaration.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt06/02/02 01:39:32 Modified files: . : ChangeLog libs : Module.c Module.h Log message: * Removed duplicate declaration.
