> 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.
> 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
>
> DesktopWindowActuatorWhichHappensToBeImplementedInCPPAndGetsTheWindowPointerFromParentItem{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.
> qmldesktopviewer could theoretically maintain its current approach of
> instantiating the items but letting them canvas themselves (which doesn't
> actually work in qt5 right now) but I'd prefer that it exposes its QQuickView
> through a context property for those properties that are deemed useful. If
> menus are reimplemented actually in QML, then those couple properties would
> be
> all you're missing. This makes the path from desktopviewer -> real
> application
> simply a matter of re-exposing any properties you happen to be using. This
> way
> requires less variation from standard QML application template code.
Indeed. QmlDesktopViewer was never intended to be part of Qt5. The only reason
it was required, was so we could specifically give explicit control over the
root window. QmlScene should have this support built in on Qt5, removing any
need for a separate runtime.
> Prototype Window{}, against recent qt5 (post declarative rename for sure), is
> at
> https://qt.gitorious.org/~aalpert/qt-components/aalperts-desktop-components
> , qt5 branch. But it hasn't reimplemented Menu related functionality yet. It
> could merge into desktop components easily if consensus is that 'No menu
> widgets' is the proper path forward.
Thanks for doing this Aalpert. I agree on cleaning up widgets from the Menu
architecture, but we still have to find some time/resources to get that work
done...
Regards,
Jens
_______________________________________________
Qt-components mailing list
Qt-components@qt.nokia.com
http://lists.qt.nokia.com/mailman/listinfo/qt-components
