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. 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) [EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) _______________________________________________ wm-spec-list mailing list wm-spec-list@gnome.org http://mail.gnome.org/mailman/listinfo/wm-spec-list
