On Sat, Apr 19, 2014 at 12:00 AM, Alan Alpert <[email protected]> wrote:
> On Thu, Apr 17, 2014 at 7:54 AM, Aleix Pol <[email protected]> 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
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
