Comments on: Further thoughts on extending the window menu

By: Killerkiwi

Killerkiwi — Thu, 16 Jul 2009 23:00:44 +0000

Sound control is some thing that needs to be bound to the window some how…

Every sound playing application having its own sound level slider / mute option is just silly :)

Pulseaudio already has the beginnings of this in that you can set the xid for any stream it just needs to be all bound together

By: A meta-post about blogging « ᛏᚦ

A meta-post about blogging « ᛏᚦ — Thu, 16 Jul 2009 22:19:08 +0000

[...] for CSS theming and window matching, and whether applications should be able to extend the window menu (so if you have Istanbul installed, you could add Screencast this window to all windows.) Hop [...]

By: ulrik

ulrik — Thu, 16 Jul 2009 21:14:07 +0000

@Oliver: That can be valid. Hopefully in the future desktop windows are going to be really interesting objects to act on.

By: Olivier Samyn

Olivier Samyn — Thu, 16 Jul 2009 15:52:40 +0000

From the small window menu, there I do not see much added value.

But, the same menu is used when you right click on the window title bar. And it may be used in various other places in the future (i’m thinking about the gnome-shell scaled windows view, why not when your right click on it be able to interact with your application). If there is an easy way to expose custom menu entries, it should be easy for other applications to also display those entries n their contextual menus (for example the gnome taskbar).

This allows you to quickly access some specific applications actions without bringing the whole window to the front.

By: ulrik

ulrik — Thu, 16 Jul 2009 14:25:43 +0000

I don’t think this post or the previous one explains *why?*.

Why do we want to mix in a few application menu entries into the window menu? Take screenshot ok, it’s very window-centered, but Play absolutely not! There is already a menu in the window normally, the gtk menu (even though I prefer a global menu bar). Does it really help the user to have very random non-window actions in the window menu?

By: stancil

stancil — Thu, 16 Jul 2009 11:35:10 +0000

For ∀:

I agree this needs to be managed in an external way. But i think there are not that much cases besides the things that actually exist and some other features like “Take Screenshot” or something else. In my opinion the interesting part is ∃.

For ∃:

My idea would be to extend the current API so that programs can register functions through a callback mechanism. Something like

add_to_taskbar_menu(icon, text, function)

To be honest I dont know if this fits into the current architecture. Are programs allowed to alter the menu, or is it a pure metacity thing?

By: Olivier Samyn

Olivier Samyn — Thu, 16 Jul 2009 11:34:24 +0000

For ∀ menu entries, using GConf seems not a bad idea.

And for ∃ is not D-Bus an option ? This should provide a way for applications to interact with window managers that supports it. Of course, applications should not rely on that feature to work, but use it as an option.

Using D-Bus will also be really dynamic, letting the application change menu entries depending on their own internal state (example: Rhythmbox may change entries when it’s playing or not).

That said, if D-Bus is used, entries provided through GConf for ∀entries, may also be provided by an other application (session management for example).