Re: Some thoughts about window management

[Yaron Tausky <decaycell gmail com>]

On Wed, 2005-06-22 at 11:50 -0700, Alex Graveley wrote:
> Mike, I know you've looked closely at solving this, just wondering what 
> I'm missing...
> 
> Seems we could signal the app to show it's in-process menu at a given 
> screen offset, with a given XID (the panel) as the parent, and avoid 
> marshalling altogether?
> 
> -Alex
> 
> Mike Hearn wrote:
> >
> > b) It's hard to implement because (unlike in Windows) menus are not shared
> >    between processes. So you'd need to define a marshalling format for
> >    menus and then teach GTK+ to marshal any given menu, and then teach
> >    the window managers what to do with it. Sounds like a lot of work and
> >    complexity for relatively little gain.

The problem is that we have to merge two menus: the app's menu items,
the the WM standard functions. This can either be done by the app
(though I tend not to like it, as it relies on the app's good will and
prone to abuse), or by the panel -- either way one process has to tell
the other about it's menu structure (which can be quite complex --
labels, icons, toggle and radio selections, sub-menus, seperators etc.).

While I agree that this is a rather complex feature (that would have to
be formed and standardized in cooperation with other projects), I argue
that the gain isn't small at all. There are talks about a cross-desktop
applet specification, and that would require the implementation of this
feature too (so that we can have a "Remove From Panel" option that would
work on a Qt-based app, for example). This can be seen here[1].

Some serious work has to be put into the panel, but in the end we would
have cross-desktop applets, a notification area that is actually used
for notification, and a standard way to have apps running in the
background and leaving an icon as a dock. I think it worths it.

[1] http://www.freedesktop.org/wiki/Standards_2fSystrayAndAppletsMeeting
-- 
Yaron Tausky <decaycell gmail com>