[Development] Notes from the QWidget session

Alan Alpert alan.alpert at nokia.com
Thu Jul 5 02:43:06 CEST 2012


On Fri, 29 Jun 2012 11:57:58 ext Olivier Goffart wrote:
> On Friday 29 June 2012 11:50:55 Alan Alpert wrote:
> > On Tue, 26 Jun 2012 12:56:06 ext Harri Porten wrote:
> > >   - Converter of .ui files to QML?
> > 
> > That's a good idea, and actually pretty close to useful already. All you
> > really need to do is to register all the QWidget types into a QtWidgets
> > import, they're already QObjects and I think all designable attributes are
> > already marked as properties. Write a plugin that's all qmlRegisterType
> > lines, and a utility that turns XML into QML (trivial, and I think I still
> > have one lying around from ye olde days ;) ) and it should be pretty
> > simple.
> > 
> > Mind you, there's a big difference between QML and .ui2 - this is one
> > reason why there's a QtQuick module instead of just using the Qt Widgets
> > in QML. Without signals on the properties, bindings won't work. Also
> > without a default children property, the hierarchy doesn't build up
> > naturally (or at all, the plugin of just qmlRegisterTypes might only work
> > for single widget scenes). Neither the property set nor the property
> > implementation is geared towards animation in widgets, so I doubt you'd
> > get good results from trying to animate it using QML animations (worth a
> > test though). All are fixable, but would require significant work on the
> > widget set. All these issues are also reaching beyond features that are
> > provided by .ui files, so go past the issue of porting from Qt 4.
> > 
> > I thought I had an ancient example which exposed QWidget in 4.6, but I
> > can't find it. For the reasons described, it wasn't very useful anyway.
> > The key point is that you can have any tree of QObjects described in QML,
> > and it would be trivial to create a wrapper that places the root item as
> > the central widget in a QMainWindow, as opposed to the current wrapper
> > which places the root item into a QQuickItem scene.
> 
> The idea was more to do a mapping to get it works with the desktop
> components:
> 
> QPushButton ->  Button
>     text -> text
>     default -> defaultButton
>     icon -> iconSource
>     ...
> 
> QLineEdit -> TextField
>     text -> text
>     readOnly-> readOnly
>     displayText -> placeHolderText
>     ...
> 
> 
> There is a lot of properties to map.  Not every property can be mapped, and
> there may be some trick required for some types (such as QIcon)
> 
> 
> The idea is that you would run such a script once over all your .ui files.
> when you port your application to QML.
> That may save you a lot of time if you have several handreds of forms to
> port (qt-creator has 207 .ui files)
> The script may leave comments in the code about stuff it could not port.
> 
> Once the script is run, you are only half done. You still need to ajust the
> C++ part.
> 
> 
> Is it worth the effort to implement such a tool?
> Or will the developer will anyway re-write their entire UI from scratch
> (including all the dialogs) if they want to move away from QtWidgets?
> (Or maybe there is really no reason to move away from QtWidgets,  and one
> should continue to use it for dialogs)

Right now I'd say it's not worth the effort, because there's no reason to move 
existing UIs away from QtWidgets yet. QtQuick and QWidgets will coexist 
initially because they're designed for different UI usecases. Existing QWidget 
style UIs shouldn't rewrite with QML unless they want to change their style as 
well (which means a rewrite anyways). Continue using QtWidgets for your 
dialogs; they're only marked done because they're really, really good at their 
job :) .

When Desktop Components are complete they'll be a good choice for new 
projects, but I'm not sure that they'll ever be much better than QWidgets for 
the widget style of user interfaces. I certainly wouldn't make such a call 
until they're more complete and widely used, perhaps this tool can be 
considered then.

--
Alan Alpert



More information about the Development mailing list