Re: Hints for swallowed pagers and MacOS-style menus

["Michael Rogers" <mrogers cs ucl ac uk>]

> Still, swallowing is very tricky thing to do and prone to hazardous conflicts
> whenever WM, swallower and/or owner app do manipulation to the window being
> swallowed at the same time. Does not happen very often - mostly on
> startups/shutdowns, but can be dangerous nevertheless.

This sounds worrying. Could you give me an example?

> If panel is implemented poorly, effect of "window theft" can be seen in such cases :
> window will get swallowed by one panel, and then when other panel comes up, it
> "steals" window from the first panel, and reswallows it into itself.
> So swallowing apps should take care to check if window about to be swallowed is
> not swallowed by some other app. Again the only way to check it is to see how
> deep from the root it is, and that can vary from one WM to another.
> Accordingly some other property or something is needed to indicate that window is
> swallowed already.

This was the point of having the child window's _NET_SWALLOW_THIS_WINDOW property 
set to its own window ID initially, and changed to None by the swallower before 
swallowing the window. A value of None indicates that the window has been claimed 
by some app and should not be swallowed. I should make that explicit.

> Actually it makes much better sence not to cary the list of window's IDs,
> but instead, have a configuration option in swallowing app, to define what
> windows to swallow by name or class of the window. that scheme is much more
> reliable, flexible and user friendly.

Good idea. This would allow any app to provide a swallowable window without linking 
with the panel. You could write applets which would work in the KDE panel, the 
Gnome panel and the WindowMaker dock. Cool.

OK, I'll try to work out a hint based on window class, which provides protection 
against window theft.


Michael