The existing popup menu lists all the notebook tabs first then shows command items below. This means the command items are harder to access (user has to move mouse further). They can also get pushed off screen when there are many tabs open (see https://github.com/geany/geany/pull/2346#issuecomment-539842133). Instead, let's split up the menu for better UX.
New notebook action widget menu, left or right click ☰ button: 
Commands-only tab menu: 
The single close item has been grouped separately and put first because:
> This will be the most common choice for anyone who disables notebook tabs. This also groups the commands closing multiple documents separately from the other commands. Closing multiple documents is a more drastic action so should be grouped separately. You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/2348
-- Commit Summary --
* Use gtk_widget_show_all in show_tab_bar_popup_menu * Remove unnecessary casts * Notebook tab menu: Move tab filenames to button menu at end of tabs * Move single close item to top of menu
-- File Changes --
M src/notebook.c (56)
-- Patch Links --
https://github.com/geany/geany/pull/2348.patch https://github.com/geany/geany/pull/2348.diff
codebrainz commented on this pull request.
void notebook_init(void)
{ + GtkWidget *btn = gtk_button_new_with_label("☰");
I think I've seen in some GNOME apps they use icon button with an icon like `view-list` or `view-more` or maybe some more semantically correct name for same icon. I guess the advantage of the icon is that it looks correct no matter which font or size being used (ex. in my browser here, it looks like an equal symbol).
I haven't tried this yet in practice, but it seems like a good improvement.
This will be the most common choice for anyone who disables notebook tabs.
If they disable notebook tabs, why does it matter? Isn't the menu only shown for people who keep tabs enabled?
This also groups the commands closing multiple documents separately from the other commands. Closing multiple documents is a more drastic action so should be grouped separately.
This doesn't really give a good reason for the ordering, for example an alternative layout that puts the _least_ drastic action first but maintains grouping of "close" related items together would be:
``` Open in New Window ---- Close Close Other Documents Close Documents to the Right (Close Documents to the Left) (Close Documents in Same Folder) (Close Documents in Other Folders) Close All ```
If they disable notebook tabs, why does it matter?
Sorry, I meant to write disabling notebook tab close buttons. I think that's a gnome hig recommendation (which I don't like).
One downside to this is that you have to move the mouse further to click the menu button than before. Clicking any tab is easier.
A simpler solution to this pull would be to move the fixed commands above the notebook tab item list. As they don't change they shouldn't appear in different vertical positions depending on number of tabs.
an alternative layout that puts the least drastic action first
But we should also consider frequency of use - I would guess Close would be used more often than Open in New Window.
Closing a single document is not a drastic action.
ntrel commented on this pull request.
void notebook_init(void)
{ + GtkWidget *btn = gtk_button_new_with_label("☰");
Ok, but do they work on Gtk 2? (More generally, how do we know which strings are guaranteed to have icons with Gtk 3, is there a list of common strings? (I saw they deprecated stock items).
ntrel commented on this pull request.
void notebook_init(void)
{ + GtkWidget *btn = gtk_button_new_with_label("☰");
BTW haven't tried it, but Gtk 3 has a menu button widget that defaults to a down arrow: https://developer.gnome.org/gtk3/stable/GtkMenuButton.html
Sorry, I meant to write disabling notebook tab close buttons.
I didn't even realize that option existed until now. I would guess users who do that, it is because they use the keybindings.
One downside to this is that you have to move the mouse further to click the menu button than before... A simpler solution to this pull would be to move the fixed commands above the notebook tab item list.
I was going to suggest doing that until I saw this PR for splitting it which seems nicer. I personally don't think it's a big deal that you move your mouse to a different location.
But we should also consider frequency of use - I would guess Close would be used more often than Open in New Window.
I would guess the large majority of users don't disable the tab close buttons and of those that do, don't use the menu to close tabs. Personally I don't think I've _ever_ used to item to close a single document from that menu, though I use all of the others often.
Closing a single document is not a drastic action.
Indeed, but it's more "drastic" than not closing any document.
I think that's a gnome HIG recommendation (which arguably doesn't apply widely to programmers).
Agree, the HIG is written for the lowest common denominator, we can reasonably allow developers more options.
Closing a single document is not a drastic action.
In some ways it is, it _irreversably_ loses edit history and any document settings. But that applies more to closing multiple documents with a single action where the user may accidentally include a document they didn't mean to close.
@ntrel pushed 0 commits.
I meant to write disabling notebook tab close buttons.
I would guess users who do that, it is because they use the keybindings.
Using a keybinding/toolbutton to close doesn't work when you want to close a tab that isn't the current one, but they could use the documents sidebar - it's harder to find a document though as the order is different.
Anyway I've removed the close item reordering, as I don't know which is used the most, close or open in new window. BTW if I wanted to use the close menu item I would prefer it was first.
ntrel commented on this pull request.
void notebook_init(void)
{ + GtkWidget *btn = gtk_button_new_with_label("☰");
@codebrainz I read that "open-menu-symbolic" is the icon that matches the unicode symbol. But that doesn't work on GTK2 with gtk_image_new_from_icon_name.
in my browser here, it looks like an equal symbol
Seems like a font bug?
codebrainz commented on this pull request.
void notebook_init(void)
{ + GtkWidget *btn = gtk_button_new_with_label("☰");
I read that "open-menu-symbolic" is the icon ...
Yeah, I think that's the one I was trying to remember. Depending on icon theme I think I've seen various images used such as three vertical dots or a gear as well.
But that doesn't work on GTK2 with gtk_image_new_from_icon_name
It should work fine if you have this icon installed. If it's not commonly available, we could always ship a fallback icon like we do for the other non-standard ones we use.
Seems like a font bug?
Nah, it's just because the font size is small so two of the lines are squished together making it look more like an equal sign than a list/burger. This is why an icon might be better, it doesn't depend on the user having their font size set large or having a proper Unicode font installed.
elextr commented on this pull request.
void notebook_init(void)
{ + GtkWidget *btn = gtk_button_new_with_label("☰");
a fallback icon like we do for the other non-standard ones we use.
:hamburger: FTW!!
github-comments@lists.geany.org