new hint for EWMH

[Tapani Pälli]

Hello,
I would like to suggest a new hint '_NET_INPUT_AREAS' for EWMH to be
used by window managers and toolkits. This hint would be a list of
rectangles representing bounding boxes of the input methods on the screen.
This allows a toolkit to place it's temporary windows (that might have input-entries)
like popup-menu's so that they won't cover input-method areas and user
can interact with those windows.

I have suggested to have this patch for Matchbox window manager :
http://bugzilla.openedhand.com/show_bug.cgi?id=333

Maemo Gtk+ (and likely other embedded solutions + desktop tablet pc
users) are interested to have this hint.

Waiting for your input,

// Tapani Pälli


_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Lubos Lunak]

On Monday 30 of July 2007, Tapani Pälli wrote:

> Hello,
> I would like to suggest a new hint '_NET_INPUT_AREAS' for EWMH to be
> used by window managers and toolkits. This hint would be a list of
> rectangles representing bounding boxes of the input methods on the screen.
> This allows a toolkit to place it's temporary windows (that might have
> input-entries) like popup-menu's so that they won't cover input-method
> areas and user can interact with those windows.
>
> I have suggested to have this patch for Matchbox window manager :
> http://bugzilla.openedhand.com/show_bug.cgi?id=333

 I'm not sure I understand the purpose of the hint correctly - why not simply
add a new window type for these windows? Could you post a description for the
hint as it should be included in the spec?

--
Lubos Lunak
KDE developer
--------------------------------------------------------------
SUSE LINUX, s.r.o.   e-mail: l.lunak@... , l.lunak@...
Lihovarska 1060/12   tel: [phone]
190 00 Prague 9      fax: [phone]
Czech Republic       http//www.suse.cz
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Tapani Pälli]

ext Lubos Lunak wrote:

> On Monday 30 of July 2007, Tapani Pälli wrote:
>  
>> Hello,
>> I would like to suggest a new hint '_NET_INPUT_AREAS' for EWMH to be
>> used by window managers and toolkits. This hint would be a list of
>> rectangles representing bounding boxes of the input methods on the screen.
>> This allows a toolkit to place it's temporary windows (that might have
>> input-entries) like popup-menu's so that they won't cover input-method
>> areas and user can interact with those windows.
>>
>> I have suggested to have this patch for Matchbox window manager :
>> http://bugzilla.openedhand.com/show_bug.cgi?id=333
>>    
>
>  I'm not sure I understand the purpose of the hint correctly - why not simply
> add a new window type for these windows? Could you post a description for the
> hint as it should be included in the spec?
>  

New Window type is fine for WM but a list of rectangles is much better
toolkit-wise. Without this hint toolkit would need to go through whole
window tree and pick input-method windows and then make collision
detection logic. This is much heavier that having coordinates from the
start. Description below :

---------- 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 input-entry windows
so that they won't overlap input-methods. Property is set and updated by
the Window Manager.

// Tapani

_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Carsten Haitzler (The Rasterman)]

On Fri, 03 Aug 2007 08:28:00 +0300 Tapani Pälli <tapani.palli@...>
babbled:

i think what lubos was getting at is - make the input method window a MANAGED
window (not override-redirect) and just have a new window type - then let the
wm place that type of window anywhere it likes (where it thinks is a good idea
so it won't overlap other windows). i agree - this is cleaner than hinting at
rectangle lists.

> ext Lubos Lunak wrote:
> > On Monday 30 of July 2007, Tapani Pälli wrote:
> >  
> >> Hello,
> >> I would like to suggest a new hint '_NET_INPUT_AREAS' for EWMH to be
> >> used by window managers and toolkits. This hint would be a list of
> >> rectangles representing bounding boxes of the input methods on the screen.
> >> This allows a toolkit to place it's temporary windows (that might have
> >> input-entries) like popup-menu's so that they won't cover input-method
> >> areas and user can interact with those windows.
> >>
> >> I have suggested to have this patch for Matchbox window manager :
> >> http://bugzilla.openedhand.com/show_bug.cgi?id=333
> >>    
> >
> >  I'm not sure I understand the purpose of the hint correctly - why not
> > simply add a new window type for these windows? Could you post a
> > description for the hint as it should be included in the spec?
> >  
>
> New Window type is fine for WM but a list of rectangles is much better
> toolkit-wise. Without this hint toolkit would need to go through whole
> window tree and pick input-method windows and then make collision
> detection logic. This is much heavier that having coordinates from the
> start. Description below :
>
> ---------- 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 input-entry windows
> so that they won't overlap input-methods. Property is set and updated by
> the Window Manager.
>
> // Tapani
>
> _______________________________________________
> wm-spec-list mailing list
> wm-spec-list@...
> http://mail.gnome.org/mailman/listinfo/wm-spec-list
>

