Subject: Move/Resize ConfigureRequest

From: Olivier Chapuis <[email-masked]>
Date: Thu, 3 Jul 2003 08:12:29 +0200

Hello,

Ok, this subject is delicate ...

Examples of pb:

- Start Mozilla, say that its position is +x+y. Set fullscreen (F11),
if you have a not too recent version of Mozilla this works (with
Mozilla-1.4 and maybe other this does not work as Mozilla use
NET_WM_FULLSCREEN which is not implemented in fvwm (this not the point
of this email). Reset to normal state (F11). Then, either Mozilla
crash or the Mozilla window totally disappear (strange) or the new
window position is
          +(x-"left_frame_width")+(y-"top_frame_height")

- Other Mozilla pbs: resizing the window with the internal Mozilla
resize grip.

- Tk experience:
[olivier@snoopy olivier]$ wish
% wm geometry . +0+0

The top-left part of the frame is out of screen

- This problem will happen with any QT, GTK, JAVA and Tk application
which "move-resize" itself (after mapping).

All this applications are not buggy! They all respect the ICCCM2 (or
at least a really reasonable interpretation of the ICCCM2).  Note that
most of the actively developed window manager respect this (e.g.,
icewm, kwin and metacity). Also this is documented in the EWMH spec.

Of course fvwm no that, however it use a legacy way to move-resize
a window because some "old" apps use this legacy logic (sorry I've no
example, but Dominik has surely some).

I suggest that we add a new style:

LegacyConfigureRequest / ICCCMConfigureRequest

or 

ICCCMConfigureRequest / LegacyConfigureRequest

to handle this problem. About default we can do something a bit more
complex: detect if the app respect the EWMH spec, if yes use
ICCCMConfigureRequest if not use LegacyConfigureRequest. However, I
think we need a new style (as there is no standard way to detect
that an application respect the EWMH spec).

Any opinions/comments/objections?

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

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 3 Jul 2003 10:14:31 +0200

>           +(x-"left_frame_width")+(y-"top_frame_height")

Yes, I noticed some of these problems too.  Yesterday I found two
download windows I had shaded on the right side of page (0 1) in
the middle of page (1 2).  I still have to find a way to reproduce
this, but chances are good that mozilla is doing something funny.

> - Other Mozilla pbs: resizing the window with the internal Mozilla

Mine doesn't have a resize grip.

> example, but Dominik has surely some).

See the endless discussions I had on the wm-spec list.  The bottom
line of them always was that nobody of the people there cares a
bit about the traditional way vs. the spec conforming way of
handling configure requests.  Thus, even with the latest EWMH
spec, manual user intervention is required to configure some
applications :-(

> ICCCMConfigureRequest if not use LegacyConfigureRequest.

Yeah, but the wm-spec folks can't agree on a protocol for this :-P
In addition, it would be really helpful to have a standard way of
advertising which method the WM uses in order to allow
applications to detect it themselves.  This would fix most of the
notorious Java... problems with fvwm.

> However, I think we need a new style (as there is no standard
> way to detect that an application respect the EWMH spec).

Having a style is not wrong anyway.

> Any opinions/comments/objections?

For a detection algorithm:

  1) If the windows CR algorithm was set by a style or detected
     before, use it.

  2) If a window resizes itself to the *exact* size of the
     display and the requested position of the client window is
     either +0+0 or +border_width+border_height, put it at +0+0
     and make a decision about the algorithm it uses based on the
     requested position.

  3) If a window resizes/positions itself so that interpreting its
     position would shift it by exactly the width/height of the
     left or top border, set the algorithm that would prevent this
     shift (if possible).

  4) If a window places itself in a way that would place it
     exaclty on the border of the display, choose the algorithm
     that keeps the border on screen.

So we should have three styles (I don't like the term "legacy"
because it displays a certain arrogance of the wm-spec people
against tradition):

  MoveByProgramAlgorithm [SmartTraditional|SmartICCCM|ICCCM|Traditional]

with "SmartTraditional" being the default (i.e. use above
algorithm and use "Traditional" by default).  However, the names
of the styles are all bad (hard too understand).

Bye

Dominik ^_^  ^_^

---

From: Kingsly John <[email-masked]>
Date: Fri, 4 Jul 2003 00:11:09 +0530

+++ Olivier Chapuis [2003-07-03 08:12:29]:

> of this email). 

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030701 It still
manages to goto full-screen without any problems!

