[Development] Question about Qt's future

[Michael Knight]

I feel like Qt is going in the direction of being Qml and Javascript only.I
fear that they may abandon Qt Widgets in the near future,I think they are
heavily promoting Qml.I don't want to use Qml,and before I start using Qt,I
want to be sure that they will not abandon C++ side of Qt and that they
continue to develop C++ side.It seems to me that they are developing Qml side
mostly.

What do you think about this?

[m***@rpzdesign.com]

Michael:

That is a great question.

I hope you get answers that focus on the mobile side of things (IOS/Android)

With Qt 5.3.0 release just around the corner, will Qt Widgets be able to
run stable on IOS and ANdroid?

Many comments I have seen on this list refers to Qt Widgets as a desktop
oriented toolkit, but I ran Qt Widgets in
test on Qt 5.2.1 IOS/Android and they seemed to work.

What is the design pattern/architecture that QML provides that renders
Qt Widgets obsolete?

Isn't Qt Widgets so mature that they are stable?

Will Qt Widgets / Qpainter be so inefficient on IOS/Android that only
using QML with screengraph/opengl
is the available choice.

The case has not been made either for or against QML and their use cases
not well documented
with respect to the amount of focus on QML and the reasons for that
design direction.

Look forward to the Monday discussion threads....

md

On 4/20/2014 9:40 PM, Michael Knight wrote:
> I feel like Qt is going in the direction of being Qml and Javascript only.I
> fear that they may abandon Qt Widgets in the near future,I think they are
> heavily promoting Qml.I don't want to use Qml,and before I start using Qt,I
> want to be sure that they will not abandon C++ side of Qt and that they
> continue to develop C++ side.It seems to me that they are developing Qml side
> mostly.
>
> What do you think about this?
>
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>

[Thiago Macieira]

Em dom 20 abr 2014, às 22:37:11, ***@rpzdesign.com escreveu:
> With Qt 5.3.0 release just around the corner, will Qt Widgets be able to
> run stable on IOS and ANdroid?

They run. They just look horrible.

> Many comments I have seen on this list refers to Qt Widgets as a desktop
> oriented toolkit, but I ran Qt Widgets in
> test on Qt 5.2.1 IOS/Android and they seemed to work.
>
> What is the design pattern/architecture that QML provides that renders
> Qt Widgets obsolete?

Modern architecture, OpenGL acceleration & shaders support, animations, pixel-
perfect layout if you know the exact screen size.

> Isn't Qt Widgets so mature that they are stable?

They are.

> Will Qt Widgets / Qpainter be so inefficient on IOS/Android that only
> using QML with screengraph/opengl
> is the available choice.

It's not the only available choice. Widgets are available. They just look
horrible because no one has done any work to make them look native.

> The case has not been made either for or against QML and their use cases
> not well documented
> with respect to the amount of focus on QML and the reasons for that
> design direction.

The design direction is because QML is easier to develop with, more modern,
and based on OpenGL. Widgets don't have that and will never be as efficient.
Therefore, the effort is directed towards the technology that has the potential
to make interfaces for 2017-2020.

> Look forward to the Monday discussion threads....

Tuesday. Monday is still a day off in both Finland and Norway.

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

[Yves Bailly]

On 21/04/2014 04:53, Thiago Macieira wrote:
> Em dom 20 abr 2014, às 22:37:11, ***@rpzdesign.com escreveu:
>> Isn't Qt Widgets so mature that they are stable?
>
> They are.

But so much could still be done... as a basic example I stumbled upon
very recently, why is it so hard to change the font of *one* item in
a combo box??

> The design direction is because QML is easier to develop with,

Not for heavy-weight applications, even less when part of the UI is
dynamically build at runtime according to context, config files, etc.

> more modern,
> and based on OpenGL. Widgets don't have that and will never be as efficient.
> Therefore, the effort is directed towards the technology that has the potential
> to make interfaces for 2017-2020.

Even in 2017-2020, we'll still have desktops. Phones or even tablets are just
not suited for *real* work, and I don't see how they could be. A professional
writer can type 100 words per minute on a keyboard, I doubt this will be
even remotely possible on a tablet. Doing serious 3D modeling on a tablet
is a joke. And think about the hundreds of mouse/keyboards shorcuts... if
you remove them, as its the case on "modern" devices, you loose a lot in
productivity.

QtCreator is a complex application, though not as heavy-weight as some I
work on. Could it be redone "the right way", with *all* the UI in QML and
the "business logic" in C++? would developing QtCreator this way be as efficient
as it is today? and finally, would a user be as efficient with it on a
"modern" device as he can be on a good'old desktop? Same question for Calligra
and others.

QML has its merit, it's certainly perfect for some projects. But for all
I've seen and tried until now, only for projects having a rather simple UI.
For really complex UIs, QML seems not suitable - at least for now.

Mind, what I (and others) is talking about, are applications where user's
productivity matters more than the UI being nice - or even looking "native".
Take Blender: sure, the learning curve is steep. But once you know it, you
can very very productive with it, *on any platform*, because it looks the
same *on all platform*. "Looking native" might be a nice selling or demo
thing, but it's just irrelevant (or even counter-productive) for a whole
class of applications.

So please, please... keep improving widgets! :-) some things are unnecessary
difficult to do, some features would be so nice to have...

--
(o< | Yves Bailly | -o)
//\ | Linux Dijon : http://www.coagul.org | //\
\_/ | | \_/`

[Robert Knight]

> The design direction is because QML is easier to develop with, more modern,
> and based on OpenGL. Widgets don't have that and will never be as efficient.
> Therefore, the effort is directed towards the technology that has the potential
> to make interfaces for 2017-2020.

Unfortunately that means there are now 4 completely separate UI stacks
to maintain in Qt - widgets,
QGraphicsView, the web and QtQuick v2. I wonder if they could be
harmonized at all?

> If you look at the wider picture QML is a replacement for XML based .ui
> files, not for any of the other technologies currently used with .ui files.

A .ui file gets translated in a fairly straightforward way into an
object graph of widgets, actions and other documented
classes though. QML adds data binding and other nice features but it
also brings a fairly complex runtime with it and that
does lead to the interop complications across the C++/JS bridge divide.

There were some interesting comments from Tim Sweeney recently about
UnrealScript and C++.
Some of those comments might equally apply to QML as well:
https://forums.unrealengine.com/showthread.php?2574-Why-C-for-Unreal-4&p=16252&viewfull=1#post16252


On 21 April 2014 14:31, Yves Bailly <***@laposte.net> wrote:
> On 21/04/2014 04:53, Thiago Macieira wrote:
>> Em dom 20 abr 2014, às 22:37:11, ***@rpzdesign.com escreveu:
>>> Isn't Qt Widgets so mature that they are stable?
>>
>> They are.
>
> But so much could still be done... as a basic example I stumbled upon
> very recently, why is it so hard to change the font of *one* item in
> a combo box??
>
>> The design direction is because QML is easier to develop with,
>
> Not for heavy-weight applications, even less when part of the UI is
> dynamically build at runtime according to context, config files, etc.
>
>> more modern,
>> and based on OpenGL. Widgets don't have that and will never be as efficient.
>> Therefore, the effort is directed towards the technology that has the potential
>> to make interfaces for 2017-2020.
>
> Even in 2017-2020, we'll still have desktops. Phones or even tablets are just
> not suited for *real* work, and I don't see how they could be. A professional
> writer can type 100 words per minute on a keyboard, I doubt this will be
> even remotely possible on a tablet. Doing serious 3D modeling on a tablet
> is a joke. And think about the hundreds of mouse/keyboards shorcuts... if
> you remove them, as its the case on "modern" devices, you loose a lot in
> productivity.
>
> QtCreator is a complex application, though not as heavy-weight as some I
> work on. Could it be redone "the right way", with *all* the UI in QML and
> the "business logic" in C++? would developing QtCreator this way be as efficient
> as it is today? and finally, would a user be as efficient with it on a
> "modern" device as he can be on a good'old desktop? Same question for Calligra
> and others.
>
> QML has its merit, it's certainly perfect for some projects. But for all
> I've seen and tried until now, only for projects having a rather simple UI.
> For really complex UIs, QML seems not suitable - at least for now.
>
> Mind, what I (and others) is talking about, are applications where user's
> productivity matters more than the UI being nice - or even looking "native".
> Take Blender: sure, the learning curve is steep. But once you know it, you
> can very very productive with it, *on any platform*, because it looks the
> same *on all platform*. "Looking native" might be a nice selling or demo
> thing, but it's just irrelevant (or even counter-productive) for a whole
> class of applications.
>
> So please, please... keep improving widgets! :-) some things are unnecessary
> difficult to do, some features would be so nice to have...
>
> --
> (o< | Yves Bailly | -o)
> //\ | Linux Dijon : http://www.coagul.org | //\
> \_/ | | \_/`
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

[Kevin Krammer]

On Monday, 2014-04-21, 15:13:08, Robert Knight wrote:
> > The design direction is because QML is easier to develop with, more
> > modern,
> > and based on OpenGL. Widgets don't have that and will never be as
> > efficient.>
> > Therefore, the effort is directed towards the technology that has the
> > potential>
> > to make interfaces for 2017-2020.
>
> Unfortunately that means there are now 4 completely separate UI stacks
> to maintain in Qt - widgets,
> QGraphicsView, the web and QtQuick v2. I wonder if they could be
> harmonized at all?

We can use QML to describe UIs in all four.

> > If you look at the wider picture QML is a replacement for XML based .ui
> > files, not for any of the other technologies currently used with .ui
> > files.
>
> A .ui file gets translated in a fairly straightforward way into an
> object graph of widgets, actions and other documented
> classes though. QML adds data binding and other nice features but it
> also brings a fairly complex runtime with it and that
> does lead to the interop complications across the C++/JS bridge divide.

True, but it mainly depends on how much JS you want to use.
If you are mainly working with bindings then that is usually not an issue.

Cheers,
Kevin
--
Qt Developer Days 2014, October 6 - 8 at BCC, Berlin. Save the dates!

Kevin Krammer | ***@kdab.com | Senior Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. Sweden (HQ) [phone], USA +1-866-777-KDAB(5322)
KDAB - Qt Experts - Platform-independent software solutions

[Simon Hausmann]

On Monday 21. April 2014 15.13.08 Robert Knight wrote:
> > The design direction is because QML is easier to develop with, more
> > modern,
> > and based on OpenGL. Widgets don't have that and will never be as
> > efficient.>
> > Therefore, the effort is directed towards the technology that has the
> > potential>
> > to make interfaces for 2017-2020.
>
> Unfortunately that means there are now 4 completely separate UI stacks
> to maintain in Qt - widgets,
> QGraphicsView, the web and QtQuick v2. I wonder if they could be
> harmonized at all?

There is maybe more harmonization going on that you might think.

With QtWebEngine, the rendering of web content layers is based on the Qt Scene
Graph, which is shared with Qt Quick.

QtQuick (and also QtWebEngine) integrate with the widget rendering thanks to
the GL based compositor in QPlatformBackingstore (raster content on top, GL
content underlay)

>

[Sorvig Morten]

On 22 Apr 2014, at 12:49, Simon Hausmann <***@digia.com> wrote:

> On Monday 21. April 2014 15.13.08 Robert Knight wrote:
>>> The design direction is because QML is easier to develop with, more
>>> modern,
>>> and based on OpenGL. Widgets don't have that and will never be as
>>> efficient.>
>>> Therefore, the effort is directed towards the technology that has the
>>> potential>
>>> to make interfaces for 2017-2020.
>>
>> Unfortunately that means there are now 4 completely separate UI stacks
>> to maintain in Qt - widgets,
>> QGraphicsView, the web and QtQuick v2. I wonder if they could be
>> harmonized at all?
>
> There is maybe more harmonization going on that you might think.

There’s even a shared platform abstraction layer which provides the base that at least three of the stacks are built on :)

And I think this is important - much of the maintenance work related to the coming and going of platforms will be done on QPA which will benefit both Widgets and Qt Quick.

Morten

[Joshua Kolden]

On Apr 21, 2014, at 6:31 AM, Yves Bailly <***@laposte.net> wrote:

> On 21/04/2014 04:53, Thiago Macieira wrote:
>> Em dom 20 abr 2014, às 22:37:11, ***@rpzdesign.com escreveu:
>>> Isn't Qt Widgets so mature that they are stable?
>>
>> They are.
>
> But so much could still be done... as a basic example I stumbled upon
> very recently, why is it so hard to change the font of *one* item in
> a combo box??
>

Trivial in QML.

>> The design direction is because QML is easier to develop with,
>
> Not for heavy-weight applications, even less when part of the UI is
> dynamically build at runtime according to context, config files, etc.
>

I think you may have a miss perception about QML. QML although young, is not a toy interface kit. It may seem like it since it is so young, and because it’s light and easy to work with. However it is actually a much better platform to do UI heavy lifting. The unified scene graph of QtQuick gives substantial performance gains (at least as intended) over redraw and QML ease of use improves implementation time and maintainability for complex interfaces.

You could absolutely create QtCreator’s interface in QML. We haven’t had the problems some have mentioned regarding a fuzzy line between view/controller javascript/c++, so I’m not sure what the issue is there. However we’ve seen significant development productivity gains by being able to implement and integrate UI with c++ backend in the running application in realtime. Usually one developer can work entirely independently from the other.

Don’t be put off by the fact most QtQuick demos are on portable devices. Our project is a desktop app in the professional post production space.

Granted, we have some issues, there are still unimplemented features, bugs and performance issues that are being shaken out. And as discussed elsewhere it may not be the perfect fit for legacy QtWidget apps (not that you couldn’t use both to some extent). So while I am suspicious that there may be other concerns that I’m keeping an eye out for, “heavy-weight”, and dynamic UIs are QML’s sweet spot not weakness.

You may also be interested in this video: https://www.youtube.com/watch?v=kvWeE3kurEQ


