Giving some Juce to cross-platform tools

Juce in the spotlight

MI makes good...

Part of the reason for Juce's flexibility lies in the elegant use of – dare I mention it – multiple inheritance (MI). I've never been a huge devotee of MI in the past. This was partly sour grapes (Delphi never implemented MI!) and partly because, in my experience, it can result in a minefield of confused and confusing code, similar to the carnage that arises from the unrestrained use of Delphi's WITH statement. However, in Juce, Julian seems to have got it about right. As an example, look at the "Paths and Transforms" page of the demo. You'll see that the source code for this part of the application kicks off with:

class PathsAndTransformsDemo  : public Component, 
                                public SliderListener, 
                                public ComboBoxListener 

{
  // More code here...

This particular part of the demo includes a combo-box component and a set of five sliders, so it needs to be able to listen out for events coming from those two types of user interface control – hence the above declaration. You can create a slider as easily as this:

addAndMakeVisible (scaleSlider    = new Slider (T("scale")));

…and add the Slider to the current component (here, the PathsAndTransformsDemo class) like this:

scaleSlider ->addListener (this);

Once done, the “listening” class can then override sliderValueChanged (defined inside SliderListener) like this:

void sliderValueChanged (Slider*)

{
    repaint();

}

The originating Slider instance is passed to the event handler so the listener can disambiguate multiple sliders on the same page. In this case, we don't need to do that – all five sliders simply trigger a repaint. Two other events, sliderDragStarted and sliderDragEnded, are also defined and can likewise be overridden in the listener, if required.

The point of mentioning all this? You'll remember that last month I looked at Qt which uses a sophisticated signal/slot mechanism in conjunction with a meta-object compiler to connect widgets to classes that respond to user interface events. Using multiple inheritance, Julian has come up with an entirely different – and arguably more straightforward – technique for connecting event producers to event consumers.

I'm sure there are deep, technical reasons why Trolltech went with the signal/slot mechanism, but from where I'm sitting, the only disadvantage of Julian's technique would seem to be that callbacks have a fixed function prototype. You can't, for example, pass arbitrary data (such as the current slider position) as an argument to the callback, thus necessitating a further interrogative call to the widget from within the event handler). To my mind, that's no big drawback. It's certainly interesting to compare the different approaches. As ever, there's always more than one way to skin a cat.