GNOME Bugzilla – Bug 470101
Context menu of a task should allow application-defined shortcuts
Last modified: 2020-11-06 20:23:27 UTC
I think the idea of having both a tray and a task list is a bad idea because I often find myself searching for my application. Sometimes I restore the window from the task list, sometimes from the tray icon. I would get rid of tray icons completely, and instead, move their contextual menu to the task list. The current contextual menu has items that are much less useful, because they correspond to already-visible buttons (minimize, maximize, close, and top-left). Other information: Some are proposing to add a fourth button: minimize to tray (Bug 140592), but I hate adding an other button. How will users make sense of it? How will it look like? Others are proposing that all applications that can minimize to tray should do so when the close button is clicked. Ok, it improves consistency, but it does not fix the inherently broken UI, because I will still tend to look at the task list, before I remember not to do so for a particular application. My proposal means it will not be possible to hide an application from the task list. An workaround is to move the applications you want to hide to an other workspace. A perhaps better workaround is to allow task items to shrink to a bare icon instead of a large button. This would look much more like tray icons, but they would be at the right place with other tasks, and would not be battling against tray icons.
It would be nice if contextual options would be available from task list items, but the tasklist shouldn't be mandatory for having notifications. Some people don't use the task list applet at all. The real problem is that some apps are abusing the notification area for 'minimized execution mode' which is simply wrong - however it's much easier to do than writing a panel applet.
I would agree with the less drastic change of keeping the notification area only for notifications (ban "minimize to tray"), and my proposal here is to help application developers go in that direction. The notification area has two advantages (let alone the notification feature): * It does not clutter the task list; * It provides an application-specific menu; For the first one, perhaps the task list should allow applications to use less space (a single icon). Maybe I should open a separate feature request for that. My proposal addresses with the second advantage of tray icons over the task list, currently. In any case, whether or not the application minimizes to tray, it would be nice to have a uniform way to interact with an application from the task list. Dropping the notification area completely is only secondary to my proposal, to illustrate my point, but it should still be taken seriously. Perhaps that should have its own bug too so we can discuss it separately.
Dropping the notification area completely would be a bad idea because it currently implements the freedesktop.org system tray spec. Although maybe it could be implemented differently, dropping support for the spec would be a regression in cross-desktop compatibility. http://standards.freedesktop.org/systemtray-spec/systemtray-spec-0.2.html
I have been mixing issues and ideas here. Let me simplify. This bug is a proposal to enhance the task list to allow applications to add custom menu items. For Rhythmbox, that would probably mean having "Play/Pause, Previous, Next, Random (checkbox), Repeat".
Why do you want to reimplement the tray?
I stumbled on this while browsing the interwebs and just want to leave a note, that it can probably be closed. Gnome 3 nowadays has "Jump Lists", or does it? I'm not sure, as I don't use it. But I am sure it has no task list anymore. ;) Anyways, somebody should clean the bug tracker once in a while. :D
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old bug reports in Bugzilla which have not seen updates for many years. If you can still reproduce this issue in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/gnome-panel/-/issues/ Thank you for reporting this issue and we are sorry it could not be fixed.