>> more modern,
>> and based on OpenGL. Widgets don't have that and will never be as efficient.
>> Therefore, the effort is directed towards the technology that has the potential
>> to make interfaces for 2017-2020.
>
> Even in 2017-2020, we'll still have desktops. Phones or even tablets are just
> not suited for *real* work, and I don't see how they could be. A professional
> writer can type 100 words per minute on a keyboard, I doubt this will be
> even remotely possible on a tablet. Doing serious 3D modeling on a tablet
> is a joke. And think about the hundreds of mouse/keyboards shorcuts... if
> you remove them, as its the case on "modern" devices, you loose a lot in
> productivity.
>
> QtCreator is a complex application, though not as heavy-weight as some I
> work on. Could it be redone "the right way", with *all* the UI in QML and
> the "business logic" in C++? would developing QtCreator this way be as efficient
> as it is today? and finally, would a user be as efficient with it on a
> "modern" device as he can be on a good'old desktop? Same question for Calligra
> and others.
>
> QML has its merit, it's certainly perfect for some projects. But for all
> I've seen and tried until now, only for projects having a rather simple UI.
> For really complex UIs, QML seems not suitable - at least for now.
>
> Mind, what I (and others) is talking about, are applications where user's
> productivity matters more than the UI being nice - or even looking "native".
> Take Blender: sure, the learning curve is steep. But once you know it, you
> can very very productive with it, *on any platform*, because it looks the
> same *on all platform*. "Looking native" might be a nice selling or demo
> thing, but it's just irrelevant (or even counter-productive) for a whole
> class of applications.
>
> So please, please... keep improving widgets! :-) some things are unnecessary
> difficult to do, some features would be so nice to have...
>
> --
> (o< | Yves Bailly | -o)
> //\ | Linux Dijon : http://www.coagul.org | //\
> \_/ | | \_/`
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

[m***@rpzdesign.com]

Yves & Devs:

I take a different view of tablets. There MANY use cases where tablets
will do a HUGE amount of mission critical *REAL* work
and they will NOT use a keyboard or type 100 words a minute.

But I agree, we need both 100% C++ Qt Widget Option (not using .ui
files) AND QML/js (the new .ui file replacement) for 2017-2020 future.

You can separate the GUI from the Model in C++ Classes as well, not just
in QML/js vs C++ boundary.

Qt Widgets are currently stable and they work. (Ignore cosmetic/native
looking issues- I want program to look SAME across all tablets)

Can Qt Widgets design pattern be brought forward using the same OpenGL
foundation
that QML uses to instantiate controls?

Peeking at the documentation, QQuickWindow is the container for the
scenegraph, which has a bunch of
QQuickItems.

Why can't a single QQuickItem == Future Qt Widget?

Any QT Devs expert in the QQuickWindow implementation care to chime in
on mapping the Qt Widget concept
into the new scenegraph architecture? (100% C++ GUI, 100% C++
Model/Controller)

Obviously, the future QtWidget will have a different pattern than
current Qt Widget.

Thanks for the lively Monday Qt Future discussion even if Finland and
Norway are on Holiday!

Cheers,

md


On 4/21/2014 9:31 AM, Yves Bailly wrote:
> On 21/04/2014 04:53, Thiago Macieira wrote:
>> Em dom 20 abr 2014, às 22:37:11, ***@rpzdesign.com escreveu:
>>> Isn't Qt Widgets so mature that they are stable?
>> They are.
> But so much could still be done... as a basic example I stumbled upon
> very recently, why is it so hard to change the font of *one* item in
> a combo box??
>
>> The design direction is because QML is easier to develop with,
> Not for heavy-weight applications, even less when part of the UI is
> dynamically build at runtime according to context, config files, etc.
>
>> more modern,
>> and based on OpenGL. Widgets don't have that and will never be as efficient.
>> Therefore, the effort is directed towards the technology that has the potential
>> to make interfaces for 2017-2020.
> Even in 2017-2020, we'll still have desktops. Phones or even tablets are just
> not suited for *real* work, and I don't see how they could be. A professional
> writer can type 100 words per minute on a keyboard, I doubt this will be
> even remotely possible on a tablet. Doing serious 3D modeling on a tablet
> is a joke. And think about the hundreds of mouse/keyboards shorcuts... if
> you remove them, as its the case on "modern" devices, you loose a lot in
> productivity.
>
> QtCreator is a complex application, though not as heavy-weight as some I
> work on. Could it be redone "the right way", with *all* the UI in QML and
> the "business logic" in C++? would developing QtCreator this way be as efficient
> as it is today? and finally, would a user be as efficient with it on a
> "modern" device as he can be on a good'old desktop? Same question for Calligra
> and others.
>
> QML has its merit, it's certainly perfect for some projects. But for all
> I've seen and tried until now, only for projects having a rather simple UI.
> For really complex UIs, QML seems not suitable - at least for now.
>
> Mind, what I (and others) is talking about, are applications where user's
> productivity matters more than the UI being nice - or even looking "native".
> Take Blender: sure, the learning curve is steep. But once you know it, you
> can very very productive with it, *on any platform*, because it looks the
> same *on all platform*. "Looking native" might be a nice selling or demo
> thing, but it's just irrelevant (or even counter-productive) for a whole
> class of applications.
>
> So please, please... keep improving widgets! :-) some things are unnecessary
> difficult to do, some features would be so nice to have...
>

[Thiago Macieira]

Em seg 21 abr 2014, às 10:59:43, ***@rpzdesign.com escreveu:
> Can Qt Widgets design pattern be brought forward using the same OpenGL
> foundation
> that QML uses to instantiate controls?

Short answer: no.

Long answer: if you want it working in other platforms, without glitches and
regressions, the effort required for this is enormous. It basically requires
rewriting all or almost all widgets from scratch so that they work in a
retained-mode OpenGL scene graph, instead of imperative-mode raster buffer
painting. It's a complete paradigm change.

Since this requires a rewrite, instead of doing it in QtWidgets and risking
regressions that users will not accept, the idea was instead to do it in a
different module, one where we can experiment and at the same time clean up
some of the mistakes that exist in QtWidgets and can't be cleaned up without
annoying someone.

That's the Qt Quick Components.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

[m***@rpzdesign.com]

Thiago:

I really appreciate your and Intel's participation in the open source Qt
project.

I think you misunderstood what I was talking about and forcefully
rejected that which I did not ask.

I want the "pattern" brought forward, but we should not try to bring the
code forward. Let sleeping dogs lie.

After reading these:

http://qt-project.org/doc/qt-5/topics-graphics.html
http://qt-project.org/doc/qt-5/qtquick-visualcanvas-scenegraph.html
http://qt-project.org/doc/qt-5/qtquick-visualcanvas-scenegraph.html#scene-graph-and-rendering

What I think would be a solution is to create a starting point
where Qt Widget 2.0 development could begin anew again based on the
QQuickPaintedItem class.

I think the notion of a Window with child custom controls is not too far
fetched.

My suggestion is basically to provide an early off ramp for QQuickWindow
to allow for 100% C++ projects.

This may even serve as the foundation for custom controls in QML as
well, don't know enough right now to be dangerous.

It would definitely provide current Qt Widget users a sense of ease
that the Widget option is still available even though QtQuickWindow is
the future focus.

QML and QTWidget would then both use the same dual GUI/render thread
foundation, but it would be good to have an early C++ jumping off point
for QQuickWindow based projects.

I do not really care about .ui file support. For all I can see, 100%
C++ GUI is fine.

What do you think?

Cheers,

md


On 4/21/2014 12:19 PM, Thiago Macieira wrote:
> Em seg 21 abr 2014, às 10:59:43, ***@rpzdesign.com escreveu:
>> Can Qt Widgets design pattern be brought forward using the same OpenGL
>> foundation
>> that QML uses to instantiate controls?
>
> Short answer: no.
>
> Long answer: if you want it working in other platforms, without glitches and
> regressions, the effort required for this is enormous. It basically requires
> rewriting all or almost all widgets from scratch so that they work in a
> retained-mode OpenGL scene graph, instead of imperative-mode raster buffer
> painting. It's a complete paradigm change.
>
> Since this requires a rewrite, instead of doing it in QtWidgets and risking
> regressions that users will not accept, the idea was instead to do it in a
> different module, one where we can experiment and at the same time clean up
> some of the mistakes that exist in QtWidgets and can't be cleaned up without
> annoying someone.
>
> That's the Qt Quick Components.
>

[Steve Gold]

I have been reading the discussions about Qt’s future and strongly feel that
it's full of promise. Last year I used a different application framework but
the company went bankrupt without notifying its users. I then tried several
other frameworks but wasn’t happy with any of them. Then I came across
Cosos2d-x and Qt and briefly tried both. I quickly came to the conclusion
that QML (with JavaScript) was an extremely powerful way to develop systems
and that I was able to use C++ if I needed to access existing libraries or
required critical performance. IMHO, this one-two punch in some ways sets Qt
above the fray and enable developers to create and deploy a wide range of
applications, including complex and highy performant ones. QML can be used
when it is appropriate and C++ can be used when it is appropriate.

When I last counted the QML types and C++ classes I found that the C++
classed outnumbered the QML typed by approximately 3:1. I’m certainly not
suggesting that the ratio be close to 1:1 but there is some room here for
improvement. I like that many of the new features of Qt 5.3 and some of its
immediate predecessors allow users to access functionality in C++ or QML and
hope that this trend continues. There are certainly several aspects of Qt
that can be improved, like the Qt Creator editor for one, but Qt is an open
source project and everyone has an opportunity to contribute by comments,
suggestions or even code.

BTW, I agree with the statement "I do not really care about .ui file
support." I would, however, like to see some improvement in the Qt Creator
design functionality, especially since the older Qt Designer appears to have
more capability than the newer Qt Quick Designer. However, I personally
disagree that "100% C++ GUI is fine." QML provides a MUCH better vehicle for
GUI than C++ and after using C++ and Java for many years I can see
tremendous benefit in QML. If someone wants to spend the time and effort to
create GUIs in C++, then I wish him or her luck. I've experienced some pain
with this in the past and I don't want to do it again. It's just my
preference and may not be right for everyone.

To Qt's bright future,

Steve

-----Original Message-----
From: ***@rpzdesign.com
Sent: Monday, April 21, 2014 12:55 PM
To: Thiago Macieira ; ***@qt-project.org
Subject: Re: [Development] Question about Qt's future

Thiago:

I really appreciate your and Intel's participation in the open source Qt
project.

I think you misunderstood what I was talking about and forcefully
rejected that which I did not ask.

I want the "pattern" brought forward, but we should not try to bring the
code forward. Let sleeping dogs lie.

After reading these:

http://qt-project.org/doc/qt-5/topics-graphics.html
http://qt-project.org/doc/qt-5/qtquick-visualcanvas-scenegraph.html
http://qt-project.org/doc/qt-5/qtquick-visualcanvas-scenegraph.html#scene-graph-and-rendering

What I think would be a solution is to create a starting point
where Qt Widget 2.0 development could begin anew again based on the
QQuickPaintedItem class.

I think the notion of a Window with child custom controls is not too far
fetched.

My suggestion is basically to provide an early off ramp for QQuickWindow
to allow for 100% C++ projects.

This may even serve as the foundation for custom controls in QML as
well, don't know enough right now to be dangerous.

It would definitely provide current Qt Widget users a sense of ease
that the Widget option is still available even though QtQuickWindow is
the future focus.

QML and QTWidget would then both use the same dual GUI/render thread
foundation, but it would be good to have an early C++ jumping off point
for QQuickWindow based projects.

I do not really care about .ui file support. For all I can see, 100%
C++ GUI is fine.

What do you think?

Cheers,

md


On 4/21/2014 12:19 PM, Thiago Macieira wrote:
> Em seg 21 abr 2014, às 10:59:43, ***@rpzdesign.com escreveu:
>> Can Qt Widgets design pattern be brought forward using the same OpenGL
>> foundation
>> that QML uses to instantiate controls?
>
> Short answer: no.
>
> Long answer: if you want it working in other platforms, without glitches
> and
> regressions, the effort required for this is enormous. It basically
> requires
> rewriting all or almost all widgets from scratch so that they work in a
> retained-mode OpenGL scene graph, instead of imperative-mode raster buffer
> painting. It's a complete paradigm change.
>
> Since this requires a rewrite, instead of doing it in QtWidgets and
> risking
> regressions that users will not accept, the idea was instead to do it in a
> different module, one where we can experiment and at the same time clean
> up
> some of the mistakes that exist in QtWidgets and can't be cleaned up
> without
> annoying someone.
>
> That's the Qt Quick Components.
>

[Robert Knight]

> Unfortunately that means there are now 4 completely separate UI stacks
> to maintain in Qt - widgets,
> QGraphicsView, the web and QtQuick v2. I wonder if they could be
> harmonized at all?
>
> We can use QML to describe UIs in all four.

True - but I'm thinking more about the implementation. If someone adds
a new feature to a QtWidgets control for example, how much extra work
is it usually to implement that for QtQuick controls as well?


On 21 April 2014 20:49, Steve Gold <***@gmail.com> wrote:
> I have been reading the discussions about Qt’s future and strongly feel that
> it's full of promise. Last year I used a different application framework but
> the company went bankrupt without notifying its users. I then tried several
> other frameworks but wasn’t happy with any of them. Then I came across
> Cosos2d-x and Qt and briefly tried both. I quickly came to the conclusion
> that QML (with JavaScript) was an extremely powerful way to develop systems
> and that I was able to use C++ if I needed to access existing libraries or
> required critical performance. IMHO, this one-two punch in some ways sets Qt
> above the fray and enable developers to create and deploy a wide range of
> applications, including complex and highy performant ones. QML can be used
> when it is appropriate and C++ can be used when it is appropriate.
>
> When I last counted the QML types and C++ classes I found that the C++
> classed outnumbered the QML typed by approximately 3:1. I’m certainly not
> suggesting that the ratio be close to 1:1 but there is some room here for
> improvement. I like that many of the new features of Qt 5.3 and some of its
> immediate predecessors allow users to access functionality in C++ or QML and
> hope that this trend continues. There are certainly several aspects of Qt
> that can be improved, like the Qt Creator editor for one, but Qt is an open
> source project and everyone has an opportunity to contribute by comments,
> suggestions or even code.
>
> BTW, I agree with the statement "I do not really care about .ui file
> support." I would, however, like to see some improvement in the Qt Creator
> design functionality, especially since the older Qt Designer appears to have
> more capability than the newer Qt Quick Designer. However, I personally
> disagree that "100% C++ GUI is fine." QML provides a MUCH better vehicle for
> GUI than C++ and after using C++ and Java for many years I can see
> tremendous benefit in QML. If someone wants to spend the time and effort to
> create GUIs in C++, then I wish him or her luck. I've experienced some pain
> with this in the past and I don't want to do it again. It's just my
> preference and may not be right for everyone.
>
> To Qt's bright future,
>
> Steve
>
> -----Original Message-----
> From: ***@rpzdesign.com
> Sent: Monday, April 21, 2014 12:55 PM
> To: Thiago Macieira ; ***@qt-project.org
> Subject: Re: [Development] Question about Qt's future
>
> Thiago:
>
> I really appreciate your and Intel's participation in the open source Qt
> project.
>
> I think you misunderstood what I was talking about and forcefully
> rejected that which I did not ask.
>
> I want the "pattern" brought forward, but we should not try to bring the
> code forward. Let sleeping dogs lie.
>
> After reading these:
>
> http://qt-project.org/doc/qt-5/topics-graphics.html
> http://qt-project.org/doc/qt-5/qtquick-visualcanvas-scenegraph.html
> http://qt-project.org/doc/qt-5/qtquick-visualcanvas-scenegraph.html#scene-graph-and-rendering
>
> What I think would be a solution is to create a starting point
> where Qt Widget 2.0 development could begin anew again based on the
> QQuickPaintedItem class.
>
> I think the notion of a Window with child custom controls is not too far
> fetched.
>
> My suggestion is basically to provide an early off ramp for QQuickWindow
> to allow for 100% C++ projects.
>
> This may even serve as the foundation for custom controls in QML as
> well, don't know enough right now to be dangerous.
>
> It would definitely provide current Qt Widget users a sense of ease
> that the Widget option is still available even though QtQuickWindow is
> the future focus.
>
> QML and QTWidget would then both use the same dual GUI/render thread
> foundation, but it would be good to have an early C++ jumping off point
> for QQuickWindow based projects.
>
> I do not really care about .ui file support. For all I can see, 100%
> C++ GUI is fine.
>
> What do you think?
>
> Cheers,
>
> md
>
>
> On 4/21/2014 12:19 PM, Thiago Macieira wrote:
>> Em seg 21 abr 2014, às 10:59:43, ***@rpzdesign.com escreveu:
>>> Can Qt Widgets design pattern be brought forward using the same OpenGL
>>> foundation
>>> that QML uses to instantiate controls?
>>
>> Short answer: no.
>>
>> Long answer: if you want it working in other platforms, without glitches
>> and
>> regressions, the effort required for this is enormous. It basically
>> requires
>> rewriting all or almost all widgets from scratch so that they work in a
>> retained-mode OpenGL scene graph, instead of imperative-mode raster buffer
>> painting. It's a complete paradigm change.
>>
>> Since this requires a rewrite, instead of doing it in QtWidgets and
>> risking
>> regressions that users will not accept, the idea was instead to do it in a
>> different module, one where we can experiment and at the same time clean
>> up
>> some of the mistakes that exist in QtWidgets and can't be cleaned up
>> without
>> annoying someone.
>>
>> That's the Qt Quick Components.
>>
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

[Kevin Krammer]

On Monday, 2014-04-21, 10:59:43, ***@rpzdesign.com wrote:

> You can separate the GUI from the Model in C++ Classes as well, not just
> in QML/js vs C++ boundary.

Of course. I meant that the boundary makes it more obvious when you are
attemping logic within the UI since you very explicitly switch from
declarative to imperative code.

> Can Qt Widgets design pattern be brought forward using the same OpenGL
> foundation
> that QML uses to instantiate controls?

QML can instantiate widgets the same way it can instantiate QtQuick items.
It can instantiate any default constructible QObject subclass and most widgets
are in that category.

Cheers,
Kevin

--
Qt Developer Days 2014, October 6 - 8 at BCC, Berlin. Save the dates!

Kevin Krammer | ***@kdab.com | Senior Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. Sweden (HQ) [phone], USA +1-866-777-KDAB(5322)
KDAB - Qt Experts - Platform-independent software solutions

[Thiago Macieira]

Em seg 21 abr 2014, às 15:31:57, Yves Bailly escreveu:
> QML has its merit, it's certainly perfect for some projects. But for all
> I've seen and tried until now, only for projects having a rather simple UI.
> For really complex UIs, QML seems not suitable - at least for now.

So our effort goes into making QML suitable.

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

[Attila Csipa]

On 21-Apr-14 18:14, Thiago Macieira wrote:
> Em seg 21 abr 2014, às 15:31:57, Yves Bailly escreveu:
>> QML has its merit, it's certainly perfect for some projects. But for all
>> I've seen and tried until now, only for projects having a rather simple UI.
>> For really complex UIs, QML seems not suitable - at least for now.
>
> So our effort goes into making QML suitable.

It's a bit tricky. Traditionally, Qt did UIs by mimicking/drawing the UI
elements itself. This is cool, as it's allows for those native looking,
but also super-customizable (and quite fast) UIs. Or, rather, this used
to be cool. It's still VERY good for embedded and custom UIs requiring
that pixel perfect snappy UI (also the reason why it fares so well in
the consultancy/solutions business). But. Unfortunately platforms have
diversified, UIs look/act more different than ever (and it's not going
to change). This is, indirectly, IMO the reason why Qt Quick Components
took so long, why they (pardon my French) suck, and why they will suck
in the foreseeable future, and why I think Qt is (still) so far behind
in mobile. It seems nobody has the bandwidth to reimplement ALL the
controls/look'n'feel for ALL the platforms, so they would feel native
and integrate with the Qt apps seamlessly. This would be OK if Qt was a
game engine or not trying to have a general application framework
appeal. The current mobile examples demonstrate IMHO this quite clearly
- they do have a "I want this" appeal on a first run, but when you
scratch the surface you see these are more like Potemkin villages than
solutions to cross platform mobile development :( After playing a bit
with Xamarin (yes, I know, but put aside the C# hate for a minute), it's
quite striking what different approaches can result in (and it also made
it quite clear what Qt is doing better - but also worse than other cross
platform solutions).

Best regards,
Attila

[Nicola De Filippo]

+1
N.
Il giorno 24/apr/2014, alle ore 21:15, Attila Csipa <***@csipa.in.rs> ha scritto:

> It's a bit tricky. Traditionally, Qt did UIs by mimicking/drawing the UI
> elements itself. This is cool, as it's allows for those native looking,
> but also super-customizable (and quite fast) UIs. Or, rather, this used
> to be cool. It's still VERY good for embedded and custom UIs requiring
> that pixel perfect snappy UI (also the reason why it fares so well in
> the consultancy/solutions business). But. Unfortunately platforms have
> diversified, UIs look/act more different than ever (and it's not going
> to change). This is, indirectly, IMO the reason why Qt Quick Components
> took so long, why they (pardon my French) suck, and why they will suck
> in the foreseeable future, and why I think Qt is (still) so far behind
> in mobile. It seems nobody has the bandwidth to reimplement ALL the
> controls/look'n'feel for ALL the platforms, so they would feel native
> and integrate with the Qt apps seamlessly. This would be OK if Qt was a
> game engine or not trying to have a general application framework
> appeal. The current mobile examples demonstrate IMHO this quite clearly
> - they do have a "I want this" appeal on a first run, but when you
> scratch the surface you see these are more like Potemkin villages than
> solutions to cross platform mobile development :( After playing a bit
> with Xamarin (yes, I know, but put aside the C# hate for a minute), it's
> quite striking what different approaches can result in (and it also made
> it quite clear what Qt is doing better - but also worse than other cross
> platform solutions).
>
> Best regards,
> Attila

[Robert Knight]

> After playing a bit with Xamarin (yes, I know, but put aside the C# hate for a minute),
> it's quite striking what different approaches can result in (and it also made
> it quite clear what Qt is doing better - but also worse than other cross
> platform solutions).

Have you elaborated on this anywhere? I think a blog post or two
comparing Qt and alternatives like Xamarin would make interesting
reading for the community.

Regards,
Rob.

On 25 April 2014 08:14, Nicola De Filippo <***@nicoladefilippo.it> wrote:
> +1
> N.
> Il giorno 24/apr/2014, alle ore 21:15, Attila Csipa <***@csipa.in.rs> ha
> scritto:
>
> It's a bit tricky. Traditionally, Qt did UIs by mimicking/drawing the UI
> elements itself. This is cool, as it's allows for those native looking,
> but also super-customizable (and quite fast) UIs. Or, rather, this used
> to be cool. It's still VERY good for embedded and custom UIs requiring
> that pixel perfect snappy UI (also the reason why it fares so well in
> the consultancy/solutions business). But. Unfortunately platforms have
> diversified, UIs look/act more different than ever (and it's not going
> to change). This is, indirectly, IMO the reason why Qt Quick Components
> took so long, why they (pardon my French) suck, and why they will suck
> in the foreseeable future, and why I think Qt is (still) so far behind
> in mobile. It seems nobody has the bandwidth to reimplement ALL the
> controls/look'n'feel for ALL the platforms, so they would feel native
> and integrate with the Qt apps seamlessly. This would be OK if Qt was a
> game engine or not trying to have a general application framework
> appeal. The current mobile examples demonstrate IMHO this quite clearly
> - they do have a "I want this" appeal on a first run, but when you
> scratch the surface you see these are more like Potemkin villages than
> solutions to cross platform mobile development :( After playing a bit
> with Xamarin (yes, I know, but put aside the C# hate for a minute), it's
> quite striking what different approaches can result in (and it also made
> it quite clear what Qt is doing better - but also worse than other cross
> platform solutions).
>
> Best regards,
> Attila
>
>
>
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>

[Peter Kümmel]

On 24.04.2014 21:15, Attila Csipa wrote:
> solutions to cross platform mobile development :( After playing a bit
> with Xamarin (yes, I know, but put aside the C# hate for a minute), it's
> quite striking what different approaches can result in (and it also made
> it quite clear what Qt is doing better - but also worse than other cross
> platform solutions).

Recently I also has to write some non-GUI code in C# (a simple class
to connect to a server written in C++/Qt using Google's protobuf).

First I was a bit annoyed about this, but after "putting away the C# hate"
it wasn't that bad. He some impressions:
- for my use case it was cross-platform out-of-the box (Windows/Linux)
- you don't have to care about the build system, just use the .sln files
- you have the feeling to write code in a hurry because everything is placed in the headers
- you realize that C++ compilers/language is much more powerful, especially when using generics
- you've lost the contact to the real hardware, all feels so smooth
- you don't see what's going on because of all the stuff in the background (ok until there are problems)

As said I didn't build a GUI, what are your experiences with the GUI part C#?

Cheers,
Peter

[Robert Iakobashvili]

On Mon, Apr 28, 2014 at 6:53 AM, Thiago Macieira
<***@intel.com>wrote:

> Em dom 27 abr 2014 15:01:10 você escreveu:
> > > It's not the only available choice. Widgets are available. They just
> look
> > > horrible because no one has done any work to make them look native.
> >
> > Is my understating correct that:
> >
> > 1. at least QML apps in iOS already have a native look?
> > Any examples beyond the most basic?
>
> The point I was trying to make is that they will have a native look, if
> they
> don't already. I don't know if they do. I don't do iOS development and
> don't
> care to follow the development there.
>
> However, QtWidgets will never have native look on iOS.
>
> > 2. there are any Qt-related benchmarks demonstrating
> > opengl versus i.e. raster performance advantages for iOS and Android?
> > Any links?
>
> That's pretty basic information. OpenGL always beats, hands down. Try to do
> nice effects in raster and you'll see a huge CPU spike, eating battery, or
> not
> able to finish at all.
>
> I don't have links for this. it should be easy to find on Google.
>
> > 3. opengl issues on Android have been addressed and it is stable?
>
> I'm not aware of any issues. But I don't follow Android development closely
> either.
>
> > 4. memory footprint, particularly on iOS devices with
> > 1GB of RAM, best case, for QML is reasonable and does
> > not cost a foot and leg?
> > Any data?
>
> I don't know either. Like I said, I don't follow iOS development. I don't
> have
> an SDK for it installed and don't care to try it.
>
> If you had asked for 256 MB, I'd be worried. For 1 GB, it shouldn't be a
> problem, but I can't give you data.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
> Software Architect - Intel Open Source Technology Center
>
>
Sorry, but the above is not helpful.

I'd never jump to conclusions and statements without
in-hands knowledge of the subject to talk about.

Thank you.

Regards,
Robert

[Thiago Macieira]

Em seg 28 abr 2014, às 07:35:10, Robert Iakobashvili escreveu:
> Sorry, but the above is not helpful.
>
> I'd never jump to conclusions and statements without
> in-hands knowledge of the subject to talk about.

You asked for my personal opinion the moment that you emailed me directly
without the list in Cc. A personal email gets a personal response -- if it
gets a response at all. Very often I'm busy and I don't reply to personal
emails.

Anyway, I replied with my opinion. What I didn't know as a fact, I clearly
stated, then gave an educated guess. Maybe it isn't helpful to you, but it's
the best I could do.

PS: please do not send personal emails to the public.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

[Joshua Kolden]

I’m curious why you are not interested in QML.

I’m just finishing up a an initial production release of software oriented towards high-performance graphics. We used QML for the interface, coffeescript for view logic, and Qt/c++ for processing and business logic. It works astonishingly well sine we can design and build the UI separately from the business logic, and designers can work interactively without a compilation step, while the business logic can worry about threads and other performance processing complexity without regard to the event loop, just throwing things over the fence to the UI when ready.

I see no reason to stay with Qt Widgets at all other than legacy application support. So what is your concern? Is it just that you don’t what to go from being an expert in the tools you already know to an beginner at new tools, or are you up to speed on QML and you have some details on why this approach is a bad idea? I haven’t found any major issues, other then a few bugs and missing features that will be fixed soon enough.

Please don’t read this as me being facetious, I’m genuinely looking for any information that would indicate the we are on the wrong path with our application design.

Thanks,
j


On Apr 20, 2014, at 6:40 PM, Michael Knight <***@gmail.com> wrote:

> I feel like Qt is going in the direction of being Qml and Javascript only.I
> fear that they may abandon Qt Widgets in the near future,I think they are
> heavily promoting Qml.I don't want to use Qml,and before I start using Qt,I
> want to be sure that they will not abandon C++ side of Qt and that they
> continue to develop C++ side.It seems to me that they are developing Qml side
> mostly.
>
> What do you think about this?
>
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

[Christoph Feck]

On Monday 21 April 2014 05:27:33 Joshua Kolden wrote:
> I’m curious why you are not interested in QML.
> [...]
> I see no reason to stay with Qt Widgets at all other than legacy
> application support. So what is your concern?
> [...]

Not speaking for Michael, but let me add that C++ is much easier to
debug compared to QML, if you get a crash. We have nearly hundred
backtraces in the Plasma bug tracker that point back to crashes in
QtDeclarative, without a single clue where the crash comes from. For
examples see bugs 328234, 332131, 331060, 333621, 333532, 333334,
332995, or 332646 to cite only some fairly recent ones.

I am not blaming QML here, all those bugs are possibly caused by
errors in Plasma itself, but the fact that you cannot see from the
backtrace what caused the crash is a major concern for me.

--
Christoph Feck
http://kdepepo.wordpress.com/
KDE Quality Team
openSUSE Review Team

[Simon Hausmann]

On Monday 21. April 2014 10.41.52 Christoph Feck wrote:
> On Monday 21 April 2014 05:27:33 Joshua Kolden wrote:
> > I’m curious why you are not interested in QML.
> > [...]
> > I see no reason to stay with Qt Widgets at all other than legacy
> > application support. So what is your concern?
> > [...]
>
> Not speaking for Michael, but let me add that C++ is much easier to
> debug compared to QML, if you get a crash. We have nearly hundred
> backtraces in the Plasma bug tracker that point back to crashes in
> QtDeclarative, without a single clue where the crash comes from. For
> examples see bugs 328234, 332131, 331060, 333621, 333532, 333334,
> 332995, or 332646 to cite only some fairly recent ones.
>
> I am not blaming QML here, all those bugs are possibly caused by
> errors in Plasma itself, but the fact that you cannot see from the
> backtrace what caused the crash is a major concern for me.

Let's turn this from a blame game into something more productive.

The nature of the beast is that we do have two language environments here and
they do (and can't) share the same stack, so stack traces will always be
separate. However there are ways of determining the "current" JavaScript stack
trace in parallel. Note that this isn't possible with Qt 5.1 or older, but
starting with Qt 5.2 it is possible.

Friedemann was kind enough to lay the infrastructure for that in QtQml and
used it on the Qt Creator side, in a way that could also be used by KDE's
drkonqi:

It will require a little bit of analysis and interaction with gdb, but I think
it's doable. It will require looking at the frames gdb reports, and if you see
functions that take a QV4::ExecutionContext * as a parameter, then you can
extract the "address" from the gdb output and then call the qt_v4StackTrace
function in QtQml from within gdb. It will print out a JavaScript stack trace.
This works rather well and Qt Creator 3.1 provides it through the context menu
in the debugger, if you'd like to try it out yourself.

This way bug reports in KDE that somehow involve Qt JavaScript execution can -
in parallel - include a C++ backtrace and a JS stack trace.


Simon

[André Pönitz]

On Thu, Apr 24, 2014 at 09:47:50AM +0200, Simon Hausmann wrote:
> Let's turn this from a blame game into something more productive.

I will simply assume this includes the readiness to re-consider some
of the non-technical decisions of the past.

> The nature of the beast is that we do have two language environments here
> and they do (and can't) share the same stack, so stack traces will always
> be separate.

There are two separate issues here: 1. The requirement to have two sources
of stack frames, and 2. the specific setup of the JS stack extraction
machinery.

Re 1: It is possible to get a single unified stack trace using standard
tools an application that's wildly mixing languages (in case of GDB e.g.
C++, C, Fortran, ADA, D, Modula 2 and a few others) _on the same stack_
_out of the box_. Such a single frame source is ideal from a tooling
perspective as it allows complete re-use of standard debugging and
profiling tools, as well as free integration into platform native IDEs
like Visual Studio or Xcode.

We could get there, but that would require de-emphasizing the importance
of JavaScript in the QML/JS conglomerate, i.e. primarily targeting a
"Pure-Declarative-UI plus C++-Core scenario". I understand that you don't
want that, but being able to re-use standard tools is the only feasible
long-term approach.

Re 2: The two sources of stack frames can be worked with in
certain setups: There are examples to e.g. extract data
from a mixed C++/Python setup using GDB (quick search finds
https://fedoraproject.org/wiki/Features/EasierPythonDebugging, but I
think I saw something more complete once). Some problems remain:
- "Certain setups": To make that work cross-platform such an integration
would be needed for all widely used native debugging backends
(currently GDB, CDB, LLDB) i.e. at least tripled work for us - and
that's already assuming the CDB calling restrictions don't interfere,
i.e. it is possible at all)
- The stack interweaving requires active IDE support, or at least some
layer on top of two language-specific frame extraction machineries.
We can do that with some effort for Qt Creator. There might be
some kind people repeating that work for KDevelop, and possibly some
others, at some time. VS? Unlikely. Xcode? No chance.
[- At least at V8 times (I really haven't looked at V4 yet, I understand
it should be less of an issue there), JS stack extraction required the
JS engine to "run", while the C++ side needed to be "stopped" to get
their respective frames. This requires extra co-ordination on the IDE
side and rules out debugging scenarios like "post mortem"/"core files"
which are rather common for non-trivial applications.]
- Repeat for profiling. And any other kind of project analysis.

All in all, the cases where "mixed stacks" really work well are very
limited and even those cases come with a steep price tag. Which brings me
back to #1: The only reasonable, long-term feasible approach is one that
allows the direct re-use of standard tools.

Andre'

[Simon Hausmann]

On Thursday 24. April 2014 14.08.03 André Pönitz wrote:
> On Thu, Apr 24, 2014 at 09:47:50AM +0200, Simon Hausmann wrote:
> > Let's turn this from a blame game into something more productive.
>
> I will simply assume this includes the readiness to re-consider some
> of the non-technical decisions of the past.
>
> > The nature of the beast is that we do have two language environments here
> > and they do (and can't) share the same stack, so stack traces will always
> > be separate.
>
> There are two separate issues here: 1. The requirement to have two sources
> of stack frames, and 2. the specific setup of the JS stack extraction
> machinery.
>
> Re 1: It is possible to get a single unified stack trace using standard
> tools an application that's wildly mixing languages (in case of GDB e.g.
> C++, C, Fortran, ADA, D, Modula 2 and a few others) _on the same stack_
> _out of the box_. Such a single frame source is ideal from a tooling
> perspective as it allows complete re-use of standard debugging and
> profiling tools, as well as free integration into platform native IDEs
> like Visual Studio or Xcode.
>
> We could get there, but that would require de-emphasizing the importance
> of JavaScript in the QML/JS conglomerate, i.e. primarily targeting a
> "Pure-Declarative-UI plus C++-Core scenario". I understand that you don't
> want that, but being able to re-use standard tools is the only feasible
> long-term approach.

Ah, is this based on the idea that the .qml files would not contain any code
but merely describe the UI layout, and all the logic is entirely and
exclusively implemented in C++ or any other language supported by the same
compilation and run-time environment? (i.e. eliminate JavaScript from Qml)


Simon

[Roland Winklmeier]

Am 21.04.2014 05:27, schrieb Joshua Kolden:
> I’m curious why you are not interested in QML.
>
> I’m just finishing up a an initial production release of software oriented towards high-performance graphics. We used QML for the interface, coffeescript for view logic, and Qt/c++ for processing and business logic. It works astonishingly well sine we can design and build the UI separately from the business logic, and designers can work interactively without a compilation step, while the business logic can worry about threads and other performance processing complexity without regard to the event loop, just throwing things over the fence to the UI when ready.
>
> I see no reason to stay with Qt Widgets at all other than legacy application support. So what is your concern? Is it just that you don’t what to go from being an expert in the tools you already know to an beginner at new tools, or are you up to speed on QML and you have some details on why this approach is a bad idea? I haven’t found any major issues, other then a few bugs and missing features that will be fixed soon enough.
>
> Please don’t read this as me being facetious, I’m genuinely looking for any information that would indicate the we are on the wrong path with our application design.
>
> Thanks,
> j
>
>
> On Apr 20, 2014, at 6:40 PM, Michael Knight <***@gmail.com> wrote:
>
>> I feel like Qt is going in the direction of being Qml and Javascript only.I
>> fear that they may abandon Qt Widgets in the near future,I think they are
>> heavily promoting Qml.I don't want to use Qml,and before I start using Qt,I
>> want to be sure that they will not abandon C++ side of Qt and that they
>> continue to develop C++ side.It seems to me that they are developing Qml side
>> mostly.
>>
>> What do you think about this?
>

I'm working for a Flight Simulator addon project which was initiated 1
year ago. When we started with the UI part, QML was heavily promoted in
Qt5 to be the future of Qt and I also got the feeling that QtWidgets are
not longer developed (except of bug fixing and minor features - but the
focus is now on QML). I hadn't used QML or QtQuick before at all, so I
looked into it and the demonstrations were indeed nice. So we started to
design our UI with QML. I liked the design to split business logic into
C++ and UI design into QML and I still like it, but I came across
several blocking issues (some of them are only valid for our
application, some of them are general):

- Our application has a huge framework of value classes. They cannot (or
at least it does not make sense to) derive from QObject for several
reasons. But subclassing QObject is the requirement to access data from
C++ in QML. So we had our framework of well designed value classes and
cannot use them in QML. There were evaluations to create QObject
wrappers, but no nice solution. So no support for value classes is
probably a show stopper for many projects. With Widgets we were able to
use them easily.
- When we did our QML tests, I got the feeling QML in general is not yet
stable enough. The performance was not always the best (e.g. scrolling
in a table view was not smooth).
- UI components: QML did not have the set of standard UI components. I
know this is currently changing with QQuickControls but one year ago,
there wasn't much. So Widgets were easier to start with.
- Memory consumption: Even a mini example took about 70 MB of memory,
QtWidgets need a lot less. This is not a complain, I know the JS runtime
needs its initial memory. It was just one factor, because our
application is running as an addon to Flight Simulators and they usally
consum a lot memory. This is especially a major problem with MS Flight
Simulator since it is only available as 32 bit application. Therefore
every any MegaByte is important.

Dont get me wrong. I'm excited about QML. Doing UI design in C++ is
awfull and QML really would improve things. The current implementation
is good for some projects, but it is not the solution for everything.
There are still even new projects going back to QtWidgets (as we did),
because QML is not suitable. So to me its not only legacy support.
However I rethink my descision when most the above points are addressed
in later QML versions.

---
Diese E-Mail ist frei von Viren und Malware, denn der avast! Antivirus Schutz ist aktiv.
http://www.avast.com

[Joshua Kolden]

On Apr 21, 2014, at 4:39 AM, Roland Winklmeier <***@gmail.com> wrote:

> Am 21.04.2014 05:27, schrieb Joshua Kolden:
>> I’m curious why you are not interested in QML.
>>
>> I’m just finishing up a an initial production release of software oriented towards high-performance graphics. We used QML for the interface, coffeescript for view logic, and Qt/c++ for processing and business logic. It works astonishingly well sine we can design and build the UI separately from the business logic, and designers can work interactively without a compilation step, while the business logic can worry about threads and other performance processing complexity without regard to the event loop, just throwing things over the fence to the UI when ready.
>>
>> I see no reason to stay with Qt Widgets at all other than legacy application support. So what is your concern? Is it just that you don’t what to go from being an expert in the tools you already know to an beginner at new tools, or are you up to speed on QML and you have some details on why this approach is a bad idea? I haven’t found any major issues, other then a few bugs and missing features that will be fixed soon enough.
>>
>> Please don’t read this as me being facetious, I’m genuinely looking for any information that would indicate the we are on the wrong path with our application design.
>>
>> Thanks,
>> j
>>
>>
>> On Apr 20, 2014, at 6:40 PM, Michael Knight <***@gmail.com> wrote:
>>
>>> I feel like Qt is going in the direction of being Qml and Javascript only.I
>>> fear that they may abandon Qt Widgets in the near future,I think they are
>>> heavily promoting Qml.I don't want to use Qml,and before I start using Qt,I
>>> want to be sure that they will not abandon C++ side of Qt and that they
>>> continue to develop C++ side.It seems to me that they are developing Qml side
>>> mostly.
>>>
>>> What do you think about this?
>>
>
> I'm working for a Flight Simulator addon project which was initiated 1
> year ago. When we started with the UI part, QML was heavily promoted in
> Qt5 to be the future of Qt and I also got the feeling that QtWidgets are
> not longer developed (except of bug fixing and minor features - but the
> focus is now on QML). I hadn't used QML or QtQuick before at all, so I
> looked into it and the demonstrations were indeed nice. So we started to
> design our UI with QML. I liked the design to split business logic into
> C++ and UI design into QML and I still like it, but I came across
> several blocking issues (some of them are only valid for our
> application, some of them are general):
>
> - Our application has a huge framework of value classes. They cannot (or
> at least it does not make sense to) derive from QObject for several
> reasons. But subclassing QObject is the requirement to access data from
> C++ in QML. So we had our framework of well designed value classes and
> cannot use them in QML. There were evaluations to create QObject
> wrappers, but no nice solution. So no support for value classes is
> probably a show stopper for many projects. With Widgets we were able to
> use them easily.

Hmm, I’m not sure what you mean by value classes. Do you mean literally data models? You don’t need to move QObjects across to QML if you are just sending data for display in the UI. We have lots of complicated data types that we simply save in QVariantMaps, and they show up as javascript objects in QML. You may not have this flexibility, but as the application designer on our project I don’t allow anyone to put new classes into QML from c++ unless they directly drive a viewable element, because that contaminates the view layer with business logic, following the MVC pattern. I wouldn’t allow that with widgets either.

> - When we did our QML tests, I got the feeling QML in general is not yet
> stable enough. The performance was not always the best (e.g. scrolling
> in a table view was not smooth).

I agree, we’ve had some issues there too. I’m still struggling with a signifiant drop in frame rate / smoothness with our app running on a macbook pro with retina display, and that’s a pretty beefy device to be having performance issues with. However, we did discover there are lots of tools for optimizing that are not well documented, or at least don’t stand out well in the documentation. Things like cacheBuffer to pre-create objects out side the viewable area in some layouts and the layer properties for creating textures for elements that are not changing at the moment. Depending on the elements they are replacing these tools may also save memory or use more memory.

More clearly defined optimization tools would be great.

> - UI components: QML did not have the set of standard UI components. I
> know this is currently changing with QQuickControls but one year ago,
> there wasn't much. So Widgets were easier to start with.

Yep, this is probably the biggest weakness for most projects at the moment I think. At the moment you’re better off creating your own interface, which we have the luxury of doing for this app, but not everyone has the resources to do custom UI design.

> - Memory consumption: Even a mini example took about 70 MB of memory,
> QtWidgets need a lot less. This is not a complain, I know the JS runtime
> needs its initial memory. It was just one factor, because our
> application is running as an addon to Flight Simulators and they usally
> consum a lot memory. This is especially a major problem with MS Flight
> Simulator since it is only available as 32 bit application. Therefore
> every any MegaByte is important.

We don’t have this constraint so I can speak to it. Our app seems fairly big in memory, but by no means approaching any limits on any devices we’re deploying too.

> Dont get me wrong. I'm excited about QML. Doing UI design in C++ is
> awfull and QML really would improve things. The current implementation
> is good for some projects, but it is not the solution for everything.
> There are still even new projects going back to QtWidgets (as we did),
> because QML is not suitable. So to me its not only legacy support.
> However I rethink my descision when most the above points are addressed
> in later QML versions.
>

Yeah, for us the biggest asset and biggest issue with QML is that it’s the future of how this kind of stuff is done, it’s already much better than the way we worked before, but not every piece we’d like to have is in place yet, and some pieces are broken. Nevertheless, that hasn’t kept us from selecting it for this project. I just hope it doesn’t bite me on the ass, when our app hits the streets.

j

> ---
> Diese E-Mail ist frei von Viren und Malware, denn der avast! Antivirus Schutz ist aktiv.
> http://www.avast.com
>
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

[Roland Winklmeier]

>>
>> - Our application has a huge framework of value classes. They cannot (or
>> at least it does not make sense to) derive from QObject for several
>> reasons. But subclassing QObject is the requirement to access data from
>> C++ in QML. So we had our framework of well designed value classes and
>> cannot use them in QML. There were evaluations to create QObject
>> wrappers, but no nice solution. So no support for value classes is
>> probably a show stopper for many projects. With Widgets we were able to
>> use them easily.
>
> Hmm, I’m not sure what you mean by value classes. Do you mean literally data models? You don’t need to move QObjects across to QML if you are just sending data for display in the UI. We have lots of complicated data types that we simply save in QVariantMaps, and they show up as javascript objects in QML. You may not have this flexibility, but as the application designer on our project I don’t allow anyone to put new classes into QML from c++ unless they directly drive a viewable element, because that contaminates the view layer with business logic, following the MVC pattern. I wouldn’t allow that with widgets either.
>

The term value classes is due to history reasons in our project. We
started creating classes to handle physical values. Hence the name.
Some of them are data models representing entities (e.g. aircrafts) and
also abstract items (e.g. altitude, callsign, flightplan). All these
classes have an advanced API and logic written in C++, for example
CAltitude has complex API methods to get the value in different units.
We also use them as a property/value for example to assign it to an
aircraft: setAltitude(const CAltitude &altitude).
If I want to access this methods from QML I would have to derive them
from QObject and register it in the QML context.
I remember QVariantMaps were also discussed. I cannot remember exactly
why we finally did not use them. But I guess QVariantMaps are only for
easy types.
Maybe there is a way to do it and I have overlooked it. I can remember
some discussion in this list
(http://lists.qt-project.org/pipermail/interest/2013-October/009202.html) and
also in IRC saying, some kind of value class support is planned.
For the time being it was a lot easier to call a c++ method
getAltitude(AltitudeUnit unit) from QtWidgets than QML :)


---
Diese E-Mail ist frei von Viren und Malware, denn der avast! Antivirus Schutz ist aktiv.
http://www.avast.com

[Kevin Krammer]

On Monday, 2014-04-21, 14:52:25, Roland Winklmeier wrote:
> >> - Our application has a huge framework of value classes. They cannot (or
> >> at least it does not make sense to) derive from QObject for several
> >> reasons. But subclassing QObject is the requirement to access data from
> >> C++ in QML. So we had our framework of well designed value classes and
> >> cannot use them in QML. There were evaluations to create QObject
> >> wrappers, but no nice solution. So no support for value classes is
> >> probably a show stopper for many projects. With Widgets we were able to
> >> use them easily.
> >
> > Hmm, I’m not sure what you mean by value classes. Do you mean literally
> > data models? You don’t need to move QObjects across to QML if you are
> > just sending data for display in the UI. We have lots of complicated
> > data types that we simply save in QVariantMaps, and they show up as
> > javascript objects in QML. You may not have this flexibility, but as the
> > application designer on our project I don’t allow anyone to put new
> > classes into QML from c++ unless they directly drive a viewable element,
> > because that contaminates the view layer with business logic, following
> > the MVC pattern. I wouldn’t allow that with widgets either.
> The term value classes is due to history reasons in our project. We
> started creating classes to handle physical values. Hence the name.
> Some of them are data models representing entities (e.g. aircrafts) and
> also abstract items (e.g. altitude, callsign, flightplan). All these
> classes have an advanced API and logic written in C++, for example
> CAltitude has complex API methods to get the value in different units.
> We also use them as a property/value for example to assign it to an
> aircraft: setAltitude(const CAltitude &altitude).

If you already have them as property values, what kind of operation do you
need to do in QML that requires JS bindings for those objects?

> If I want to access this methods from QML I would have to derive them
> from QObject and register it in the QML context.

Not necessarily, depends on what you want to do.
However, it is true that it would be nice to have something similar to
QtScript's binding facilities.

> For the time being it was a lot easier to call a c++ method
> getAltitude(AltitudeUnit unit) from QtWidgets than QML :)

You mean if the method is in a different class then the enum definition?

Cheers,
Kevin
--
Qt Developer Days 2014, October 6 - 8 at BCC, Berlin. Save the dates!

Kevin Krammer | ***@kdab.com | Senior Software Engineer
KlarÀlvdalens Datakonsult AB, a KDAB Group company
Tel. Sweden (HQ) [phone], USA +1-866-777-KDAB(5322)
KDAB - Qt Experts - Platform-independent software solutions

[charleyb123 .]

I'm not Roland (talking about "value-types"), but I completely agree with
his comments on why they are important (we have that issue also).

But, "jumping-in", ...

<snip, from Roland>,

> >> - Our application has a huge framework of value classes. They cannot
> (or
> > >> at least it does not make sense to) derive from QObject for several
> > >> reasons. But subclassing QObject is the requirement to access data
> from
> > >> C++ in QML. So we had our framework of well designed value classes and
> > >> cannot use them in QML. <snip>



> > The term value classes is due to history reasons in our project. We
> > started creating classes to handle physical values. Hence the name.
>
<snip>,

We call them, "deep/rich" types, sometimes "domain-specific-abstractions",
sometimes "value-types", sometimes "popcorn-types" (domain-specific values
that come-and-go, and typically comprise our API interfaces).

Kevin asketh:

> If you already have them as property values, what kind of operation do you
> need to do in QML that requires JS bindings for those objects?
>

The issue is that Real World Code almost always defines many "value-types"
that propagate through the interface. They NEST. That's the Big Deal
Thing(tm). These typically define your APIs. Those (existing C++) APIs
are EXACTLY what we want to (or "must") expose to QML. The values
*themselves* are typically "properties", like those that you would want
exposed through QML.

For example, on our system:

my_cytometer.laser.wavelength // Yields "Wavelength" property

...In this case, none of "class Cytometer" nor "class Laser" nor "class
Wavelength" derive from QObject, but we want them exposed to QML.
Including their nested properties. Wrapping-or-deriving-from-QObject is
now required. The "Wavelength" is literally an attribute of "Laser", which
is an attribute of "Cytometer" in existing code. We need to expose to QML
all of them: "QmlCytometer", "QmlLaser", "QmlWavelength"

When you have hundreds of classes like this, and their relationships define
your APIs (this is C++ and strong-compile-time-typing and that's what you
are SUPPOSED to do), and NONE of these are derived from QObject, it is now
"work" to figure out how to expose these to QML.

No, exposing a "long" or "double" is not sufficient (you MUST expose a real
"Wavelength-object" to QML. It has "rules" in the class, such as for
forming/parsing strings, conversion to/from RGB, and QML needs to
*reference* specific "Wavelength" instances in the back-end-system (and
sometimes have a "value" of a "Wavelength" instance).

And actually, the "biggest-issue" is the NESTING: The "Laser" is an
attribute of "Cytometer". That granularity must be respected all the way
through to QML, because they comprise one-to-many and many-to-many in your
design (e.g., many "Laser" instances are on a single "Cytometer", but a
single "Laser" typically has a single "Wavelength", but sometimes more.)

> If I want to access this methods from QML I would have to derive them
> > from QObject and register it in the QML context.
>
> Not necessarily, depends on what you want to do.
> However, it is true that it would be nice to have something similar to
> QtScript's binding facilities.
>

Agree with Roland. Must. I MUST have "Cytometer" and "Laser" and
"Wavelength" exposed to QML.

In only the "simplest-of-toy-applications" could we pretend that a
"QmlCytometer" exposed to QML has a vector-of-double values to represent
the "several-wavelengths" that might be associated with that "cytometer".

In our system: We code-gen to wrap everything. "Wavelength" is now a QML
exposed property of "Laser", which is a QML exposed property of "Cytometer".

--charley

[Kevin Krammer]

On Monday, 2014-04-21, 11:28:24, charleyb123 . wrote:

> ...In this case, none of "class Cytometer" nor "class Laser" nor "class
> Wavelength" derive from QObject, but we want them exposed to QML.
> Including their nested properties. Wrapping-or-deriving-from-QObject is
> now required. The "Wavelength" is literally an attribute of "Laser", which
> is an attribute of "Cytometer" in existing code. We need to expose to QML
> all of them: "QmlCytometer", "QmlLaser", "QmlWavelength"
>
> When you have hundreds of classes like this, and their relationships define
> your APIs (this is C++ and strong-compile-time-typing and that's what you
> are SUPPOSED to do), and NONE of these are derived from QObject, it is now
> "work" to figure out how to expose these to QML.

Right. As I wrote elsewhere a mechanism like the one available in QtScript
would be benefitial.

> > If I want to access this methods from QML I would have to derive them
> >
> > > from QObject and register it in the QML context.
> >
> > Not necessarily, depends on what you want to do.
> > However, it is true that it would be nice to have something similar to
> > QtScript's binding facilities.
>
> Agree with Roland. Must. I MUST have "Cytometer" and "Laser" and
> "Wavelength" exposed to QML.
>
> In only the "simplest-of-toy-applications" could we pretend that a
> "QmlCytometer" exposed to QML has a vector-of-double values to represent
> the "several-wavelengths" that might be associated with that "cytometer".
>
> In our system: We code-gen to wrap everything. "Wavelength" is now a QML
> exposed property of "Laser", which is a QML exposed property of "Cytometer".

What I meant was: what kind of operations in QML do need access to these
compond types?

For example in a widget based UI you wouldn't have a standard widget [1] that
knows how to display or enter a Wavelength, right?

You would have some adapter code that will take a Wavelength object and then
process it into something a standard widget can handle.

Why does the adapter code no longer suffice?

Since I don't know about your data types let me try a different example.

If I had the need to display width/height/depth of an image I would likely
have a widget that has three labels or read-only spinboxes, neither of which
can read the image properties themselves.

So I would have adapter code that takes a QImage and accesses its width(),
height() and depth() methods and put those into the widgets.

As far as I can tell I could use the exact same adapter code if the UI was in
QML.
For additional declarative niceness I might be inclined to expose the wrapper
in the form of a type with an image property for input and three appropriately
named integer properties for output.
But the actual adapter code would be the same.

Cheers,
Kevin

[1] Custom widget would be in the same boat as custom item, so that obviously
can always deal with domain specific types.
--
Qt Developer Days 2014, October 6 - 8 at BCC, Berlin. Save the dates!

Kevin Krammer | ***@kdab.com | Senior Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. Sweden (HQ) [phone], USA +1-866-777-KDAB(5322)
KDAB - Qt Experts - Platform-independent software solutions

[Roland Winklmeier]

>
>
> > > If I want to access this methods from QML I would have to derive them
> > >
> > > > from QObject and register it in the QML context.
> > >
> > > Not necessarily, depends on what you want to do.
> > > However, it is true that it would be nice to have something similar to
> > > QtScript's binding facilities.
> >
> > Agree with Roland. Must. I MUST have "Cytometer" and "Laser" and
> > "Wavelength" exposed to QML.
> >
> > In only the "simplest-of-toy-applications" could we pretend that a
> > "QmlCytometer" exposed to QML has a vector-of-double values to represent
> > the "several-wavelengths" that might be associated with that "cytometer".
> >
> > In our system: We code-gen to wrap everything. "Wavelength" is now a
> QML
> > exposed property of "Laser", which is a QML exposed property of
> "Cytometer".
>
> What I meant was: what kind of operations in QML do need access to these
> compond types?
>
> For example in a widget based UI you wouldn't have a standard widget [1]
> that
> knows how to display or enter a Wavelength, right?
>
> You would have some adapter code that will take a Wavelength object and
> then
> process it into something a standard widget can handle.
>
> Why does the adapter code no longer suffice?
>
> Since I don't know about your data types let me try a different example.
>
> If I had the need to display width/height/depth of an image I would likely
> have a widget that has three labels or read-only spinboxes, neither of
> which
> can read the image properties themselves.
>
> So I would have adapter code that takes a QImage and accesses its width(),
> height() and depth() methods and put those into the widgets.
>
> As far as I can tell I could use the exact same adapter code if the UI was
> in
> QML.
> For additional declarative niceness I might be inclined to expose the
> wrapper
> in the form of a type with an image property for input and three
> appropriately
> named integer properties for output.
> But the actual adapter code would be the same.
>

What you are saying is correct and I'm not an expert in GUI design (sorry
if my explanations violate any Model-View theorems), but here is a real
world example.
Lets say we have a UI to display the Com and NAV frequency settings of your
aircraft. The whole aircraft is encapsulated in a CAircraft which looks
similar to this

class CAircraft
{

public:
CComDevice getCom1() const;
....
private:
CComDevice m_com1;
CComDevice m_com2;
CNavDevice m_nav1;
CNavDevice m_nav2;
}

class CComDevice
{
enum Unit
{
MHz,
kHz
};

CFrequency getFrequency(Unit unit) const;
....
private:
CFrequency m_frequency();
}

In a C++ QtWidget environment I'm now able to do the following to display
the frequency in a widget:

dataModel->getAircraft().getCom1().getFrequency(chosenUnit).toQString();

The main points are that at the time of writing the C++ model I don't know
which unit the user might select during runtime - MHz or kHz. So I need to
invoke getFrequency or call it from a wrapper.
In general I don't know what a GUI designer might need.
The second point is that the C++ data models are nested a lot and they are
easily accessible in C++ code because C++ of course knows how all these
data classes look like. The idea behind that is, the GUI designer can
choose what he wants to display and how. This is transparent to the C++
models.
Ideally I can to the same via QML by accessing the property hierarchy. This
would mean my data models are decoupled from my QML view implementation:

dataModel.aircraft.com1.frequency.string

but that requires of course that all classes are known in the QML context
which is not possible (if they dont subclass QObject).
As you said I can of course create C++ wrappers specific to a view, add the
line
dataModel->getAircraft().getCom1().getFrequency(chosenUnit).toQString();
into it and transfer the result as a QVariant, but that also means QML is
limited to what the wrappers provide. This is a loss of flexibility
additional to the effort writing the wrapper. This is of course possible
but not nice. Widgets are a lot more flexibel. If I want to display
different data in my view, I have to add/change only one line C++.

I'm missing this flexibility in QML to walk through my nested objects and
display in QML whatever I like. Having that, I would be a fan of QML :)

[Oswald Buddenhagen]

On Mon, Apr 21, 2014 at 02:52:25PM +0200, Roland Winklmeier wrote:
> If I want to access this methods from QML I would have to derive them
> from QObject and register it in the QML context.
>
try playing with Q_GADGET instead of QObject/Q_OBJECT - that's much less
heavyweight.
if it doesn't work with qml/quick in cases where there is no good reason
why it shouldn't, i'm sure the qml maintainers would welcome
contributions ...

[Olivier Goffart]

On Tuesday 22 April 2014 12:20:58 Oswald Buddenhagen wrote:
> On Mon, Apr 21, 2014 at 02:52:25PM +0200, Roland Winklmeier wrote:
> > If I want to access this methods from QML I would have to derive them
> > from QObject and register it in the QML context.
>
> try playing with Q_GADGET instead of QObject/Q_OBJECT - that's much less
> heavyweight.
> if it doesn't work with qml/quick in cases where there is no good reason
> why it shouldn't, i'm sure the qml maintainers would welcome
> contributions ...

Q_GADGET unfortunately only support enums. It does not support invokable or
properties.

(it actually could if we made use of the qt_static_metacall introduced in Qt
4.8)

--
Olivier

Woboq - Qt services and support - http://woboq.com - http://code.woboq.org

[André Somers]

Olivier Goffart schreef op 22-4-2014 13:01:
> On Tuesday 22 April 2014 12:20:58 Oswald Buddenhagen wrote:
>> On Mon, Apr 21, 2014 at 02:52:25PM +0200, Roland Winklmeier wrote:
>>> If I want to access this methods from QML I would have to derive them
>>> from QObject and register it in the QML context.
>> try playing with Q_GADGET instead of QObject/Q_OBJECT - that's much less
>> heavyweight.
>> if it doesn't work with qml/quick in cases where there is no good reason
>> why it shouldn't, i'm sure the qml maintainers would welcome
>> contributions ...
> Q_GADGET unfortunately only support enums. It does not support invokable or
> properties.
>
> (it actually could if we made use of the qt_static_metacall introduced in Qt
> 4.8)
>
Futhermore, it is private API. As still is basically all of Quick itself
(from a C++ perspective), making extending Quick a bit of a hazardous
experience...

André

[charleyb123 .]

Roland sayeth:

> <snip>, I liked the design to split business logic into
> C++ and UI design into QML and I still like it, but I came across
> several blocking issues (some of them are only valid for our
> application, some of them are general):
>
> - Our application has a huge framework of value classes. They cannot (or
> at least it does not make sense to) derive from QObject for several
> reasons. But subclassing QObject is the requirement to access data from
> C++ in QML. So we had our framework of well designed value classes and
> cannot use them in QML. There were evaluations to create QObject
> wrappers, but no nice solution. So no support for value classes is
> probably a show stopper for many projects. With Widgets we were able to
> use them easily. <snip>
>

Ditto for us: Huge network of value-classes, cannot derive from QObject.

However, integrating proprietary C++ classes to QML (both value and
reference semantics) through a code generator works great (and has other
advantages): I did a talk on this at Qt Dev Days (San Fran) 2013, and the
slides are online:

http://www.qtdeveloperdays.com/northamerica/2013/c-object-adapter-layer-qml

--charley

[cincirin]

Sorry for re-open this topic, but as someone else already pointed out,
what do you think about the Unreal engine guys to abandon the unreal
script which was used until now for many years ?
To quote some comments:
"In the past, gameplay code existed in UnrealScript. UnrealScript is the
scripting language which forms the core of current community mods, and
much of the gameplay code of all previous Unreal Engine titles.
However, UnrealScript is being removed.
In its place, the engine will be 100% C++, and highly optimized."

Also I'm curios why Android xml files are good for design the UI, but
"old" QtDesigner ui (xml) files seems to be deprecated in favor of qml.

Best regards,
Marius

[Robin Burchell]

Hi,

On 23 Apr 2014, at 14:14, cincirin <***@gmail.com> wrote:

Sorry for re-open this topic, but as someone else already pointed out,
what do you think about the Unreal engine guys to abandon the unreal
script which was used until now for many years ?


I don’t think this topic is really suited for this list, but I’ll answer it
anyway because why not.

To give some background about myself: I’ve been around Qt for a while,
actively developing with it since - I think - around 4.4, but I have also
had exposure to code a lot older than that. I’ve been involved with
developing two phones (one with C++ as the primary language of choice for
the system applications - the Nokia N9) and more recently I’ve been working
on Jolla’s Sailfish OS - which is a QML-centric (but not exclusive)
platform, with most middleware and logic (that is - the real guts) written
in C++.

My feeling is that QML has exactly the flaws everyone talks about: it can
easily create a mess of an application, it’s annoying to tool, it’s
annoying to debug (because, well, you’ve two languages / runtimes / etc
instead of one).

On the other hand, it’s also one of the fastest things I’ve ever found to
prototype UIs in (for context, the initial home screen code prototyping I
mention on https://twitter.com/w00teh/status/447041014520643584 happened
literally in one day). We had similar stories with most of our other
applications, being fleshed out in UI within a very short span of time,
with a lot more time then subsequently being spent in getting the
middleware in good shape and bolted together correctly.

Having a language runtime that isn’t C++ also frees you up from a few of
the usual messes (access-after-free, etc, etc, etc) and generally means
that the problems you get to debug are on a more superficial level. Unless
you run into engine or Quick item implementation issues, which sadly aren’t
yet as infrequent as I’d like - but it’s young. Give it time.

The central point I guess I’m trying to make here is that, like any other
tool, QML has its downsides, and as a developer, it is your job to be aware
of those downsides, and to try to stick to best practices when writing your
application. It’s perfectly possible to write a horribly unmaintainable
mess in any tool/language, given a bad developer. I think the tradeoffs are
worth the risks, even though I’ve seen a few of those horribly
unmaintainable messes already in QML’s short lifespan.

BR,
Robin

[Sze Howe Koh]

Hi Marius,

On 23 April 2014 20:14, cincirin <***@gmail.com> wrote:
> Sorry for re-open this topic, but as someone else already pointed out,
> what do you think about the Unreal engine guys to abandon the unreal
> script which was used until now for many years ?
> To quote some comments:
> "In the past, gameplay code existed in UnrealScript. UnrealScript is the
> scripting language which forms the core of current community mods, and
> much of the gameplay code of all previous Unreal Engine titles.
> However, UnrealScript is being removed.
> In its place, the engine will be 100% C++, and highly optimized."

I think UnrealScript and QML have different use cases.

UnrealScript was for _all_ the code: GUI and core logic. The article
says it was replaced because C++ gives better logic performance. I
think that makes sense, because games need to run complex code.

With QML, the general idea is to use QML for the GUI and use C++ for core logic.

Also, UnrealScript and C++ are imperative languages which are
well-suited for writing instructions. QML is a declarative language
(like HTML/CSS), which is well-suited for writing GUIs. It's a good
idea to choose the best tool for any job.


> Also I'm curios why Android xml files are good for design the UI, but
> "old" QtDesigner ui (xml) files seems to be deprecated in favor of qml.

Which of the following do you prefer?

//================================================
// Android XML
// http://developer.android.com/guide/topics/ui/declaring-layout.html
//================================================

<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:layout_width="fill_parent"
android:layout_height="fill_parent"
android:orientation="vertical" >
<TextView android:id="@+id/text"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:text="I am a TextView" />
<Button android:id="@+id/button"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:text="I am a Button" />
</LinearLayout>

//================================================
// QML
// Don't need "wrap_content", because it's default behaviour
//================================================

ColumnLayout {
anchors.fill: parent
TextEdit {
id: textEdit
text: "I am a TextEdit"
}
Button {
id: button
text: "I am a Button"
}
}


> Best regards,
> Marius

Regards,
Sze-Howe

[Sze Howe Koh]

On 23 April 2014 22:50, Sze Howe Koh <***@gmail.com> wrote:
> Hi Marius,
>
> On 23 April 2014 20:14, cincirin <***@gmail.com> wrote:
>> Sorry for re-open this topic, but as someone else already pointed out,
>> what do you think about the Unreal engine guys to abandon the unreal
>> script which was used until now for many years ?
>> To quote some comments:
>> "In the past, gameplay code existed in UnrealScript. UnrealScript is the
>> scripting language which forms the core of current community mods, and
>> much of the gameplay code of all previous Unreal Engine titles.
>> However, UnrealScript is being removed.
>> In its place, the engine will be 100% C++, and highly optimized."
>
> I think UnrealScript and QML have different use cases.
>
> UnrealScript was for _all_ the code: GUI and core logic. The article
> says it was replaced because C++ gives better logic performance. I
> think that makes sense, because games need to run complex code.

I just read http://gameindustry.about.com/od/trends/a/Unreal-Engine-4-First-Look.htm
in more detail. Another big benefit they described is: "Programmers
can click on a property and edit the C++ code directly, with no
rebuild time required."

QML offers this for GUIs. No need to compile, just edit your .qml file
and restart your app.


> With QML, the general idea is to use QML for the GUI and use C++ for core logic.
>
> Also, UnrealScript and C++ are imperative languages which are
> well-suited for writing instructions. QML is a declarative language
> (like HTML/CSS), which is well-suited for writing GUIs. It's a good
> idea to choose the best tool for any job.
>
>
>> Also I'm curios why Android xml files are good for design the UI, but
>> "old" QtDesigner ui (xml) files seems to be deprecated in favor of qml.
>
> Which of the following do you prefer?
>
> //================================================
> // Android XML
> // http://developer.android.com/guide/topics/ui/declaring-layout.html
> //================================================
>
> <LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
> android:layout_width="fill_parent"
> android:layout_height="fill_parent"
> android:orientation="vertical" >
> <TextView android:id="@+id/text"
> android:layout_width="wrap_content"
> android:layout_height="wrap_content"
> android:text="I am a TextView" />
> <Button android:id="@+id/button"
> android:layout_width="wrap_content"
> android:layout_height="wrap_content"
> android:text="I am a Button" />
> </LinearLayout>
>
> //================================================
> // QML
> // Don't need "wrap_content", because it's default behaviour
> //================================================
>
> ColumnLayout {
> anchors.fill: parent
> TextEdit {
> id: textEdit
> text: "I am a TextEdit"
> }
> Button {
> id: button
> text: "I am a Button"
> }
> }
>
>
>> Best regards,
>> Marius
>
> Regards,
> Sze-Howe

[cincirin]

Hi Sze Howe,

On 4/23/2014 5:50 PM, Sze Howe Koh wrote:
> With QML, the general idea is to use QML for the GUI and use C++ for core logic.
Well from I understand QML is used in a lot of other aspects than GUI:
Qt WebKit 2 is QML ( only ? ), also QML is used in multimedia, position
modules and so on ...

> Which of the following do you prefer?

It's absolute clear that if you want to manually edit the UI file,
there's no point to compare the solutions, QML is preferred instead of
writing xml mannually.
But what I meant is to create the UI file with some specific UI editor
like QtDesigner or Android UI editor. You don't have to write the file
manually.
So what I don't understand why Android xml file can be the most
efficient way to define the UI for that platform for many developers,
and why we are somehow forced to abandon QtDesigner UI (xml) files in
favor of QML.
>
> Regards,
> Sze-Howe

Regards,
Marius

[Sze Howe Koh]

Hi Marius,

On 23 April 2014 23:07, cincirin <***@gmail.com> wrote:
> On 4/23/2014 5:50 PM, Sze Howe Koh wrote:
>>
>> With QML, the general idea is to use QML for the GUI and use C++ for core
>> logic.
>
> Well from I understand QML is used in a lot of other aspects than GUI: Qt
> WebKit 2 is QML ( only ? ), also QML is used in multimedia, position modules
> and so on ...

Yes, that's true. I think WebKit 2 and 3D audio are the odd ones out
though (I'm not sure why they did this -- we'll have to ask the devs).
Nokia invented QML for the purpose of GUI development, but I guess
people find it convenient to be able to access non-graphical features
directly from QML.

Except for graphics, WebKit 2 and 3D audio, all other QML features
(including other multimedia features and Qt Positioning) are simply a
QML counterpart to C++ features.


> It's absolute clear that if you want to manually edit the UI file, there's
> no point to compare the solutions, QML is preferred instead of writing xml
> mannually.
> But what I meant is to create the UI file with some specific UI editor like
> QtDesigner or Android UI editor. You don't have to write the file manually.

Have you seen Qt Quick Designer?
http://qt-project.org/doc/qtcreator-3.1/creator-using-qt-quick-designer.html
It doesn't matter whether your file is .ui or .qml -- you can use a
visual editor and you don't need to modify the files directly to
create your UI. (Of course, you'd still need to implement slots and
signal handlers in C++ and QML respectively)


> So what I don't understand why Android xml file can be the most efficient
> way to define the UI for that platform for many developers, and why we are
> somehow forced to abandon QtDesigner UI (xml) files in favor of QML.

To understand this, you need to look at Qt's history. Here is a simple
timeline of Qt UI technologies:

1995 -- (C++) -- Widgets introduced
2006 -- (C++) -- Graphics View Framework introduced
2010 -- (QML) -- Qt Quick 1 introduced, built on the Graphics View Framework.
2012 -- (QML) -- Qt Quick 2 introduced, built on a new OpenGL framework.

The Graphics View Framework supports UI technologies which are
important to many modern platforms, such as animated transitions.
Widgets don't support these techs easily (you need to write lots of
code to make it work).

Android was released in 2008 and Android XML files were designed for
modern UI techs. In contrast, Qt's .ui XML files can only assemble
Widget-based GUIs. To compete with Android GUIs, you often need to use
Graphics View, which makes the .ui XML files less useful -- you need
to define your UI layout in C++ code, which is inefficient. QML and Qt
Quick and Qt Quick 1 aimed to make it easier to write GUIs for the
Graphics View Framework.

Qt Quick 2 provides superior performance than Qt Quick 1. It can do
everything that Graphics View and Qt Quick 1 can do, so it replaces
these technologies. However, it can't do everything that Widgets can
do yet, so it doesn't replace Widgets yet. Nobody needs to abandon Qt
Designer. New features are still being added to Qt Widgets (see
http://qt-project.org/wiki/New-Features-in-Qt-5.2), and it will still
be supported for many years. I still use it to create traditional
office-style GUIs.

However, when I want to make modern fluid GUIs, I use Qt Quick,
because it is much more efficient for this purpose compared to Qt
Widgets.


On the topic of efficiency and animations, compare these 2 examples
which do similar things:
* http://developer.android.com/training/animation/cardflip.html
* http://qt-project.org/doc/qt-5/qml-qtquick-flipable.html

Files required:
- Android: 6 XML files + 1 Java file
- Qt Quick: 1 QML file

Code required (excludes XML/comments/braces/empty lines)
- Android: 34 lines of Java code
- Qt Quick: 23 lines of QML code
- (Also note: the average QML line is shorter than the average Java line)

I think QML is for more efficient than Android's XML+Java to create a
card flip effect.

Finally, here is a Graphics View card-flipping example, which is also
far less efficient than the QML example:
https://blog.qt.digia.com/blog/2009/06/09/flippin-widgets-medium-rare-please/


Again, the bottom line is:
* Choose the best tool currently available for the job.
* Choose Qt Quick and QML for mobile phone apps.
* Choose Qt Widgets and .ui XML files for traditional desktop office-style apps.


Does this answer your question?


Regards,
Sze-Howe

[Sze Howe Koh]

On 25 April 2014 10:20, Sze Howe Koh <***@gmail.com> wrote:
> On 23 April 2014 23:07, cincirin <***@gmail.com> wrote:
>> Well from I understand QML is used in a lot of other aspects than GUI: Qt
>> WebKit 2 is QML ( only ? ), also QML is used in multimedia, position modules
>> and so on ...
>
> Yes, that's true. I think WebKit 2 and 3D audio are the odd ones out
> though (I'm not sure why they did this -- we'll have to ask the devs).
> Nokia invented QML for the purpose of GUI development, but I guess
> people find it convenient to be able to access non-graphical features
> directly from QML.
>
> Except for graphics, WebKit 2 and 3D audio, all other QML features
> (including other multimedia features and Qt Positioning) are simply a
> QML counterpart to C++ features.

I forgot: Qt WebKit is being deprecated in favour of the
Chromium-based Qt WebEngine. Qt WebEngine will have both Widget and
QML APIs.[1]


Regards,
Sze-Howe

[1] http://blog.qt.digia.com/blog/2014/01/23/qt-webengine-technology-preview-available/

[André Pönitz]

On Wed, Apr 23, 2014 at 10:50:23PM +0800, Sze Howe Koh wrote:
> QML is a declarative language

Are you considering sequences of JavaScript statements, especially control
flow statements, as "declarative"?

Andre'

[Sze Howe Koh]

On 24 April 2014 00:35, André Pönitz <***@t-online.de> wrote:
> On Wed, Apr 23, 2014 at 10:50:23PM +0800, Sze Howe Koh wrote:
>> QML is a declarative language
>
> Are you considering sequences of JavaScript statements, especially control
> flow statements, as "declarative"?
>
> Andre'

Of course not. :-) I was highlighting the fact that their declarative
structures make QML or HTML+CSS good for describing a GUI's looks.
This is in contrast to imperative languages like C++ or JavaScript or
PHP -- I don't want to use any of these to describe a GUI's looks.

I consider QML and JavaScript to be different languages. JavaScript
can be embedded into QML to extend QML's capabilities, just like how
it can be embedded into HTML to extend HTML's capabilities.
(Alternatively, one could argue that QML is a hybrid
declarative-imperative language).


Regards,
Sze-Howe

[Joerg Bornemann]

On 25-Apr-14 04:21, Sze Howe Koh wrote:

> I consider QML and JavaScript to be different languages. JavaScript
> can be embedded into QML to extend QML's capabilities, just like how
> it can be embedded into HTML to extend HTML's capabilities.

Yep, I hear people keep repeating the mantra "QML is declarative. It's
just QML/JS that isn't." Does that buy us anything tooling-wise? No.
Because, even though this thought is true in essence, in practice you
have to use the JS part.
People throw handwritten QML files full of clever hacks at Qt
Creator's QmlDesigner and wonder why it doesn't fully understand the
magic, even though everything is deemed "declarative" (== "toolable").


BR,

Joerg

[Peter Kümmel]

On 25.04.2014 12:18, Joerg Bornemann wrote:
>
> Yep, I hear people keep repeating the mantra "QML is declarative. It's
> just QML/JS that isn't."

I think the "declarative-mantra" is a good idea, especially when used for
_specifying_ (not programming) the GUI.

At Adobe they tried it with pure C++
http://stlab.adobe.com/group__asl__overview.html#asl_overview_adam_and_eve_architecture
which consequently ended up in a template/boost massacre. Looks like is is dead now.

QML is also a nice try, but it got messed up with the imperative part.
Maybe because the temptation was too overwhelming to use the already integrated
JS engine for more stuff than running declarative part.

Having imperative code on the JS side is also the root of the rejection of QML
for many C++ developers. If QML would have been just a improved .ui nobody would
have complained.


> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>

[Yves Bailly]

On 27/04/2014 12:55, Peter Kümmel wrote:
> Having imperative code on the JS side is also the root of the rejection of QML
> for many C++ developers. If QML would have been just a improved .ui nobody would
> have complained.

+1


--
(o< | Yves Bailly | -o)
//\ | Linux Dijon : http://www.coagul.org | //\
\_/ | | \_/`

