Slider Pimpl


#1

In one of my app, I have a child class of Slider that used to use some of the elements that are not in Slider anymore due to the new implementation (pimpl). For exemple, I have a method resized() that contains: sliderRegionStart = buttonSizeH/2;

Of course, now it tells me that sliderRegionStart in an undeclared identifier. I’m not used to this kind of implementation methods, how could I quickly use gain access to this variable again?


#2

You can’t. The whole point of the pimpl approach is that it stops people writing code that relies on the class’s internal implementation details. It’s there for your own good!

If there’s something that you need to do which can’t be done by just creating a custom lookandfeel, then let’s discuss it - if it’s not completely weird then perhaps it’s something that could be added to the class’s public interface.


#3

I had a nice subclass that displayed only the value box and let you change the value by vertical dragging (like in countless audio plugins, Waves for instance). This class isn’t working anymore because it relied on internal variables of the slider class. Is there any obvious way to recreate this behaviour with the new class, using lookandfeel?


#4

Sounds like a version of the LinearBar mode that doesn’t draw the bar?


#5

Yes, but doesn’t the LinearBar mode only support horizontal dragging (at least that’s why I reimplemented the MouseDrag method in my previous class)?


#6

The slider code should be broken up into multiple individual Component-derived objects, and the original slider re-implemented as a small wrapper that aggregates these sub-objects together. This way the sub-objects can be reused. It would also be possible to write a new aggregated slider that uses different sub-objects or makes the existing ones behave differently.


#7

Can’t a rotary slider have a textbox? That can do vertical dragging…

I think if I was to re-implement the slider class, the main thing I’d do would be to encapsulate the different modes in some kind of virtual “SliderDragBehaviour” classes, so you plug different behaviours in there, or write your own, and keep it separate from the UI.


#8

Yeah, but only the LinearBar paints just the text box if you don’t do anything in the LookAndFeel slider painting method, and lets the textbox react to dragging. All other modes place the text box above, below, left or right and leave some space where the slider graphics (that I don’t want) is supposed to be painted. All I need is a LinearBar where x and y are interchanged, but I can’t do it because of that pimple thing, which is a little bit frustrating…


#9

I’m open to suggestions for minimal changes that’d do what you need.


#10

Well, if there was an option in LinearBar mode to switch between horizontal and vertical dragging, that would already be sufficient… the “value box with vertical dragging” is a pretty widespread widget, not only in the audio plugin world, so there should be some way of creating it with JUCE without jumping through too many hoops.


#11

Would you consider this a “minimal change”? :slight_smile:


#12

Yes, will try to find time to do it at some point…


#13

I’ve now added a LinearBarVertical type… it’s really simple, it basically does everything the same way as LinearBar, except the dragging mode is vertical. Just a few lines with changes in the Slider and LookAndFeel code. It does exactly what I (and I’m sure quite a few others) need, would be cool if you could add it.


#14

Bump-e-di-bump…


#15

Sorry, I didn’t see that post first time round. I’ll have a look at get something done today…