Re: Proposal: revisiting menus in Gnome
- From: Greg K Nicholson <greg gkn me uk>
- Cc: d-d-l <desktop-devel-list gnome org>
- Subject: Re: Proposal: revisiting menus in Gnome
- Date: Wed, 12 Apr 2017 01:56:27 +0100
Hi Michael, Alberto and Hashem,
First off, thank you for your welcoming and positive responses!
I did know GUADEC was coming to Manchester, and I've been intending to
look into it in more detail. Judging by last year's schedule I think I
just need to get on with it and register. (For the completely
uninitiated, perhaps GUADEC's website could include some links to info
about last year's event, as a rough guide to what to expect?)
Hashem, thank you for your suggestions.
I hadn't thought of removing Quit completely, and it's worthwhile to
consider, but on balance I think there are good reasons to keep it:
- Some apps continue running when their last window is closed (or
might want to) – for example music players, Transmission and some
messaging clients can be configured to do this. In this case, Quit is
a different action from just closing the last window. Firefox doesn't
have this to worry about.
- Some apps are commonly used with multiple windows, for example
LibreOffice, Eye of Gnome, GIMP and Nautilus. A single button to quit
the app is more useful than having to close each window individually.
- It's already there, so we should only remove it if we have a
compelling reason.
I wasn't aware Firefox was switching away from icons in their menu. I
actually had the idea to copy the system menu before I realised
Firefox was already doing something similar. I guess the fact Firefox
ever did it shows it can work in practice.
Perhaps the reason jump list options aren't used often is that they're
difficult to discover? :) The intent is that these are major
entry-points into the app – an email client's might be “Inbox” and
“Compose New Message”, and a web browser might have “New Window”, “New
Private Window”, “Bookmarks” and “History”; Evolution and LibreOffice
could show each of their components. And remember, the dash menu also
contains options to switch between windows, plus the options to manage
the app itself, which we can show even for uncooperative third-party
apps. I think that's a reasonably useful menu.
I see your point about having a dock in the top panel. Personally I
like the focus of only showing the active app. I also wanted to avoid
proposing such a substantial change, which might be less likely to get
agreement.
The App Indicators suggestion is really a whole other proposal, but
very briefly: an App Indicator comprises a status icon for a running
app, plus some menu items that are relevant now. Instead of having a
separate system tray, let's treat these as what they are: running apps
– show the app's icon in the dash, overlay the status icon as an
emblem, and put those menu items in the app's dash menu. The protocol
is supported well enough that we could finally get rid of legacy
system tray icons, and we wouldn't end up with loads of apps polluting
the top bar's system status area.
And lastly, I've made some mockups. The mailing list doesn't seem to
like large attachments, so:
http://gkn.me.uk/stuff/gnome/gnome-menu-proposal.png
http://gkn.me.uk/stuff/gnome/gnome-menu-proposal-annotated.png
http://gkn.me.uk/stuff/gnome/gnome-menu-proposal-help-submenu.png
Cheers,
--
Greg K Nicholson
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]