Re: Proposal for ConfigureRequest handling

[Dominik Vogt <dominik vogt gmx de>]

On Thu, Aug 08, 2002 at 01:58:19PM +0200, Marko Macek wrote:
> > If you have to change all WMs anyway (to add support for your new 
> > property), why not change them to deal properly with static gravity 
> > instead ? 
> 
> I agree with this. 
> 
> > If we indeed need a way to advertise support for static gravity by the WM,
> > 
> > wouldn't it be more consistent to add an new atom like 
> > _NET_STATIC_POSITION to _NET_SUPPORTED ?
> 
> Dominik's proposal allows for "fixes" to old (non ICCCM compliant wm)
> without modifying the actual WM (can be done by an external program).

Hm, right.  That's not a generic solution, but it could be used to
cope with WMs that don't care about the issue or are no longer
being developed.

> But I'd
> rather that ICCCM compliance was fixed, ... I'd rather see that all apps using
> wmspec hints would require this to be ICCCM compliant anyway (at least when WM
> claims to be, the existance of _NET_SUPPORTED should guarantee that).

In other words:  Demand that all applications and WMs are
ICCCM/EWMH compliant and discontinue support for all that are not
and at the same time?  That rules out most existing applications
and probably the majority of window managers too.

> The root window setting should be enough.
> 
> We need:
> 1. improve the description of correct behavior in the wm-spec
> in *big bold letters* ;) (The current win_gravity handling is not obvious
> enough). I know this because I was fixing these kinds problems for icewm-1.2.0
> release.

I agree that this should be done in many places, but it won't help
here since the damage was already done.

> 2. Make a test program that tests all aspects of this (in pure Xlib)

> 3. Maintain a list of all non-compliant/buggy window managers
>  AND applications (various applications have hacks that break on compliant
> WMs -- galeon and xv come to mind).

That reasoning is pointless.  First, I can't think of any WM that
is fully ICCCM compliant (except perhaps the most minimal ones),
so they are all buggy by your definition (remember that the ICCCM
demands that application provided icons must have depth 1?).  And
second, many of the problematic apps are not going to be "fixed".
So, your proposal breaks down to finger pointing at the "baddies"
and does nothing to help applications or window managers to cope
with both types of ConfigureRequest handling.

> If we can't have a standard way of positioning windows, X is in a sorry
> state indeed.

X *is* in a sorry state.  But that's really not the point.  

[snip]

> Java has some other problems though. It would be nice if the apps could get
> the geometry of the managed window (decorations), before showing the window
> itself.

Hm, perhaps this could be done via the initial_state.  Set this to
"withdrawn" and the WM sets up the window as usual, but does not
map the frame itself.  The client would notice that it was
reparented and could look up the frame size and its position.  It
would then ask to map the window manually and the WM maps the
frame.

> The problem is (last time I checked) that Java API set's the window
> size using the frame geometry, not the client geometry (broken IMO).

Sure, that's pretty broken.

Bye

Dominik ^_^  ^_^

 --
Dominik Vogt, mail: dominik vogt schlund de, phone: 0721/91374-382
Schlund + Partner AG, Erbprinzenstr. 4-12, D-76133 Karlsruhe