[Development] Window{} API for QML

Charley Bay charleyb123 at gmail.com
Mon Nov 7 20:45:01 CET 2011


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).

(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.)

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.

(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".

Do I properly understand what is being proposed?

--charley
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20111107/243d59cb/attachment.html>


More information about the Development mailing list