Re: USPosition vs. PPosition with Virtual viewports

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

On Wed, 26 Oct 2005 10:06:11 +0100 Bill Haneman <Bill Haneman Sun COM> babbled:

> Positioning "ordinary" application windows with respect to the screen 
> glass rather than with respect to
> NET_WORKAREA breaks accessibility. This is something that really needs 
> to be taken into account in these discussions. low-vision or mobility 
> impaired users need to be able to rely on apps not impinging on the 
> screen space used by onscreen magnification windows or onscreen 
> keyboards, for instance. Allowing applications to do this without 
> requiring them to participate in STRUTS or be type dock is a bad idea.
> 
> Maybe I am misreading some of this discussion, but it sounds to me as 
> though some of the proposals here would not respect NET_WORKAREA, which 
> is a 'bad thing' for accessibility.

the wm can adjust for that quite happily - if it choses to enforce such
"accessibility" stuff. :) as it is - its just more info in the hints allowing a
better descision to be made. if the window the app asks to be in he middle of,
for example, is off the screen, or not within the workspace area - the wm can
choose to do something appropriate - dont honor it and keep the dialog within
workspace (and out of the way of maginifier/accessibility windows), or move the
main window on screen so the dialog will, given its requested hint, be visible
- etc. the wm has a choice of doing whatever it believes is best. and the users
gets to choose wm, and its config, so this will end up being consistent for
their desktop. right now an app needs to query its parent window geometry (or
track it) then calculate a position it wants and place the dialog at that x,y
co-ord explicitly. this co-ord is by logic and convention treated relative to
the "glass" as its the onyl sane way to look at it. wm's CAN ignore the hint
and choose to do something more apprioriate if they please - given the current
scheme or any new one.

> Best regards,
> 
> Bill
> 
> 
> Carsten Haitzler (The Rasterman) wrote:
> 
> >On Tue, 25 Oct 2005 09:48:18 -0500 Sasha Vasko <sasha aftercode net> babbled:
> >
> >  
> >
> >>Carsten Haitzler (The Rasterman) wrote:
> >>
> >>    
> >>
> >>>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.
> >>>
> >>>      
> >>>
> >>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 ).
> >>    
> >>
> >
> >well i added the "relative to another window" thing as an answer for "kwin
> >does better placement than the apps" - often apps want their dialog up - but
> >centered on their OWN "main" window for example. this can be used in many
> >ways
> >- wm's can still ignore it too, but it gives the app power to say more :)
> >
> >  
> >
> >>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.
> >>    
> >>
> >
> >i definitely think the app NEEDs to be able to say if its requested position
> >is relative to the screen - the glass of the monitor, OR relative to a
> >desktop. often borderless windows like panels, and maybe temporary similar
> >windows want to position themselves relative to the SCREEN and possibly
> >maintain that positionr egardless where the virtual desktop viewport goes
> >(ie sticky) - but this is a different kind of sticky i guess. then there is
> >requested position but it may be relative to the overall massive desktop, or
> >the currently visible section. you could use sticky to try and indicate this
> >- but i dones see any harm in providing more information and allowing the wm
> >to figure out what it wants to do about it. :)
> >
> >  
> >
> >>Sasha Vasko
> >>_______________________________________________
> >>wm-spec-list mailing list
> >>wm-spec-list gnome org
> >>http://mail.gnome.org/mailman/listinfo/wm-spec-list
> >>
> >>    
> >>
> >
> >
> >  
> >
> 
> _______________________________________________
> wm-spec-list mailing list
> wm-spec-list gnome org
> http://mail.gnome.org/mailman/listinfo/wm-spec-list
> 


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