> - Other Mozilla pbs: resizing the window with the internal Mozilla

I think the resize grip only comes with certain themes for the gtk2 builds...
I remember seeing this kind of resizing when we had a demo of Gnome2 at my
LUG... was supposed to be some kind of feature introduced in Gnome2. 

I found a similiar resize-grip in nautilus... it manages to get the window
into resize mode... maybe mozilla is doing something different.

BTW is it possible that the problem with the resize grip and the window
shifting when coming back from full-screen are related... I seem to find the
mozilla window drifting towards the top-left corner when trying to resize ..
seems to be moving in a similiar ratio too (I didn't measure too carefully)

Kingsly

---

From: Dan Espen <[email-masked]>
Date: Thu, 03 Jul 2003 15:03:38 -0400

> LUG... was supposed to be some kind of feature introduced in Gnome2. 

I don't think I have Gtk2 on my machine.
I don't see the resize handle with the Classic theme,
but it is there with Modern.

-- 
Dan Espen                           E-mail: [email-masked]

---

From: parv <[email-masked]>
Date: Thu, 3 Jul 2003 16:22:01 -0400

in message <[email-masked]>, wrote Kingsly
John thusly...
>
> > - Start Mozilla, say that its position is +x+y. Set fullscreen
> > (F11), if you have a not too recent version of Mozilla this
> > works (with Mozilla-1.4 and maybe other this does not work as
> > Mozilla use NET_WM_FULLSCREEN which is not implemented in fvwm
> > (this not the point of this email). 
> 
> Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030701 It
> still manages to goto full-screen without any problems!

I don't know which version of mozilla that Gecko corresponds to, but
i have the same experience.

Using the "grip" in 1.4b version (to resize a window, "modern"
theme) makes the the mozilla window to dance around, which was not
the case in version 1.3-something.  (The "grip" thingy, in  the
lower right corner, seemed to be introduced in version 1.4b for
"modern" theme only.)

Also in version 1.4b, mozilla doesn't go full screen as it did
previously.  Now it just hides various bars and uses miniature
buttons w/ the same full screen window size as it was before going
full screen.

(I am using fvwm 2.5.6.)

  - Parv

-- 
A programmer, budding Unix system administrator, and amateur photographer
ISO employment...

  http://www103.pair.com/parv/work/

---

From: Olivier Chapuis <[email-masked]>
Date: Fri, 4 Jul 2003 07:21:58 +0200

>      and make a decision about the algorithm it uses based on the

I am not sure to understand this one, can you be more precise?
 
>      that keeps the border on screen.

I will add: if the window has _NET_WM_PID set use the ICCCM algo.

> of the styles are all bad (hard too understand).

I think that we cannot found good names here.

Regards, Olivier

---

From: Kingsly John <[email-masked]>
Date: Fri, 4 Jul 2003 11:40:16 +0530

> i have the same experience.

That's Mozilla 1.4(latest stable release)

> lower right corner, seemed to be introduced in version 1.4b for

It's been there from before 1.4b.. (I've used atleast 2 builds which had the
grip thingie.)

> buttons w/ the same full screen window size as it was before going

This is what moz 1.4 looks like after I hit F11 ...

http://kingsly.net/mozfull.jpg

info fromthe xwd file before conversion to jpeg.

mozfull.xwd: XWD X-Windows Dump image data, "The Official FVWM Home Page -
M", 1280x1024x24

My X runs at the same resolution too.. so it is going full screen!
> (I am using fvwm 2.5.6.)

I'm using 2.5.7

Kingsly

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 4 Jul 2003 10:14:28 +0200

> I am not sure to understand this one, can you be more precise?

I.e., if the window attempts to become full screen, check whether
it took the border size into account or not.

Bye

Dominik ^_^  ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 4 Jul 2003 10:19:57 +0200

> buttons w/ the same full screen window size as it was before going

I think that is because Mozilla assumes that if a wm implements
the EWMH spec, it also supports _NET_WM_STATE_FULLSCREEN.  This is
not true for fvwm.

Bye

Dominik ^_^  ^_^

---

From: [email-masked]
Date: Sat, 5 Jul 2003 22:15:25 +0200

> I think that we cannot found good names here.

I have mostly completed and applied the patch.  Still missing:

 * The window styles (although the members of the window_style
   structure are already defined).
 * Handling changes in update.c.
 * Write man page.
 * Check for _NET_WM_PID.
 * Test the patch.  I have only tried Mozilla yet.

Bye

Dominik ^_^  ^_^

 --
Dominik Vogt, [email-masked]
Reply-To: [email-masked]
--
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: Sun, 6 Jul 2003 07:24:33 +0200

>  * Handling changes in update.c.

I can do that if you want ... as I have also write down a patch
(partial) too!

>  * Check for _NET_WM_PID.

Seems you do that.

>  * Test the patch.  I have only tried Mozilla yet.

Make some test with Tk it is ok.

With mozilla-1.1 when I press F11 to go to fullscreen and go back to
normal stat (F11) my mozilla window totally disappear (probably a
mozilla bug).

With mozilla-1.4 (no fullscreen) when I use the resize grip mozilla
do not go up and up anymore, however resizing is a bit erratic (probably
bad interaction with the inc hints ...).

By the way, should we implement _NET_WM_STATE_FULLSCREEN?
Also you just wrote all the code for _NET_MOVERESIZE_WINDOW but
the trivial stuff in fvwm/ewmh*

Regards, Olivier

---

From: [email-masked]
Date: Sun, 6 Jul 2003 14:12:54 +0200

> I can do that if you want ... as I have also write down a patch

I'm already on the job - I'm getting nervous with a half finished
patch in cvs :-)

