Hello, This is about support for argb visuals in fvwm windows (decors, menus, modules, etc).
Surprisingly (or not), one can already specify that (s)he wants an ARGB visual for fvwm windows. First you have to run xdpyinfo to copy the id of the appropriate visual (tipically the last one). Then it's a matter of running "fvwm -I <vis-id>". If you're running a compositor (like xcompmgr), menus/modules with black backgrounds will appear with real full transparency!! (for window decors, it needs a slight change in the code). The problem is, there's currently no way of controlling this "power", so it ends up being useless as is. The first problem we have is that the user needs to manually specify the visual id, which changes with the xorg setup. Most users would expect some form of automatic configuration, so here are the alternatives: 1) Leave it as is (not user friendly nor portable, bad idea IMHO) 2) Provide a command line switch for argb, like "fvwm --argb" 3) Detect if the composite extension is present, and activate the argb visuals if it is. 4) Provide a config file option for argb visuals. Second, the argb visuals expect an alpha value of 0xff for fully opaque, and 0x00 for fully transparent. Most of the current code only "paints" the color values, so the alpha value ends up with 0x00, meaning full transparency. The notable exception to this problem is the font rendering, which prints as expected (fully opaque). This problem is a lot more complex, so I'll try to subdivide it. First, the rendering code needs to be revised to correctly accommodate another color channel. Our options: 1) Move away from "core X" and use XRender (IMHO the smarter change, as the it deals with these things "transparently". Some operations are server side and hw accelerated). 2) Change the current code to support another color channel, and deal with the nuances ourselves (easier on short term, but probably harder to maintain). Second, the colorset parsing needs to be revised. The severity of the revision is dependent on how we solve the previous problem. We need a way of storing the four color components. For fake transparency, we have "RootTransparent", "Transparent", and several "Tint" and "Alpha" options. When it comes to real transparency, it is a matter of using a four byte color code. I'll not provide a list of options for this one, because I don't know how to solve it.. It should be a compromise between compatibility versus simplicity... Finally, the modules need to be updated accordingly. It should be fairly easy to do once the other problems are solved. Real transparency is a feature that a lot of users would like, yet it should bring no harm for the rest. It doesn't require a high end gfx card nowadays, since most modern cards support some form of 2D acceleration. Please give me some feedback on this, as I don't want to decide this on my own. Cheers, Renato
