[Ubuntu] How get screen available geometry?
-
Hello everybody,
for a couple of week, I'm trying to solve the question in the title - How get screen available geometry?
Of course, I'm fully aware of QScreen methods, such as availableGeometry() or geometry() or properties such as QScreen::size - but the issue seems to be (and the reason, why I'm mixing all those methods together), they all return the same value - screen total resolution.
While what I'm trying to achieve is - get available screen geometry, for s/w windows. Meaning, initial coordinates (top,left I guess) and width/height for a screen not including ubuntu taskbar height at the top and ubuntu dock (sidebar at the left) width.
Hence, total screen geometry isn't helpful. Now, maybe I'm missing something and/or lacking some knowledge - I have quite a few years of experience developing for Windows (C++ too), but that's my first project on Linux. So it's very probable that I'm missing something. I've done my research and tried quite a few tactics, but none yielded yet. Anyhow, feel free to point out my mistakes.
How should I:
- How get screen available geometry? (geometry being my explanation above)
- How get a window current size and coordinates?
- How get ubuntu system bars (taskbar/dock) height and width?
Target system: Ubuntu Ubuntu 24.04 LTS, using Wayland (if that's matters)
Hopefully, all of the above can be achieved using QT tools, but feel free to direct me to any system APIs if necessary. Anyhow, since that's my first Linux project, any explanation (even who's calling who) will be greatly appreciated.
-
You should take a look at https://doc.qt.io/qt-6/qscreen.html#availableSize-prop
-
Hello Christian and thank you for replying.
My bad, sorry - my current code's calling QScreen::availableSize() (I should've mentioned it) but unfortunately it too returns the whole screen resolution.
To be clear, the code in question currently looks like:
QScreen* screen = QGuiApplication::primaryScreen(); //static method QSize aSize = screen->availableSize();at runtime aSize is assigned: 2560x1440 (QHD resolution as far as I know, hence the whole screen).
-
This might be a Wayland issue. I don't use Wayland so someone else must check it
-
Hello Christian and thank you for replying.
My bad, sorry - my current code's calling QScreen::availableSize() (I should've mentioned it) but unfortunately it too returns the whole screen resolution.
To be clear, the code in question currently looks like:
QScreen* screen = QGuiApplication::primaryScreen(); //static method QSize aSize = screen->availableSize();at runtime aSize is assigned: 2560x1440 (QHD resolution as far as I know, hence the whole screen).
@AlexK7
Like @Christian-Ehrlicher I wonder if this is a Wayland thing.I run Ubuntu 24.04 with GNOME but under Xorg. It's a bit hard to tell, because I run inside a VirtualBox which has its own menus/furniture, but if I full screen on a 2560x1440 monitor I get
QSize(2494, 1294). Width-wise there is just the GNOME shortcut bar down the left, and that could well be 66 pixels wide? The 1294 is 146 short of 1440, which might be the top & bottom "furniture" I get from the VB host. And certainly I do not get the full 2560x1440. So I think Xorg is indeed excluding windowing furniture and your behaviour is Wayland. There may be a way to get what you want from Wayland but I don't know what call, for you to investigate. -
This might be a Wayland issue. I don't use Wayland so someone else must check it
@Christian-Ehrlicher Not might be - definitely is. Under the core wayland protocol, applications are not allowed to know anything about surfaces belonging to other applications - not their size, not even that they exist. The information given to applications about screens via the
wl_outputprotocol object is just their full size in physical units.This by itself is not so serious restriction, since the protocol also prevents applications from doing anything based on that information - as applications are not allowed to position themselves (or even query their own position), or obtain input events from outside their surfaces.
@AlexK7 one escape hatch to is to run under the XWayland protocol, which allows much more information for backward compatibility. Run with the environment variable
QT_QPA_PLATFORM=xcb. It would help to describe what your eventual goal in knowing this information is, since if you are doing something which is more shell-like, you may need to use specialized Wayland protocols or compositor-specific APIs. -
Hello Christian, JonB and thank you both for replying.
As for the question at hand, it's twofold (as I see it). First, yes - I've suspected it might be Wayland related. That's why I've mentioned it in the first place. Unfortunately, I haven't found a clear contact for Wayland/Ubuntu developers. If somebody can point out a proper channel, such as Internet forum, for such a question - it will be appreciated.
Second, I fully understand that QT methods are essentially wrappers around system APIs (in our regard). But on the second hand, I think it should be either working (i.e. return values as intended) or throw an exception (we don't work with wayland). At the very least, I think QT developers (framework developers, not us - QT users) should be familiar with such limitation.
-
Wayland is so superior...😕
-
Hello Christian, JonB and thank you both for replying.
As for the question at hand, it's twofold (as I see it). First, yes - I've suspected it might be Wayland related. That's why I've mentioned it in the first place. Unfortunately, I haven't found a clear contact for Wayland/Ubuntu developers. If somebody can point out a proper channel, such as Internet forum, for such a question - it will be appreciated.
Second, I fully understand that QT methods are essentially wrappers around system APIs (in our regard). But on the second hand, I think it should be either working (i.e. return values as intended) or throw an exception (we don't work with wayland). At the very least, I think QT developers (framework developers, not us - QT users) should be familiar with such limitation.
@AlexK7 said in [Ubuntu] How get screen available geometry?:
But on the second hand, I think it should be either working (i.e. return values as intended) or throw an exception (we don't work with wayland).
It (Qt) just does not work that way. At least here/in this area, the "as intended" is whatever the underlying windowing system returns, and you are expected to deal with differences between window systems as you see appropriate.
At least just try @IgKh's
QT_QPA_PLATFORM=xcbto see if that gets it right. Whether you will want to run your Qt app this way is another matter. For my own part I found so many "messy" issues with Wayland --- not just in Qt programming but elsewhere in behaviour too --- that I have given up on it and set my (GNOME) desktop to log in as Xorg instead. -
Hello IgKh and thank you for replying.
First, thank you for providing an explanation. Second, the goal is quite simple: I'd like my main window positioned at the leftmost/topmost position available, with width/height covering the entire screen but not larger.
Since due to the business logic, the main window may grow very large in size - for UX/UI purposes, I'd rather reposition/scale/change elements within it, so a user can see the control he needs - without scrolling. Basically, available geometry = maximum window size.
-
Hello Christian, JonB and thank you both for replying.
As for the question at hand, it's twofold (as I see it). First, yes - I've suspected it might be Wayland related. That's why I've mentioned it in the first place. Unfortunately, I haven't found a clear contact for Wayland/Ubuntu developers. If somebody can point out a proper channel, such as Internet forum, for such a question - it will be appreciated.
Second, I fully understand that QT methods are essentially wrappers around system APIs (in our regard). But on the second hand, I think it should be either working (i.e. return values as intended) or throw an exception (we don't work with wayland). At the very least, I think QT developers (framework developers, not us - QT users) should be familiar with such limitation.
@AlexK7 said in [Ubuntu] How get screen available geometry?:
Second, I fully understand that QT methods are essentially wrappers around system APIs (in our regard). But on the second hand, I think it should be either working (i.e. return values as intended) or throw an exception (we don't work with wayland). At the very least, I think QT developers (framework developers, not us - QT users) should be familiar with such limitation.
That is debatable, actually. When you have one windowing system that has very different capabilities to the other systems, returning error values (not an exception, Qt does not use exceptions in its' APIs and is only partially exception-safe) is one option. Returning the "next best thing", even if it is only an approximation, is another - and there are pros and cons from the perspective of a cross-platform application author either way. For better or worse, this second approach is what Qt usually does in such situations.
That said, I agree that limitations should be documented. The good thing about Qt is that it is open source, and anyone can be a "Qt developer". Adding a Wayland compatibility note on the availableGeometry property of QScreen could be a great first contribution, if you are so inclined.
-
Hello IgKh and thank you for replying.
First, thank you for providing an explanation. Second, the goal is quite simple: I'd like my main window positioned at the leftmost/topmost position available, with width/height covering the entire screen but not larger.
Since due to the business logic, the main window may grow very large in size - for UX/UI purposes, I'd rather reposition/scale/change elements within it, so a user can see the control he needs - without scrolling. Basically, available geometry = maximum window size.
@AlexK7 said in [Ubuntu] How get screen available geometry?:
First, thank you for providing an explanation. Second, the goal is quite simple: I'd like my main window positioned at the leftmost/topmost position available, with width/height covering the entire screen but not larger.
Ah, that's easy. In Wayland - you just can't do this from the application side. Applications are not allowed to set their own position, and
QWidget::moveis a no-op under Wayland for top-level widgets.You can request to be maximized (via
QWidget::showMaximizedslot), but the compositor is allowed to completely ignore your request. Or you can do so from the compositor side (however assuming you are using GNOME - it has no facilities for that without writing a shell extension, sorry; KDE and Sway do have something). -
@AlexK7 said in [Ubuntu] How get screen available geometry?:
Second, I fully understand that QT methods are essentially wrappers around system APIs (in our regard). But on the second hand, I think it should be either working (i.e. return values as intended) or throw an exception (we don't work with wayland). At the very least, I think QT developers (framework developers, not us - QT users) should be familiar with such limitation.
That is debatable, actually. When you have one windowing system that has very different capabilities to the other systems, returning error values (not an exception, Qt does not use exceptions in its' APIs and is only partially exception-safe) is one option. Returning the "next best thing", even if it is only an approximation, is another - and there are pros and cons from the perspective of a cross-platform application author either way. For better or worse, this second approach is what Qt usually does in such situations.
That said, I agree that limitations should be documented. The good thing about Qt is that it is open source, and anyone can be a "Qt developer". Adding a Wayland compatibility note on the availableGeometry property of QScreen could be a great first contribution, if you are so inclined.
@IgKh said in [Ubuntu] How get screen available geometry?:
Adding a Wayland compatibility note on the availableGeometry property of QScreen could be a great first contribution, if you are so inclined.
This would only be the start of myriad necessary/suggested doc notes for Wayland. For example, as you yourself pointed out
QWidget::move()is a no-op,showMaximized()may do nothing or whatever, and the compositor may or may not do things, and differently from other compositors.... If the Qt docs really intend to do anything about Wayland I would rather it were a large effort from the team covering everything than the occasional user note.
