Subject: Remaining issues in Transparency

From: Olivier Chapuis <[email-masked]>
Date: Mon, 21 Jan 2002 15:07:55 +0100

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?

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.
The FVWM_NET_WM_STATE_PARENT_RELATIVE properties may help
here too for fvwm modules. But I've no precise idea of how
to fix this problem yet.

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-masked].
To report problems, send mail to [email-masked]

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 21 Jan 2002 16:14:17 +0100

> 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

> here too for fvwm modules. But I've no precise idea of how

Bye

Dominik ^_^  ^_^

-- 
Dominik Vogt, email: [email-masked]
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-masked].
To report problems, send mail to [email-masked]

---

From: Olivier Chapuis <[email-masked]>
Date: Tue, 22 Jan 2002 09:03:16 +0100

>   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".

> > 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

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 22 Jan 2002 10:44:42 +0100

> background become non transparent the modules then send

Okay, a (module) command then.  I didn't give it too much though.
I just don't like the idea of exporting such information to the
world that anybody might use and then complain if we change it
some day.

> 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 :-)

> 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.
 
> 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.

> Is this acceptable?

> 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.

Bye

Dominik ^_^  ^_^

---

From: Olivier Chapuis <[email-masked]>
Date: Tue, 22 Jan 2002 16:14:14 +0100

On Tue, Jan 22, 2002 at 10:44:42AM +0100, Dominik Vogt wrote:
> [snip]

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).
 
> BG_CHANGE, FOO_CHANGE, BAR_CHANGE etc.

Yes, good idea I will use it.

> 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.

> 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

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 22 Jan 2002 17:19:02 +0100

>     (by using module to fvwm2 to module communication).

Yes, I agree.  That's a good thing to do.

> (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.

> modules.

Ah, yes, right.

> So, it is possible that a FvwmButtons says to a module

Bye

Dominik ^_^  ^_^

---

From: Tim Phipps <[email-masked]>
Date: Wed, 23 Jan 2002 14:07:33 +0000

I sent this direct to Olivier, here it is to the mailing list.

> background become non transparent the modules then send
 
Why not wait until the WindowStyle command is implemented and then have

the module send "WindowId xxx WindowStyle ParentRelative On" ?
 
> 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.

Cheers,
Tim.

---

From: Olivier Chapuis <[email-masked]>
Date: Wed, 23 Jan 2002 18:10:31 +0100

> 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).
 
> changes, they all already have code to cope with colorset changes so let's use

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