Re: new hint for EWMH

["Elijah Newren" <newren gmail com>]

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.


Just my $0.02,
Elijah