[Development] Window{} API for QML

Alan Alpert alan.alpert at nokia.com
Tue Nov 8 02:15:50 CET 2011


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



More information about the Development mailing list