Re: My comments on 1.9b

[Dominik Vogt <dominik vogt fvwm org>]

On Wed, Oct 27, 1999 at 12:55:14AM +0200, Matthias Ettrich wrote:
> On Tue, 26 Oct 1999, Owen Taylor wrote:
> >  * _NET_ACTIVE_WINDOW:
> >  
> >     What is an "active" window? How does this differ from
> >     focused window? What does "activating" a window on a
> >     different desktop mean since you can't give it the
> >     input focus? Should WM implementations switch desktops?
> 
> That's what I would say, yes. The "active" window is the window that has focus.
> Making it active implies giving the focus to it. If that's impossible since the
> window is on another desktop, it implies switching to the desktop. If the
> window is iconified, it implies de-iconifying it.
> 
> It's basically the action that happens when you click on a taskbar entry. It
> indicates that the user wants to work with this window. The WM should make this
> possible.

This is what I proposed a while ago:

---------------------- snip ------------------------
1. Degrees of activation: (proposed by Dominik Vogt)

> Do you have a suggestion for meaningful degrees of activation?

  _NET_ACTIVATE_VISIBLE_ON_VIEWPORT:  make visible if on the active viewport
  _NET_ACTIVATE_VISIBLE_ON_DESK:      make visible if on the active desktop
  _NET_ACTIVATE_VISIBLE_EVERYWHERE:   make visible everywhere

One bit each, if multiple bits are set, EVERYWHERE take precedence over
ON_DESK, ON_DESK takes precedence over ON_VIEWPORT.

  _NET_ACTIVATE_NORMALIZE:            de-iconify and unshade

One bit, may be set independently of the other bits.

  _NET_ACTIVATE_FOCUS:                give it the focus
  _NET_ACTIVATE_FOCUS_AND_WARP:       give it the focus wnd warp into it

One bit each. If multiple bits are set, FOCUS_AND_WARP takes precedence.

[[ I am worried about the WARP thing, so I'll have to think about it. I
think assumes that the app knows about the focus model (currently it
doesn't and I'd like to keep it that way if possible) ]]
---------------------- snip ------------------------

I.e. making a window visible, unshading/deiconifying it and giving it
the focus can be controlled independently.  I'd scrap the
_NET_ACTIVATE_FOCUS_AND_WARP bit completely.  With these hints the
application can choose different degrees of activating itself.
A taskbar could even be configured in a way the user likes best.
For example it isn't strictly necessary to deiconify a window or
to make it visible to type into it (in fact this is something I
use quite often personally: I move the mouse over the mini window
in my FvwmPager and simply type into it. The pager asks fvwm to
focus the window without switching pages/desks).

Note that I left the interpretation of 'make visible' to the
WM authors.  Thus, the user may choose himself if he wants
the WM to ignore this completely, to switch the viewport so
that the window is visible or to move the window to the current
desktop.  This limits the possibilities of applications to
abuse these hints and provides full configurability for each
window inside the WM.

> >  2.
> > 
> >  * _NET_WM_MOVERESIZE:
> > 
> >     What is the rational for needing this?
> >     How does the "MOVE" part of this work?
> >     There probably should be the ability to not specify
> >     a resize direction. (Many window managers have some
> >     way of starting a resize other than dragging on the
> >     border)
> 
> The rationale got lost between Draft1 and Draft1.9b. The idea is to make it
> possible for toolkits to provide a sizegrip a la MacOS (or MS-Windows). A
> sizegrip usually is a small triangular thing in the bottom right corner of a
> status bar that can be used to resize a window. It's very practical, since
> window borders are often too narrow and therefore hard to click on.
> 
> The problem with a pure toolkit implementation was that the sizegrip worked
> differently than the rest (no outline mode even if the user wanted it).
> 
> So I proposed some kind of property to tell the window manager that this is a
> sizegrip.  Raster extended the idea ( as usual ;-) to be able to provide
> different sizegrips (for different directions) and even a move grip. 
> 
> I agreed since it is easy implementable and may be useful someday.
> 
> Marko replaced the size-grip property mechanism with a client message that is
> sent to the window manager in the draft 1.9b. I must admit I like the idea.
> It's very easy to use once the toolkit found out that the protocol is indeed
> supported and it's even easier to implement on the WM side.

Hm, what would happen if the resize grip is - say - in the middle of
the window.  I guess fvwm and all the derived window managers are unable
to resize a window properly if the pointers is nowhere near the border.
Of course the pointer could be warped, but that would make the grip
useless.  This seems to be too WM dependend to work out of the box with
all spec compliant WMs.  I propose to change the meaning of the MOVERESIZE
client message like this:

old version:
-------------------------- draft 1.9b ---------------------------
_NET_WM_MOVERESIZE

