On Thu, 3 Nov 2011 20:10:03 Bache-Wiig Jens (Nokia-MP-Qt/Oslo) wrote:
> > 1. No Widgets. Previously the window/menu stuff was providing QML
> > wrappers around QWidget based classes, and the QWidget menu system. I
> > never really wanted widgets in my QML anyways, but with the big split in
> > Qt5 this seems even more like a necessary step.
>
> That is truly not really controversial at all. The reason we use widgets in
> Qt4 is due to necessity. It is purely an implementation detail. The
> QtQuick API should not in any way dictate a connection to QWidgets. We are
> planning (but haven't gotten around to invest much work on it yet) To make
> a new QAction/menu api that does not rely on Widgets at all.
> Unfortunately, at the moment this is the only way to implement these
> things in the Qt 4.X branch which is what most people outside of our
> offices will still use for the foreseeable future. Though having some
> widget dependencies in an early version of components is not a show
> stopper in my opinion, but not the ideal solution.
It's a show stopper for Qt5 in my opinion, because the widget separation means
we can avoid using a massive library now by avoiding widgets. Qt5 actually
gives you a chance to use QML without pulling widgets in, and it would be
really nice to have that on the desktop as well.
Another reason for this is that, in my opinion, desktop components are
supposed to differentiate from widgets. You can still use widgets just fine on
the desktop, but QML has the *potential* to do an even better job. It would be
nice to focus on the potential for improvements in the research project before
we make sacrifices to get it working ;) .
> > The drawback is that there are still widget stuff in there for menus,
> > which actually use QtWidgets/QMainWindow and QtWidgets/QMenu*. If this
> > approach is taken then the menus - like all the other widgets - will
> > have to be reimplemented in QML based off of hints from the native
> > platform. I quite like the idea, but can't mandate it since I'm not
> > going to reimplement all those widgets ;) .
>
> Yes. The first version of ContextMenu and ComboBox(then called ChoiceList)
> was actually written in Pure QML (apart from the styling). The main
> problem was that before we had a Window element, we could not make them
> look truly native as there was no way to create a true window popup within
> At Quick. We can certainly go back to writing these components in pure qml
> now that we have a working top-level Window API on both Qt 4.x and Qt5 to
> build on. Menus are a different beast altogether though, as it will
> require us to re-engineer a significant part of widgets in Qt5.
>
> > 2. The line between components and core. In pure theory-land there are
> > some commonalities between windows on multiple platforms. Even on mobile
> > or embedded devices, you need one window per screen and so would benefit
> > from the API (for the external display usecase at least). Even in pure
> > desktop-land, I always hoped that "desktop" components would actually
> > split into Mac, Windows and KDE components with just general
> > similarities. This would allow the Mac developers to do a UI that
> > actually looks native there finally! It would greatly increase the
> > challenge of write once, deploy everywhere, but I'd think Mac components
> > would benefit from having a different way to specify their crazy menu
> > bars.
>
> I personally don't see a real reason to deliberately create a different API
> for each platform. The main problem was not that the QMenu api was too
> limited to make a nice menu on Mac. It was that the platform guidelines
> are different and people were too lazy to make their UI explicitly for the
> mac. Having an explicit incompatible API is not going to help them achieve
> that goal. I do however, plan to have an extra MacExtras import though,
> for components that truly only make sense on one platform. If you see
> anything explicitly wrong about the existing QMenu API, that could be
> addressed by making a new mac specific one I would like to know about it.
> Having said that, we already experimented with a mac specific toolbar API
> in the "mac" branch.
>
> > So this theoretical future would have:
> > Window{} in the QtQuick module, not components, with roughly the
> > following API:
> > bool visible
> > bool modal
> > int x
> > int y
> > string title
> > bool fullscreen
> > DesktopWindow{} in the desktop components, implemented roughly like this:
> > Window{
> >
> > property alias windowState: actual.windowState
> > property alias windowDecorations: actual.windowDecorations
> > property alias minimumWidth: actual.minimumWidth
> > property alias minimumHeight: actual.minimumHeight
> > property alias maximumWidth: actual.maximumWidth
> > property alias maximumHeight: actual.maximumHeight
> >
> > DesktopWindowActuatorWhichHappensToBeImplementedInCPPAndGetsTheWindowPoin
> > terFromParentItem{id: actual}
> > }
>
> Do we really need to split Window and DesktopWindow? I don't see how the
> simplified Window API is actually useful to anyone. It is already too
> cluttered for a mobile display (x,y,modal etc) and it is still too limited
> to be of any serious use on the desktop? Perhaps QtQuickWindow as a
> separate import? Also, I think the modality API needs some work. I don't
> know how to currently make a distinction between window modal and
> application modal. Would it make sense to support anchoring for top-level
> windows by the way? It would make it a lot easier to position them but I
> am sure some window managers would make this difficult/impossible to
> support.
You're right that model can be dropped from the basic window. Perhaps even
title, depends on what mobile device compositors want to have (but e.g. N900 I
think had a window title). But in order to do a multi-screen UI you need to
have some basic Window{} available even on mobile. And I suspect other niche
use-cases might also have a strict requirement (a daemon spawning occasional
custom notifications which wouldn't fit in with the system notification
framework perhaps? Or an application that wants to look like 4 different
applications on a multi-tasking mobile?).
If modal moved to DesktopWindow it could become an Enum instead of a bool, and
provide window modality. I thought maybe application modality could be useful
on mobile, but window modality isn't.
Anchoring will just work - provided that the parent window is positioned at
0,0. Perhaps the Window{} element should have x relative to the parent window
X, instead of absolute coordinates? That should make anchors.centerIn just
work(in some contexts), but make absolute positioning on screen difficult.
--
Alan Alpert
Senior Engineer
Nokia, Qt Development Frameworks
_______________________________________________
Qt-components mailing list
Qt-components@qt.nokia.com
http://lists.qt.nokia.com/mailman/listinfo/qt-components
