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).
> > 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?
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. 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).
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]
