Re: USPosition vs. PPosition with Virtual viewports

[Lubos Lunak <l lunak suse cz>]

On Tuesday 25 of October 2005 16:48, Sasha Vasko wrote:
> Carsten Haitzler (The Rasterman) wrote:
> > On Mon, 24 Oct 2005 22:07:19 +0200 Lubos Lunak <l lunak suse cz> babbled:
...
> >> Does somebody think it wouldn't be completely naive to try to fix this
> >>USPosition/PPosition madness by adding some kind of I-do-it-properly
> >> property that both WMs and apps could set?
> >>
> >> Qt also sets both US and P positions, because of the reasons listed
> >> above, in order to work around broken old WMs and whatnot, and I've run
> >> already into this a couple of times with KWin. Qt e.g. always places
> >> dialogs, and although KWin has much better placement algorithm it's
> >> simply not of much use because of US and P position set. I even tried to
> >> actually ignore those flags in general for dialogs but that wasn't that
> >> good idea either :( . And having the user to manually set setting for
> >> every app is not really a solution.
> >
> > agreed - for the aqverag user. power users when they get annoyed enough
> > will set it. :)
> >
> > as for a new hint - i don't see this as a bad idea, but if we were to
> > propose such a hint - may i suggest we expand it a bit. we should:
> >
> > 1. provide another client window id (that should be mapped at the time)
> > to place RELATIVE to. (if not provided root is assumed). 2. a flag to
> > indicate if the position is screen relative (viewport relative) or
> > desktop relative. 3. the ability to provide absoloute position offsets
> > relative to the top-left (or any other corner) but ALSO relative
> > percentage offsets (as a percentage of the relative window mentioned in
> > 1. and its geometry at the time the window is mapped.
>
> Woa! Hold On! :)
> That's a whole different aspect you are bringing in here.
> As I see it we have two problems here now :
> 1) Let client apps know how Window Manager handles USPosition and PPosition
> 2) Possibly allow clients to request placement in relation to desktop
> origin or another window ( which is what you are bringin up ).
>
> As to first problem I agree with Lubos, and here is what we could do :
>
> _NET_PLACEMENT, ATOM[]/32
>
> With possible atoms :
> 	_NET_PPOSITION
> 	_NET_USPOSITION
> 	_NET_USPOSITION_IS_DESKTOP_RELATIVE

 I don't understand what you actually mean with these hints. My idea was 
basically a hint saying "you stupid app I'm a sane WM, don't try your 
USPosition tricks on me that you need only for some BorkenWM-0.1". I.e. if we 
now go to toolkit authors and ask them to remove all the UPosition abuse 
(which I've already tried for Qt) they'll refuse with "but we need that for 
CrapWM". With a hint they could check whether they need it. The same way with 
a hint set by apps the WM could be less paranoid about those apps.

 As for the dialogs my reason was basically that KWin tries to do some sane 
placement for all normal windows (i.e. except docks and stuff like that). If 
an app opens a window of type dialog without specifying any position KWin 
will use its special algorithm for placing dialogs for it (and at least 
Metacity can do that as well). My problem here is that toolkits always 
specify position for dialogs, even if they in fact don't want any special 
position for it and just want it to be placed "normally" for dialogs, because 
most WMs wouldn't place dialogs properly and pre-EWMH ones can't even know 
what is a dialog. Since KWin can do better placement than apps I'd find it 
nice if apps would leave this up to KWin as well.

 And it's actually not really related to the USPosition issue, it'd be more 
like having a flag for don't-abuse-USPosition and a flag for 
leave-default-dialog-placement-to-the-WM.

> For the second problem, I'd say it will be good enough if we'll allow
> clients to request position in relation to its other windows, but not
> root or viewport, as those should be dictated by window manager's own
> policy. Even that is to much IMHO. and I think we need to start a second
> thread for that discussion.

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l lunak suse cz , l lunak kde org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/