> Seems you do that.

Actually, I have difficulties to understand the design of the
ewmh_...c files.  I understand there are properties that are

 * set once on the root window at fvwm startup
 * set on the root window but updated regularly
 * set by fvwm on application windows (?)
 * set by once applications on their windows when mapped
 * set by apps on their window and updated later (?)
 * client messages from apps to fvwm
 * client messages from fvwm to client windows.

Where is this all located in the code and how does it correspond
to the nine atom lists in ewmh.c?  What is the idea behind these
lists and how are they handled.  E.g., are the atoms in the lists
detected automatically?

> Make some test with Tk it is ok.

I have written a small testing app and found a lot of bugs that
are all fixed now.  Can you check with Tk, please?  If anything
strange happens give instructions to reproduce and post the
console output.

The seven detection methods are:

  - _NET_WM_PID (dould not find an application that sets it)
  - full screen detection (icccm)
  - full screen detection (traditional)
  - moving window adjacent to a border (icccm)
  - moving window adjacent to a border (traditional)
  - moving window by the border width/height (icccm) while it
    would stay in the same placew with the traditional method.
  - same for traditional

I did not test the _NET_WM_PID detection yet.

> By the way, should we implement _NET_WM_STATE_FULLSCREEN?

Yes.  I'd like to do it myself to gather some experience with the
ewmh code.

> the trivial stuff in fvwm/ewmh*

Yes, I think so.  The logic in the __cr_get_grav_position()
function should return the requested frame position.  It needs
some work on the interface, though.

Bye

Dominik ^_^  ^_^

---

From: [email-masked]
Date: Sun, 6 Jul 2003 21:12:13 +0200

> I'm already on the job - I'm getting nervous with a half finished

Done.  The new style is named MoveWindowByProgramMethod :-P

Bye

Dominik ^_^  ^_^

---

From: Olivier Chapuis <[email-masked]>
Date: Mon, 7 Jul 2003 09:09:42 +0200

On Sun, Jul 06, 2003 at 02:12:54PM +0200, [email-masked] wrote:
> to the nine atom lists in ewmh.c?

The logic in the lists splitting is a bit different. There are
comments which explain this logic where there are defined. Basically,
atoms in a given list are handled in the same way by the code. The
code is maybe a bit difficult to understand at first reading but it is
easy to add new EWMH stuff as a lot of things are done automatically:
_basically_ add an atom in a list with a function handler and you have
done.

Note that the signification of an atom can depends on how it is used.
For, example the atoms in the EWMH_ATOM_LIST_WM_STATE can be received
by fvwm as a client message (send by any application) to ask a state
change.  Secondly, the wm must set the _NET_WM_STATE on an application
window with the atoms of the EWMH_ATOM_LIST_WM_STATE accordingly with
the state of the window. Finally, a window can map with a
_NET_WM_STATE set on it to indicate a desired mapping state. It is
useful to have such a list for automatic handling of these 3
situations via the functions handler of the list. These functions
should handle 3 different situations:

- Client msg (ev != NULL && style == NULL)
- Initial Mapping with the state set (ev == NULL && style != NULL).
  Note the additional arg "any" (== has_hint) for recapture and
  restarting.