--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster@...
裸好多
Tokyo, Japan (東京 日本)
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Mark Tiefenbruck]

> i think what lubos was getting at is - make the input method window a MANAGED
> window (not override-redirect) and just have a new window type - then let the
> wm place that type of window anywhere it likes (where it thinks is a good idea
> so it won't overlap other windows). i agree - this is cleaner than hinting at
> rectangle lists.

I think the argument against this was for applications opening
override-redirect windows, such as pop-up menus. Placing such a window
appropriately would require going through the client list and checking
which ones have the new window type, then querying the geometry and
visibility of each of those windows.

Keeping a list of rectangles up to date seems like too much work,
though. Maybe a list of windows with the new window type would be
better, but I don't think this is necessary at all. Pop-up menus
probably shouldn't be placed over toolbars and docks (which can
display critical information/interfaces), so _NET_WORKAREA should be
fine. I would support a window type for things like on-screen
keyboards; in that case, if the pop-up can't be placed inside the
_NET_WORKAREA, there would be a fallback for avoiding those.

  Mark
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Lubos Lunak]

On Friday 03 of August 2007, Tapani Pälli wrote:

> ext Lubos Lunak wrote:
> > On Monday 30 of July 2007, Tapani Pälli wrote:
> >> Hello,
> >> I would like to suggest a new hint '_NET_INPUT_AREAS' for EWMH to be
> >> used by window managers and toolkits. This hint would be a list of
> >> rectangles representing bounding boxes of the input methods on the
> >> screen. This allows a toolkit to place it's temporary windows (that
> >> might have input-entries) like popup-menu's so that they won't cover
> >> input-method areas and user can interact with those windows.
> >>
> >> I have suggested to have this patch for Matchbox window manager :
> >> http://bugzilla.openedhand.com/show_bug.cgi?id=333
> >
> >  I'm not sure I understand the purpose of the hint correctly - why not
> > simply add a new window type for these windows? Could you post a
> > description for the hint as it should be included in the spec?
>
> New Window type is fine for WM but a list of rectangles is much better
> toolkit-wise. Without this hint toolkit would need to go through whole
> window tree and pick input-method windows and then make collision
> detection logic. This is much heavier that having coordinates from the
> start.

 I see, I guess that makes sense. However that's only some kind of
optimization, I think a window type is still needed to find out which windows
create the regions. That's from somebody who has no clue about input methods
though - from your suggested description I wouldn't have any idea how to
actually implement the support.

--
Lubos Lunak
KDE developer
--------------------------------------------------------------
SUSE LINUX, s.r.o.   e-mail: l.lunak@... , l.lunak@...
Lihovarska 1060/12   tel: [phone]
190 00 Prague 9      fax: [phone]
Czech Republic       http//www.suse.cz
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Carsten Haitzler (The Rasterman)]

On Mon, 6 Aug 2007 15:36:07 +0200 Lubos Lunak <l.lunak@...> babbled:

> On Friday 03 of August 2007, Tapani Pälli wrote:
> > ext Lubos Lunak wrote:
> > > On Monday 30 of July 2007, Tapani Pälli wrote:
> > >> Hello,
> > >> I would like to suggest a new hint '_NET_INPUT_AREAS' for EWMH to be
> > >> used by window managers and toolkits. This hint would be a list of
> > >> rectangles representing bounding boxes of the input methods on the
> > >> screen. This allows a toolkit to place it's temporary windows (that
> > >> might have input-entries) like popup-menu's so that they won't cover
> > >> input-method areas and user can interact with those windows.
> > >>
> > >> I have suggested to have this patch for Matchbox window manager :
> > >> http://bugzilla.openedhand.com/show_bug.cgi?id=333
> > >
> > >  I'm not sure I understand the purpose of the hint correctly - why not
> > > simply add a new window type for these windows? Could you post a
> > > description for the hint as it should be included in the spec?
> >
> > New Window type is fine for WM but a list of rectangles is much better
> > toolkit-wise. Without this hint toolkit would need to go through whole
> > window tree and pick input-method windows and then make collision
> > detection logic. This is much heavier that having coordinates from the
> > start.
>
>  I see, I guess that makes sense. However that's only some kind of
> optimization, I think a window type is still needed to find out which windows
> create the regions. That's from somebody who has no clue about input methods
> though - from your suggested description I wouldn't have any idea how to
> actually implement the support.

