We have had occasion to want to modify the behavior of a component, such as a Slider, via a derived class. However, a number of important functions are implemented through the private pimpl member, which use members of that Pimpl class that code in a derived class cannot access. It would be much easier to customize component behavior if we had some way to access those internal variables via a derived class, which we could do if the Pimpl class were protected instead of private.
Hi, maybe I’ll say something stupid or maybe it’s not allowed by Juce’s license, but it seems to me that it’s possible to copy the library module with your project and modify what you want, just jump to the slider definition to find its code and modify or make accessible what you want.
Certainly I can modify the JUCE SDK, but I’ve been instructed not to by my boss, unless we as a team all decide it’s absolutely necessary.
So you can make your own alternate slider, copy the original rename and modify.
What is the behavior you needed ?
This is technically possible, and not hard to do, like you say. But practically it is not advisable, only as a last resort. Howard’s team has good reasons not wanting to do that, because you will be locked out from future additions and bug fixes of the original class.
The Slider class however is a good example, it is very feature rich, so everybody who changes anything on that class has to be very careful.
The pimpl approach is certainly something to debate, it is not very nice to extend. But many features are exposed already by aggregation, which is by today’s standard the preferred form of adding features.
I doubt the whole architecture of these fundamental classes will change, but it is a fair ask, and up to the juce team to decide.
1 Like
All you have to do now is convince the Juce team to make what you need accessible, considering the opacity of the pimpl architecture…
Slider needs to be more modular. Its’ a right pain when you need to do something custom with it!
6 Likes
Pimpl stands for “private implementation”. The main reason for choosing to structure a class like that is to deliberately make the implementation opaque to end-users, and to stop them doing what you’re asking to do!
Generally whenever you ask any experienced library author to give you more access to the internals of a class so that you can customise it, you should expect the answer to be “NO!” The more external coupling there is to the internals of a class, the less opportunity there is for the authors to change or fix the way that class works, and that’s very bad for long-term maintenance.
The Slider class is definitely one of the more monstrous ones in JUCE though - it has swelled over the years and is badly in need of an overhaul. However, the way to make it better will never be to just let people loose on its internals - like jimc said, it needs to be split up and modularised so that different aspects of its behaviour are individually customisable.
7 Likes
That sounds even better, Jules!
Yes! Add my vote in favor of refactoring slider to be modular!
1 Like
In the meantime, can we get some kind of callback or look and feel to customize the bubble component used for the popupdisplay the slider creates? I was able to customize the paint itself, but not it’s layout and size.
Right now, if the displayed string is short, the bubble is narrow, then when the value changes, the bubble gets wider. I would like to enforce a minimum width, so the bubble seems visually more stable.
Please let us customize the pop up display.
3 Likes
Second this, doesn’t seem to be a way to change the bounds of the popup
Separate FR I guess?
1 Like
Yeah, quite frustrating, I have some Slider that have a lot of transparency around them, so the popup seems massively disconnected, and the distance parameter does support negative values. Ended up adding in a manually controllable X/Y offset for where the arrow should point to work around it.