On Thu, Mar 27, 2008 at 9:50 PM, julio teca <[EMAIL PROTECTED]> wrote: > > > Renato, thank you for your answer. > > It's more or less what I supposed. Are all the modules affected, or is this > a particular > aspect of FvwmButtons?
All modules. It's pretty simple actually, all fvwm windows are not transparent. Meaning that if you put some transparent window inside an opaque window, you'll not see the desktop, but the window underneath. To be able to see the desktop you'd need for the "container" window to also be transparent. > I can run the clocks, and place them with "Next", and "Move", but I prefer > to control > my widgets through FvwmButtons. It's easier to control the number of > instances > running, and it's by far more elegant. I could modify the code of > cairo-clock, but > I believe that it would be nonsense. Could you provide me information about > the management of argb within fvwm? Currently fvwm uses the root window visual for everything. This visual is selected from xorg.conf, or you can specify it with a command line option to fvwm. Fvwm uses this visual as the default for every window it creates. When a program creates a window, that window is swallowed by a fvwm "container" window, which also swallows the various decoration windows (the title bar, handles, etc). Normally this container window is not visible, because every child window is opaque. The problem is, if you swallow a transparent window, the container will show through.. There was a patch submitted recently that selects an argb visual for the container window so that it is transparent when the app window also is. For FvwmButtons you would need to do the same thing. IMHO this is a hack, because fvwm itself should be fully argb compatible. The problem is that the change is really complex, as fvwm code is not that modular. So it is acceptable to use these hacks. I'm slowly trying to make the change, but I'm currently stuck with the image loaders... Cheers, Renato