technically speaking - there already is a netwm property that lists all windows
(_NET_CLIENT_LIST) so all you need to do is:

1. get this
2. get geometry/attributes and window type property for each of these
3. if window type is appropriate - it works like your rect property.

yes - this is more round-trips, but it feels cleaner to me.

> --
> Lubos Lunak
> KDE developer
> --------------------------------------------------------------
> SUSE LINUX, s.r.o.   e-mail: l.lunak@... , l.lunak@...
> Lihovarska 1060/12   tel: [phone]
> 190 00 Prague 9      fax: [phone]
> Czech Republic       http//www.suse.cz
> _______________________________________________
> wm-spec-list mailing list
> wm-spec-list@...
> http://mail.gnome.org/mailman/listinfo/wm-spec-list
>

--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster@...
裸好多
Tokyo, Japan (東京 日本)
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Lubos Lunak]

Dne pondělí 06 srpen 2007 15:55 Carsten Haitzler napsal(a):

> On Mon, 6 Aug 2007 15:36:07 +0200 Lubos Lunak <l.lunak@...> babbled:
> >  I see, I guess that makes sense. However that's only some kind of
> > optimization, I think a window type is still needed to find out which
> > windows create the regions. That's from somebody who has no clue about
> > input methods though - from your suggested description I wouldn't have
> > any idea how to actually implement the support.
>
> technically speaking - there already is a netwm property that lists all
> windows (_NET_CLIENT_LIST) so all you need to do is:
>
> 1. get this
> 2. get geometry/attributes and window type property for each of these
> 3. if window type is appropriate - it works like your rect property.
>
> yes - this is more round-trips, but it feels cleaner to me.

 Technically speaking :) - there is already a netwm precedent, _NET_WORKAREA,
that your approach above also makes not needed, yet it is there. I admit
though that _NET_WORKAREA is not a very good argument for many reasons.

 I'd be currently fine to provide such feature in KWin, based on the
(currently insufficient) knowledge of this area.


--
Lubos Lunak
KDE developer
--------------------------------------------------------------
SUSE LINUX, s.r.o.   e-mail: l.lunak@... , l.lunak@...
Lihovarska 1060/12   tel: [phone]
190 00 Prague 9      fax: [phone]
Czech Republic       http//www.suse.cz
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Nathaniel Smith]

On Mon, Aug 06, 2007 at 10:55:20PM +0900, Carsten Haitzler wrote:
> technically speaking - there already is a netwm property that lists all windows
> (_NET_CLIENT_LIST) so all you need to do is:
>
> 1. get this
> 2. get geometry/attributes and window type property for each of these
> 3. if window type is appropriate - it works like your rect property.
>
> yes - this is more round-trips, but it feels cleaner to me.

Not just more round-trips -- you need to monitor for changes, i.e.,
select for props on the root window (to catch _NET_CLIENT_LIST
updates) and then look at every new window to see what type it is, and
also monitor for ConfigureEvents on all input windows in case they
change size.

Alternatively, instead of selecting for events to stay up to date,
one could re-poll all those windows every time one wants to display a
menu.

Since this would be in the toolkits, with either approach we're
actually talking about every app doing all of these things all the
time.  That seems totally crazy to me.

-- Nathaniel

--
Details are all that matters; God dwells there, and you never get to
see Him if you don't struggle to get them right. -- Stephen Jay Gould
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Mark Tiefenbruck]

> Not just more round-trips -- you need to monitor for changes, i.e.,
> select for props on the root window (to catch _NET_CLIENT_LIST
> updates) and then look at every new window to see what type it is, and
> also monitor for ConfigureEvents on all input windows in case they
> change size.
>
> Alternatively, instead of selecting for events to stay up to date,
> one could re-poll all those windows every time one wants to display a
> menu.
>
> Since this would be in the toolkits, with either approach we're
> actually talking about every app doing all of these things all the
> time.  That seems totally crazy to me.

Maybe my response didn't go through. Why not just use _NET_WORKAREA?
Pop-up windows shouldn't be going over docks/toolbars, anyway, since
they might also have critical UI elements. Then, all you need is a
window type for these input method windows, and the window manager can
update its struts.

  Mark
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Nathaniel Smith]