- Query of the state (ev == NULL && style == NULL) 

> What is the idea behind these

Yes. For example to add a _NET_WM_STATE add it to the
EWMH_ATOM_LIST_WM_STATE list (in alphabetic order) and write down the
function handler (all the other stuff is done automatically: client
msg detection, initial mapping checking, state query for
_NET_WM_STATE, addition in the list of supported _NET stuff).

I will add more comment in ewmh code, but the list name and the
functions handler name can be used to know where a given EWMH property
is handled. 

> strange happens give instructions to reproduce and post the

Ok.

> I did not test the _NET_WM_PID detection yet.

It seems to work as mozilla set it and the good algo is choosen.
(All KDE >= 2 and GNOME2 apps set this prop).

> Yes.  I'd like to do it myself to gather some experience with the

It seems that this start to work. But what about a FullScreen command
which removes the decoration, MoveResize the window to the size
of the screen and possibly put the window in a given layer:

FullScreen [bool] [StayOnTop|layer x y] [size_hint_override]

then we define defaults fvwm func:

AddToFunc EWMHFullScreenOn I FullScreen On
AddToFunc EWMHFullScreenOff I FullScreen Off

which are called when needed by the ewmh code. 

> some work on the interface, though.

What about building a ConfigureRequest event and send it to the
"events code" with an override_gravity arg (which forces icccm
motion algo and use the override_gravity gravity in the place
of the app gravity)?

Regards, Olivier

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 7 Jul 2003 09:37:54 +0200

> which are called when needed by the ewmh code. 

I'd prefer doing this via a function.  We have way too many move/
resize/maximize functions already.  The new ewmh code calls the
ResizeMoveMaximize command.

> motion algo and use the override_gravity gravity in the place

Thath's what I thought about.  To keep the code clean, the gravity
should be passed in through the argument list, as opposed to
temporarily modifying the fw->hints.win_gravity field.  And it
should be safe to assume that an application using this protocol
uses the ICCCM conformant way of specifying its position in
ConfigureRequests.

Bye

Dominik ^_^  ^_^

---

From: Olivier Chapuis <[email-masked]>
Date: Tue, 8 Jul 2003 08:12:18 +0200

> ResizeMoveMaximize command.

Yes. But I do not see how to restore the "initial" window state
without a designed command (or an new Maximize flags) for fullscreen:

AddToFunc EWMHFullScreenOn
+ I WindowStyle !Borders, !Title
+ I WindowStyle StaysOnTop
+ I Maximize ewmhiwa 100 100

AddToFunc EWMHFullScreenOff
+ I WindowStyle Borders, Title
+ I WindowStyle StaysPut
+ I Maximize off

works well only on decorated stays put window. 

Regards, Olivier

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 8 Jul 2003 08:31:49 +0200

> works well only on decorated stays put window. 

Again - use the ResizeMoveMaximize command.  It does all you need
at the same time.  I see no need to remove the window decorations.
Moving them off screen should suffice.

Bye

Dominik ^_^  ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 8 Jul 2003 08:55:37 +0200

> works well only on decorated stays put window. 

A more detailed reply.  I should have read more carefully.

 1) I think fiddling with the window's decorations and layer is a
    bad idea.  If the application wants the window on a specific
    layer it can use the layer protocol.

 2) The StaysOnTop style is used only for new windows.  The Layer
     command must be used for existing windows.