[Hausmann Simon]

Hmm, but why don't you use Qml like that then? The language doesn't force you to use inline js code, does it?

A lot of the work that has gone into the engine lately also enables this to work better and reduce the use of JS. For example bindings that just consist of a qsTr don't actually end up creating any js bindings.

Simon

Opprinnelig melding
Fra: Yves Bailly
Sendt: 16:52 søndag 27. april 2014
Til: ***@qt-project.org
Emne: Re: [Development] Question about Qt's future


On 27/04/2014 12:55, Peter Kümmel wrote:
> Having imperative code on the JS side is also the root of the rejection of QML
> for many C++ developers. If QML would have been just a improved .ui nobody would
> have complained.

+1


--
(o< | Yves Bailly | -o)
//\ | Linux Dijon : http://www.coagul.org | //\
\_/ | | \_/`

[Frank Hemer]

On Sunday 27 April 2014 12:55:58 Peter Kümmel wrote:
> Having imperative code on the JS side is also the root of the rejection of
> QML for many C++ developers. If QML would have been just a improved .ui
> nobody would have complained.

+1

Frank

[Thiago Macieira]

Em dom 27 abr 2014, às 12:55:58, Peter Kümmel escreveu:
> Having imperative code on the JS side is also the root of the rejection of
> QML for many C++ developers. If QML would have been just a improved .ui
> nobody would have complained.

We'd end up with one of the problems of CSS which is that you can't do
calculations in the bindings. I can't do

width: 50% - 10em

The moment you start adding some math, you need stuff like Math.random() and
you end up again in JS.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

[Mark Gaiser]

On Sun, Apr 27, 2014 at 10:37 PM, Thiago Macieira
<***@intel.com> wrote:
> Em dom 27 abr 2014, às 12:55:58, Peter Kümmel escreveu:
>> Having imperative code on the JS side is also the root of the rejection of
>> QML for many C++ developers. If QML would have been just a improved .ui
>> nobody would have complained.
>
> We'd end up with one of the problems of CSS which is that you can't do
> calculations in the bindings. I can't do
>
> width: 50% - 10em
>


Actually, you can..
http://css-tricks.com/a-couple-of-use-cases-for-calc/

And even Internet Explorer has support for it: http://caniuse.com/#feat=calc

> The moment you start adding some math, you need stuff like Math.random() and
> you end up again in JS.

[Richard Moore]

On 27 April 2014 22:31, Mark Gaiser <***@gmail.com> wrote:

> Actually, you can..
> http://css-tricks.com/a-couple-of-use-cases-for-calc/
>
> And even Internet Explorer has support for it:
> http://caniuse.com/#feat=calc
>
>
It's a variant of the expression() facility that IE has offered to CSS
since IE6. It's extremely useful for bypassing XSS filters. :-)

Rich.

[André Pönitz]

On Sun, Apr 27, 2014 at 01:37:33PM -0700, Thiago Macieira wrote:
> Em dom 27 abr 2014, às 12:55:58, Peter Kümmel escreveu:
> > Having imperative code on the JS side is also the root of the rejection of
> > QML for many C++ developers. If QML would have been just a improved .ui
> > nobody would have complained.
>
> We'd end up with one of the problems of CSS which is that you can't do
> calculations in the bindings. I can't do
>
> width: 50% - 10em
>
> The moment you start adding some math, you need stuff like Math.random() and
> you end up again in JS.

Not true. Some (basic) math fits the "declarative" needs, and would
be toolable. Math.random() does obviously not fit the bill.

Andre'

[Thiago Macieira]

Em seg 28 abr 2014, às 00:55:12, André Pönitz escreveu:
> On Sun, Apr 27, 2014 at 01:37:33PM -0700, Thiago Macieira wrote:
> > Em dom 27 abr 2014, às 12:55:58, Peter Kümmel escreveu:
> > > Having imperative code on the JS side is also the root of the rejection
> > > of
> > > QML for many C++ developers. If QML would have been just a improved .ui
> > > nobody would have complained.
> >
> > We'd end up with one of the problems of CSS which is that you can't do
> > calculations in the bindings. I can't do
> >
> > width: 50% - 10em
> >
> > The moment you start adding some math, you need stuff like Math.random()
> > and you end up again in JS.
>
> Not true. Some (basic) math fits the "declarative" needs, and would
> be toolable. Math.random() does obviously not fit the bill.

Math.floor() then.

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

[Hartmann Thomas]

Hi,

while (at least for me) it is not really clear where exactly the boundary between declarative and functional programming lies, we could/should at least rule out control flow statements and anything with side effects in bindings.

The statement "width: Math.floor(height)" could be considered declarative (enough), if we limit the allowed functions to a well defined subset.

But currentlty one can do this: width: { Any imperative code one can imagine, including loops, while(true) and side effects. } This clearly is not declarative anymore.

Another issue with QML is that some parts of the API of Qt Quick are not accessible through a declarative API (e.g. setting a state). While this is not a problem in principle (since we could extend the API), it is a problem in practice.
Until now nobody (including me) found the time to fix it.

>

[Nils Jeisecke]

Hi,

> Another idea is to allow C++ companion objects, that would
> take the place of any Java Script code for people who
> prefer C++. A companion object would be a QObject
> paired with the QML object, that has access to the
> QML context. The QObject would then define a couple
> of signals/slots that can be used from QML as
> Java Script is used today.
I really like this idea. Maybe one could even write C++ code
directly in the QML file and let a preprocessor generate
a proper C++ class containing this code. So, no more JavaScript,
data conversion and garbage collection. Or just another tooling
nightmare?

Nils

[Hartmann Thomas]

Hi,

yes, writting C++ inline in QML would be another "tooling nightmare". Also what is the problem with:

MouseArea {
onClicked: companion.mouseAreaClicked();
}

If tooling creates the companion object for you (In a wizard) and code completion and code naviagtion (F2) works as expected?


Kind Regards,
Thomas Hartmann


________________________________________
From: Nils Jeisecke [***@saltation.de]
Sent: 28 April 2014 11:00
To: Hartmann Thomas
Cc: ***@qt-project.org
Subject: Re: [Development] Question about Qt's future

Hi,

> Another idea is to allow C++ companion objects, that would
> take the place of any Java Script code for people who
> prefer C++. A companion object would be a QObject
> paired with the QML object, that has access to the
> QML context. The QObject would then define a couple
> of signals/slots that can be used from QML as
> Java Script is used today.
I really like this idea. Maybe one could even write C++ code
directly in the QML file and let a preprocessor generate
a proper C++ class containing this code. So, no more JavaScript,
data conversion and garbage collection. Or just another tooling
nightmare?

Nils

[Nils Jeisecke]

> Also what is the problem with:
>
> MouseArea {
> onClicked: companion.mouseAreaClicked();
> }

Where is the event handler's argument (the one that's kind of
invisible in QML and requires you to read the documentation, I think
it's called "mouse" :-).

Could this be a function binding instead?

MouseArea {
onClicked: companion.mouseAreaClicked;
}

Nils

[Hartmann Thomas]

Hi,

good point and this shows why it is actually no that easy to come up with a nice solution.

The most natural solution for me would be to just add the mouse property to the java script context
of the function call. The java script context would be a C++ argument.

slot:
mouseAreaClicked(QJSContext context)
{
context.get("mouse.x") ....
}

But currently this is not more then a couple of wild ideas.

Kind Regards,
Thomas Hartmann
________________________________________
From: Nils Jeisecke [***@saltation.de]
Sent: 28 April 2014 11:56
To: Hartmann Thomas
Cc: ***@qt-project.org
Subject: Re: [Development] Question about Qt's future

> Also what is the problem with:
>
> MouseArea {
> onClicked: companion.mouseAreaClicked();
> }

Where is the event handler's argument (the one that's kind of
invisible in QML and requires you to read the documentation, I think
it's called "mouse" :-).

Could this be a function binding instead?

MouseArea {
onClicked: companion.mouseAreaClicked;
}

Nils

[André Somers]

Hartmann Thomas schreef op 28-4-2014 11:32:
> Hi,
>
> yes, writting C++ inline in QML would be another "tooling nightmare". Also what is the problem with:
>
> MouseArea {
> onClicked: companion.mouseAreaClicked();
> }
>
> If tooling creates the companion object for you (In a wizard) and code completion and code naviagtion (F2) works as expected?
>

I'm not sure if I understand what you mean by a "companion" object. Why
exactly do we need another object in the mix? Where does it come from?
Where is exposed to the C++ side of things? What problem is it supposed
to solve exactly?

QML already allows you to specify signals. Would exposing these signals
on the C++ side through the object created by QQmlComponent::create not
be enough? You could then on the QML side bind the handler to signal on
the root object (directly or indirectly), and handle the signal on the
C++ side. Tooling-wise, I _guess_ these signals could be exposed for
code completion and the likes.

But... you can already do something like that. You can already expose a
custom QObject with slots to QML that you can use to bind your handlers
to. Sort of like a UI controller object.


André

[Hartmann Thomas]

Hi,

gluing together C++ and Java Script is currently not always that easy.
The solution I propose is the option to write C++ code in the exact same way you currently write Java Script code.
This means every QML context/component can have a C++ object attached to it that implements a set of methods
that are exposed to QML. The important part would be that C++ would have access to the QML context (e.g. context.get("someID.x").

All of this is already possible, if we assume that we handle the context via QVariant function arguments and resolve it on the JS side (someObjectInTheContext.mouseAreaClicked(mouse.x)), but it requires quite a lot of boiler plate code and there is no canonical well documented way how to exactly do this.
Also the setting of context objects is string based and quite hard to track for the code model (especially if there is more then one engine in the project) for auto completion and code navigation.

What problem does this sovle?

If there is a complex C++ backend there is no glue code needed anymore. There would be no need to expose types from C++ to QML anymore, since it would work the other way around. QML would expose its context to C++.
People could work in nearly the same way as they work with .ui files. Typically the QML context is not very complex and only consists of a couple of objects, signals and state variables (e.g. currentIndex of a ComboBox).

Kind Regards,
Thomas Hartmann
________________________________________
From: development-bounces+thomas.hartmann=***@qt-project.org [development-bounces+thomas.hartmann=***@qt-project.org] on behalf of André Somers [***@familiesomers.nl]
Sent: 28 April 2014 11:57
To: ***@qt-project.org
Subject: Re: [Development] Question about Qt's future

Hartmann Thomas schreef op 28-4-2014 11:32:
> Hi,
>
> yes, writting C++ inline in QML would be another "tooling nightmare". Also what is the problem with:
>
> MouseArea {
> onClicked: companion.mouseAreaClicked();
> }
>
> If tooling creates the companion object for you (In a wizard) and code completion and code naviagtion (F2) works as expected?
>

I'm not sure if I understand what you mean by a "companion" object. Why
exactly do we need another object in the mix? Where does it come from?
Where is exposed to the C++ side of things? What problem is it supposed
to solve exactly?

QML already allows you to specify signals. Would exposing these signals
on the C++ side through the object created by QQmlComponent::create not
be enough? You could then on the QML side bind the handler to signal on
the root object (directly or indirectly), and handle the signal on the
C++ side. Tooling-wise, I _guess_ these signals could be exposed for
code completion and the likes.

But... you can already do something like that. You can already expose a
custom QObject with slots to QML that you can use to bind your handlers
to. Sort of like a UI controller object.


André

[charleyb123 .]

On Mon, Apr 28, 2014 at 4:39 AM, Hartmann Thomas
<***@digia.com>wrote:

> Hi,
>
> gluing together C++ and Java Script is currently not always that easy.
> The solution I propose is the option to write C++ code in the exact same
> way you currently write Java Script code.
> This means every QML context/component can have a C++ object attached to
> it that implements a set of methods
> that are exposed to QML. The important part would be that C++ would have
> access to the QML context (e.g. context.get("someID.x").
>
> All of this is already possible, if we assume that we handle the context
> via QVariant function arguments and resolve it on the JS side
> (someObjectInTheContext.mouseAreaClicked(mouse.x)), but it requires quite a
> lot of boiler plate code and there is no canonical well documented way how
> to exactly do this.
> Also the setting of context objects is string based and quite hard to
> track for the code model (especially if there is more then one engine in
> the project) for auto completion and code navigation.
>
> What problem does this solve?
>
> If there is a complex C++ backend there is no glue code needed anymore.
> There would be no need to expose types from C++ to QML anymore, since it
> would work the other way around. QML would expose its context to C++.
> People could work in nearly the same way as they work with .ui files.
> Typically the QML context is not very complex and only consists of a
> couple of objects, signals and state variables (e.g. currentIndex of a
> ComboBox).
>
> Kind Regards,
> Thomas Hartmann
>

This is *very* interesting.

I just wanted to re-quote that section that got me to "sit up in my chair":

If there is a complex C++ backend there is no glue code needed anymore.
> There would be no need to expose types from C++ to QML anymore, since it
> would work the other way around. QML would expose its context to C++.


I'll need to think on this. It seems to be proposing the act of QML<==>C++
binding is for C++ to act on "signals/events" forwarded to it from QML,
because C++ has all the type information (it can "do the job"). I really
like that.

My current generator works well, "wrapping" the C++ types to expose them
natively into QML. That also works, letting QML "do the job". However, we
then have expressions within QML (today's JS bound expressions), and as
others have said, those can "sprawl" and become difficult to maintain in
big/complex systems.

In general, I'd prefer to stay in C++ with my strong type information. QML
has strong typing for its internal types (which I think is essential), but
some GUI logic really needs knowledge of the domain-specific types (that's
this discussion). I'll have to think on how much "essential expression
logic" is really an attribute of the GUI, and whether QML signals/events
exposed to C++ is sufficient to "tool" the GUI workflow. It's certainly
"different logic" from the rest of the C++ system, so I'd want to separate
it (the C++ signal/event logic that services the GUI, as separate from the
C++ logic intrinsic to the large/complex back-end).

At present, I almost never write JS in my QML. When the QML starts to get
even "slightly" rich-with-logic, we implement a C++ QML/GUI component to
expose to QML with "knowlege-of" the C++ types upon which it operates (like
custom "domain-specific-controls" that are then loaded as a "plugin").

--charley

[Peter Kümmel]

On 28.04.2014 00:55, André Pönitz wrote:
> On Sun, Apr 27, 2014 at 01:37:33PM -0700, Thiago Macieira wrote:
>> Em dom 27 abr 2014, às 12:55:58, Peter Kümmel escreveu:
>>> Having imperative code on the JS side is also the root of the rejection of
>>> QML for many C++ developers. If QML would have been just a improved .ui
>>> nobody would have complained.
>>
>> We'd end up with one of the problems of CSS which is that you can't do
>> calculations in the bindings. I can't do
>>
>> width: 50% - 10em
>>
>> The moment you start adding some math, you need stuff like Math.random() and
>> you end up again in JS.
>
> Not true. Some (basic) math fits the "declarative" needs, and would
> be toolable. Math.random() does obviously not fit the bill.

Yes, isn't math by definition only functional, all they talk about is
"Given A and B with ... then exists F(A)->B. ... q.e.d." ;)

Sorry to all mathematician.

>
> Andre'
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>

[Tony Van Eerd]

>
> On 25.04.2014 12:18, Joerg Bornemann wrote:
> >
> > Yep, I hear people keep repeating the mantra "QML is declarative. It's
> > just QML/JS that isn't."
>
> I think the "declarative-mantra" is a good idea, especially when used for
> _specifying_ (not programming) the GUI.
>
> At Adobe they tried it with pure C++
>
> http://stlab.adobe.com/group__asl__overview.html#asl_overview_adam_a
> nd_eve_architecture
> which consequently ended up in a template/boost massacre. Looks like is is
> dead now.
>

https://github.com/stlab

"I'm not dead. I'm getting better. I think I'll go for a walk."

Sean Parent left Adobe for a while (was at Google) but now is back at Adobe, and there seems to be life in ASL again (and it wasn't exactly dead when he was gone either).

The code might be templates/boost (is that a bad thing?) but the declarative language is pretty straightforward.

[Peter Kümmel]

On 28.04.2014 18:01, Tony Van Eerd wrote:
>>
>> On 25.04.2014 12:18, Joerg Bornemann wrote:
>>>
>>> Yep, I hear people keep repeating the mantra "QML is declarative. It's
>>> just QML/JS that isn't."
>>
>> I think the "declarative-mantra" is a good idea, especially when used for
>> _specifying_ (not programming) the GUI.
>>
>> At Adobe they tried it with pure C++
>>
>> http://stlab.adobe.com/group__asl__overview.html#asl_overview_adam_a
>> nd_eve_architecture
>> which consequently ended up in a template/boost massacre. Looks like is is
>> dead now.
>>
>
> https://github.com/stlab
>
> "I'm not dead. I'm getting better. I think I'll go for a walk."
>
> Sean Parent left Adobe for a while (was at Google) but now is back at Adobe, and there seems to be life in ASL again (and it wasn't exactly dead when he was gone either).

Thanks, didn't noticed they moved to github.

>
> The code might be templates/boost (is that a bad thing?) but the declarative language is pretty straightforward.
>
>
>

[André Pönitz]

On Fri, Apr 25, 2014 at 10:21:04AM +0800, Sze Howe Koh wrote:
> On 24 April 2014 00:35, André Pönitz <***@t-online.de> wrote:
> > On Wed, Apr 23, 2014 at 10:50:23PM +0800, Sze Howe Koh wrote:
> >> QML is a declarative language
> >
> > Are you considering sequences of JavaScript statements, especially control
> > flow statements, as "declarative"?
> >
> > Andre'
>
> Of course not. :-)

Right. With the obvious consequence for .qml files containing such.

Within a .qml file, JavaScript is in no way an "optional extension" of some
"declarative QML language". QML and JavaScript are _inseparably_ tied
together in the QML/JS hybrid contents of a .qml file.

A quick grep in qtdeclarative/examples/quick/demos e.g. finds the pattern
'if (' in 30 out of 88 .qml files. All nine examples are affected. And
that's not "just an accident", as "pure declarative QML" features like
ScriptAction, or on{Triggered,Clicked,Loaded,...} handlers _require_
immediate use of JavaScript.

> I was highlighting the fact that their declarative
> structures make QML or HTML+CSS good for describing a GUI's looks.
> This is in contrast to imperative languages like C++ or JavaScript or
> PHP -- I don't want to use any of these to describe a GUI's looks.

Not wanting to "use imperative languages like [...] JavaScript [...] to
describe a GUI's look" is fine with me, but how on earth is that an
argument _in favour_ of .qml?

You could have made the point "declarative structures are good for GUI
description" for Qt Widget's .ui files, after all, .ui files contents
pretty much _is_ declaring layout nesting and property values.

Trying to make that point for "parts of the contents of at .qml file"
(and even admitting that it doesn't hold for "the other parts") is
misleading at best.

> (Alternatively, one could argue that QML is a hybrid
> declarative-imperative language).

Alternatively, one could argue that QML is a not-well-defined, non-standard
languange largely incompatible with established tools and workflows, with
developers not agreeing on fundamental aspects of its nature, costs and
benefits... But, hey, which fool would raise such a claim ;-}


To get back on the constructive trail:

The meaning of "QML" keeps oscillating between "QML is whatever can be
written in a .qml file" and "QML is only the declarative outer layer of a
.qml file". Terminology should be clear, and uniformly applied to all
audiences (users, marketing, developers)

So "someone" should sit down and come up with a single "official" definition
of the basics: What is QML, how does it relate to JS, what's the relation
to .qml files.

http://qt-project.org/doc/qt-5/qmlapplications.html does not suffice. The
use of the term "QML" there and on the directly linked pages match mainly
the "QML is whatever can be written in a .qml file" concept ("develop
your own applications using QML and Qt C++") but sometimes mentions
JavaScript seperately ("integrate QML code with JavaScript and C++.").

Andre'

[Peter Kümmel]

On 26.04.2014 17:39, André Pönitz wrote:
>
> You could have made the point "declarative structures are good for GUI
> description" for Qt Widget's .ui files, after all, .ui files contents
> pretty much _is_ declaring layout nesting and property values.

Just an idea:
Declarative-only QML files could be translated to C++ by a tool similar
to uic, and then used by a C++-only successor of QtWidgets.

Or are there any technical reasons why all the state-of-the-features
provided by QML v2 could not be implemented on the C++ side assuming
there is a QML-to-C++ code generation step?


Having a clear cut between declarative and imperative QML would
also improve visibility of specification- and implementation-parts
of a QML file.

> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>

[Thiago Macieira]

Em dom 27 abr 2014, às 13:09:50, Peter Kümmel escreveu:
> On 26.04.2014 17:39, André Pönitz wrote:
> > You could have made the point "declarative structures are good for GUI
> > description" for Qt Widget's .ui files, after all, .ui files contents
> > pretty much _is_ declaring layout nesting and property values.
>
> Just an idea:
> Declarative-only QML files could be translated to C++ by a tool similar
> to uic, and then used by a C++-only successor of QtWidgets.
>
> Or are there any technical reasons why all the state-of-the-features
> provided by QML v2 could not be implemented on the C++ side assuming
> there is a QML-to-C++ code generation step?

It's possible, but there's no API in the C++ side to create the graph. Until
such an API exists, you can't write the generator.

Care to contribute the C++ side, including passing all the reviews? Note that
this is a major undertaking and will probably take two or three releases to
get a minimal functional API out there. Plus the maintenance effort.

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

[Peter Kümmel]

On 27.04.2014 22:40, Thiago Macieira wrote:
> Em dom 27 abr 2014, às 13:09:50, Peter Kümmel escreveu:
>> On 26.04.2014 17:39, André Pönitz wrote:
>>> You could have made the point "declarative structures are good for GUI
>>> description" for Qt Widget's .ui files, after all, .ui files contents
>>> pretty much _is_ declaring layout nesting and property values.
>>
>> Just an idea:
>> Declarative-only QML files could be translated to C++ by a tool similar
>> to uic, and then used by a C++-only successor of QtWidgets.
>>
>> Or are there any technical reasons why all the state-of-the-features
>> provided by QML v2 could not be implemented on the C++ side assuming
>> there is a QML-to-C++ code generation step?
>
> It's possible, but there's no API in the C++ side to create the graph. Until
> such an API exists, you can't write the generator.

I know that currently there is no support for this in Qt, also no plans
to add it, all I wanted to hear is "It's possible".

I assume it would be only a community-driven long-term project, which takes
years until it is on par with QtWidgets. But hey, I'm fascinated by the idea,
and maybe I'm not alone.

ATM the problem is to get started because I don't know much about the
current architecture of the graphic stack.
Any hints where to start for a first hello world?


>
> Care to contribute the C++ side, including passing all the reviews? Note that
> this is a major undertaking and will probably take two or three releases to
> get a minimal functional API out there. Plus the maintenance effort.
>

[Kurt Pattyn]

> On 28 Apr 2014, at 07:53, Peter Kümmel <***@gmx.net> wrote:
>
>> On 27.04.2014 22:40, Thiago Macieira wrote:
>>> Em dom 27 abr 2014, às 13:09:50, Peter Kümmel escreveu:
>>>> On 26.04.2014 17:39, André Pönitz wrote:
>>>> You could have made the point "declarative structures are good for GUI
>>>> description" for Qt Widget's .ui files, after all, .ui files contents
>>>> pretty much _is_ declaring layout nesting and property values.
>>>
>>> Just an idea:
>>> Declarative-only QML files could be translated to C++ by a tool similar
>>> to uic, and then used by a C++-only successor of QtWidgets.
>>>
>>> Or are there any technical reasons why all the state-of-the-features
>>> provided by QML v2 could not be implemented on the C++ side assuming
>>> there is a QML-to-C++ code generation step?
>>
>> It's possible, but there's no API in the C++ side to create the graph. Until
>> such an API exists, you can't write the generator.
>
> I know that currently there is no support for this in Qt, also no plans
> to add it, all I wanted to hear is "It's possible".
>
> I assume it would be only a community-driven long-term project, which takes
> years until it is on par with QtWidgets. But hey, I'm fascinated by the idea,
> and maybe I'm not alone.
>
> ATM the problem is to get started because I don't know much about the
> current architecture of the graphic stack.
> Any hints where to start for a first hello world?

Maybe a translation from QML to a .ui file could be a first step? That could work if you use QtWidgets in the QML file.
>
>
>>
>> Care to contribute the C++ side, including passing all the reviews? Note that
>> this is a major undertaking and will probably take two or three releases to
>> get a minimal functional API out there. Plus the maintenance effort.
>
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

[Peter Kümmel]

On 28.04.2014 08:10, Kurt Pattyn wrote:
>
>
>> On 28 Apr 2014, at 07:53, Peter Kümmel <***@gmx.net> wrote:
>>
>>> On 27.04.2014 22:40, Thiago Macieira wrote:
>>>> Em dom 27 abr 2014, às 13:09:50, Peter Kümmel escreveu:
>>>>> On 26.04.2014 17:39, André Pönitz wrote:
>>>>> You could have made the point "declarative structures are good for GUI
>>>>> description" for Qt Widget's .ui files, after all, .ui files contents
>>>>> pretty much _is_ declaring layout nesting and property values.
>>>>
>>>> Just an idea:
>>>> Declarative-only QML files could be translated to C++ by a tool similar
>>>> to uic, and then used by a C++-only successor of QtWidgets.
>>>>
>>>> Or are there any technical reasons why all the state-of-the-features
>>>> provided by QML v2 could not be implemented on the C++ side assuming
>>>> there is a QML-to-C++ code generation step?
>>>
>>> It's possible, but there's no API in the C++ side to create the graph. Until
>>> such an API exists, you can't write the generator.
>>
>> I know that currently there is no support for this in Qt, also no plans
>> to add it, all I wanted to hear is "It's possible".
>>
>> I assume it would be only a community-driven long-term project, which takes
>> years until it is on par with QtWidgets. But hey, I'm fascinated by the idea,
>> and maybe I'm not alone.
>>
>> ATM the problem is to get started because I don't know much about the
>> current architecture of the graphic stack.
>> Any hints where to start for a first hello world?
>
> Maybe a translation from QML to a .ui file could be a first step? That could work if you use QtWidgets in the QML file.

I think we should start on top of the C/C++ part of current QMLv2 stack (if such a thing exists), with some handwritten
widget code. Otherwise we have a QPainter based system which we already have with QWidgets.

>>
>>
>>>
>>> Care to contribute the C++ side, including passing all the reviews? Note that
>>> this is a major undertaking and will probably take two or three releases to
>>> get a minimal functional API out there. Plus the maintenance effort.
>>
>> _______________________________________________
>> Development mailing list
>> ***@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
>

[Thiago Macieira]

Em seg 28 abr 2014, às 08:33:23, Peter Kümmel escreveu:
> >> ATM the problem is to get started because I don't know much about the
> >> current architecture of the graphic stack.
> >> Any hints where to start for a first hello world?
> >
> > Maybe a translation from QML to a .ui file could be a first step? That
> > could work if you use QtWidgets in the QML file.
> I think we should start on top of the C/C++ part of current QMLv2 stack (if
> such a thing exists), with some handwritten widget code. Otherwise we have
> a QPainter based system which we already have with QWidgets.

Forget about QPainter.

Your first step, it seems to me, would be to add the necessary C++ public API
to QtQml so you can instantiate new items in the QML graph, then manipulate
their properties and bindings, as well as set new JavaScript code and
expressions. This simply replaces the QML parser, keeping all the benefits (and
problems) of the QML language. In particular, it does not extricate the JS
interpreter and engine.

If you want to extricate the JS engine, you probably need to move the Scene
Graph classes out of QtQuick and into a module that depends only on QtGui,
bypassing the QtQml dependency. You'll need a way to insert generic items into
the graph. But, at this point, I question: why don't you just use an existing
OpenGL scene graph, like Ogle3D?

Once you've got the base API, you can start thinking of writing widgets again,
the platform look and feel. If the QtQml dependency was maintained, it might
be possible to reuse the code from Qt Quick Components. If not, you'll
probably need to start from scratch.

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

[Peter Kümmel]

On 28.04.2014 09:26, Thiago Macieira wrote:
> Em seg 28 abr 2014, às 08:33:23, Peter Kümmel escreveu:
>>>> ATM the problem is to get started because I don't know much about the
>>>> current architecture of the graphic stack.
>>>> Any hints where to start for a first hello world?
>>>
>>> Maybe a translation from QML to a .ui file could be a first step? That
>>> could work if you use QtWidgets in the QML file.
>> I think we should start on top of the C/C++ part of current QMLv2 stack (if
>> such a thing exists), with some handwritten widget code. Otherwise we have
>> a QPainter based system which we already have with QWidgets.
>
> Forget about QPainter.

Yes, this I wanted to say.

>
> Your first step, it seems to me, would be to add the necessary C++ public API
> to QtQml so you can instantiate new items in the QML graph, then manipulate
> their properties and bindings, as well as set new JavaScript code and
> expressions. This simply replaces the QML parser, keeping all the benefits (and
> problems) of the QML language. In particular, it does not extricate the JS
> interpreter and engine.
>
> If you want to extricate the JS engine, you probably need to move the Scene

Initially I thought this would be important, but if JS is just another
foreign language (like OpenGL shaders) deep in the drawing stack invisible
to the C++ developer it doesn't hurt.
At least it seems to me this is the only way to see some progress
within the time frame of a after-work project.

> Graph classes out of QtQuick and into a module that depends only on QtGui,
> bypassing the QtQml dependency. You'll need a way to insert generic items into
> the graph. But, at this point, I question: why don't you just use an existing
> OpenGL scene graph, like Ogle3D?

Goal is still to have desktop widgets within the Qt framework.

>
> Once you've got the base API, you can start thinking of writing widgets again,
> the platform look and feel. If the QtQml dependency was maintained, it might
> be possible to reuse the code from Qt Quick Components. If not, you'll
> probably need to start from scratch.

This would be the tedious part.

Peter

[Gunnar Sletta]

On 28 Apr 2014, at 07:53, Peter Kümmel <***@gmx.net> wrote:
>
...

> ATM the problem is to get started because I don't know much about the
> current architecture of the graphic stack.

http://qt-project.org/doc/qt-5/qtquick-visualcanvas-scenegraph.html
http://qt-project.org/doc/qt-5/qtquick-visualcanvas-scenegraph-renderer.html

> Any hints where to start for a first hello world?

I started on this some time ago, but it has been sitting there ever since as the interest for splitting it out has been non-existent. It will for sure not compile, but it contains the "general idea" :)

https://codereview.qt-project.org/#change,52682

cheers,
Gunnar

[Peter Kümmel]

On 28.04.2014 09:32, Gunnar Sletta wrote:
>> ATM the problem is to get started because I don't know much about the
>> current architecture of the graphic stack.
>
> http://qt-project.org/doc/qt-5/qtquick-visualcanvas-scenegraph.html
> http://qt-project.org/doc/qt-5/qtquick-visualcanvas-scenegraph-renderer.html
>
>> Any hints where to start for a first hello world?
>
> I started on this some time ago, but it has been sitting there ever since as the interest for splitting it out has been non-existent. It will for sure not compile, but it contains the "general idea" :)
>
> https://codereview.qt-project.org/#change,52682

Many thanks, this is more than I hoped to see in a reply!
I will definitely have a look at it.

Peter

>
> cheers,
> Gunnar
>
>

[Rutledge Shawn]

On 28 Apr 2014, at 9:32 AM, Gunnar Sletta wrote:

>
> On 28 Apr 2014, at 07:53, Peter Kümmel <***@gmx.net> wrote:
>>
> ...
>
>> ATM the problem is to get started because I don't know much about the
>> current architecture of the graphic stack.
>
> http://qt-project.org/doc/qt-5/qtquick-visualcanvas-scenegraph.html
> http://qt-project.org/doc/qt-5/qtquick-visualcanvas-scenegraph-renderer.html
>
>> Any hints where to start for a first hello world?
>
> I started on this some time ago, but it has been sitting there ever since as the interest for splitting it out has been non-existent. It will for sure not compile, but it contains the "general idea" :)
>
> https://codereview.qt-project.org/#change,52682

That was a good patch to have around, but it hasn't applied cleanly for some time.

[Tony Van Eerd]

> So we started to design our UI
> with QML. I liked the design to split business logic into
> C++ and UI design into QML and I still like it, but I came across
> several blocking issues (some of them are only valid for our application, some
> of them are general):
>
> - Our application has a huge framework of value classes. They cannot (or at
> least it does not make sense to) derive from QObject for several reasons. But
> subclassing QObject is the requirement to access data from
> C++ in QML. So we had our framework of well designed value classes and
> cannot use them in QML. There were evaluations to create QObject
> wrappers, but no nice solution. So no support for value classes is probably a
> show stopper for many projects.

When I started to use QML, every 3 or 4 months I would to think "I should add Value support to QML", but never had time.
Now I think "I wish I had added Value support to QML".

You can use QVariantMaps or just send your valuetype "through" QML via a QVariant (if its members don't need to be accessed in QML, but just transferred back to C++).
Or wrap them in QObject classes.

But none of those are very nice solutions.

Modern C++ is written with value-types. I wish Qt had more support for them.

Tony

[Peter Kümmel]

On 21.04.2014 13:39, Roland Winklmeier wrote:
> - Memory consumption: Even a mini example took about 70 MB of memory,
> QtWidgets need a lot less. This is not a complain, I know the JS runtime
> needs its initial memory. It was just one factor, because our
> application is running as an addon to Flight Simulators and they usally
> consum a lot memory. This is especially a major problem with MS Flight
> Simulator since it is only available as 32 bit application. Therefore
> every any MegaByte is important.

Especially on "non-fat" embedded systems this is a problem:
When you wanna use Linux you need some MBs Ram for the kernel,
some to get a running system, and some MBs for your application.
So you end at minimum 5-32MBs.
Then adding 100MB just to run QML really hurts, and you start
looking for alternatives, like using only QWidgets with very
limited OpenGL support or not to use a Qt-GUI at all.

Maybe such systems are also interesting from a business perspective.

>
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>

[Thiago Macieira]

Em dom 27 abr 2014, às 13:31:33, Peter Kümmel escreveu:
> Then adding 100MB just to run QML really hurts, and you start
> looking for alternatives, like using only QWidgets with very
> limited OpenGL support or not to use a Qt-GUI at all.

Of those 100 MB, 30 MB are taken by QtCore and QtGui (including ICU data). The
rest, I'm guessing you pulled the numbers out of thin air without a benchmark.

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

[Peter Kümmel]

On 27.04.2014 22:41, Thiago Macieira wrote:
> Em dom 27 abr 2014, às 13:31:33, Peter Kümmel escreveu:
>> Then adding 100MB just to run QML really hurts, and you start
>> looking for alternatives, like using only QWidgets with very
>> limited OpenGL support or not to use a Qt-GUI at all.
>
> Of those 100 MB, 30 MB are taken by QtCore and QtGui (including ICU data). The
> rest, I'm guessing you pulled the numbers out of thin air without a benchmark.
>

Yes, only a wild guess based on the numbers provided by Roland.
Currently I have a QWidget based system which runs with 32MB,
and I would not even try QML on this board, but maybe I'm too
pessimistic. (hint: here Digia's marketing has to jump in ;) )

Peter

[Thiago Macieira]

Em seg 28 abr 2014, às 08:00:56, Peter Kümmel escreveu:
> On 27.04.2014 22:41, Thiago Macieira wrote:
> > Em dom 27 abr 2014, às 13:31:33, Peter Kümmel escreveu:
> >> Then adding 100MB just to run QML really hurts, and you start
> >> looking for alternatives, like using only QWidgets with very
> >> limited OpenGL support or not to use a Qt-GUI at all.
> >
> > Of those 100 MB, 30 MB are taken by QtCore and QtGui (including ICU data).
> > The rest, I'm guessing you pulled the numbers out of thin air without a
> > benchmark.
> Yes, only a wild guess based on the numbers provided by Roland.
> Currently I have a QWidget based system which runs with 32MB,
> and I would not even try QML on this board, but maybe I'm too
> pessimistic. (hint: here Digia's marketing has to jump in ;) )

I'd say that if you don't care to try, then keep it running with QWidget.
Marketing shouldn't convince you, only engineers should. And since engineers
are in this discussion and can't convince you, then maybe no one can.

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

[Roland Winklmeier]

2014-04-27 13:31 GMT+02:00 Peter KÃŒmmel <***@gmx.net>:

> On 21.04.2014 13:39, Roland Winklmeier wrote:
> > - Memory consumption: Even a mini example took about 70 MB of memory,
> > QtWidgets need a lot less. This is not a complain, I know the JS runtime
> > needs its initial memory. It was just one factor, because our
> > application is running as an addon to Flight Simulators and they usally
> > consum a lot memory. This is especially a major problem with MS Flight
> > Simulator since it is only available as 32 bit application. Therefore
> > every any MegaByte is important.
>
> Especially on "non-fat" embedded systems this is a problem:
> When you wanna use Linux you need some MBs Ram for the kernel,
> some to get a running system, and some MBs for your application.
> So you end at minimum 5-32MBs.
> Then adding 100MB just to run QML really hurts, and you start
> looking for alternatives, like using only QWidgets with very
> limited OpenGL support or not to use a Qt-GUI at all.
>
> Maybe such systems are also interesting from a business perspective.
>

I did a test with Qt 5.3 beta using an nearly empty dialog and the numbers
aren't that bad:

Dialog with two buttons and one menu (release build)
QtWidgets: about 15 MB
QML: about 29 MB.

The numbers came from TaskManager, so no idea how reliable they are.
The 70 MB came from a more complex application. I cannot tell how memory
increase is associated with the complexity of a QML project. So one would
really need to perform a more sophisticated benchmark. But its definitely
not 100 MB just for the JS engine. Sorry if I caused confusion or mixed the
numbers in my head.

[Peter Kümmel]

On 28.04.2014 16:00, Roland Winklmeier wrote:
> 2014-04-27 13:31 GMT+02:00 Peter Kümmel <***@gmx.net <mailto:***@gmx.net>>:
>
> On 21.04.2014 13 <tel:21.04.2014%2013>:39, Roland Winklmeier wrote:
> > - Memory consumption: Even a mini example took about 70 MB of memory,
> > QtWidgets need a lot less. This is not a complain, I know the JS runtime
> > needs its initial memory. It was just one factor, because our
> > application is running as an addon to Flight Simulators and they usally
> > consum a lot memory. This is especially a major problem with MS Flight
> > Simulator since it is only available as 32 bit application. Therefore
> > every any MegaByte is important.
>
> Especially on "non-fat" embedded systems this is a problem:
> When you wanna use Linux you need some MBs Ram for the kernel,
> some to get a running system, and some MBs for your application.
> So you end at minimum 5-32MBs.
> Then adding 100MB just to run QML really hurts, and you start
> looking for alternatives, like using only QWidgets with very
> limited OpenGL support or not to use a Qt-GUI at all.
>
> Maybe such systems are also interesting from a business perspective.
>
>
> I did a test with Qt 5.3 beta using an nearly empty dialog and the numbers aren't that bad:
>
> Dialog with two buttons and one menu (release build)
> QtWidgets: about 15 MB
> QML: about 29 MB.

Thanks, looks much better than 70MB.

Peter

>
> The numbers came from TaskManager, so no idea how reliable they are.
> The 70 MB came from a more complex application. I cannot tell how memory increase is associated with the complexity of a
> QML project. So one would really need to perform a more sophisticated benchmark. But its definitely not 100 MB just for
> the JS engine. Sorry if I caused confusion or mixed the numbers in my head.
>
>
>
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>

[Kevin Krammer]

On Monday, 2014-04-21, 01:40:50, Michael Knight wrote:
> I feel like Qt is going in the direction of being Qml and Javascript only.I
> fear that they may abandon Qt Widgets in the near future,I think they are
> heavily promoting Qml.I don't want to use Qml,and before I start using Qt,I
> want to be sure that they will not abandon C++ side of Qt and that they
> continue to develop C++ side.It seems to me that they are developing Qml
> side mostly.

In discussion around QML and UI it is important to understand that QML is not
tied to any UI technology in particular.
I.e. the advantages of QML can be used with basically any component set [1]
that can be described in trees and properties on nodes, e.g. also with
QtWidgets [2].

The language "barrier" between C++ and QML makes it easier to see where UI
ends and program logic begins, leading to better abstraction between core
application and its interface.

This in turn allows different types of interface in top of the same core, e.g.
having different UI across different devices or different types of users.

Being loadable means that an application can decide at runtime which of those
interface to use.

Well written QML is runtime reloadable so switching between those different
UIs can even be done while the program is running.
During development that makes it very convenient for prototyping and testing.

If you look at the wider picture QML is a replacement for XML based .ui files,
not for any of the other technologies currently used with .ui files.

Cheers,
Kevin

[1] including a console UI technology like Curses, see
https://www.youtube.com/watch?v=pTSPviWQs4w for an inspiration
[2] https://www.youtube.com/watch?v=NqpJEj15t9Q
--
Qt Developer Days 2014, October 6 - 8 at BCC, Berlin. Save the dates!

Kevin Krammer | ***@kdab.com | Senior Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. Sweden (HQ) [phone], USA +1-866-777-KDAB(5322)
KDAB - Qt Experts - Platform-independent software solutions

[André Pönitz]

On Mon, Apr 21, 2014 at 10:53:01AM +0200, Kevin Krammer wrote:
> The language "barrier" between C++ and QML makes it easier to see where UI
> ends and program logic begins, leading to better abstraction between core
> application and its interface.

The compulsory QML/JS - C++ language cut generates otherwise uneeded work
on the user side as well as significant tooling (refactoring, debugging,
profiling...) problems. In a typical Qt Quick application the cut usually
goes straight through the middle of the Controler part of a classical
Model-View-Controler setup, i.e. sits in a pretty bad (and expensive...)
location. It's a sink of resources.

Sure, in theory, with a lot of discipline, project policy, and some luck in
prediction making, it would be possible to e.g. do only View related things
in QML/JS and align the language cut with the View-(Controler and Model)
cut, but in practice any crossing of the divide takes some effort and so
it's often "easier" to simply do some of the Controler work on the QML/JS
side (read "make the bindings a bit more complex"). On the other hand there
are (at least for non-toy applications) Controler bits that need to live on
the C++ side for performance reasons. So parts of the controler do end up
in QML/JS, others in C++, putting the language cut in an awkward place.

Having M/V/C boundaries not properly "worked out in code" while developing
a long lived application is not necessarily bad, as long as one keeps the
idea in mind, and properly does the separation on an as-needed base as the
application grows and gains in functionality. If the project is
"unilingual" this usually just means introducing some interface and some
mechanical refactoring, often enough supported by "native" tooling for the
chosen languange.

Having an enforced language break in the system takes away this
flexibility, leaving essentially the options (a) to accept the need to
re-write parts of the system in the "other" language once the time comes,
or (b) to use a waterfall style development model, fix the V/M/C boundary
before coding starts (and ignore future uses that might need some
wiggling). I presume we agree that neither sounds good.

Andre'

[Kevin Krammer]

On Monday, 2014-04-21, 14:15:16, André Pönitz wrote:
> On Mon, Apr 21, 2014 at 10:53:01AM +0200, Kevin Krammer wrote:
> > The language "barrier" between C++ and QML makes it easier to see where UI
> > ends and program logic begins, leading to better abstraction between core
> > application and its interface.
>
> The compulsory QML/JS - C++ language cut generates otherwise uneeded work
> on the user side as well as significant tooling (refactoring, debugging,
> profiling...) problems. In a typical Qt Quick application the cut usually
> goes straight through the middle of the Controler part of a classical
> Model-View-Controler setup, i.e. sits in a pretty bad (and expensive...)
> location. It's a sink of resources.

Can you given an example?
What kind of controller pieces would you do in QML?

> Having an enforced language break in the system takes away this
> flexibility, leaving essentially the options (a) to accept the need to
> re-write parts of the system in the "other" language once the time comes,
> or (b) to use a waterfall style development model, fix the V/M/C boundary
> before coding starts (and ignore future uses that might need some
> wiggling). I presume we agree that neither sounds good.

Well, you don't have an enforced language break, you can still make the logic
depend on the UI and maniulate the objects instantiated by QML via code,
similar to using QUiLoader but more bidirectional.

Obviously removes any flexibility you had for having different UIs for
different usage scenarios.

Cheers,
Kevin
--
Qt Developer Days 2014, October 6 - 8 at BCC, Berlin. Save the dates!

Kevin Krammer | ***@kdab.com | Senior Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. Sweden (HQ) [phone], USA +1-866-777-KDAB(5322)
KDAB - Qt Experts - Platform-independent software solutions

[Hausmann Simon]

Hi Michael,

In response to your email I have two questions:

1) As your email is addressed to the open source community working on Qt itself, who are you referring to with "they"?

2) You are saying that you "want to be sure". What kind of assurance are you looking for?


Simon

Opprinnelig melding
Fra: Michael Knight
Sendt: 03:45 mandag 21. april 2014
Til: ***@qt-project.org
Emne: [Development] Question about Qt's future


I feel like Qt is going in the direction of being Qml and Javascript only.I
fear that they may abandon Qt Widgets in the near future,I think they are
heavily promoting Qml.I don't want to use Qml,and before I start using Qt,I
want to be sure that they will not abandon C++ side of Qt and that they
continue to develop C++ side.It seems to me that they are developing Qml side
mostly.

What do you think about this?