On Sat, Aug 04, 2007 at 08:00:19PM -0700, Mark Tiefenbruck wrote:
> Keeping a list of rectangles up to date seems like too much work,
> though. Maybe a list of windows with the new window type would be
> better, but I don't think this is necessary at all. Pop-up menus
> probably shouldn't be placed over toolbars and docks (which can
> display critical information/interfaces), so _NET_WORKAREA should be
> fine. I would support a window type for things like on-screen
> keyboards; in that case, if the pop-up can't be placed inside the
> _NET_WORKAREA, there would be a fallback for avoiding those.

My pop-up menus with GTK/Gnome/Metacity are happy to go over the dock
right now, and it seems like the right thing to me... why would you
expect otherwise?

(Most clients do not select for PropertyNotify on the root window, do
they?  With all the proposals suggested so far, all apps would have to
start doing so, with the resulting extranous wakeups and thus power
problems, not to mention the general memory manager unfriendliness of
waking up dozens of otherwise-idle programs all at once all the time.)

-- Nathaniel

--
Details are all that matters; God dwells there, and you never get to
see Him if you don't struggle to get them right. -- Stephen Jay Gould
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Mark Tiefenbruck]

> My pop-up menus with GTK/Gnome/Metacity are happy to go over the dock
> right now, and it seems like the right thing to me... why would you
> expect otherwise?

I'd expect pop-up windows to stay within _NET_WORKAREA because that's
the geometry of the desktop. Windows shouldn't be placed outside it
because they might interfere with important widgets. And just
aesthetically, I think pop-up windows should remain within the window
that owns them; as a bonus, when implemented as child windows, this
avoids all the nastiness of grabbing the server (causing xmms to stop,
breaking alt-tab, etc.), but it's usually not an option.

Anyway, don't bother arguing with that. I know I'm in the minority.
So, how many of these input method windows do you expect to see at a
time? How often do they get moved or resized? Are they free-floating
(like xvkbd), or do they stick to the sides of the screen? I don't
think I'm the only one who's not totally sure how these interactions
take place.

> (Most clients do not select for PropertyNotify on the root window, do
> they?  With all the proposals suggested so far, all apps would have to
> start doing so, with the resulting extranous wakeups and thus power
> problems, not to mention the general memory manager unfriendliness of
> waking up dozens of otherwise-idle programs all at once all the time.)

No, you don't have to listen to the root window continuously. Just
check the property when you need to open a pop-up window.

  Mark
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Tapani Pälli]

ext Mark Tiefenbruck wrote:

>> My pop-up menus with GTK/Gnome/Metacity are happy to go over the dock
>> right now, and it seems like the right thing to me... why would you
>> expect otherwise?
>>    
>
> I'd expect pop-up windows to stay within _NET_WORKAREA because that's
> the geometry of the desktop. Windows shouldn't be placed outside it
> because they might interfere with important widgets. And just
> aesthetically, I think pop-up windows should remain within the window
> that owns them; as a bonus, when implemented as child windows, this
> avoids all the nastiness of grabbing the server (causing xmms to stop,
> breaking alt-tab, etc.), but it's usually not an option.
>
> Anyway, don't bother arguing with that. I know I'm in the minority.
> So, how many of these input method windows do you expect to see at a
> time? How often do they get moved or resized? Are they free-floating
> (like xvkbd), or do they stick to the sides of the screen? I don't
> think I'm the only one who's not totally sure how these interactions
> take place.
>
>  

Well, actually for Maemo only IM is visible at time but I've heard
argument that on some tablet-pc:s there can be several at time
especially with asian languages. With Maemo the original problem was
that our browser's url-entrycompletion is very close to IM (on top of
it) and while you were writing url, entrycompletion would popup it's
completion-list (from history) covering partly top of IM so one could
not continue writing anymore (or at least use all of keys). It might be
that this proposal is not optimal solution everywhere though.

>> (Most clients do not select for PropertyNotify on the root window, do
>> they?  With all the proposals suggested so far, all apps would have to
>> start doing so, with the resulting extranous wakeups and thus power
>> problems, not to mention the general memory manager unfriendliness of
>> waking up dozens of otherwise-idle programs all at once all the time.)
>>    
>
> No, you don't have to listen to the root window continuously. Just
> check the property when you need to open a pop-up window.
>
>  

Yep, this is how I thought it would work. Update property whenever IM
window is mapped/unmapped.

>   Mark
> _______________________________________________
> wm-spec-list mailing list
> wm-spec-list@...
> http://mail.gnome.org/mailman/listinfo/wm-spec-list
>  

// Tapani

_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Tapani Pälli]

ext Lubos Lunak wrote:

> On Friday 03 of August 2007, Tapani Pälli wrote:
>  
>> ext Lubos Lunak wrote:
>>    
>>> On Monday 30 of July 2007, Tapani Pälli wrote:
>>>      
>>>> Hello,
>>>> I would like to suggest a new hint '_NET_INPUT_AREAS' for EWMH to be
>>>> used by window managers and toolkits. This hint would be a list of
>>>> rectangles representing bounding boxes of the input methods on the
>>>> screen. This allows a toolkit to place it's temporary windows (that
>>>> might have input-entries) like popup-menu's so that they won't cover
>>>> input-method areas and user can interact with those windows.
>>>>
>>>> I have suggested to have this patch for Matchbox window manager :
>>>> http://bugzilla.openedhand.com/show_bug.cgi?id=333
>>>>        
>>>  I'm not sure I understand the purpose of the hint correctly - why not
>>> simply add a new window type for these windows? Could you post a
>>> description for the hint as it should be included in the spec?
>>>      
>> New Window type is fine for WM but a list of rectangles is much better
>> toolkit-wise. Without this hint toolkit would need to go through whole
>> window tree and pick input-method windows and then make collision
>> detection logic. This is much heavier that having coordinates from the
>> start.
>>    
>
>  I see, I guess that makes sense. However that's only some kind of
> optimization, I think a window type is still needed to find out which windows
> create the regions. That's from somebody who has no clue about input methods
> though - from your suggested description I wouldn't have any idea how to
> actually implement the support.
>  

Yep this is 'minor' optimization and makes toolkit code more clean, it's
a bit 'ugly' to have these 'go through all windows' loops there. WM
naturally knows the IM windows (hint needed for this aswell ... Maemo
uses '_NET_WM_WINDOW_TYPE_INPUT' for this) and updates hint whenever
such windows is (un)mapped, so implementation is quite trivial.

// Tapani

_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Lubos Lunak]

On Monday 13 of August 2007, Tapani Pälli wrote:

> ext Lubos Lunak wrote:
> > On Friday 03 of August 2007, Tapani Pälli wrote:
> >> New Window type is fine for WM but a list of rectangles is much better
> >> toolkit-wise. Without this hint toolkit would need to go through whole
> >> window tree and pick input-method windows and then make collision
> >> detection logic. This is much heavier that having coordinates from the
> >> start.
> >
> >  I see, I guess that makes sense. However that's only some kind of
> > optimization, I think a window type is still needed to find out which
> > windows create the regions. That's from somebody who has no clue about
> > input methods though - from your suggested description I wouldn't have
> > any idea how to actually implement the support.
>
> Yep this is 'minor' optimization and makes toolkit code more clean, it's
> a bit 'ugly' to have these 'go through all windows' loops there. WM
> naturally knows the IM windows (hint needed for this aswell ... Maemo
> uses '_NET_WM_WINDOW_TYPE_INPUT' for this)

 Please don't use such name for private properties, use a private prefix.

> and updates hint whenever
> such windows is (un)mapped, so implementation is quite trivial.

 Could you please post a complete text you'd like to see included in the spec?

--
Lubos Lunak
KDE developer
--------------------------------------------------------------
SUSE LINUX, s.r.o.   e-mail: l.lunak@... , l.lunak@...
Lihovarska 1060/12   tel: [phone]
190 00 Prague 9      fax: [phone]
Czech Republic       http//www.suse.cz
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Tapani Pälli]

ext Lubos Lunak wrote:

> On Monday 13 of August 2007, Tapani Pälli wrote:
>  
>> ext Lubos Lunak wrote:
>>    
>>> On Friday 03 of August 2007, Tapani Pälli wrote:
>>>      
>>>> New Window type is fine for WM but a list of rectangles is much better
>>>> toolkit-wise. Without this hint toolkit would need to go through whole
>>>> window tree and pick input-method windows and then make collision
>>>> detection logic. This is much heavier that having coordinates from the
>>>> start.
>>>>        
>>>  I see, I guess that makes sense. However that's only some kind of
>>> optimization, I think a window type is still needed to find out which
>>> windows create the regions. That's from somebody who has no clue about
>>> input methods though - from your suggested description I wouldn't have
>>> any idea how to actually implement the support.
>>>      
>> Yep this is 'minor' optimization and makes toolkit code more clean, it's
>> a bit 'ugly' to have these 'go through all windows' loops there. WM
>> naturally knows the IM windows (hint needed for this aswell ... Maemo
>> uses '_NET_WM_WINDOW_TYPE_INPUT' for this)
>>    
>
>  Please don't use such name for private properties, use a private prefix.
>
>  

