On Mon, Jan 21, 2002 at 04:14:17PM +0100, Dominik Vogt wrote: > On Mon, Jan 21, 2002 at 03:07:55PM +0100, Olivier Chapuis wrote: > > Hello, > > > > I hope that the Transparent colorset for top level background > > work fine now for all modules but for FvwmWharf (a lot of > > changes is needed here and there is FvwmButtons if one want > > transparency). > > > > Of course so that Transparency works the module must have the > > ParentalRelativity Style. I think it will be good that if > > a module has a Transparent colorset background then fvwm2 > > sets automatically this style to the module and unset this > > style if the colorset is no more transparent (the > > WindowShadeShrinks style may be toggled too). This is more > > in the spirit of FvwmThemes than using a Style command > > after a colorset change. > > One solution is to add an FVWM extension to the wm-spec: > > we can add a new state FVWM_NET_WM_STATE_PARENT_RELATIVE. > > Monitoring this state will allow to automatically sets > > the good styles. Is there any objection for this method? > > Wouldn't it be better to keep that functionality inside fvwm for > now and not export properties to the world? This could be done > with a style: > > SendToModule FvwmTheme ... > Style FvwmButtons ParentRelativeFrameBackground >
I am afraid to do not understand. what I would like to implement is automatic configuration. An alternative to atom is a new (undocumented) _command_, say, ParentRelative. If a module has a transparent background then it send to fvwm2 "ParentRelative On" to force the ParentalRelativity and WindowShadeShrinks styles. If the colorset change and the background become non transparent the modules then send "ParentRelative Off". > > An other problem is transparent modules swallowed into > > a transparent or not FvwmButtons, there are currently > > some problems when the colorsets of the FvwmButtons change. A solution here, is again a new command similar to Colorset. When a FvwmButton change the background of a swallowed window with X-id ID (and if the swallowed app is an Fvwm module, see the next paragraph) it can send the command "BackgroundChange". Then fvwm2 will send the string "ROOT_BG_CHANGE_STRING ID" to modules and the module with X-id ID may be able to update its background if it is transparent (fvwm2 already send "ROOT_BG_CHANGE_STRING" when fvwm2 detects that the root background change). BTW, it will be maybe better to send a MX_ROOT_BG_CHANGE message as we have now some places? Also it will be useful for FvwmButtons to know if the swallowed window is a FVWM Module or a normal X application. The only solution I see is to claim in the FvwmButtons man page that if the swallow command begin with Fvwm or Module then FvwmButtons will consider that it will swallow a Fvwm module. So if a complex function is used to launch a swallowed app the name of this complex function have some importance. Is this acceptable? Maybe, in the place of "BackgroundChange" we may use a command as "SwallowedConfigure id [bg_ch ...other options in the future]", which will force fvwm to send a MX_SWALLOWED_CONFIGURE message. Olivier -- 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]
