-
Notifications
You must be signed in to change notification settings - Fork 796
Session dialog improvements #991
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
It did nothing. And it was called in different contexts, making it hard to imagine which single thing it possibly could do.
…gins _disable_plugins was the only widget in SessionDialog that had set_can_focus(). That made it look like something special was going on there. But that is not the case. "can_focus" is already the default, and there is no point in setting it again. Remove it, and make it a bit more clear what is going on with focus control.
The file had a bit of structure and grouping, but didn't use it consistently. These changes might not make it perfect, but I think it makes it better.
…ial state The dialog always has 3 different tabs. After changing the tab, the window title became misleading. It seems more helpful to use a windows title that shows the intent of the dialog: Selecting a session.
The mnemonics only show up when pressing the Alt key and do not do any harm.
The hardcoded numbers were fragile ... especially if the numbers should happen to change in the future ...
…ead of custom ArdourButton In my opinion, the ArdourButton approach for SessionDialog introduced in 524073d regressed in some annoying ways: * No keyboard shortcuts. * Big panes look a bit like Tcl/Tk. * YELLING. While it seems like keyboard shortcuts for ArdourButton would be handy in many places, it doesn't seem trivial to add it. Plain GtkNotebook seems to work better: * Keyboard shortcuts for changing tabs. * More standard look. With these changes, New and Recent works pretty well with keyboard navigation. There should only be minor changes when using mouse. The buttons are of course smaller, but that not be a problem for users that can navigate other parts of the Ardour UI. Keyboard navigation in GtkFileChooser remains broken for now. There is thus not much use of keyboard navigation to open the Open page, but we add it anyway.
…* calling callbacks Allow signal_switch_page to move focus into the page, instead of forcing focus on the label that just was activated. This is very useful for SessionDialog for allowing the same behaviour when changing page with mouse and keyboard.
The "New" page moves focus to "Session name", and there was no easy way to get the template list at the top of the page. Fix that by showing the header line (even though the table only has one column in Ardour) and put a mnemonic on "Template". Headers are already shown by default and there is no need to enable them explicitly - just don't hide them.
x42
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is used in downstream projects
x42
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have no issues using keyboard shortcuts with the current layout. it works just fine here without a mouse (I do that many times a day, new sessions, recent sessions..) One can Tab to different widgets just fine.
What issue does this address?
|
Since three downstream projects will need to have the current dialog (with different logo), we cannot merge this as-is. |
It is very interesting information if keyboard navigation works for you in this dialog. It doesn't work for me at all. No relevant mnemonics, no tabbing to the buttons for changing page, and no working tab navigation in the file chooser widget. I assumed everybody saw the same, and I worked towards making it work for me instead of complaining. I'm using Gnome/Wayland/Fedora. What Linux desktop environment are you using? Perhaps I can find a workaround that achieves enough of the same. Meanwhile, perhaps some of the changes adding new mnemonics can be used in all cases. |
|
Ah you're right I cannot use the keyboard to navigate to "New" on the side. That'll need some On our ongoing quest to modernize the look/feel we've removed most gtk notebook tabs (also editor sidebar) and the excess borders those added. For interaction ArdourButtons are preferable since they implement multi-touch support. I've ping'ed you on IRC, it would [have been] nice to discuss the changes before moving forward. |
|
My first attempt was to try to find a way to add keyboard navigation (mnemonics and tabbing) to the ArdourButtons, but could not find a way to make it work. Is it possible without significant changes to ArdourButton? ArdourButton doesn't seem to be much like the "native" gtk widgets. FWIW, I do not think these big yelling buttons look like a modernization and I see no UI hints that they actually change pane/page. I also don't understand the use case for multi-touch when changing page in a "notebook". I thus don't see any improvements, only regressions. |
|
It would be nice to find a working compromise here. |
|
Agreed, any solution would be great, no matter if would be a compromise or a perfect solution. Also great if my contribution here could be used. First, let's clarify: Do we agree on the main problem I'm trying to fix: The lack of tab navigation and mnemonics in the session dialog? Do you consider it feasible to make tab navigation & mnemonics work with ArdourButton as it is used now? Or should ArdourButton mainly be used on the canvas with the fine tuned UI, while plain gtk widgets might be preferable in plain dialogs? Do you kind of agree on the direction of these changes: Change these ArdourButton to plain "set_show_tabs"? Then comes the challenge of Ardour upstream not only carrying disabled but working downstream code, but apparently also carrying dead code that is used by hidden-source downstreams, and constraints of fixed UI design where we can't pragmatically analyze the actual use cases. That's pretty much a show-stopper for contributing. I learned that you have been hurt by GTK and decided to fork it. So now you are stuck with the old buggy GTK, not only for canvas (where I agree on using custom widgets), but also for plain dialogs (where I'm less convinced custom widgets are the best solution). But here we are, and our task now is to try to work around old gtk2 bugs. Is the main problem with my "gtk notebook tabs" approach that they seem to add another layer of embossed borders? Do I understand correctly that the changes would be more acceptable if it somehow didn't do that? |
|
We were not hurt by GTK. GTK2 has been EOL'ed by numerous Linux distributions, and will surely be EOL'ed by them all in the not too distant future. So we vendored it into our own source tree to make it reasonably easy to build Ardour moving forward. We have already added multitouch to it, improved macOS rendering behavior, and there will likely be more to come. There was never any chance of us moving to newer versions of GTK, so this has not changed the future at all. |
|
Re: mnemonics ... I cannot think of any other dialog where we use mnemonics on buttons. There are almost no keyboard bindings available, and certainly almost no "obvious" ones, so I am not clear what your thinking is around this. Re: navigation ... tab navigation is strongly desirable. |
|
Yes, ideally we'd allow tab navigation, while retaining the borderless plain layout with themable ArdourButtons.
|
|
Could you check if recent git address your issues? You can tab to sidebar buttons, and activate them with space and/or enter.. |





I have been working on addressing some usability issues, mainly introduced by 524073d. This works much better for my use case, and I think it should work fine for other use cases too.
Please look at the individual commits. The last ones might not meet all use case requirements (yet), but please cherry-pick the first more trivial ones.