Re: [Interest] Creating Qt Quick controls from C++

[Shawn Rutledge]

> On 19 Jul 2016, at 16:44, Uwe Rathmann  wrote:
> 
> On Tue, 19 Jul 2016 15:45:44 +0200, Jean-Michaël Celerier wrote:
> 
>> Is there some code somewhere ?
> 
> Sure on my disk ;)
> 
> Being serious: the code is supposed to be available under an Open Source 
> License, but it needs to have an initial level of quality first. And 
> there is still a long way to go.

Working on the Qt Project may have affected your instincts (we have inhibitions 
baked into the process because of long-term API support, we don’t have quite 
the right solution for hosting experimental git repos, and in the past we have 
been afraid to open-source too much), but in actual normal open source 
development I think “release early, release often” is still a good mantra.  If 
it’s just an experiment, it won't need a fixed API just yet, right?

Otherwise someone else who is interested in doing similar things is going to 
either waste time redoing your work, or else feel that it’s better to wait - 
which may also be a waste of time and especially energy.

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Creating Qt Quick controls from C++

[Uwe Rathmann]

On Tue, 19 Jul 2016 15:45:44 +0200, Jean-Michaël Celerier wrote:

> Is there some code somewhere ?

Sure on my disk ;)

Being serious: the code is supposed to be available under an Open Source 
License, but it needs to have an initial level of quality first. And 
there is still a long way to go.

But even then - don't expect to find a set of controls, that is nearly as 
feature rich as Quick Controls 1, it won't not even be close to Quick 
Controls 2. But of course it could be a starting point to get there.

Uwe

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Creating Qt Quick controls from C++

[Jean-Michaël Celerier]

On Tue, Jul 19, 2016 at 12:33 PM, Uwe Rathmann 
wrote:

>
> More details about my experiment will be presented at: https://
> conf.qtcon.org/en/qtcon/public/events/428


Is there some code somewhere ?
I really want to use the Qt scenegraph but I'd much rather use C++ than QML.

Best,
Jean-Michaël
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Creating Qt Quick controls from C++

[Uwe Rathmann]

On Tue, 19 Jul 2016 11:10:26 +0200, Benjamin TERRIER wrote:

> * you can't even create ...

As I'm currently working on a library offering Quick Controls with an C++ 
API ( having a QML API as well ) I already have some experience in what 
it means.

The very first thing you will notice is that the Quick classes available 
as private or public headers from the Qt Quick core module have never 
been consequently designed for the C++ use case.

Next you will notice, that this module does not follow concepts you would 
expect, when being used to widgets. This starts with using homebrew 
notification hooks instead of events, continues with having 2 different 
object hierarchies and ends with being inconsistent with QGuiApplication.

Next you will see, that you don't have a powerful layout system. The 
existing implementation for QML builds an API using attached properties.
But this is only a frontend for QGridLayoutEngine and it is not that much 
work to write another one, that offers a C++ API ( my version is around 
1000 lines of code for Grid/Box/Stack layouts ), that can be used like 
the QLayout classes.

So there is a lot of initial work to be done before you are in the 
position to start with implementing Quick Controls in C++. But once you 
have it you can easily outperform the existing QML implementations in 
terms of instantiation times and memory footprint - not to mention that 
you are free to decide to have a pure C++ code base.

More details about my experiment will be presented at: https://
conf.qtcon.org/en/qtcon/public/events/428

Uwe

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Creating Qt Quick controls from C++

[Benjamin TERRIER]

If your app is for desktop only, I suggest you go with Widget instead
of Qt Quick.

