Re: Use-positions-properly-dammit hint



Are there many EWMH clients that are doing this sort of abuse?  If
mostly the abusers are those that don't support EWMH, then it's not
likely to help much.  Otherwise, clients could simply detect EWMH
support by checking for the existence of a supported hint at all, and
follow those guidelines.

-Rob

On Thu, 2006-08-10 at 18:17 +0200, Lubos Lunak wrote:
>  Hello,
> 
>  this is basically a followup to the "USPosition vs. PPosition with Virtual 
> viewports" thread, this time with a patch :).
> 
>  To quickly sum up: Some apps abused PPosition, so WMs started to ignore 
> PPosition. So apps moved onto abusing USPosition. So basically now it's a big 
> mess with many windows having PPosition|USPosition and WMs having no idea if 
> the app just happens to be stupid or if it really has a good reason for that.
> 
>  The solution :) :
> 
> _NET_WM_FULL_PLACEMENT [*]
> 
> By including this hint in _NET_WM_SUPPORTED_LIST the Window Manager announces 
> that it performs reasonable window placement for all window types it supports 
> (for example centering dialogs on the mainwindow or whatever handling the 
> Window Manager considers reasonable). This in turn means that Clients[**], 
> when they detect that this hint is supported, SHOULD NOT abuse or often even 
> use PPosition and USPosition hints for requesting placement. In particular:
> - USPosition is reserved to be used only to indicate that the position was 
> specified by the user and MUST NOT be used for anything else (see ICCCM 
> section 4.1.2.3 for details)
> - PPosition SHOULD be used for for specifying position only if a specific 
> position should be used. Position SHOULD NOT be specified for "default" 
> placement such as centering dialog windows on their mainwindow.
> 
> Rationale: Window managers can often perform better placement (that may be 
> even configurable) for windows than the application. However at the time of 
> writing this it is problematic for Window managers to decide when to use them 
> because many applications abuse positioning flags and/or provide unnecessary 
> default positions.
> 
> [*] Suggestions for a better name are welcome
> [**] Question: Should it be also required that Clients set the same hint e.g. 
> in their WM_PROTOCOLS (or a newly made hint) to show that they conform? It 
> should not be strictly necessary because the WM should be able to simply act 
> sanely and only old broken apps (which won't have the support anyway) will 
> keep abusing the flags.
> 
> 
>  Comment, improvements, objections? I already have some patches for Xinerama 
> support developed that use this hint (so there's a working 
> implementation :) ).
> 




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]