[Development] QScreen API

[Alan Alpert]

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