On Wed, Jul 09, 2003 at 07:46:05AM +0200, Olivier Chapuis wrote:
> On Tue, Jul 08, 2003 at 08:55:37AM +0200, Dominik Vogt wrote:
[snip]
> >From the ewmh spec:
>
> _NET_WM_STATE_FULLSCREEN indicate that the window should fill the entire
> screen and have no window decoration.
>
> Also there are stacking order recommendation in the ewmh spec. At present
> time fvwm respect this recommendation only if the EWMHUseStackingOrderHints
> style is used (off by default). The recommendation is:
>
> - window with _NET_WM_STATE_BELOW
> - normal window
> - panel/dock apps (_NET_WM_TYPE_DOCK) without _NET_WM_STATE_BELOW
> - FULLSCREEN window with the _focus_
I think you know my opinion about the recommendations made by the
EWMH :-) It's a license to annoy the users. In my eyes, defining
policy in the spec is stupid.
> Regarding this there is two types of user. Those who want its
> "panel" (or main Buttons or TaskBar) on top and those who want
> its "panel" put (like me and you dominik I think). The first type
> of users will want fullscreen window on top, the others will want
> fullscreen window put.
> I do not want to consider the _focus_ condition (but this can be
> implemented with WindowStyle + FvwmEvent and a FullScreen condition).
> So a reasonable alternative is to use the same layer than the "panel"
> for fullscreen window.
>
> So my suggestion is to add a new fvwm command
>
> --
> FullScreen [flags] [bool]
>
> Without its optional arguments (or if the bool bit has the value
> "toggle") FullScreen causes the window to alternately switch from
> a full-screen size without decoration to its normal size with its
> normal decoration. To force a window into full-screen (normal) state
> you can use a "True" or "False" value for the bool argument.
>
> The optional flags argument is a space separated list containing the
> following key words: ewmh, layer x, ontop, decoration,
> size_override. These options are useful only when the window switch to
> full-screen and the possible effect caused by these options are
> discarded when the window switch back to its normal size. layer x put
> the fullscreen window into layer x, ontop put the fullscreen window
> into the StaysOnTop layer, ewmh put the fullscreen window into the
> StaysOnTop layer only if the window has the EWMHUseStackingOrderHints
> style, decoration forces to do not remove the window decoration. A
> full-screen window may not be resized to the full size of the screen,
> because a window may require some specific sizes. The size_override
> key word forces screen full size.
> --
>
> Of course as we are in feature freeze it is may be not reasonable
> to add this command??
>
> Then, we add default functions
>
> EWMHFullScreenOn I FullScreen ewmh True
>
> EWMHFullScreenOff I FullScreen False
>
> that the user can redefine.
> If we do not add such a command I think we should leave the code
> at is now (decoration off screen!?) or we need to add new variables
> as explained in 3) to be able to define EWMHFullScreen{On,Off}.
Not for 2.6. It is way too complex and error prone.
> By the way, Dominik if I well understand your last mail in
> the "StyleById patch voting thread" thread, the addition of the
> WindowStyle command will not have grave consequence?
It already had the consequence that I no longer care about the
feature freeze. Does that qualify for 'grave'? And I made it
clear several times that I think adding a new command is a mistake
(see somewhere above in this thread for an example).
Bye
Dominik ^_^ ^_^
--
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]
