Closed hfiguiere closed 3 years ago
It's hard to tell from the screenshot, but it looks like the menu is not being displayed properly? The black arrows look a bit weird, wondering why they are all the way to the right like that. Are you able to in fact navigate to each item up to the very last item? Maybe another screenshot(s) if possible. Seems like a system style issue. Meanwhile, in the Global Settings GUI Tweaks tab, there is the "scrollable submenus" button that @kybos added, it is supposed to turn the menus into a single scrollable list. Still tedious perhaps, but does it work?
The right side is a panel with empty item BUT a >
and the lead to a submenu (one is displayed) - thats where the mouse pointer is.
But whatever this is, it is really hard to use.
Whatever the UI tweak is, it is at its default value as I wiped the app configuration,
By enabling scrollable menu I get a scrollable menu. It make this only marginally better.
Yeah, bummer, I know, too much stuff in there. As I just said yesterday in another thread:
I have long been trying to design a replacement for all those popup menus which potentially may have many items. It would be more of a mini popup 'tree' widget than a popup menu. However, the convenience and features of popup menus is a powerful thing to ignore and attempt to replace and duplicate in some other scheme.
Perhaps it is time to take a serious look at replacing them, eh?
The right side is a panel with empty item BUT a >
Hm, seems it is not working properly. Looks like a style problem. Can you try changing the style or choose a stylesheet in Appearance Settings? It is supposed to look like this:
there is the "scrollable submenus" button that @kybos added
@terminator356: No, it was not me ;-). Yet both variants of the option work quite well for me (Cinnamon, with Qt Fusion style set in MusE).
I don't have so many plugins installed, but some synths have huge amount of patches that are also displayed in popup menus (e.g. amsynth). Yes, it's difficult to find something there, but I am not sure a tree popup would make it better (but of course I don't know what exactly you have in mind).
I would rather suggest to replace (or supplement) the "More..." string by the first entry of the individual submenu (maybe elided if necessary). That would improve the orientation in such huge lists immensely IMO.
Oops, sorry that was danvd's (Andrew) work.
Interesting suggestion, replacing the 'More...' with the first items. Much like say... an index in a book, or a categorized A-Z web page listing. It would show, at a glance, where each section starts, for easier navigation. One slight problem: With that first item being shown instead of 'More...', then do we actually include (duplicate) that first item in the submenu? Or should we make that top parent item clickable (which is possible I think, but unusual), and therefore leave it out of the actual submenu?
No, the parent item should not be clickable in any special way, that would be very non-standard (of course it must be normally clickable to open the sub-menu). I don't see the parent item as a duplicate, only a pointer or index, and I would also put it in parentheses/elide it/put three dots behind it or anything you can think of, to make it clear it's not the "real thing" but only an orientation help. We could even keep the "More..." thing and put the first entry in parentheses behind it, for example.
Gotcha. Ah yes, now I see the reason for the elide suggestion, we don't want some menu column's width to be unnecessarily overwhelmed by one rogue long-named parent item, the full text will be shown in full in the submenu.
You know, I don't think it never dawned on me to make it like an index. If it did, I probably felt it would be too 'redundant'. (Neatness freak?) [ Desperately tries to find holes in the suggestion... Seems solid, me thinks. ] What was I thinking of, with 'More...'. Thanks bro, good one!
Gotcha. Ah yes, now I see the reason for the elide suggestion, we don't want some menu column's width to be unnecessarily overwhelmed by one rogue long-named parent item, the full text will be shown in full in the submenu.
Exactly, that was the idea.
My idea was more:
Add synth > Synth 1
Synth 2
Synth 3
Synth 4
--------
More...
Where the first 4 (number to be determined) would be the most used (or most recently or a combination of), with a default being the MESS synth that come with MuSE. It could also be a small number of "favourites" that the user like.
More...
would open a dialog with a proper list of synth. The synth selected would end up being one of the entries above. This is a place where the user could mark their favourite plugins.
Also things I think should be avoided:
Just my idea.
In git master now: OK I changed it. (And found + fixed an old bug.) We can play with the actual text later I suppose. Suggestions? I tried a few things, this seemed the least offensive for now. The elide is done based on the number of characters in the string rather than the pixel width of the menu column's available text area (which is actually not possible to find without using custom actions etc.). I simply take the first twenty characters. left(). Hopefully it remains consistent with different font sizes.
One small problem is that by using the text of the first item of the submenu, it is possible the items in the submenu were not added in particular textual order, so the first item may not be the first in textual order. On the other hand if that's how the items were added and intended to be seen by the user, then by golly I guess we have to use the text of that first item, eh?
@hfiguiere Interesting. Favourite and recent -based listings for the synths.
Windfisch added this favourites feature to the plugin dialog:
But... oops, it does not seem to work for the LV2 plugins. Sigh... another bug hunt...
Should be fixed in git master now. My fault. Fixed regression at 03.02.2020: Plugin dialog user 'categories' not showing LV2 plugins It happened when I switched all the LV2 stuff to show URIs instead of library paths. One line slipped through the cracks. Thanks for leading me to this bug!
In git master now: OK I changed it. (And found + fixed an old bug.) We can play with the actual text later I suppose. Suggestions? I tried a few things, this seemed the least offensive for now. The elide is done based on the number of characters in the string rather than the pixel width of the menu column's available text area (which is actually not possible to find without using custom actions etc.). I simply take the first twenty characters. left(). Hopefully it remains consistent with different font sizes.
One small problem is that by using the text of the first item of the submenu, it is possible the items in the submenu were not added in particular textual order, so the first item may not be the first in textual order. On the other hand if that's how the items were added and intended to be seen by the user, then by golly I guess we have to use the text of that first item, eh?
Thanks for implementing it. I completely agree with your solution, no change suggestions on my part.
I noticed another issue, however: When using the VST version of amsynth, no menu is opened when I click on Patch name in the mixer strip of the midi track. With the LV2 version it works.
Meh... amSynth is a little weird. You're lucky I have it installed.
No patches for you today, sir!
From the dispatcher() function:
case effSetProgram:
case effGetProgram:
case effGetProgramName:
return 0;
I offer this glimmer of hope for the ugly popup menu situation:
Psst! Hey, you know that audio controller popup menu I mentioned? The one that may contain thousands of controllers? (Surge has 666 of 'em.) Very tedious to navigate, and to get an overview of your controllers.
So... Eight years ago I started a code unit to replace all of that with a proper dialog with a table listing all the controllers. Each row includes everything that you see in the popup menus. Including a colour chooser, and even the 'learn' function and its assignments. You can see all your controllers at a glance.
The unit got lost in time. I could swear I threw it into our current tree for safe-keeping, but no, it was not there. So I spent an hour rummaging through my old PCs and found it! I have put it into our tree now so that I might finish it. It is in /components/control_mapper.cpp/h/ui
It was my first time working with item delegates, so it is a bit messy. But my vast experience since then with the Advanced Router and other stuff should make it easier for me to finish.
Yes, I know, we really need to replace some of the menus, including the synth and patch choosers. Since we already have a list of synths in the Midi/Synth Config dialog, I was thinking of making that list a reusable component and we'll pop that up as a synth chooser. Something like that... maybe.
Cheers. Tim.
Trying to catch up on my mails... I agree the plugin/synth menus are not very usable and get outright unfriendly when there are a lot of items. And the menues (for reasons I absolutely do not understand) look different on different computers. Qt seems to chose different ways of displaying them, all by itself.
Can't we simply reuse the plugin dialog, maybe with some tweaks? I'm a big advocate for the text filtering box there, I use it 99,3% of the times I'm looking for a plugin.
It ain't pretty but I cooked up a little menu proposal that would suit me very good. Some hard coded items at the top, then the 'Add...' which brings up a more advanced dialog. And finally a search box which would make a short list below, maybe 5/10 items long with what bubbles up from the search.
I have observed the poster's menu problem. When I choose the Adwaita style, I get the arrows but missing texts. Yeah, after so many years of dealing with these crazy styles, I sure know what you mean:
It bears repeating that the OOM fork of MusE completely removed custom colours and style and appearance stuff in favour of one giant overriding master stylesheet. One reliable look, one reliable feel, that's it. One dev once said "MusE is NOT a desktop application!". I didn't disagree, I knew the pain and trouble that would alleviate. But I was caught off-guard by the suggestion, like a deer caught in headlights. Deep thoughts about our design, trying to decide how to respond and whether to change MusE at all. He certainly had a strong valid point. But we put so much effort into customization that removing appearance features seemed unthinkable for MusE - at the time styles were, well, simpler, and we seemed to handle them fairly well ;-)
I know what you'll say: We have that option, we support stylesheets well now, and if someone desires, they could make a whole one (given better access to our widgets). So that's how I decided. To forge ahead supporting both stylesheets and styles, and our custom-drawn controls with customizable colours all at the same time. Ugh. What a can of worms, eh? He he.
It ain't pretty but I cooked up a little menu proposal that would suit me very good. Some hard coded items at the top, then the 'Add...' which brings up a more advanced dialog. And > finally a search box which would make a short list below, maybe 5/10 items long with what bubbles > up from the search.
Another (similar) suggestion:
Keep the context menu as it is now, it works well when there are not so many synths/effects. Add another menu item below like "Add synth from dialog...". In the synth dialog, make a fixed "Favourites" tab. If the user defined some Favourites, add a "Favourites" submenu to the context menu OR list the Favourites as own items in the context menu (after a separator line).
Or even, no fixed Favourites, let the user define his/her own groups, and display these dynamically as submenus.
There is a new selection dialog for the synths incl. Favorites maintenance. Favorites are also displayed in the Synth submenu when available.
The original problem with the menu display shouldn't occur in MusE 4 anyway, so closing this.
When I want to add a Synth track it seems that I have too many plugins installed:
As you can see the menu is all over the place and navigation is hard.