On Tue, Jan 22, 2002 at 04:14:14PM +0100, Olivier Chapuis wrote: > On Tue, Jan 22, 2002 at 10:44:42AM +0100, Dominik Vogt wrote: > > On Tue, Jan 22, 2002 at 09:03:16AM +0100, Olivier Chapuis wrote: > > > 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, > > > > > > > [snip] > > > > > 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". > > > > Whoa, don't overestimate the usefulness of that FvwmButtons hack. > > Setting the background of swallowed applications > > > > - is *evil* > > - rarely works > > - may screw up or even crash the application > > > > You can't even find out which window to set the background to. > > Personally, I'd not even consider making transparency of swallowed > > windows in a transparent button bar working :-) > > > > Yes agree. But It will be fine that if a FvwmButton button swallow > a _Fvwm Module_ with a transparent background (typically a FvwmPager > or an IconMan), the things work in the following sens: > 1 - Disabled the evil hack for Fvwm Module > 2 - If the background of the button change inform the swallowed modules > (by using module to fvwm2 to module communication).
Yes, I agree. That's a good thing to do. > > > 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? > > > > If the message makes sense I have no objections. To prevent that > > we run out of messages again too soon one might consider to write > > a generic message like 'MX_PROPERTY_CHANGE' with an argument like > > BG_CHANGE, FOO_CHANGE, BAR_CHANGE etc. > > Yes, good idea I will use it. > > > > 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. > > > > I guess it would be acceptable if the user has to put this > > information in the Swallow command, e.g. > > > > *FvwmButtons(Swallow (fvwmmodule) foo "exec foo") > > > > > So if a complex function is used to launch a swallowed app the > > > name of this complex function have some importance. > > > > I don't understand what you mean. > > What I mean is that with a line of the form: > > *FvwmButtons(Swallow "foo" "Module foo [xyz]") > or > *FvwmButtons(Swallow "foo" "Fvwmfoo [xyz]") > > then FvwmButtons consider that it swallow a Fvwm Module > and with a line of the form > > *FvwmButtons(Swallow "foo" "Complexfunc") > or > *FvwmButtons(Swallow "Foo" "Exec exec foo") > > then FvwmButtons consider that it swallow classical > X app. > > But of course Complexfunc can run a module and Fvwmfoo > maybe a complex function which runs a classical X app. > > In the place of the "fvwmmodule" flags for Swallow I > will prefer that FvwmButtons consider that it swallows > a Fvwm Module if the swallow command begin with "Module" > (no space at the end, no case of course). No? Okay. In addition the option I proposed won't hurt for the cases in which the module has another name (some old setups may do this with aliases) or a normal application has such a name. > But we may imagine a more complex protocol: FvwmButtons > send a message to all modules when it swallows an > application with the x-id of the swallowed window and > with the x-id the FvwmButtons, if a module recognize > itself it sends back a message with the x-id of the > FvwmButtons. > > > > 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. > > > > Fvwm does not manage swallowed windows. The window structure is > > destroyed when the window is reparented to FvwmButtons. > > Yes I know. But, of course fvwm2 still sends messages to a sawllowed > modules. Ah, yes, right. > So, it is possible that a FvwmButtons says to a module > that it is swallowed and it can send a message to this module via > fvwm2 (E.g., a MX_PROPERTY_CHANGE with SWALLOWED as argument). Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- 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]
