Re: frame size hints

[dominik vogt gmx de]

On Fri, Nov 29, 2002 at 04:17:21PM -0500, Havoc Pennington wrote:
> On Fri, Nov 29, 2002 at 09:49:37PM +0100, Matthias Clasen wrote: 
> > a) these toolkits won't use it anyway
> 
> The motive for this post is that Sun asked for advice on how to make
> AWT work with Metacity. Honestly, what answer can you give them? They
> have to make AWT API keep working, now that it's been shipped for
> years, even if they do deprecate the broken API and replace it, the
> deprecated API has to keep working. As far as I know, historically
> they rely on mwm-specific hacks and I'm even told some JDKs have
> contained enlightenment-specific hacks.
> 
> The "walk up the window tree and find the frame" hack doesn't quite
> work with Metacity, so they have to do something else. I'd rather they
> do something I have in my upstream version that works on Linux as well
> as Solaris and won't break every time I touch the code, so I'm
> inclined to give them some "supported" mechanism.
> 
> I can give them _METACITY_FRAME_EXTENTS of course (which makes Sun
> happy as they don't ship anything else), but that just means the JDK
> will break on every other window manager.
> 
> I'll do metacity-specific if I have to, but I think it would be better
> if any WM could choose to support this.

In my eyes, the right way to "fix" the problem is to allow a
custom MoveResize request that refers to the frame geometry:

  "Resize the frame to 1024x768"

The look-for-the-window-frame-myself approach is simply wrong and
buggy.  With modern window managers, the size of the decorations
can change at any time and would thus have to be reread aevery
time the client wants to do something with its geometry.  xv is a
wonderful proof that it simply does not work, regardless of the
number of window manager specific hacks.

Another example where it does not work is window clustering.  Some
wms can put multiple windows into a single frame dynamically.  You
won't get very far with watching the frame layout here either.

I suggest to finally make that custom client message we discussed
in other threads that tells the wm:

  - A WM_NORMAL_HINTS structure which contains desired size,
    position, base size, win_gravity etc.
  - The reference window (FRAME or CLIENT as symbolic constants)
    for the size.
  - The reference window for the position (may not be necessary to
    keep that separately from the one above).
  - bit_gravity
  - possibly other information about allowed sizes

All fields are optional.  That allows full control of the window
geometry without even knowing about the frame layout.  The values
given in the WM_NORMAL_HINTS structure of the request replace any
old settings and are used for the request.

For example, if a window wants to become full screen with the frame
still visible it requests:

  size: screen width x screen height
  pos : +0+0
  reference window (size): FRAME
  reference window (pos) : FRAME
  (win_gravity: meaningless when FRAME is used)

And if it wants to become full screen without the frame visible:

  size: screen width x screen height
  pos : +0+0
  reference window (size): CLIENT
  reference window (pos) : CLIENT
  win_gravity: StaticGravity

This also avoids the various race conditions with the
WM_NORMAL_HINTS members.

Bye

Dominik ^_^  ^_^

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