On Wed, Jan 23, 2002 at 02:07:33PM +0000, Tim Phipps wrote: > I sent this direct to Olivier, here it is to the mailing list. > > [EMAIL PROTECTED] wrote: > >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". > > Why not wait until the WindowStyle command is implemented and then have > the module send "WindowId xxx WindowStyle ParentRelative On" ? >
Yes, but the question is: when the new WindowStyle command will appear? Moreover, it will be not difficult to change "ParentRelative On/Off" to "WindowId xxx WindowStyle ParentRelative On/Off" when the WindowStyle command will be available (the ParentRelative command will not be documented as the Colorset command). I promise that I will do the change (if I implement this automatic configuration). > >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? > > > The only thing a transparent window needs to do when the root window > changes is a refresh. Why not have FvwmButtons do a refresh on each > swallowed window if the button that holds the window is transparent? > > // end of resend // > > On playing a bit with this I think the correct way to handle transparent > colorsets and the root window changinf is for FvwmTheme to look for changes > to the root window and for it to resend the Colorset command to fvwm. > > The following line in FvwmConsole fixes up all the transparent modules > with a background change: > > sendtomodule FvwmTheme Colorset 0 transparent > > Obviously this only works with colorset 0 being transparent and FvwmTheme > should do the necessary for each colorset with a transparent background. > > I don't think there is any need to have any code in the modules to handle root > changes, they all already have code to cope with colorset changes so let's use > that mechanism. > Yes, maybe. I see __small__ problems with this: 1) At present time FvwmTheme has no XEvent loop and it is planed to move FvwmTheme into fvwm2 (this does not mean that FvwmTheme will effectively go into fvwm2). In any case, I think that it is better that fvwm2 monitor background change (and fvwm2 can broadcast the transparent colorsets). 2) Say that you have a FvwmButtons which swallow a transparent fvwm module under a button with an not transparent colorset xx. If colorset xx change the mechanism you propose will not work. So in any case a message mechanism is needed. Ok, this does not contradict your proposition. But when the root background change the swallowed module will receive and process an unuseful Colorset config info. With the message mechanism the swallowed module will know that it is swallowed and will ignore background change messages. Ok, you may say that if the module can know that it swallowed then it can ignore a transparent colorset message if this colorset is already transparent. I do not think this is a good idea. So, I think that a new message mechanism is needed to really handle the ParentRelative colorset (message should also be used when a transparent FvwmButtons is moved and have a transparent swallowed fvwm module, at present time FvwmButtons send an XEvent to the swallowed modules, I think this is bad). Finally, as a new message mechanism is needed I think that centralizing all the background change in this mechanism is better than using a short cut for root background change. IMHO this will give a more clear "code". Yes, all this is complicate. But, it is the price to pay with parental relativity to implement transparency in the place of the "Esetroot" method which has some advantages and disadvantages and which gives an other notion of transparency: with parental relativity the "layer" between windows is taken in account as with the Esetroot method transparency means root transparency. Maybe one days we would like to implement such transparency (and close a transparent bug report on transparent IconMan buttons). The good news here is that the XFree XRender extension will support "real" transparency in the future (Keith Packard says that we have to wait one or two years). BTW, I've tried to mix parental relativity and XRender to have shaded and tinted transparency (this was suggested by Sasha Vasko from AfterSetp in the wm-spec mailing list). This work very well until you begin to opaque move or resize, shade or maximize the window (it seems that it is impossible to reduce the number of redraw to a reasonable number, e.g., I can _see_ 3 redraws after maximizing such a window). Regards, 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]
