Hello guys !
I need a ComboBox which allows sub menus in my application. Something which looks like that at least. My purpose will be very original, it’s for handling presets and categories of presets.
I have seen there have been a few topics already created on the JUCE forum, with people talking about that issue but in my opinion, none really brought a viable solution. For example there :
So right now, I’m wondering how to do this for real the best possible way. I see three potential solutions :
- Creating a new component, totally independent of any of the standard JUCE classes (I’m not talking about the Component and PopupMenu classes of course)
- Creating a component heriting from the ComboBox class, using mainly the functions made already virtual there, which are showPopup() and addItemsToMenu (PopupMenu&) (strangely, the destructor hasn’t been made virtual in the ComboBox class however)
- Reworking the current ComboBox class to add this feature, and pushing it into the current JUCE code
I’ve been asking myself, what would be the best solution out of these three. The first solution is something I have done already in the past, but I’m not really fond of it myself. I am a fervent activist of the don’t repeat yourself (DRY) principle, so when I need something I want to be able to have it a way that will make its future use as simple and fast as possible. That’s why I like to propose code to the JUCE base once in a while. Moreover, all the look and feel classes are very convenient to use, and I’d like to be able to use the current ones to change the appeareance of my application, instead of tweaking manually the paint functions of custom components. Finally, if I had to do that from scratch properly, I would need to copy and paste a lot of things from the original ComboBox class code, even if I’m developing a custom independent component, and well I think that’s silly.
The second solution seemed to be the best at first glance. However, when I attempt to do so, I discovered a few things in the JUCE ComboBox class which prevented me to succeed. For example, there is absolutely nothing with the status “protected”, which means that whatever I decide to do with the two virtual functions available, I can’t rely on any of the ComboBox internal functions and variables. To summarize, it wouldn’t be possible to use most of the provided functions in the ComboBox class, and I would need to add a lot of code for adding items, my submenus, looking for the selected item etc. And most of the original ComboBox functions would be totally useless. Moreover, I have seen in the 2014 thread that @jules doesn’t want to make protected the class elements that would make that solution convenient. So it doesn’t seem that this solution would be good either.
And… what remains here is the third solution Instead of starting coding something that might become useless if someone from the JUCE team says “no”, I thought I would try to sell my idea, give a proposal for an API and an implementation, and then code it and ask the JUCE team to include my changes in the base code. I understand also that the main worry here is that I would have to do something that can’t break other people code, and don’t make more difficult the adding of any potential future add-ons in the ComboBox class.
I would like also to say once again that such a change would be very useful to most of the JUCE library users, since that demand has already appeared numerous times in the past, and because it would be specifically very useful for preset management in plug-ins.