Carsten Haitzler (The Rasterman) wrote:

On Mon, 24 Oct 2005 22:07:19 +0200 Lubos Lunak <[EMAIL PROTECTED]> babbled:


Dne čt 20. října 2005 03:29 Carsten Haitzler napsal(a):

On Wed, 19 Oct 2005 15:30:00 -0500 Sasha Vasko <[EMAIL PROTECTED]>

babbled:

There is a certain ambiguity in how geometry should be specified by
user, when Window Manager is supporting virtual viewports. This surfaced
 as the result of GIMP abuse of USPosition flag which is outlined here

: http://bugzilla.gnome.org/show_bug.cgi?id=319099

Basically, for user to be able to place , say, a term window into
arbitrary viewport on the desktop, using just a command-line options -
geometry must be specified in relation to the desktop origin, there is
no other way around it. Therefore it is a duty of a Window Manager to
always treat USPosition in relation to a desktop origin.

On the other hand, as apps itself may not be aware of existence of
virtual viewports, and even if they do - its not possible to reliably
take it into consideration - PPosition must always be treated in
relation to the current viewport's origin.

Now this is not a transparent conclusion for anyone not involved with
window management to a certain depth, and therefore I suggest that this
should be clarified in specs under "Desktop/workspace model" subsection
of Implementation notes.

Anybody wants to comment on that ?

this is a tough one. most existing apps will see BOTH USPosition and
PPosition as ROOT window relative co-ordinate hints (out of practicality
and a loong history). changing this will mean breakage of at least some
apps. but this also makes using a virtual desktop + movable viewport a bit
of a nightmare,as i assume you are discovering.

basically a lot of wm's have ignored pposition in the past due to abuse by
apps (like netscape) and thus many aps have moved to abusing usposition
instead (though they do it better than netscape did). i know that
personally im gettigng to the point of encouraging users to use the lock
and override features of the wm to say "dont listen to the apps request for
position, size etc. use mine and ignore the app" as its geenralyl more
reliable :) thus in that scneario - the wm can choose to put the app where
it was last - relative to the virtual desktop co-ordinates, not the
viewport. :)

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

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.


Sasha Vasko
_______________________________________________
wm-spec-list mailing list
wm-spec-list@gnome.org
http://mail.gnome.org/mailman/listinfo/wm-spec-list

Reply via email to