Sure Qt Quick has many advantages but for desktop only software it still lacks
major features, for instance Qt Quick Controls 2 does not handle mouse hovering
(e.g Buttons will not highlight when the cursor is over) and Qt Quick Controls 1
does not handle keyboard focus properly (e.g you cannot press 'space' to toggle
a check box, https://bugreports.qt.io/browse/QTBUG-47658 ).

Also as you already spotted the public C++ API fro Qt Quick and the
Scene Graph is very
limited*. So you will need to generate QML from your C++ code and then
run it through the QML
engine to create your GUI, if you choos to go this way.

* you can't even create a C++ "QuickButton" class derived from
QQuickItem with Qt public API
as you have nothing to easily draw text on the SceneGraph

Br,

Benjamin

2016-07-07 23:52 GMT+02:00 Rob Allan :
> I'm part of a team that is looking at migrating an existing Windows C++ app
> to Qt. The first decision is whether to use Widgets or Qt Quick. Since Qt
> Quick is newer, shinier, faster, etc, that seems like the obvious choice.
> However, for reasons that I won't go into here, the vast majority of forms
> in our app are built dynamically in code. This kind of approach seems easy
> enough with Widgets, but looks like it could be difficult, or even
> infeasible, with Qt Quick. That's because the preferred way of creating Qt
> Quick layouts is using QML, and while there is an object model backing that,
> my impression is that this object model is not designed to support
> heavy-duty creation and manipulation of layout elements. For example, while
> QQuickItem is documented, none of its derived classes are, and I believe
> their interfaces may be private - so the only way to manipulate items is
> using a generic "setProperty" syntax. And while there are a few articles
> around that talk about accessing the Qt Quick model from C++, such as this
> one
> [http://stackoverflow.com/questions/31890372/add-objects-to-qml-layout-from-c],
> they tend to use snippets of QML to get the job done in a rather hacky way,
> and make various comments about the perils and pitfalls of trying to
> manipulate the model from code.
>
> I can't help comparing this with two other popular layout frameworks:
> WPF/XAML, and Android/AXML. In both of these worlds, the markup language and
> the "code-behind" class hierarchy of UI elements are absolutely equivalent
> 1st class citizens. Anything you can do in XAML, you can also do in the C#
> code-behind, whether it be creating controls, changing their properties,
> altering layouts, etc. Likewise in Android/AXML, I can (if I choose) create
> FrameLayouts, RelativeLayouts, TextViews, etc in code, and arrange them and
> manipulate them any way I like, as an alternative to creating an AXML
> designer layout.
>
> It seems very unfortunate that Qt Quick doesn't take this approach, and that
> the "code-behind" experience is so limited.
>
> Am I missing something here? Assuming I'm not, are there any plans to make
> the Qt Quick class model more "open", with full documentation and public
> interfaces for all relevant properties and methods?
>
> Thanks,
> Rob
>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Creating Qt Quick controls from C++

[André Somers]

Op 07/07/2016 om 23:52 schreef Rob Allan:
I'm part of a team that is looking at migrating an existing Windows 
C++ app to Qt. The first decision is whether to use Widgets or Qt 
Quick. Since Qt Quick is newer, shinier, faster, etc, that seems like 
the obvious choice. However, for reasons that I won't go into here, 
the vast majority of forms in our app are built dynamically in code. 
This kind of approach seems easy enough with Widgets, but looks like 
it could be difficult, or even infeasible, with Qt Quick. That's 
because the preferred way of creating Qt Quick layouts is using QML, 
and while there is an object model backing that, my impression is that 
this object model is not designed to support heavy-duty creation and 
manipulation of layout elements. For example, while QQuickItem is 
documented, none of its derived classes are, and I believe their 
interfaces may be private - so the only way to manipulate items is 
using a generic "setProperty" syntax. And while there are a few 
articles around that talk about accessing the Qt Quick model from C++, 
such as this one 
[http://stackoverflow.com/questions/31890372/add-objects-to-qml-layout-from-c], 
they tend to use snippets of QML to get the job done in a rather hacky 
way, and make various comments about the perils and pitfalls of trying 
to manipulate the model from code.


I can't help comparing this with two other popular layout frameworks: 
WPF/XAML, and Android/AXML. In both of these worlds, the markup 
language and the "code-behind" class hierarchy of UI elements are 
absolutely equivalent 1st class citizens. Anything you can do in XAML, 
you can also do in the C# code-behind, whether it be creating 
controls, changing their properties, altering layouts, etc. Likewise 
in Android/AXML, I can (if I choose) create FrameLayouts, 
RelativeLayouts, TextViews, etc in code, and arrange them and 
manipulate them any way I like, as an alternative to creating an AXML 
designer layout.


It seems very unfortunate that Qt Quick doesn't take this approach, 
and that the "code-behind" experience is so limited.


Am I missing something here? Assuming I'm not, are there any plans to 
make the Qt Quick class model more "open", with full documentation and 
public interfaces for all relevant properties and methods?


No, you are not missing anything here. You are right that there is 
currently no exposed C++ interface for QML that allows you to define 
your UIs like you can from QML. I understand the reasoning for not (yet) 
providing it, but it is indeed an often-requested thing and I would 
apreciate one appearing. AFAIK, the main reason for not having an 
exposed C++ backend is the stability that would enforce. Having only a 
QML backend frees the developers from having a stable C++ backend with 
binary compatibility guarantees. That is quite a burden to have for a 
young technology like QML en Qt Quick.


But of course there are still several supported options available. 
Xavier already mentioned one, but did you consider just generating the 
actual QML on the fly and loading that? That would allow totally dynamic 
forms.


Still, you may want to consider sticking with Qt Widgets. There is 
nothing wrong with that approach. I don't know the needs of your 
application, but most applications consisting of lots of dialogs with 
buttons, line edits, drop-downs, lists, etc. Qt Widgets is just a very 
good fit. It is very mature, stable and has the C++ interface you're 
looking for. Where it does *not* shine is if you want performant 
animations of your UI like you have mobile devices. If that's not what 
you're after, then Qt Widgets may just be a better fit for you.


HTH,

André
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Creating Qt Quick controls from C++

[Xavier Bigand]

If some of your forms are user defined, maybe you can take a look to the
QML editor code integrated in QtCreator. I don't know if it's rendered with
QML or something else, if it's in QML then the way it is done should be
correspond to what your a looking for.

I don't know why Qt doesn't support property bindings in c++, for our
project we have implemented it to solve a lot of issues we had because of
dependencies in our algorithms.
Maybe it will come in a futur with public APIs to manipulate QML objects
from c++.

Have a good day.

2016-07-13 6:37 GMT+02:00 Rob Allan :

> Hi Xavier,
>
> Thanks for your thoughts on this. Yes, I think I understand the way that
> Qt Quick and QML can be used to make layouts that are dynamic and updatable
> depending on property bindings. However, I think I'm talking about another
> level of customization - namely, forms that are constructed entirely at
> runtime from application logic. This is way more than just showing or
> hiding fields, changing colors, or some of the things that I suspect are
> typically done with bindings, slots and signals. In our case we have dozens
> - in fact hundreds - of forms, some user-definable, that are built at
> runtime, and it is just not feasible for us to build these ahead of time as
> static QML files.
>
> I still contend that Qt Quick does not make this as easy as it could, if
> the entire QML object tree could be created and/or manipulated from C++ -
> as is the case in the other UI frameworks I mentioned.
>
> Regards,
> Rob
>
> On Fri, Jul 8, 2016 at 11:56 AM, Xavier Bigand 
> wrote:
>
>> I think that our approche can be wrong, maybe you don't need to be able
>> to access to the QtQuick components from the C++. The best is to follow the
>> philosophy of QtQuick with the property bindings. You can expose variables
>> (properties) from your c++ to the QML and let the QML interact with them.
>> In QML you have everything to build the GUI dynamically, property bindings,
>> loaders,...
>> The c++ code have just to emit a signal when the property value changed,
>> and your GUI will be updated depending of your conditions in the property
>> bindings on the QML side.
>>
>> We use that to create a custom GUI, that can be adapted to every screen
>> size (from mobile to desktop) be able to change GUI skins, language,...
>> without restarting the application. It's a major time development win,
>> because we can emulate the GUI we have on phone on desktop without
>> restarting the application (we simply change the c++ property that give us
>> the device type),...
>>
>> And because we can't use the design due to the c++ dependencies, we add
>> the QML hot reloading when files are changing.
>>
>>
>> If you are looking to change our GUI library, removing our actual c++
>> dedicated to the interface creation shouldn't much harder than refactoring
>> it to fit the new API.
>>
>>
>> QtQuick is made to works with property binding, that it is not supported
>> on the c++ side by Qt. The only thing you can create on c++ side is new
>> item types by derived some existing.
>>
>>
>> 2016-07-07 23:52 GMT+02:00 Rob Allan :
>>
>>> I'm part of a team that is looking at migrating an existing Windows C++
>>> app to Qt. The first decision is whether to use Widgets or Qt Quick. Since
>>> Qt Quick is newer, shinier, faster, etc, that seems like the obvious
>>> choice. However, for reasons that I won't go into here, the vast majority
>>> of forms in our app are built dynamically in code. This kind of approach
>>> seems easy enough with Widgets, but looks like it could be difficult, or
>>> even infeasible, with Qt Quick. That's because the preferred way of
>>> creating Qt Quick layouts is using QML, and while there is an object model
>>> backing that, my impression is that this object model is not designed to
>>> support heavy-duty creation and manipulation of layout elements. For
>>> example, while QQuickItem is documented, none of its derived classes are,
>>> and I believe their interfaces may be private - so the only way to
>>> manipulate items is using a generic "setProperty" syntax. And while there
>>> are a few articles around that talk about accessing the Qt Quick model from
>>> C++, such as this one [
>>> http://stackoverflow.com/questions/31890372/add-objects-to-qml-layout-from-c],
>>> they tend to use snippets of QML to get the job done in a rather hacky way,
>>> and make various comments about the perils and pitfalls of trying to
>>> manipulate the model from code.
>>>
>>> I can't help comparing this with two other popular layout frameworks:
>>> WPF/XAML, and Android/AXML. In both of these worlds, the markup language
>>> and the "code-behind" class hierarchy of UI elements are absolutely
>>> equivalent 1st class citizens. Anything you can do in XAML, you can also do
>>> in the C# code-behind, whether it be creating controls, changing their
>>> properties, altering layouts, etc. Likewise 

Re: [Interest] Creating Qt Quick controls from C++

[Rob Allan]

Hi Xavier,

Thanks for your thoughts on this. Yes, I think I understand the way that Qt
Quick and QML can be used to make layouts that are dynamic and updatable
depending on property bindings. However, I think I'm talking about another
level of customization - namely, forms that are constructed entirely at
runtime from application logic. This is way more than just showing or
hiding fields, changing colors, or some of the things that I suspect are
typically done with bindings, slots and signals. In our case we have dozens
- in fact hundreds - of forms, some user-definable, that are built at
runtime, and it is just not feasible for us to build these ahead of time as
static QML files.

I still contend that Qt Quick does not make this as easy as it could, if
the entire QML object tree could be created and/or manipulated from C++ -
as is the case in the other UI frameworks I mentioned.

Regards,
Rob

On Fri, Jul 8, 2016 at 11:56 AM, Xavier Bigand 
wrote:

> I think that our approche can be wrong, maybe you don't need to be able to
> access to the QtQuick components from the C++. The best is to follow the
> philosophy of QtQuick with the property bindings. You can expose variables
> (properties) from your c++ to the QML and let the QML interact with them.
> In QML you have everything to build the GUI dynamically, property bindings,
> loaders,...
> The c++ code have just to emit a signal when the property value changed,
> and your GUI will be updated depending of your conditions in the property
> bindings on the QML side.
>
> We use that to create a custom GUI, that can be adapted to every screen
> size (from mobile to desktop) be able to change GUI skins, language,...
> without restarting the application. It's a major time development win,
> because we can emulate the GUI we have on phone on desktop without
> restarting the application (we simply change the c++ property that give us
> the device type),...
>
> And because we can't use the design due to the c++ dependencies, we add
> the QML hot reloading when files are changing.
>
>
> If you are looking to change our GUI library, removing our actual c++
> dedicated to the interface creation shouldn't much harder than refactoring
> it to fit the new API.
>
>
> QtQuick is made to works with property binding, that it is not supported
> on the c++ side by Qt. The only thing you can create on c++ side is new
> item types by derived some existing.
>
>
> 2016-07-07 23:52 GMT+02:00 Rob Allan :
>
>> I'm part of a team that is looking at migrating an existing Windows C++
>> app to Qt. The first decision is whether to use Widgets or Qt Quick. Since
>> Qt Quick is newer, shinier, faster, etc, that seems like the obvious
>> choice. However, for reasons that I won't go into here, the vast majority
>> of forms in our app are built dynamically in code. This kind of approach
>> seems easy enough with Widgets, but looks like it could be difficult, or
>> even infeasible, with Qt Quick. That's because the preferred way of
>> creating Qt Quick layouts is using QML, and while there is an object model
>> backing that, my impression is that this object model is not designed to
>> support heavy-duty creation and manipulation of layout elements. For
>> example, while QQuickItem is documented, none of its derived classes are,
>> and I believe their interfaces may be private - so the only way to
>> manipulate items is using a generic "setProperty" syntax. And while there
>> are a few articles around that talk about accessing the Qt Quick model from
>> C++, such as this one [
>> http://stackoverflow.com/questions/31890372/add-objects-to-qml-layout-from-c],
>> they tend to use snippets of QML to get the job done in a rather hacky way,
>> and make various comments about the perils and pitfalls of trying to
>> manipulate the model from code.
>>
>> I can't help comparing this with two other popular layout frameworks:
>> WPF/XAML, and Android/AXML. In both of these worlds, the markup language
>> and the "code-behind" class hierarchy of UI elements are absolutely
>> equivalent 1st class citizens. Anything you can do in XAML, you can also do
>> in the C# code-behind, whether it be creating controls, changing their
>> properties, altering layouts, etc. Likewise in Android/AXML, I can (if I
>> choose) create FrameLayouts, RelativeLayouts, TextViews, etc in code, and
>> arrange them and manipulate them any way I like, as an alternative to
>> creating an AXML designer layout.
>>
>> It seems very unfortunate that Qt Quick doesn't take this approach, and
>> that the "code-behind" experience is so limited.
>>
>> Am I missing something here? Assuming I'm not, are there any plans to
>> make the Qt Quick class model more "open", with full documentation and
>> public interfaces for all relevant properties and methods?
>>
>> Thanks,
>> Rob
>>
>> ___
>> Interest mailing list
>> Interest@qt-project.org
>> 

Re: [Interest] Creating Qt Quick controls from C++

[Xavier Bigand]

I think that our approche can be wrong, maybe you don't need to be able to
access to the QtQuick components from the C++. The best is to follow the
philosophy of QtQuick with the property bindings. You can expose variables
(properties) from your c++ to the QML and let the QML interact with them.
In QML you have everything to build the GUI dynamically, property bindings,
loaders,...
The c++ code have just to emit a signal when the property value changed,
and your GUI will be updated depending of your conditions in the property
bindings on the QML side.

We use that to create a custom GUI, that can be adapted to every screen
size (from mobile to desktop) be able to change GUI skins, language,...
without restarting the application. It's a major time development win,
because we can emulate the GUI we have on phone on desktop without
restarting the application (we simply change the c++ property that give us
the device type),...

And because we can't use the design due to the c++ dependencies, we add the
QML hot reloading when files are changing.


If you are looking to change our GUI library, removing our actual c++
dedicated to the interface creation shouldn't much harder than refactoring
it to fit the new API.


QtQuick is made to works with property binding, that it is not supported on
the c++ side by Qt. The only thing you can create on c++ side is new item
types by derived some existing.


2016-07-07 23:52 GMT+02:00 Rob Allan :

> I'm part of a team that is looking at migrating an existing Windows C++
> app to Qt. The first decision is whether to use Widgets or Qt Quick. Since
> Qt Quick is newer, shinier, faster, etc, that seems like the obvious
> choice. However, for reasons that I won't go into here, the vast majority
> of forms in our app are built dynamically in code. This kind of approach
> seems easy enough with Widgets, but looks like it could be difficult, or
> even infeasible, with Qt Quick. That's because the preferred way of
> creating Qt Quick layouts is using QML, and while there is an object model
> backing that, my impression is that this object model is not designed to
> support heavy-duty creation and manipulation of layout elements. For
> example, while QQuickItem is documented, none of its derived classes are,
> and I believe their interfaces may be private - so the only way to
> manipulate items is using a generic "setProperty" syntax. And while there
> are a few articles around that talk about accessing the Qt Quick model from
> C++, such as this one [
> http://stackoverflow.com/questions/31890372/add-objects-to-qml-layout-from-c],
> they tend to use snippets of QML to get the job done in a rather hacky way,
> and make various comments about the perils and pitfalls of trying to
> manipulate the model from code.
>
> I can't help comparing this with two other popular layout frameworks:
> WPF/XAML, and Android/AXML. In both of these worlds, the markup language
> and the "code-behind" class hierarchy of UI elements are absolutely
> equivalent 1st class citizens. Anything you can do in XAML, you can also do
> in the C# code-behind, whether it be creating controls, changing their
> properties, altering layouts, etc. Likewise in Android/AXML, I can (if I
> choose) create FrameLayouts, RelativeLayouts, TextViews, etc in code, and
> arrange them and manipulate them any way I like, as an alternative to
> creating an AXML designer layout.
>
> It seems very unfortunate that Qt Quick doesn't take this approach, and
> that the "code-behind" experience is so limited.
>
> Am I missing something here? Assuming I'm not, are there any plans to make
> the Qt Quick class model more "open", with full documentation and public
> interfaces for all relevant properties and methods?
>
> Thanks,
> Rob
>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
>


-- 
Xavier
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

[Interest] Creating Qt Quick controls from C++

[Rob Allan]

I'm part of a team that is looking at migrating an existing Windows C++ app
to Qt. The first decision is whether to use Widgets or Qt Quick. Since Qt
Quick is newer, shinier, faster, etc, that seems like the obvious choice.
However, for reasons that I won't go into here, the vast majority of forms
in our app are built dynamically in code. This kind of approach seems easy
enough with Widgets, but looks like it could be difficult, or even
infeasible, with Qt Quick. That's because the preferred way of creating Qt
Quick layouts is using QML, and while there is an object model backing
that, my impression is that this object model is not designed to support
heavy-duty creation and manipulation of layout elements. For example, while
QQuickItem is documented, none of its derived classes are, and I believe
their interfaces may be private - so the only way to manipulate items is
using a generic "setProperty" syntax. And while there are a few articles
around that talk about accessing the Qt Quick model from C++, such as this
one [
http://stackoverflow.com/questions/31890372/add-objects-to-qml-layout-from-c],
they tend to use snippets of QML to get the job done in a rather hacky way,
and make various comments about the perils and pitfalls of trying to
manipulate the model from code.

I can't help comparing this with two other popular layout frameworks:
WPF/XAML, and Android/AXML. In both of these worlds, the markup language
and the "code-behind" class hierarchy of UI elements are absolutely
equivalent 1st class citizens. Anything you can do in XAML, you can also do
in the C# code-behind, whether it be creating controls, changing their
properties, altering layouts, etc. Likewise in Android/AXML, I can (if I
choose) create FrameLayouts, RelativeLayouts, TextViews, etc in code, and
arrange them and manipulate them any way I like, as an alternative to
creating an AXML designer layout.

It seems very unfortunate that Qt Quick doesn't take this approach, and
that the "code-behind" experience is so limited.

Am I missing something here? Assuming I'm not, are there any plans to make
the Qt Quick class model more "open", with full documentation and public
interfaces for all relevant properties and methods?

Thanks,
Rob
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest