elements
elements copied to clipboard
cycfi
combobox widget
A combobox, as described by Qt and wxWidgets, is a combination of a textbox (editable or read only) and a listbox/menu to display a list of selectable items.
Currently Elements provides a similar control with dropdown menu buttons, which can't display the selected item directly on the button label.
It would be a composite control with an optional item icon on the left, the selected item label on center and an arrow icon on the right.
I'm currently using button menus
This is too vague.
could be a control with an optional item icon on the left, the item value label on center and the arrow icon on the right
Elements is full of composable widgets. You should be able to make a menu which arbitrarily nests different elements. The gallery contains many example widget-hierarchy factories.
IMO, there probably should be more (different) menu factories. I haven't looked deeply over all of them (yet) but I think I don't like the currently offered ones.
Sorry, I was talking about the dropdown menus, here from the gallery:
but I wasn't able to find something like a combobox, the following could be what it could be called a ownerdrawn combobox. The icon is not something I use but I listed it as some optional feature.
Terribly busy at the moment, but please note that all these are in my radar screen and I will act on it as soon as I loosen up tasks currently in front of me.
Quick note: Yes of course it is possible.
I'm not expecting this to be done quickly, just added this "TODO/feature request" because AFAIK this is one of the most used widgets and I use it every time I need to display a choice on many. In the meanwhile I try to code something myself, also a way to get more familiar with the library.
It seems I haven't noticed the selection_menu series, so I copied and then modified one to accept a vscroller, so quite good as combobox for now.
Could you share a sample code? I'm interested in a widget described in #33 and while it is already possible to code it, elements should offer much better support for such complex widgets.
Thanks, I will take it as an example when implementing my own needs. Few notes:
- You should use
!items.empty()instead ofitems.size()because this expresses the intent clearer, sometimes some people stare at code likeitems.size() ? x : yand wonder whether this is a bug or a very implicit-convertion-heavy code was intended. - The functor reminds me of one of small things I don't like in elements: menu callbacks should not get strings as the representation of selected option; for multiple reasons:
- strings are much heavier than any alternative index mechanism (enum, iterators, integers)
- 2 options can have the same string
- options do not even have to be strings - they can be arbitrary elements
- strings are type unsafe for indexing purpose (casing errors, empty strings, unnecessary data, data inconsistency)
As I wrote earlier, I haven't looked thoroughly into menus yet but definitely there are parts that I dislike and would like to improve through PRs. I'm currently waiting for Joel to response on many other issues. Please share any positive/negative experience with menu/button APIs if you have.
I'm getting here a step at a time as I go through the "issues"....
As you noticed, the ingredients are already there. Essentially... think of the element directory as a kitchen where you have all the ingredients, and the gallery as a store where you can buy pre-made, ready-to-eat food. If you want something that is not provided by the gallery, you customize what is there to your taste. So, the gallery will evolve over time as more use-cases emerge.
I absolutely welcome custom gallery submissions! Or, better yet, improvements of what's already there.
Thank you for the answers! Elements is the choice we have for our common plugin project as unified UI solution for AU, LV2 and VST3 versions, I think I'll use it also on other personal projects of mine, so we surely come back with some other feedback.