Put the menubar in the titlebar or have a deducated menubutton on the left side (not default hamburger) #1243
Replies: 5 comments 7 replies
-
|
Indeed, there isn't much of an alternative proposed by the Gnome guidelines, at least when I last read through it. IIRC, libadwaita's |
Beta Was this translation helpful? Give feedback.
-
|
I love the new UI coming with 3.0. I am so excited for it! :) Personally, regarding the question of menubars vs hamburger menus... in my opinion, the best solution is neither. The best way to handle exposing many functions to users in software like this, is via a searchable command palette. Some great examples of this are Dune 3D (a CAD program) and the old Plotinus GNOME extension.
Simply put, you press a button, and an overlay appears showing you a list of available actions, along with their keyboard shortcuts (so you can memorise them). This list of actions is ideally context-sensitive, so unlike a traditional menu bar, it only shows you the actions that are actually relevant for you at the time. The list is quickly searchable, so you can type what you want and it will find it for you immediately. Type "blu" and suggestions for gaussian blur might appear, for example. That's the best way to go. |
Beta Was this translation helpful? Give feedback.
-
|
That is a very good suggestion to think about for a future version, especially since it can be hard to find specific effects from nested menus even when there is a regular non-hamburger menubar. |
Beta Was this translation helpful? Give feedback.
-
|
I'm glad you think so. I included some example clips above from the old Plotinus extension because they were easily grabbable from their GitHub page — but I think the app Dune 3D might be worth taking a look at, as it's using GTK4 and being actively maintained, so it might be a better reference. Here's how it looks in Dune 3D:
Spacebar just brings up this context-aware command palette, and it appears near the mouse cursor for quick access. Very handy and makes it a breeze to interact with the program. |
Beta Was this translation helpful? Give feedback.
-
This is a good solution for showing all options, overall. A command palette even helps with discovering tools and options that the user didn't know existed. I think there should simultaneously be a discussion on exposing such features as effects in their own panels, along with their options, much like how Path Effects are handled in Inkscape. Reason being, the more tools get added, the less inclined the user is to go searching for them. However, if tools can be grouped into areas that the user expects, this can eliminate extra steps and/or speed up their workflow by making certain steps have a "shortcut" (that doesn't involve searching). |
Beta Was this translation helpful? Give feedback.
-
|
Give the option to have a menubar please instead of the button (ideally in title bar where the shortcuts currently are). We don't all use Gnome (or Linux), so it feels unnatural and constricting. |
Beta Was this translation helpful? Give feedback.
-
|
I'm thinking that panels are the way forward for certain tools, but I need to give this some more thought as to how it should be implemented. I'm thinking what GIMP, Inkscape, and tools like Figma, PenPot, and Affinity have is ideal. |
Beta Was this translation helpful? Give feedback.
-
|
Figma has a full menu hamburger in the upper left corner I think. This is the standard solution for cramming traditional cascading menubars into hamburgers. |
Beta Was this translation helpful? Give feedback.
-
|
So, I am still actively using pinta and some features of the new release are great. Thank you for adding in the ability to rotate in partial degree increments. I also appreciate that work that was recently completed to introduce negative rotation in the rotate tool and look forward to seeing it released. I will say the new menu/ short cut bar at the top makes things harder. I realize everyone has their own work flows but the majority of mine involve a fairly routine process.
the new short cut bar works awesome for every process except the rotate function. I would say my average edit time is decreased by several seconds each. I don't know if there is an easy approach to allow the addition of additional shortcuts from the hamburger menu to the main bar to eliminate digging through the hamburger? Thank you for your work on this project it is greatly appreciated. |
Beta Was this translation helpful? Give feedback.
-
Perhaps a customizable toolbar, as is found in some other tools? If certain tools found in those menus could be made available as actions (I don't know GTK well enough, but I think this is possible?) that could then each have an icon, users could choose what actions to show/hide from the toolbar. Would need a dialog that lists the commands shown in the toolbar/headerbar though. |
Beta Was this translation helpful? Give feedback.
-
|
#1386 also has some discussion about making the layer-related actions more accessible in the layers panel. Having a keyboard shortcut for the Rotate/Zoom Layer action would also be a good idea |
Beta Was this translation helpful? Give feedback.
-
I the keyboard shortcut would be a bonus but having the option to move common tools to the main toolbar would be better. Most of the work I do is 100% mouse and the less a person has to change to the keyboard or click down through multiple menus the quicker it works. Or at least that is the way it seems. I can acknowledge that maybe my workflow is different than others but I always try to make things as efficient as possible. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
It's bad usability to shove the full menubar into a hamburger, especially if the hamburger is in the right corner. Gnome doesn't recommend putting huge menu hierarchies into the hamburger, though they also don't propose much of an alternative. One could keep the hamburger for a few elementary actions (shortcuts, help etc) but the full menubar should be its own thing and should not be crippled by trying to shoehorn it into a design that's intended for barebones utility and content consumption applications. And it often fails even for those - I've used Chrome for over a decade and that bloated hamburger menu remains a usablity nightmare that I will never get to used to.
I think either a full menubar in the titlebar like VS Code, or a dedicated (preferably rectangular so it's easier to click) "Menu" button on the left would be better. As a bonus, it would also help serve as a roadmap for other GTK apps to move to a more modern CSD style in a way that makes sense and without needlessly crippling the UI.
Edit: The standard solution for stuffing cascading menus into a hamburger is a "triple equals" button in the upper left corner. Not ideal but it's pretty standard at this point in apps that don't use traditional menubars. So I retract my recommendation to use some kind of special "Menu" button - the triple equals hamburger button on the left is the standard and therefore seems preferable.
Beta Was this translation helpful? Give feedback.
All reactions