Re: frame size hints

[dominik vogt gmx de]

On Fri, Nov 29, 2002 at 11:22:00PM -0500, Havoc Pennington wrote:
> On Sat, Nov 30, 2002 at 01:50:49AM +0100, dominik vogt gmx de wrote: 
> > I have thought about this topic a lot and come to the conclusion
> > that it is very wrong to export information about the wm frame
> > layout to the application.  It simply does not work unless the
> > application is willing to listen for ConfigureNotify events on the
> > frame window.
> 
> Or PropertyNotify on the property that's exported to the app.

Yes, I thought of PropertyNotify too.  But I would like to make it
as inconvenient as possible to discourage using that feature.  The
client should have to ask every time and not dump the workload on
the window manager.  I find it stupid to provide a broken property
on tons of windows just to make a few broken applications happy.
That would only encourage other people using it.
 
> > For example, in fvwm I can dynamically change the side at which
> > the title is displayed (top/bottom, left/right) without the
> > client window moving.  Such applications would never even notice
> > that this has happened.  And I shudder at the thought of
> > applications examining the geometry of a *shaded* frame window.
> 
> That's in fact what metacity was breaking in the AWT - AWT is confused
> by shaded windows. So the property giving the frame edge sizes, if we
> had one, would track whatever frame size the WM was going to use for
> configure requests on the shaded window.

xemacs is another example.  If it gets a ConfigureNotify 

> IIRC metacity honors configure requests as if the window were not
> shaded, so it would provide the unshaded size even while shaded.

Hm, in fvwm we ignore configure requests on shaded windows
because it would lead to a ConfigureNotify on the client window.
Some apps (for example xemacs), look at the size of their frame
window and answer with a ConfigureRequest with a huge height in
response (height of 1 pixel - menubar height - toolbar height etc.
= -something which is cast to an unsigned short).  And resizing a
shaded window can be very confusing to the user as the title might
jump around the screen (when the title is on the opposite side of
the window than the reference gravity point, e.g. NW gravity and a
title below the window or SE and title above the window).

> > *If* this can not be avoided, the frame geometry should be
> > readable cia a client message ("Give me the frame geometry") and
> > the WM replies with another client message that contains the
> > (unshaded) frame geometry.  At no cost should the window id of the
> > frame window be exported to the client.
> 
> Isn't a property on the app window equivalent to the client message?
> The property gives us change notification for free.

See above.  I don't want an automatic change notification.  Then,
the client has to ask every time with the risk of not getting an
answer, having to wait for a few seconds before giving up.  I hope
that discourages people from using that bug.

> > Of course, that information is already obsolete when it is
> > delivered to the client.
> 
> Yes, of course. There's no way to avoid races here, that I see, if the
> client is going to compute the relative positions of two windows. AWT
> will just have to be broken that way.

Well, this problem can be solved with an enhancement of the custom
move/resize message:

_NET_FUNKY_MOVE_RESIZE_CLIENT_MESSAGE draft 2:
---------------------------- snip -------------------------------
Information provided by the client:

 - Client window id to reconfigure
 - A WM_NORMAL_HINTS structure which contains desired size,
   position, base size, win_gravity etc.
 - Whether the size is requested for the client window
   (RESIZE_CLIENT, default), for the frame window (RESIZE_FRAME)
   or in units of the ..._inc (RESIZE_UNITS)
 - Whether the position is requested for the client window
   (PLACE_CLIENT), or for the frame (PLACE_FRAME, default).
 - A reference window.
 - The reference point of the reference window expressed as a
   win_gravity.
 - The bit_gravity for the operation.

All information is optional, except the client window id.

--

If no reference window is given, the root window is used as the
reference window.  If no reference point is given,
NorthWestGravity is assumed, i.e. the top left corner of the
reference window is the reference point.

If the reference window is another client window managed by the
wm, the frame of this window is used as the reference window.

If the reference window is not a sibling of the frame of the
client window, the request is ignored.

Only size change requested:

 * Size is changed according to request, using the provided
   win_gravity or the old win_gravity if none is provided.
 * The reference window is ignored in this case.

Only position requested:

 * The window is placed so that the reference point of the client
   window (as defined by the requested win_gravity) is at the same
   place as the reference point of the reference window.  The
   desired x/y is then added to this position.

Both, position and size requested:

 * The window is resized first as if no new position had been
   requested.  This is done only internally, not on the X server,
   of course.  The win_gravity has no meaning here.
 * The window is then placed as if the request did not contain a
   new size.
---------------------------- snip -------------------------------

Some examples:

To make the frame full screen, anchored in the top left corener:

 - pos:         0 0
 - place ref.:  PLACE_FRAME
 - size:        (screen width)x(screen height)
 - resize ref.: RESIZE_FRAME
 - win_gravity: NW

Same, but anchored in the bottom right corner:
 
 - pos:         0 0
 - place ref.:  PLACE_FRAME
 - size:        (screen width)x(screen height)
 - resize ref.: RESIZE_FRAME
 - win_gravity: SE
 - ref. window: Root
 - ref. point:  SE

Make the client window full screen:

 - pos:         0 0
 - place ref.:  PLACE_CLIENT
 - size:        (screen width)x(screen height)
 - resize ref.: RESIZE_CLIENT
 - win_gravity: NW

Center window on screen:

 - pos:         0 0
 - place ref.:  PLACE_FRAME
 - win_gravity: C
 - ref. window: Root
 - ref. point:  C

Place window right of another window, aligned at the top:

  +-----------++--------+
  |           ||        |
  | reference || client |
  |  window   ||        |
  |           |+--------+
  +-----------+

 - pos:         1 0
 - place ref.:  PLACE_FRAME
 - win_gravity: NW
 - ref. window: Root
 - ref. point:  NE

Make a full screen window that is placed so that it equally
overlaps four pages (with the current viewport at page 0 0):

  +------------+------------+
  |page 0 0    |    page 1 0|
  |            |            |
  |      +-----------+      |
  |      |           |      |
  |      |           |      |
  +------|  window   |------+
  |      |           |      |
  |      |           |      |
  |      +-----------+      |
  |            |            |
  |page 0 1    |    page 1 1|
  +------------+------------+

 - pos:         0 0
 - place ref.:  PLACE_FRAME
 - size:        (screen width)x(screen height)
 - resize ref.: RESIZE_FRAME
 - win_gravity: C
 - ref. window: Root
 - ref. point:  SE

> > Just out of curiosity:  What is so special about metacity that AWT
> > can not find the frame window?  Does that mean that xwininfo and
> > xkillclient do not find it either?
> 
> It's just the shaded frames that were breaking.
> 
> AFAIK xwininfo and xkillclient look for the client window (the one
> with WM_STATE) rather than the frame, don't they?

Yes, and to do this they must figure out which is the wm frame so
they can ignore it.

Bye

Dominik ^_^  ^_^

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