Using fltk::app::screen

help
1

So, in my usual clumsy way I've been experimenting with the rust version of FLTK. Today I've been messing around trying to find the coordinates of the center of my screen. I finally put together something that worked and here it is below:

use fltk::app::Screen;

fn main() {
    let mntr1 = Screen::new(0).expect("Could not find screen.");
    let width = mntr1.w();
    let height = mntr1.h();

    let cntr_x = width / 2;
    let cntr_y = height / 2;

    println!("\nWidth =  {}", width);
    println!("\nHeight =  {}", height);

    println!("\n The center point is:   ({}, {})", cntr_x, cntr_y);
}

Here is the output:

Width =  2684
Height =  1096
 The center point is:   (1342, 548)

Of course, I really don't know what I'm doing, and now I'm wondering just what it is that I found. The actual screen resolution I'm using is 3440 x 1440 which doesn't match up with the output above. Anyone care to try explaining this to me? Thanks.

Oh, and I'll bet someone can show me a better way to accomplish finding the center of my screen. The idea is to eventually use those coordinates to place a FLTK widget at that location.

2

The aspect ratios don't match up, either (2.448 vs. 2.388); furthermore, 2684 x 1096 doesn't seem to be a commonly used resolution.

  • Can you check that you are inspecting the correct screen? Ie., try unplugging all but one screen and retry.
  • Check the X and Y coordinates of the screen using the x and y methods. Maybe the returned coordinates really represent a drawing area available to your application (eg. excluding the top bar/chrome or the panel at the bottom of the screen) rather than the physical screen.
1 Like
3

Can you try app::screen_size() which returns a tuple. The Screen struct mostly deals with what FLTK considers a working_area.

1 Like
4

Well, I only use one screen, so that isn't the issue.

That could be it. I use POP OS Linux with the Gnome GUI and there is a narrow top bar that isn't available to an application. That probably is enough to throw the aspect ratio off.

I used the bottom_right() method. Here's the output:

The bottom right corner is:     Coordinates { x: 2684, y: 1123 }
Width =  2684
Height =  1096
The center point is:   (1342, 548)

That gives me an aspect ratio of 2.39 and since we're looking for 2.388, I think that's close enough. Apparently, the upper bar in Gnome is enough to throw the aspect ratio off for the working area.

5

Just did that. Here's the output:

 The screen size is:   2684 x  1096

That kind of confirms that it's the top bar in the Gnome GUI that is throwing the numbers off.

That satisfies me. Thanks for your help, guys. :cowboy_hat_face:

6

The difference between the physical display size (3440 x 1440) and the Monitor::bottom_right (2684 x 1123) is almost certainly due to a scaling ratio you have configured in the desktop environment (it's approximately 1.28). The common terminology for this difference is "physical pixels" vs "logical pixels", where the latter refers to what the compositor will use for pixel coordinates (but not for rasterization).

In addition to using @MoAlyousef's suggestion to get the physical logical [1] pixels, you can also use app::screen_scale() to get the scaling ratio for each dimension (which I suspect is approximately 1.28). The scale can be used to transform pixel coordinates between the physical space and logical space.

  1. Edit: Looks like screen_size() returns logical units! ↩ī¸Ž

3 Likes
7

@parasyte That really clears things up for me. Good explanation. I figured I'd dig into the 3440 x 1440 vs 2684 x 1123 disparity later, but you explained it very well. Thanks.