0094: Hardware I – Monitors

Knowing the size and position of the application window (Blog Post #90, #91, and #92) becomes more important if your user has more than one monitor. Most will use one as a primary where they do 90% of their work while relegating the other(s) to such tasks as reference materials, etc. I’m sure you know that, but it makes a great preamble to today’s topic.

But before we dig in, let’s go over some…

GTK/GDK Hardware Class Objects

The following objects are not really hierarchical. Some contain pointers to the others while still others just stand by themselves. For easiest access to almost all of them, start with a Display to grab a pointer to the default Seat or the default Screen.


Back in the day (like, 1960s and ’70s) when computer technicians were first moving away from using punch cards, the interface that caught on was the terminal consisting of a keyboard, a monitor, and (eventually) a pointing device.

That concept lives on in GTK as the GTK Seat. A Seat is considered to be any and all hardware available to a single user at a single workstation. In other words, if the user doesn’t have to get up from his seat to physically touch the device, it’s part of his GTK Seat. That will include a keyboard, one or more monitors, and a pointing device.


A Display is any and all hardware providing visuals to a single user at a single workstation. What makes it stand out from all the other hardware objects is that the Display is part of GDK, not GTK. The Seat is about tracking all user hardware whereas the Display is about the visuals. You can access the Seat from the Display using getDefaultSeat(), but the Display’s main purpose is to act as a container for anything the user will be looking at:

  • the monitor(s),
  • the cursor,
  • the pointer, and
  • the Screen.


Figure 1: Seat, Display, and Screen
Figure 1: Seat, Display, and Screen

So, we’ve got the monitors, the Display and the Screen. So… what’s a Screen? This is the most abstract concept of the three. Where Seat represents a collection of user hardware and a Display is a collection of monitors, a Screen is the visible surface area of all the monitors collectively. So, it’s not the monitors, but the monitor screens all butted together into one single surface.

And why do we care about all this?

Sometimes, you need to put a window on a specific monitor… or capture the input from a keyboard or pointing device before it gets processed through other widgets. Or, as I’ve been going on about for the last few blog posts, you might want to do your users a favor and give them predictable sizing and positioning for windows and dialogs as a way to boost productivity.

So, let’s start by…

Monitoring the Monitors

Results of this example:
Current example output
Current example output
Current example terminal output
Current example terminal output (click for enlarged view)

The basic idea here is to ask the gdk.Display how many monitors it has. This code can appear anywhere you wanna put it, so I picked the top-level window just to keep the demo as brief as possible. We start by adding two definitions to the TestRigWindow preamble:

Display myDisplay;
int monitors;

Which means the constructor becomes:

	myDisplay = Display.getDefault();
	monitors = myDisplay.getNMonitors();


} // this()

We grab the default Display, the one that all GTK applications have right out of the box, and from there, we get the number of monitors. This number is then reported in the monitorReport() function:

void monitorReport()
	writeln("Your set-up has ", monitors, " monitors");
} // monitorReport()

But we’re not stopping here. Next time, we’ll go after a full report on the Screen and the monitors that make it up. Until then, have a happy coding life.

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.

You can also subscribe via RSS so you won't miss anything. Thank you very much for dropping by.

© Copyright 2023 Ron Tarrant