[Development] QScreen API

Aleix Pol aleixpol at kde.org
Tue Apr 22 18:10:32 CEST 2014


On Sat, Apr 19, 2014 at 12:00 AM, Alan Alpert <416365416c at gmail.com> wrote:

> On Thu, Apr 17, 2014 at 7:54 AM, Aleix Pol <aleixpol at kde.org> wrote:
> > Hi,
> > Yesterday I was trying to figure out a problem I've been having on some
> code
> > that keeps track of screen management changes on my system. After some
> > investigation I came to the conclusion that my problem was in Qt [1].
> >
> > I'm sending this e-mail to know what's the status on the subject, if
> this is
> > something we'd like to fix or we have to adopt a solution specific for
> the
> > project (actually we already have a libkscreen, that would work). Still
> the
> > current state doesn't look good and we probably want to have it fixed in
> Qt.
>
> That bug sounds like it's in the xcb platform plugin and should be fixed
> there.
>
> > Furthermore, we realized that there's some API we're lacking as well, at
> > least we'd need to have a QGuiApplication::primaryScreenChanged signal
> and
> > probably a QGuiApplication::screenRemoved signal as well (this way we
> > wouldn't have to connect to QObject::destroyed on the screens).
>
> Those signals both make a lot of sense. It also makes it sound like we
> might want some sort of "Screen manager" abstraction in Qt 6, which
> could do all this change handling plus be aware of virtual desktops
> and stuff.
>
> > TL;DR, what do the maintainers think of the screen management API we
> have?
> > Is anybody working on it? Is it documented anywhere why it was designed
> this
> > way? Am I missing something?
>
> I am not too happy with the screen management API we have. Here's a short
> rant:
>
> It doesn't work conveniently cross-platform (or reliably across all
> platforms). You can technically do most of what you need about
> hardware screens, but it's confusing when virtual desktops span
> screens (and it sounds like it's missing some APIs for that as well).
> I've been looking into QML abstractions to make it easier for QtQuick,
> but the QScreen APIs work on so few platforms that I've given up for
> now.
>
> The one case where the API does work is when plugging an HDMI output
> into a BB10 device. So the mobile/embedded usecase of a completely
> separate screen works on one platform, but isn't easy (presumably a
> lot of QNX cases would work too, but the embedded world doesn't talk
> that much). I don't know whether app developers want to think about
> one virtual desktop or multiple physical screens in most cases. Think
> about a cross-platform app written for mobile which might just want
> another window instead when on desktop. Or a desktop app might want to
> use a secondary screen when available on mobile but doesn't care about
> the existence of two physical screens on one virtual desktop. These
> cases are quite a pain to implement right now, if at all possible (I
> haven't tried, but I assume something could be hacked together which
> no-one would be proud of).
>
> --
> Alan Alpert
>

Hi,
I took a look at the implementation, to see what's going on, then realized
the implementation is quite naïve at the moment, exactly to fulfill the
use-case Alan is describing here.
I added some further description in the bug report of what is wrong in case
somebody wants to shed some light on how this mess should be fixed. I can
maybe take some time and see if we can at least improve the situation in
this area, but I'd like to have some input.

Cheers!
Aleix
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20140422/f525648a/attachment.html>


More information about the Development mailing list