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
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
