0010 - Observing CheckButtons
Today’s mission is to have a button exhibit different behaviour depending on the state of another widget, a
Right at the top, as usual, we have to add an import statement:
Now, skip to the end of the file to look at the
This is the observer half of the observer/observed class objects that make up the observer pattern. Our other button (which we’ll look at in a moment, as dull as it is) is watched so the
ObserverButton knows which of two actions to take.
You’ll notice, below the label and other strings representing actions we can take with this button, there’s a pointer to a
CheckButton. It’s passed in through the
ObserverButton’s constructor and assigned to a local variable so we can call its
getActive() function which reads the state of the
The Callback: doSomething()
If you look at the callback (so aptly named:
doSomething) you’ll see the simple logic used to decide which of the two messages to spit out to the command shell.
Everything else here is off-the-shelf, so let’s look at…
Not that’s there’s anything really new here. All we really do is establish the box as parent to both buttons. If we’d built them outside the box, we’d have to drag them in here anyway, so why not?
And Now for Something Completely… Toggled
CheckButton is replaced by the
ToggleButton. The statement:
has been replaced by:
Take a look at the
We’re still adding two buttons, but the
ObservedToggleButton is more elaborate than the simple
CheckButton used in the first example. So, let’s go look at that:
This is what can happen if we want to hook something up to one of the
ToggleButton’s signals, giving it something else to do besides sitting there looking oh-so pretty. All those strings are there to tell us the state of things, not just in the command shell, but on the
ToggleButton’s label, too.
And in the constructor, we’re using a new signal, the
onToggle signal, which we hook up with
A little side note: if we’d wanted to add a callback to the
CheckButton, instead of using the
onClicked signal (inherited from
Button) we could have used
onToggle there, too. But because
CheckButton inherits the signal from
ToggleButton, we’d have to add an extra import statement:
in order to get access to the signal and the all-important hook-up function,
And that’s pretty much it. The
ObserverButton is almost identical to the one in the
CheckButton example. The only significant difference being that it calls the
getMode() to find its state rather than the
getActive() function used with the first example.
And that is a day’s work, two examples that do very much the same thing, a
CheckButton and a
ToggleButton. You might think there’s so little difference that only one is actually needed and maybe that’s the case. But when you think about it, the
CheckButton’s state is visually obvious the moment you glance at it. With a
ToggleButton, we’ve got to go the extra mile and make changes to the label. We could also have changed the colour of the button if we really wanted it to stand out. Either way, though, in the end it comes down to which is more appealing for the GUI design you’re working on.
And that’s it. Until next time, may your wookies eat cookies and don’t stare into any novas.
If you'd like to leave a comment...
Until I get time to research and install a commenting system, I ask that you try one of these options:
- come on over to the D Language Forum and look for one of the gtkDcoding announcement posts,
- drop by the gtkD Forum,
- follow the link below to email me, or
- go to the gtkDcoding Facebook page.
You can also subscribe via RSS so you won't miss anything.
© Copyright 2019 Ron Tarrant