Without these two, restoring the initial state is trivial.

 3) And finally, I noticed that certain information about the
    window is not accessible from functions.  To allow placing the
    window with ResizeMoveMaximize we need:  the size of the
    window decorations on the top and left sides and the geometry
    of its Xinerama screen.  This can be done with a couple of new
    variables:

    Border width + title thickness:

     $[w.decorsize.left]
     $[w.decorsize.right]
     $[w.decorsize.width]   # sum of last two
     $[w.decorsize.top]
     $[w.decorsize.bottom]
     $[w.decorsize.height]  # sum ov last two

    Only title geometry:

     $[w.title.thickness]
     $[w.title.direction]

    Only border geometry:

     $[w.bordersize.left]
     $[w.bordersize.right]
     $[w.bordersize.top]
     $[w.bordersize.bottom]

    Screen related:

     $[w.screen] # Xinerama screen number
     $[scr.x.<screen #>]
     $[scr.y.<screen #>]
     $[scr.width.<screen #>]
     $[scr.height.<screen #>]

Phew, that's a whole lot of new code.

Bye

Dominik ^_^  ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 8 Jul 2003 09:19:26 +0200

> > > > But what about a FullScreen command

Oh well, I'm a bit slow today.  You meant a command that is called
by the user, not one to be called from the
_NET_WM_STATE_FULLSCREEN code, right?  As you said, it can't be
implemented in 2.6 because you can not find out the initial style
and state of the window.  For 3.0 I want to have more flexible
style parsing:

 - The setting for every style can be queried by a variable, e.g.

     $[w.style.StaysOnTop]   -> true/false
     $[w.style.HandleWidth]  -> <integer>
     $[w.style.TitleAtLeft]  -> true/false

 - For every style, an option that can be passed to a style
   command can be generated:

     $[w.styleoption.StaysOnTop] -> <nil>/Layer <n>
     $[w.styleoption.HandleWidth] -> <nil>/HandleWidth <n>
     $[w.styleoption.TitleAtLeft] -> <nil>/TitleAt{Top,Left,Right,Bottom}

 - Similar interface for querying styles by pattern.

 - Using style options in conditions, e.g.

     Next (TitleAtLeft, HandleWidth 0) WindowShade

But I don't see this in 2.6.

Bye

Dominik ^_^  ^_^

---

From: Mikhael Goikhman <[email-masked]>
Date: Tue, 8 Jul 2003 16:53:48 +0000

> Moving them off screen should suffice.

FullScreen should remove decorations, at least this is what a user
expects. A window in the full screen mode should occupy only one page.
A window occupying 9 pages (ResizeMoveMaximize) causes several problems.

fvwm-themes has MaximizeFullScreen functions similar to the ones above
for some years. Of course it uses Style $n to remove decorations,
so there are often glitches (unrelated windows loosing decorations).
The proper way to do this is using WindowStyle, not Style $n, of course.
There are several other things in fvwm-themes that require WindowStyle.

As for me, restoring the initial values of the layer and decorations is
a bonus, but not very important, the functions similar to the ones above
may be enough until 3.0. What is more important for 2.6 is WindowStyle.
So a user has a full control on his windows individually, something that
is possible in most of the other window managers.

Returning to this thread, it is nice that we support both application
move methods now. Nice work, Dominik.

Regards,
Mikhael.

---

From: Mikhael Goikhman <[email-masked]>
Date: Tue, 8 Jul 2003 16:57:37 +0000

> Done.  The new style is named MoveWindowByProgramMethod :-P

Some shorter (and I hope understandable) suggestions:
MoveByProgramMethod, ProgrammaticMoveMethod.

Regards,
Mikhael.

---

From: parv <[email-masked]>
Date: Tue, 8 Jul 2003 15:26:28 -0400

in message <[email-masked]>,
wrote Mikhael Goikhman thusly...
> expects.

This user does not.

I would like to have the fvwm decorations retained on
windows/programs that (try) to go full-screen by their own mechanism
(say mozilla) ... unless that is against some spec.  If fvwm's idea
of full-screen is different than the client, i would like to have
some control on the fvwm aspect.

(FWIW, i just tried acrobat 5.06; decorations are retained but title
bar is moved outside of current view.)

  - Parv

---

From: Mikhael Goikhman <[email-masked]>
Date: Tue, 8 Jul 2003 20:57:43 +0000

> bar is moved outside of current view.)

We speak about functions posted by Olivier, if you need decorations that
are out of the screen and unaccessible, define these functions
differently. Or maybe just don't request windows to go full-screen.

Removing decorations should be at least an option if not the default.
There are several problems in a window occupying 9 pages. For example: a
window looks a bit strange in a pager; 2 full-screen windows on different
pages overlap each other, without decorations they would not conflict;
when you shade such window it ends up mostly in the different page;
conditions Visible and CurrentPage work on 9 pages for such window
although a user intended a window to maximized on one page only; there is
also a Xinerama related issue:

  http://mail.gnome.org/archives/wm-spec-list/2003-March/msg00062.html

I may continue this list, for example if full-screen window has
decorations, it is not clear whether to start to count WarpToWindow from
decorations or from a window, either way may be problematic, currently it
counts from a client window with maximized mozilla, if full-screen window
has no decorations there is no such problem.

Again, removing decorations should not be forced, but at least allowed.

Regards,
Mikhael.

---

From: [email-masked]
Date: Tue, 8 Jul 2003 22:45:31 +0200

> MoveByProgramMethod, ProgrammaticMoveMethod.

The first one is fine.  I don't like the second suggestion because
the style name does not begin with "Move".

Bye

Dominik ^_^  ^_^

---

From: [email-masked]
Date: Tue, 8 Jul 2003 23:15:06 +0200

> FullScreen should remove decorations, at least this is what a user

I agree with parv that this should *at least* be configurable.
Moving the title bar off screen or even disabling it completely is
about the worst abuse of the power given to an application.  In
many configurations this has the potential to make the desktop
totally unusable.  Perhaps we should think of an emergency key
binding to disable the full screen state of all windows on the
current page.

> A window in the full screen mode should occupy only one page.

I don't think anybody suggested that.  I was talking about
Xinerama screens.

> is possible in most of the other window managers.

There may be an easy way to achieve overriding styles for a
limited period of time.  Add a field to the style structure that
can contain a unique style id.  Then throw in a couple of
features:

  StyleWithId <envvar> <Stylename> <Options>

    Like Style, but assigns a unique id to the style and stores it
    in the environment variable <envvar>.  Styles with different
    ids can not be merged.  By default, all normal styles have the
    id 0.

  DestroyStyleId <id>

    Destroys the style with the <id>.

Usage:

  AddToFunc foo
  + I StyleWithId SID_$w $n HandleWidth 0, BorderWidth 0, NoTitle

and later:

  ThisWindow DestroyStyleWithId $$[SID_$w]

(The ThisWIndow call is necessary to force expanding variables
twice - no idea how to do this in a functions.)

--

By the way, this idea shows nicely one of the shortcomings of a
WindowStyle command separate from the Style command.  You'd have
to add the id functionality to both. 

Bye

Dominik ^_^  ^_^

---

From: Mikhael Goikhman <[email-masked]>
Date: Tue, 8 Jul 2003 23:22:10 +0000

On 08 Jul 2003 23:15:06 +0200, [email-masked] wrote:
> > What is more important for 2.6 is WindowStyle.

Let's see. :) This introduces 2 temporary commands that do not help at
all to implement invidual window styles. The style changes are still
applied to all windows with the same name, it relies on environement
variables and it still suffers from a problem that X assigns the same id
to different windows (close a window and open a new one).

WindowStyle and DestroyWindowStyle commands and their syntax was thought
and designed to be final, they do not need to be thrown away at all.
At least it is my impression that Olivier, me, Dan and Tim discussed it
and agreed that WindowStyle is good to be non temporary.

Anyway, if you can implement "WindowStyle <style-options>" syntax
differently than Olivier, it would be just fine with me. The point here
is to have individual window styles and thus to improve fvwm, not to have
an implementation that you don't agree with. Although I should say that
I think that the second Olivier implementation is good and clean.

If you don't agree with the WindowStyle syntax I would like to know why.
For me, regardless of how we may redesign (or not) Style command, the
minimal WindowStyle syntax working on window context will always remain
good and meaninful. Just what we miss for individual window styles.

> twice - no idea how to do this in a functions.)

I thought about this problem too, and the best I can think is using
Schedule 0 command... I guest we need a dummy prefix Expand or similar.

Regards,
Mikhael.

---

From: parv <[email-masked]>
Date: Tue, 8 Jul 2003 23:18:07 -0400

in message <[email-masked]>, wrote Mikhael
Goikhman thusly...
> > in message <[email-masked]>, wrote Mikhael
> > Goikhman thusly...
> > >
> > > FullScreen should remove decorations, at least this is what
> > > a user expects.
...
> > windows/programs that (try) to go full-screen by their own
> > mechanism (say mozilla) ... unless that is against some spec.
> > If fvwm's idea of full-screen is different than the client,
> > i would like to have some control on the fvwm aspect.

(Let me add to the last sentence that having control on the fvwm
aspect is desirable to control an annoying client.)

> Removing decorations should be at least an option if not the

Or vice versa, same difference.  As long as there is a way to
(un)do...

> There are several problems [...] 2 full-screen windows on
> different pages overlap each other, without decorations they would
> not conflict; when you shade such window it ends up mostly in the
> different page;

Oh yes, i have experienced that.  Irritating indeed.

  - Parv

---

From: Olivier Chapuis <[email-masked]>
Date: Wed, 9 Jul 2003 07:46:05 +0200

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

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

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?

Regards, Olivier

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 9 Jul 2003 09:10:42 +0200

> On Tue, Jul 08, 2003 at 08:55:37AM +0200, Dominik Vogt wrote:
[snip]
> - 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.

> as explained in 3) to be able to define EWMHFullScreen{On,Off}.

Not for 2.6.  It is way too complex and error prone.
 
> 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 ^_^  ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 9 Jul 2003 09:18:00 +0200

> to different windows (close a window and open a new one).

I thought it was clear that this isn't a proposal but a sketch of
the idea.

> and agreed that WindowStyle is good to be non temporary.

I disagree.  Separate commands will lead to matrices of commands
plus options they have to support.

> If you don't agree with the WindowStyle syntax I would like to know why.

See above and many other mails I wrote about this topic.  It's
inflexible and hard to extend.

> Schedule 0 command... I guest we need a dummy prefix Expand or similar.

Yes.

Bye

Dominik ^_^  ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 9 Jul 2003 09:19:48 +0200

> Or vice versa, same difference.  As long as there is a way to

The default must always allow the user to bring the desktop into a
usable state.  Applications can not be trusted to behave.

Bye

Dominik ^_^  ^_^

---

From: Mikhael Goikhman <[email-masked]>
Date: Wed, 9 Jul 2003 19:54:06 +0300

> usable state.  Applications can not be trusted to behave.

I agree.

Thinking about the emergency key. We already have Alt-Tab that may be
used to switch to any (non WindowListSkip) window. WindowList calls
WindowListFunc that currently contains this line among others:

  + I Iconify off

In case we will have FullScreen command, I think, we should also add:

  + I FullScreen off

to the default WindowListFunc. This will help users to bring their
windows to a normal state. Just an idea, nothing else.

Regards,
Mikhael.

---

From: [email-masked]
Date: Thu, 10 Jul 2003 01:48:28 +0200

> windows to a normal state. Just an idea, nothing else.

This unfortunately does not work if the full screen window is the
only window.

We could extend the Ctrl-Alt-Escape sequence we already use for
similar purposes.  In addition to what it already does, it would
call a "Quarantaine" function that quanrantaines the window under
the pointer.  Ideally the function would

 * Remove the window from the desktop, perhaps by iconifying it.
   The window must be unmapped to ensure it can not cause further
   damage on the desktop.

 * Show a reprensentation of all windows in quarantaine and allow
   the user to end the quarantaine by clicking on the placeholder.

Bye

Dominik ^_^  ^_^

---

From: Mikhael Goikhman <[email-masked]>
Date: Thu, 10 Jul 2003 03:46:55 +0300

> This unfortunately does not work if the full screen window is the

If WindowListFunc includes "FullScreen off" it will work even if there is
only one window. Or do you mean extreme cases unrelated to full screen?

>    the user to end the quarantaine by clicking on the placeholder.

I would think more before implementing something like this. A lot of
users already have bindings that make such emergency key redundant.
I may count several such bindings in fvwm-themes, for example Alt-Mouse1
inside any window opens the root menu, Alt-Mouse2 raiselowers/moves the
window, Alt-Mouse3 opens the window menu and Alt-F9 iconifies the window.

Another Alt-Tab based solution may be as follows. When we will support
different mouse buttons in a menu, i.e. supporting different menu item
actions depending on the mouse button, we could bind a window operation
menu to the right mouse click in the WindowList menu. Such window
operation menu could contain Iconify, Move and other window operations.

Regards,
Mikhael.

---

From: Mikhael Goikhman <[email-masked]>
Date: Thu, 10 Jul 2003 04:03:58 +0300

> window, Alt-Mouse3 opens the window menu and Alt-F9 iconifies the window.

Just for the curious, I tried to find all emergency keys in fvwm-themes,
and it is not easy, there are a lot. :) Like Ctrl-Alt-arrows to switch
pages, Ctrl-Alt-1 to Ctrl-Alt-4 to switch desks, Ctrl-Alt-0 to go to the
previous page/desk, Shift-Ctrl-keypad or Shift-Alt-keypad to move the
window to either other pages or for some pixels in the given direction.
Additionally, Alt-F6 may be always used to restore the window from the
maximized/iconified/shaded state, it will be surely extended to support
full screen as well. Did I mention Alt-F11, Alt-PgDn and Alt-PgUp? :)

Regards,
Mikhael.