OK, I think the original intention was to push that hint for EWMH aswell
and therefore name it like that from the beginning. I guess this new
window-type would be OK?

>> and updates hint whenever
>> such windows is (un)mapped, so implementation is quite trivial.
>>    
>
>  Could you please post a complete text you'd like to see included in the spec?
>  

Yep, I'll work on it.

// Tapani

_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Tapani Pälli]

ext Mark Tiefenbruck wrote:

>> Not just more round-trips -- you need to monitor for changes, i.e.,
>> select for props on the root window (to catch _NET_CLIENT_LIST
>> updates) and then look at every new window to see what type it is, and
>> also monitor for ConfigureEvents on all input windows in case they
>> change size.
>>
>> Alternatively, instead of selecting for events to stay up to date,
>> one could re-poll all those windows every time one wants to display a
>> menu.
>>
>> Since this would be in the toolkits, with either approach we're
>> actually talking about every app doing all of these things all the
>> time.  That seems totally crazy to me.
>>    
>
> Maybe my response didn't go through. Why not just use _NET_WORKAREA?
> Pop-up windows shouldn't be going over docks/toolbars, anyway, since
> they might also have critical UI elements. Then, all you need is a
> window type for these input method windows, and the window manager can
> update its struts.
>
>  

This sounds a good idea, but it limits IM windows to always grip on edge
of the screen, which might not be wanted on tablet pc's. It would be
enough currently for Maemo though ...

>   Mark
> _______________________________________________
> wm-spec-list mailing list
> wm-spec-list@...
> http://mail.gnome.org/mailman/listinfo/wm-spec-list
>  

// Tapani

_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Lubos Lunak]

On Tuesday 14 of August 2007, Tapani Pälli wrote:

> ext Lubos Lunak wrote:
> > On Monday 13 of August 2007, Tapani Pälli wrote:
> >> Yep this is 'minor' optimization and makes toolkit code more clean, it's
> >> a bit 'ugly' to have these 'go through all windows' loops there. WM
> >> naturally knows the IM windows (hint needed for this aswell ... Maemo
> >> uses '_NET_WM_WINDOW_TYPE_INPUT' for this)
> >
> >  Please don't use such name for private properties, use a private prefix.
>
> OK, I think the original intention was to push that hint for EWMH aswell
> and therefore name it like that from the beginning. I guess this new
> window-type would be OK?

 I would think so. The point is however that if the semantics change for the
spec, you either have to live with that or the name for the spec needs to be
different (even though, in this specific case, TYPE_INPUT is probably too
vague). Not to mention the case that something completely different would
make it into the spec with this name.

--
Lubos Lunak
KDE developer
--------------------------------------------------------------
SUSE LINUX, s.r.o.   e-mail: l.lunak@... , l.lunak@...
Lihovarska 1060/12   tel: [phone]
190 00 Prague 9      fax: [phone]
Czech Republic       http//www.suse.cz
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Tapani Pälli]

ext Lubos Lunak wrote:

> On Monday 13 of August 2007, Tapani Pälli wrote:
>  
>> ext Lubos Lunak wrote:
>>    
>>> On Friday 03 of August 2007, Tapani Pälli wrote:
>>>      
>>>> New Window type is fine for WM but a list of rectangles is much better
>>>> toolkit-wise. Without this hint toolkit would need to go through whole
>>>> window tree and pick input-method windows and then make collision
>>>> detection logic. This is much heavier that having coordinates from the
>>>> start.
>>>>        
>>>  I see, I guess that makes sense. However that's only some kind of
>>> optimization, I think a window type is still needed to find out which
>>> windows create the regions. That's from somebody who has no clue about
>>> input methods though - from your suggested description I wouldn't have
>>> any idea how to actually implement the support.
>>>      
>> Yep this is 'minor' optimization and makes toolkit code more clean, it's
>> a bit 'ugly' to have these 'go through all windows' loops there. WM
>> naturally knows the IM windows (hint needed for this aswell ... Maemo
>> uses '_NET_WM_WINDOW_TYPE_INPUT' for this)
>>    
>
>  Please don't use such name for private properties, use a private prefix.
>
>  
>> and updates hint whenever
>> such windows is (un)mapped, so implementation is quite trivial.
>>    
>
>  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.


// Tapani

_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Elijah Newren]

Hi,

On 8/16/07, Tapani Pälli <tapani.palli@...> 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
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list