Re: USPosition vs. PPosition with Virtual viewports

[Carsten Haitzler (The Rasterman) <raster rasterman com>]

On Mon, 24 Oct 2005 22:07:19 +0200 Lubos Lunak <l lunak suse cz> babbled:

> Dne čt 20. října 2005 03:29 Carsten Haitzler napsal(a):
> > On Wed, 19 Oct 2005 15:30:00 -0500 Sasha Vasko <sasha aftercode net> 
> 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.

so we would have (just types - no names atm)
(1.) XA_WINDOW property
(2.) XA_CARDINAL for flags (only 1 bit used atm)
(3.) XA_CARINAL[2] for relative position x, y (use 16.16 fixed point?)

(x and y are relative to the entire set of virtual desktops assuming its NxM
pixels and the viewport looks at a rectangular region of these pixels)

if (1.) provided AND (3.) provided:
  x = (1.)->x + (((3.)[0] * (1.)->width) >> 16) + client->x;
  y = (1.)->y + (((3.)[1] * (1.)->height) >> 16) + client->y;
if (2.) has "desktop relative" flag set and no (3.) provided:
  x = client->x - viewport->x
  y = client->y - viewport->y
if (3.) provided and (2.) has no desktop relative flag set:
  x = viewport->x + (((3.)[0] * viewport->width) >> 16) + client->x;
  y = viewport->y + (((3.)[1] * viewport->height) >> 16) + client->y;
etc.

this should allow for clients to say "please center my dialog" and more - these
calculations calculate client window position excluding the frame whihc is
placed around the client.

this is  just an idea - for now, not even a good attempt at a final spec, but
it is trying to illustrate the idea. we can do this as a single property with 3
cardinal values and interpret each differently etc.

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster rasterman com
裸好多
Tokyo, Japan (東京 日本)