Re: new hint for EWMH

[Tapani Pälli <tapani palli nokia com>]

ext Elijah Newren wrote:
> Hi,
>
> On 8/16/07, Tapani Pälli <tapani palli nokia com> wrote:
>   
>>>  Could you please post a complete text you'd like to see included in the spec?
>>>
>>>       
>> OK, 2 new things specified here. a new window type + a new root window
>> property
>>
>> ---------- 8< -------------------------------------------------------
>>
>> Section : Application Window Properties
>> ...
>> _NET_WM_WINDOW_TYPE_INPUT, Atom
>>
>> _NET_WM_WINDOW_TYPE_INPUT indicates that the window includes an input-method such as a virtual keyboard or area used by hand-writing recognition software. Window manager can use this information to position input-methods in it's own fashion and avoid overlaps with regular application windows.
>>
>> ---------- 8< -------------------------------------------------------
>>
>> Section : Root Window Properties (and Related Messages)
>> ...
>> _NET_INPUT_AREAS
>>
>> _NET_INPUT_AREAS CARDINAL[]/32
>>
>> This array contains a list of input-method areas. Toolkit and applications can use this
>> information to place their pop-up (such as entry-completion or search pop-up)
>> windows so that they won't overlap input-method areas. Property is set and updated by
>> the Window Manager.
>>     
>
> Why not make a more generalized strut property instead?
>
> Magnification windows and other accessibility tools would probably
> like to use these; currently they just restrict themselves to the side
> of the screen and use the current strut properties.
>
> This would probably also solve the issue of vertical panels midway
> between xineramas.  Users have complained about windows being hidden
> by such panels, horizontally maximized windows not avoiding them, etc.
>
>
> Sure, you mention having toolkits make popups avoid that area on the
> screen, whereas struts are predominantly only honored by WMs to the
> best of my knowledge.  However, that's a nasty bug for the
> accessibility folks and there's an open GTK bug on the issue.  I do
> realize that there is a can of worms about whether override-redirect
> windows should avoid taskbars, so maybe we do need both a more
> generalized strut and something else like your hint.  But even in that
> case your hint should be generalized (in name) to not exclude
> accessibility tools.
>
>   

Any suggestions on the name? I'm a bit worried to have it too generic
since that will lead to situation where there will be different
implementations using this 'generic' hint for different things as it's
not specific enough.

> Just my $0.02,
> Elijah
>   

// Tapani