0070: Statusbar Part I – Statusbar Basics
The Statusbar
is a simple widget, but to demonstrate it, we need something else going on, something that might have a status that needs to be reported. To that end, I borrowed from two previous examples:
- filling a
DrawingArea
(from cairo_01_fill_surface.d), and - tracking the mouse (from mouse_04_tracker.d).
In this example, mouse movements over the DrawingArea
are reported in the Statusbar
. And the most complex part of this example isn’t the Statusbar
itself, but the communication between widgets… not that it’s complicated, just more so than any other part of this code.
The MyStatusbar Class
We only need a few lines to get a working Statusbar
:
class MyStatusbar : Statusbar
{
uint contextID;
string contextDescription = "Mouse position within the DrawingArea";
this()
{
contextID = getContextId(contextDescription);
} // this()
} // class MyStatusBar
Context
Because your application might have a bunch of things going on at the same time—for instance, a drawing application might keep the user informed of mouse position (as in this example) but it might also report on the currently-selected color—you can categorize these things by context.
Each context needs:
- a description of the status category (a string, in other words), and
- a context ID associated with that description.
The context ID isn’t hard to get, just throw a context description at the getContextID()
function and it’ll give back a context ID. Need a second context ID? Throw it another string description and Bob’s your uncle.
This system means that a single Statusbar
can deal with as many contexts as you’re willing to describe.
Although we might assume that the description needs to be elaborate, as it is in this example—I did this just to show the lack of limitations—it’s actually for internal use by your app, the only requirement is that each description be unique, but we’ll talk more about that when the time comes.
The DrawingArea being Reported On
We’ve seen most of the DrawingArea
class code before in the Cairo examples. One thing of note here, though, is that the DrawingArea
is passed a pointer to the Statusbar
so as to allow communication between them. And to do this, the DrawingArea
constructor adds a second signal:
this(MyStatusbar myStatusbar)
{
_myStatusbar = myStatusbar;
setSizeRequest(640, 360);
addOnDraw(&onDraw);
addOnMotionNotify(&onMotion); // track mouse movements
} // this()
The call to addOnMotionNotify()
(borrowed from the mouse example mentioned above) brings a second callback into play:
public bool onMotion(Event event, Widget widget)
{
if(event.type == EventType.MOTION_NOTIFY)
{
_myStatusbar.push(_myStatusbar.contextID, "Mouse position: " ~ format("%s, %s", event.motion.x, event.motion.y));
}
return(true);
} // onMotion()
This is the meat-n-taters of our example right here. A call to the Statusbar
’s push()
function puts the mouse movement report onto the Statusbar
’s message stack and automatically displays it in the Statusbar
at the same time. The format()
function is here just to supply window dressing for the string we’re passing along.
Note: The format()
function uses %s
as a format specifier for the double
values returned by event.motion.x
and event.motion.y
.
Conclusion
Next time, we’ll talk about how to get more out of a Statusbar
by stuffing extra widgets in there and harnessing the Statusbar
’s onTextPushed
signal.
Until then.
Comments? Questions? Observations?
Did we miss a tidbit of information that would make this post even more informative? Let's talk about it in the comments.
- 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. Thank you very much for dropping by.
© Copyright 2024 Ron Tarrant