When application wishes to initiate window resizing it must send
a message to the root window:

   window = target app window
   message_type = _NET_WM_MOVERESIZE
   format = 32
   data.s[0] = x_root
   data.s[1] = y_root
   data.s[2] = direction:

#define _NET_WM_MOVERESIZE_DIRECTION_TOPLEFT     0 /* towards the top-left */
#define _NET_WM_MOVERESIZE_DIRECTION_TOP         1 /* towards the top */
#define _NET_WM_MOVERESIZE_DIRECTION_TOPRRIGHT   2 /* towards the top-right */
#define _NET_WM_MOVERESIZE_DIRECTION_RIGHT       3 /* towards the right */
#define _NET_WM_MOVERESIZE_DIRECTION_BOTTOMRIGHT 4 /* towards the bottom-right*/
#define _NET_WM_MOVERESIZE_DIRECTION_BOTTOM      5 /* towards the bottom */
#define _NET_WM_MOVERESIZE_DIRECTION_BOTTOMLEFT  6 /* towards the bottom-left */
#define _NET_WM_MOVERESIZE_DIRECTION_LEFT        7 /* towards the left */
#define _NET_WM_MOVERESIZE_DIRECTION_MOVE        8 /* only movement */
-----------------------------------------------------------------

new version:
--------------------------- proposal ----------------------------
_NET_WM_MOVERESIZE

When application wishes to initiate window resizing it must send
a message to the root window:

   window = target app window
   message_type = _NET_WM_MOVERESIZE
   format = 32
   data.s[0] = x_root
   data.s[1] = y_root
   data.s[2] = grip:

#define _NET_WM_MOVERESIZE_MOVE               0 /* only movement */
#define _NET_WM_MOVERESIZE_RESIZE_TOPLEFT     1 /* top-left grip */
#define _NET_WM_MOVERESIZE_RESIZE_TOP         2 /* top grip */
#define _NET_WM_MOVERESIZE_RESIZE_TOPRRIGHT   3 /* top-right grip */
#define _NET_WM_MOVERESIZE_RESIZE_LEFT        4 /* left grip */
#define _NET_WM_MOVERESIZE_RESIZE_CENTER      5 /* 'center' grip */
#define _NET_WM_MOVERESIZE_RESIZE_RIGHT       6 /* right grip */
#define _NET_WM_MOVERESIZE_RESIZE_BOTTOMLEFT  7 /* bottom-left grip */
#define _NET_WM_MOVERESIZE_RESIZE_BOTTOM      8 /* bottom grip */
#define _NET_WM_MOVERESIZE_RESIZE_BOTTOMRIGHT 9 /* bottom-right grip */
-----------------------------------------------------------------

Comments on the proposal:

 - The 'grip' indicates in which directions the window is resized.
   E.g. the 'top' grip allows to move the top border up and down
   while the 'bottom-right' grip allows to resize as if the bottom
   right corner of the frame was grabbed, and so on.
 - The 'center' grip initiates a resize operation and lets the user/WM
   choose which part to resize (e.g. the initial click is in the
   center of the window, then the user moves the mouse to the left
   border to choose the 'left' grip or to the top-right corner for
   a 'top-right' grip.  This is necessary if the resize operation
   is started by a menu entry.
 - This way it's easy for a WM to initiate the resize operation.
 - I prefer that the actual numbers of the constants are arranged in
   rows like this (but I don't really care).

    123              012
    456  instead of  783
    789              654

 - I see a problem here when an application resizes a window while
   the mouse is somewhere else (e.g. a 'window managing' module).
   The mouse would be potentially far away from the window at the
   time.  If one of the eight outer grips are specified the user
   may be unable to get the size he wants, and if the 'center'
   grip is used he may not be able to reach the border he wants to
   resize without passing a different border and thus starting the
   resize:

     Screen
     +--------------------+
     |           1---2---3|
     |           |       ||
     |           4   5   6|
     |           |       ||
     |           7---8---9|
     |           Window   |
     |                    |
     | *                  |
     |                    |
     +--------------------+

   If the pointer is at the '*' when the resize is triggered,
   you will be unable to reach the '3' grip without passing
   over one of the others.

  - Come to think of it: there is a very ugly race condition
    lurking here: what if the user moves the mouse before the
    client message is received by the WM?  The user may have
    actually have clicked on '7' above.  But when the WM
    finally starts resizing it may alrady have traveled to
    the '*' position.  The WM won't be able to properly resize
    the window anymore.  The client message has to provide
    more information:  the root coordinates of the pointer
    and the button that triggered the action (because that may
    change the way moing/resizing works).  The client
    message should contain enough information to create a
    fake button press event.  This way the changes in
    existing WMs should be limited to handling the client
    message itself, the move/resize code wouldn't have to be
    touched.

Bye

Dominik ^_^

--
Dominik Vogt, dominik.vogt@gmx.de
Reply-To: dominik.vogt@gmx.de