On Sat, Feb 09, 2008 at 11:01:15PM +0000, seventh guardian wrote: > 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.
I don't understand what this means practically. > 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). I don't think we'll ever be able to implement (2) properly. Even if we do we need to always remember the fourth colour channel in the future. Even if it's doable it would result in unmaintainable code. > 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. I don't think general transparency (for any window) sould be added to fvwm directly. The transparency stuff we have now is limited to fvwm internal colour sets and modules, and honouring the ParentRelative attribute. If adding argb visuals is much more complex that this, I'd prefer to not implement it. Transparency could easily be handled by a third party tool (no idea if such a tool exists) with support from the X server. All fvwm would have to tell the tool is the window id and the alpha value. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
