[Development] Exposing QScreen API to QML

[Samuel Rødal]

On 11/07/2011 09:21 AM, ext Alan Alpert wrote:
> On Wed, 2 Nov 2011 18:03:21 ext Samuel Rødal wrote:
>> Hello,
>>
>> I'm one of the guys who have been working on the Lighthouse API changes
>> for Qt 5 and new Qt 5 APIs like QWindow and QScreen. For those who are
>> not familiar, QWindow is the low-level Qt abstraction of a native window
>> that has its own rendering surface (native means whatever the Lighthouse
>> platform plugin provides, ie with the minimal plugin "native" currently
>> means a QImage backing store that simply gets saved as images to disk).
>> The QWidget stack and the scene graph both use QWindow as the
>> abstraction to get input and to get content onto the screen.
>>
>> QScreen provides a way to query information (like geometry, dpi,
>> orientation, etc) about screens, and to move a window to a certain
>> screen with QWindow::setScreen(). QGuiApplication provides screens()
>> which returns a list of all the available screens, primaryScreen() which
>> returns the default screen, as well as the screenAdded() signal when a
>> new screen is connected. The QScreen header can be seen here:
>> https://qt.gitorious.org/qt/qtbase/blobs/master/src/gui/kernel/qscreen.h
>
> Looking at the QScreen header, would all of these properties really be
> constant? virtualSize and availableVirtualGeometry sound like they could
> change easily, as could logical size. If they can change, they'll need NOTIFY
> signals so that th bindings and update.

True, looking at QWindowSystemInterface it seems they can change. I'll 
change them to be NOTIFY.

>> Currently we're trying to find a nice way to expose the QScreen API to
>> QML. The obvious way of exposing the QGuiApplication properties /
>> signals as Qt.application.screens, Qt.application.primaryScreen, and
>> Qt.application.screenAdded doesn't work too well unfortunately, since
>> there's no way of finding out which screen the QQuickView belongs to
>> from QML, and the screen list is useless as there's no way to control
>> which screen you're on from QML at the moment. We could limit ourselves
>> to only allowing a single declarative context to only be associated with
>> one screen, but that prevents future use cases like controlling the UI
>> for both the main display and the external display from a single QML
>> file, which might be useful in for example presentation tools or video
>> players / gallery viewers where the main display shows some controls
>> that are not shown on the external display. In the future we might want
>> to support these use cases as well as better support desktop
>> applications by having a Window item or similar to be able to explicitly
>> create new top-level windows from QML (a similar feature is already
>> exposed in QML desktop components, but it sounds like it would be useful
>> to have a generic abstraction in the QML core).
>
> When you say QML core, you mean this should go in the QtQuick module? Or into
> the engine, and be available without an import statement? The QtQuick module
> is my preference.

Right.

> My first guess is that it would need to hook into QQuickCanvas to easily find
> its QWindow* (for screen()) and to be notified of screen changes. That could
> affect where it can be placed. But if they're all in the QtDeclarative library
> then it's quite easy for it to work closely with the canvas to achieve this.

Yeah, and even though QScreen has a lot of CONSTANT properties all of 
the ones in Screen would presumably have to be NOTIFY, since the QScreen 
the QQuickCanvas is on might change.

--
Samuel