I agree with most of the things in this thread, but not everything. Here's
my thoughts:
We need a Window {} element to create surfaces on a physical screen. This
Window object should IMO be more or less a direct representation of
QQuickView in QML.
So far we all seem to agree. But I also do not see a need to limit the
Window {} API to the mobile use cases. I'd rather that we expose the full
functionality in one Object, and rather document some of the differences
in behavior between mobile and desktop.
Using the Window {} object anywhere in QML creates a new top level window.
This implies that a Window{} as the root item of a QQuickView would create
an empty QQuickView and a second top-level created through the WIndow
object. But at least this would mean there's no magic involved.
Like that we can change the default way of using QML to be symmetric
between Desktop and Mobile. You instantiate a QQuickEngine, and then load
a QML file that contains a WIndow {} as the outermost element. If we
remove the Window {} in QtComponents and use this instead, we can then
make this fully symmetrical on the QML side between desktop and mobile.
The only difference would be in the default behavior of Window (most
likely full screen on mobile, windowed on desktop).
Differentiation between mobile and desktop can then happen on the
ApplicationWindow level in QtComponents, where the ApplicationWindow for
the desktop would support menu- and toolbars, the mobile version would
support pages and whatever else is needed there.
In addition, it should be easy to associate a Window {} with a certain
physical screen. For this I'd propose, we somehow expose the list of
screens as objects in Qt.application, and give Window {} a screen property
that can be bound to a screen.
So
Window {
screen: Qt.application.primaryScreen // the default behavior
}
would create a Window on the primary screen.
The main question I'm unsure about is what to do with Windows on screens
that are going away (by unplugging the VGA cable going to the projectorŠ).
So my proposal would be something exposing most of the QWindow API:
Window {
property Screen screen
property Orientation orientation // { Portrait, Landscape, Š }
property Rect geometry // or x, y, width, height
property WindowFlags windowflags
property Window parent
property real opacity
property string title
...
}
I'd go for a similar approach for Screen, basically exposing QScreen.
If the API of these classes aren't suitable for direct use in QML (after
adding properties with notifications of course), let's fix them. It's new
API in Qt5 and we can still work on it and make it directly usable from
QML.
If we get this in, I believe we have a good part of the foundations in
place to give us really good multi screen support in QML as well as having
what's needed to build desktop components directly on QtQuick2.
Cheers,
Lars
On 11/8/11 2:15 AM, "ext Alan Alpert" <alan.alp...@nokia.com> wrote:
>On Tue, 8 Nov 2011 05:45:01 ext Charley Bay wrote:
>> Reading Alan's post a couple times, I *think* this summarizes to:
>>
>> (a)- A new "Window{}" element is being proposed for QML that is
>>different
>> from the current QML components. Specifically, the new "Window{}" is a
>> "top-level" concept, where you could have more-than-one, such as one for
>> each monitor. Other QML components could be instantiated *within* the
>>new
>> "Window{}", but a "Window{}" itself is a top-level item.
>>
>> (b)- The new QML "Window{}" element may break QWidget menus/toolbars
>>within
>> that "Window{}".
>>
>> (c)- The new QML "Window{}" behaves differently from other QML
>>components
>> which may be used *within* that "Window{}". Specifically, QML components
>> can move/resize based on QML source code, but the top-level "Window{}"
>> would be anchored/sized based on the launching C++ program (not based on
>> QML API).
>
>Not quite. The Window{} in QML would be controllable, at least minimally,
>from
>QML. The QWindow* (probably a QQuickView*) created in C++ would remain
>controllable only from C++ - Window{} like API would not be granted to
>them.
>
>> (Please feel free to correct my impression -- Alan's email was fine, my
>> brain is just small and I'm trying to understand all of the implications
>> for what Alan is proposing.)
>
>I was invoked with --verbose but I think you got the picture ;) .
>>
>> My impressions:
>>
>> (1) This makes sense to me (I like this proposal). I've tried to create
>> "desktop gadgets" with QML, or otherwise have more-than-one "top-level"
>>QML
>> window into which I could put QML components, and I think it would be
>>much
>> easier if we distinguished between these two "types" of real-estate
>>(e.g.,
>> IMHO it would be nice to distinguish between "top-level" real-estate,
>>and
>> "nested" QML components that move around that "top-level" real estate).
>> Logically, the "top-level" real-estate represents the "device" (e.g.,
>>like
>> the whole phone screen), while the "nested" real estate represents
>> space-within-that-top-level-device. (This seems elegant.)
>>
>> (2) I don't have a strong opinion on whether the top-level "Window{}"
>> should have size/placement attributes exposed to QML. Alan's proposal
>>to
>> *not* have that seems fine with me (I just need a way to "anchor" the
>> desktop gadget, or place it on the desktop where it needs to go, and
>>it's
>> fine if I can do it only through the C++ application.) I *assume* the
>> "Window{}" will have some kind of frame-with-title on the desktop so the
>> user could size/move it? If not, no biggie, I can do that myself.
>
>It will be a QWindow and so the desktop window manager will have the
>operation
>to decorate it as normal. Technically this is the same for mobile window
>managers, but they tend to be simpler.
>
>>
>> (3) I don't care if menus/toolbars are broken. IMHO, (as Alan
>>suggests),
>> they would be done again in QML (so they could be "skinned/sized"
>> properly), or they would be done with a different metaphor (there are
>> lots).
>>
>> (4) Perhaps off-topic for this thread, IMHO this type of
>> "desktop-and-mobile-unification" is really important to "think-through"
>> (that's how I see this proposal). I like what is proposed, but we may
>>need
>> some iteration as we experiment on both desktop and mobile. I see this
>> proposal as simpler and more bounded than other unification concerns I
>>have
>> (for QML), such as "skinning-styles" and "layout".
>
>I fully agree. Desktop and mobile unification for QML is not something
>where
>it's clear how to implement it yet, but Qt 5 is the right time to start
>thinking about it. Even if 5.0 doesn't manage to bring desktop QML up to
>par
>with desktop widgets, we want to have thought the issues through well
>enough
>that we've left that path open. That is a prerequisite for a QML in the
>Qt 5.x
>series that is great on both mobile and desktop.
>
>>
>> Do I properly understand what is being proposed?
>
>So close, but thanks for trying Charley :) .
>
>--
>Alan Alpert
>Senior Engineer
>Nokia, Qt Development Frameworks
>_______________________________________________
>Development mailing list
>Development@qt-project.org
>http://lists.qt-project.org/mailman/listinfo/development
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
