[Development] The place of QML

[Alan Alpert]

Hi,

I'm a little worried that the position of QML in Qt5 is not entirely clear.
It's a great new technology, but that "new" part means that realistically it
will not take over everything, everywhere, immediately upon the release of Qt
5.0.0. To help place QML within the greater Qt context, I've written the
following article. You will certainly need to read it if you think that Qt5 is
pure QML (or pure C++)! It is also highly relevant to the increasing number of
Qt developers writing QML APIs for their C++ functionality. The things I need
feedback on are:
A) We need to establish a consensus on the role of QML within Qt.
B) Where would such an article go? Labs Blog? Qt 5 Book? Wiki or Doc page?

Now, here's the wall-of-text:

Writing QML modules in C++ for QML is an important part of the Qt/QML story
and it helps to know what roles each part is supposed to play in the story.
This article is written from the QML perspective, so the C++ referred to here
is about when you implement your QML facing APIs in C++ (or implement the
application backend in C++, for your QML frontend). The QML referred to here
refers to the QML users of your API. This article is not relevant for QML
facing APIs which are themselves written in QML, but those are expected to be
extremely rare given QML's current stage of development.

QML is the User Experience (UX or UI, User Interface) layer. This means that
the visual representation of the application is done with QML. It also means
that logic reacting to user input is done in QML. This is highly advantageous
in allowing the user interaction to affect the visual representation of the
application directly. In order for user input logic to be done in QML, the
application's functionality usually needs to be exposed in some way. This
allows for the QML code to map the UX to the application abilities in a
scripting language, for more versatility and rapid application development.

C++ is the data layer. This means that data manipulation and often the real
functionality of the application remains in C++. What is exposed to QML is the
UX abstraction of the functionality, such as an action you might find on a
toolbar (e.g. save file). The programmatic instructions for implementing this
on a computer remain in C++ (e.g. opening a file, writing data from the main
view to the file, closing the file). Some logic can be done in the UX layer
(e.g. passing the main view to the function instead of the C++ plugin assuming
this) but only UX level abstractions should be exposed to QML. The logic of
how to manipulate your application's data, if it is not exposed to the end
user, should not be exposed to QML.

The split is right where a QML module's API usually lies (if the module is
written in C++). So your API should be written with this split in mind. What
this means in terms of API design is that such an API should expose results
and high-level functionality to QML, anything which might be exposed directly
to a user to manipulate. If the functionality is sufficiently low-level that
it would never be directly called from the UI layer, try not to expose it.
Instead, expose the higher level results that are expected so that more of the
imperative logic can be done in C++, and to simplify any QML using it.

In the Qt/QML story it is important that you can always drop down to a,
usually separate, C++ API for anything more complex or involved than is
provided in the QML API. For example, in QtQuick 1.x subclassing
QDeclarativeItem was the only solution for imperative painting in a QML scene
because that usecase was not common enough for the first iteration (of course,
QtQuick 2.x has the Canvas API). This is particularly true at this early
development stage, because there is always a C++ application entry point. It
is okay if a rare use-case is only serviced by the C++ API. There should
usually be a C++ API as well as the QML API, although it may be shared with
the QML API for implementation reasons.

As an example, consider file I/O. Your starting point for a QML file I/O
plugin would be the high level QFile API, not the lower level QIODevice API.
But even QFile exposes a lot of imperative object state and niche
functionality. A QML File object could be as simple as filePath and contents
properties to cover the majority of usecases. Upon changes to the filePath
property (or item destruction) the underlying QFile could be closed and
reopened. It could read the file contents into a buffer at that time for
updating the contents property when read by QML. Changes to the contents
property are treated as writes to the file. There is some inefficiency in this
implementation compared to a C++ implementation, but (for this example at
least) large files are a minority use case which is catered for using the C++
API. High-performance usecases will usually need to use the C++ API directly
for the efficiencies given by having fine grained control. A Hex editor would
likely need to expose its own file handling for the binary view of file data,
but could still use the simple File element for a preview pane.

--
Alan Alpert
Senior Engineer
Nokia, Qt Development Frameworks

[Girish Ramakrishnan]

Hi Alan,

On Mon, Apr 16, 2012 at 7:09 PM, Alan Alpert <***@nokia.com> wrote:
> Hi,
>
> I'm a little worried that the position of QML in Qt5 is not entirely clear.
> It's a great new technology, but that "new" part means that realistically it
> will not take over everything, everywhere, immediately upon the release of Qt
> 5.0.0. To help place QML within the greater Qt context, I've written the
> following article. You will certainly need to read it if you think that Qt5 is
> pure QML (or pure C++)! It is also highly relevant to the increasing number of
> Qt developers writing QML APIs for their C++ functionality. The things I need
> feedback on are:
> A) We need to establish a consensus on the role of QML within Qt.
> B) Where would such an article go? Labs Blog? Qt 5 Book? Wiki or Doc page?
>

That's a fantastic article. I would like to see these as part of Qt
documentation itself as the soft-introduction to QML.

As for the consensus, this is very much in vibe with what my idea of
QML is. I think we should push QML primarily as a UI technology and
encourage people to keep their data and models in C++. Any non-UI
items created in QML is primarily to aid writing the UI (it's easy to
create data bindings). I advocated something on these lines at dev
days (http://get.qt.nokia.com/videos/DevDays2011/TechnicalSessions/DevDays2011_-_Qt_Quick_Best_Practices_And_Design_Patterns.pdf).

I don't want to hijack the thread, but apart from articles on QML we
also need a big app that remove the notion that QML is a "toy". This
big app should try to implement the "ideal" vision of what QML is. We
need the equivalent of a Qt Creator or a designer for the QML world.
Something that solves a real world problem and not flying images, if
you get my point. I think QtMediaHub will solve this problem if we
(the qmh devs) can get it ready before 5.0 (which is very likely). Do
we know of any other big QML application that the world can see to
appreciate how code looks? (The N9 would have been a good showcase but
afaik that code is not open). The other day, I learnt about, Snow shoe
but I am not sure what state it is - http://snowshoe.qtlabs.org.br/.

The way most people learn a new programming language is by reading
other people's code. If we want people to learn QML and have a
pleasant experience with QML, we need to somehow showcase some good
sized QML apps that will help them write good code from the beginning.

Girish

[Girish Ramakrishnan]

Hi,

On Wed, Apr 18, 2012 at 10:56 PM, Girish Ramakrishnan
<***@forwardbias.in> wrote:
> Hi Alan,
>
> On Mon, Apr 16, 2012 at 7:09 PM, Alan Alpert <***@nokia.com> wrote:
>> Hi,
>>
>> I'm a little worried that the position of QML in Qt5 is not entirely clear.
>> It's a great new technology, but that "new" part means that realistically it
>> will not take over everything, everywhere, immediately upon the release of Qt
>> 5.0.0. To help place QML within the greater Qt context, I've written the
>> following article. You will certainly need to read it if you think that Qt5 is
>> pure QML (or pure C++)! It is also highly relevant to the increasing number of
>> Qt developers writing QML APIs for their C++ functionality. The things I need
>> feedback on are:
>> A) We need to establish a consensus on the role of QML within Qt.
>> B) Where would such an article go? Labs Blog? Qt 5 Book? Wiki or Doc page?
>>
>

As for a blog, why is there no qt-project blog? It would be great to
have people blogging about Qt development related stuff.

Girish

[Robin Burchell]

On Thu, Apr 19, 2012 at 8:11 AM, Girish Ramakrishnan
<***@forwardbias.in> wrote:
> As for a blog, why is there no qt-project blog? It would be great to
> have people blogging about Qt development related stuff.

presumably because it's a bit hard to define who gets access to that, etc.

there is planetqt, which is also syndicated to the front page of
qt-project. I'm not sure who to contact to get syndicated on there
nowdays...

[André Somers]

Op 19-4-2012 8:18, Robin Burchell schreef:
> On Thu, Apr 19, 2012 at 8:11 AM, Girish Ramakrishnan
> <***@forwardbias.in> wrote:
>> As for a blog, why is there no qt-project blog? It would be great to
>> have people blogging about Qt development related stuff.
> presumably because it's a bit hard to define who gets access to that, etc.
>
> there is planetqt, which is also syndicated to the front page of
> qt-project. I'm not sure who to contact to get syndicated on there
> nowdays...
I bet if you contact Alexandra Leisse (troubalex on IRC), it will be
taken care off. If not by her personally, she'll know who to tickle.

André

[Girish Ramakrishnan]

On Wed, Apr 18, 2012 at 11:25 PM, André Somers <***@familiesomers.nl> wrote:
> Op 19-4-2012 8:18, Robin Burchell schreef:
>> On Thu, Apr 19, 2012 at 8:11 AM, Girish Ramakrishnan
>> <***@forwardbias.in>  wrote:
>>> As for a blog, why is there no qt-project blog? It would be great to
>>> have people blogging about Qt development related stuff.
>> presumably because it's a bit hard to define who gets access to that, etc.
>>
>> there is planetqt, which is also syndicated to the front page of
>> qt-project. I'm not sure who to contact to get syndicated on there
>> nowdays...
> I bet if you contact Alexandra Leisse (troubalex on IRC), it will be
> taken care off. If not by her personally, she'll know who to tickle.
>

I think many of us know the 'problems' with planetqt, so I won't voice
it out here because I don't know what is public information.

I think if we can just have a aggregator on the qt-project, it would
be good enough. Alexandra, what do you think?

Girish

[m***@nokia.com]

On 19/04/2012 09:49, ext Girish Ramakrishnan wrote:
> On Wed, Apr 18, 2012 at 11:25 PM, André Somers<***@familiesomers.nl> wrote:
>> Op 19-4-2012 8:18, Robin Burchell schreef:
>>> On Thu, Apr 19, 2012 at 8:11 AM, Girish Ramakrishnan
>>> <***@forwardbias.in> wrote:
>>>> As for a blog, why is there no qt-project blog? It would be great to
>>>> have people blogging about Qt development related stuff.
>>> presumably because it's a bit hard to define who gets access to that, etc.
>>>
>>> there is planetqt, which is also syndicated to the front page of
>>> qt-project. I'm not sure who to contact to get syndicated on there
>>> nowdays...
>> I bet if you contact Alexandra Leisse (troubalex on IRC), it will be
>> taken care off. If not by her personally, she'll know who to tickle.
>>
>
> I think many of us know the 'problems' with planetqt, so I won't voice
> it out here because I don't know what is public information.
>
> I think if we can just have a aggregator on the qt-project, it would
> be good enough. Alexandra, what do you think?

We already have blog aggregation on qt-project, on the right-hand side
of the front page. Alexandra can add more there, afaik.

Thiago's blog has already been added, as well as the Qt Labs ones, and
The Qt Blog.

--
.marius

[Richard Moore]

On 19 April 2012 16:17, <marius.storm-***@nokia.com> wrote:
>> I think many of us know the 'problems' with planetqt, so I won't voice
>> it out here because I don't know what is public information.
>>
>> I think if we can just have a aggregator on the qt-project, it would
>> be good enough. Alexandra, what do you think?
>
> We already have blog aggregation on qt-project, on the right-hand side
> of the front page. Alexandra can add more there, afaik.

I don't know which blogs are added here, but it is very misleading -
the title is 'Planet Qt' and at the bottom it links to planetqt.org,
but the actual feed is not planetqt. I've no idea what problems you're
referring to, but right now the aggregation is essentially just nokia
stuff and not really either planetqt or qt-project.

>
> Thiago's blog has already been added, as well as the Qt Labs ones, and
> The Qt Blog.

In fact this seems to be the stuff that was previously nokia and thiago.

Rich.

[Quim Gil]

Please, let's use The place of QML thread to discuss The place of QML. :)

Website, blogs etc is a topic for the [Marketing] list, where you can
discuss with Alex and others taking care of the website.

fwiw the discussion about Qt Progect news, blogs and planets has started
in that list 2 or 3 times but never reached a conclusion or actions.
Yes, this is an invitation to push this topic until a satisfactory
change is done.

Unfortunately I don't have time to drive this myself, but I can help.

--
Quim

[d3fault]

*cough*

http://qt-project.org/forums/viewthread/16465/

Does Qt need a modern C++ GUI API?
> -No, I am perfectly happy with QML, JavaScript, interpreters, virtual
> machines, glue code, glue abstract and proxy object
> -Yes, I’d like the option of 100% native development without being left
> behind with a last century GUI API
>


Can someone put that poll, or at least a link to it, on the front page of
qt-project.org?

[m***@nokia.com]

That's a strongly biased poll due to the wording. And it's missing the points the Lars has been trying convey, but some seem to ignore.

--
Sent from my Nokia N9On 4/20/12 17:31 ext d3fault wrote:
*cough*

http://qt-project.org/forums/viewthread/16465/


Does Qt need a modern C++ GUI API?
-No, I am perfectly happy with QML, JavaScript, interpreters, virtual machines, glue code, glue abstract and proxy object
-Yes, I’d like the option of 100% native development without being left behind with a last century GUI API



Can someone put that poll, or at least a link to it, on the front page of qt-project.org

[d3fault]

Yes, it is strongly biased due to the wording. Fix the wording and post it
anyways. The numbers will not change.

I got bored and drew a pretty picture to summarize my feelings for QML:
http://bayimg.com/jaooAAaDC
Hope you laugh.

But back to being serious. How can anybody in the QML camp argue against
this: Modern, Hardware Accelerated GUI Defining/Declaring/Creation does not
require QML/JS Interpreter/Virtual Machine.

It's like these genius' (QML/QtQuick is still brilliant) got so caught up
with what they were working on that they forgot the big picture: Hardware
Accelerated C++ GUI. Forcing the use of a declarative language, a JS
Interpreter, and a virtual machine just makes most of us want to stab
ourselves in the eye out of principle (our principles differ from yours).

To quote Lars,

> We want to make the usage of Javascript supported as well as C++ is
> supported. We are not making it the *superior* way or even the only way.
>
...except that the javascript way currently is the superior way. If you
want a hardware accelerated UI (without hacking together your own...
defeating the purpose of using a UI toolkit), you are forced to use
javascript (QML).

d3fault

On Fri, Apr 20, 2012 at 3:59 PM, <marius.storm-***@nokia.com> wrote:

> That's a strongly biased poll due to the wording. And it's missing the
> points the Lars has been trying convey, but some seem to ignore.
>
> --
> Sent from my Nokia N9On 4/20/12 17:31 ext d3fault wrote:
> *cough*
>
> http://qt-project.org/forums/viewthread/16465/
>
>
> Does Qt need a modern C++ GUI API?
> -No, I am perfectly happy with QML, JavaScript, interpreters, virtual
> machines, glue code, glue abstract and proxy object
> -Yes, I’d like the option of 100% native development without being left
> behind with a last century GUI API
>
>
>
> Can someone put that poll, or at least a link to it, on the front page of
> qt-project.org?
>

[l***@nokia.com]

On 4/22/12 9:14 AM, "ext d3fault" <***@gmail.com> wrote:

>Yes, it is strongly biased due to the wording. Fix the wording and post
>it anyways. The numbers will not change.
>
>I got bored and drew a pretty picture to summarize my feelings for QML:
>http://bayimg.com/jaooAAaDC
>
>Hope you laugh.
>
>But back to being serious. How can anybody in the QML camp argue against
>this: Modern, Hardware Accelerated GUI Defining/Declaring/Creation does
>not require QML/JS Interpreter/Virtual Machine.
>
>
>It's like these genius' (QML/QtQuick is still brilliant) got so caught up
>with what they were working on that they forgot the big picture: Hardware
>Accelerated C++ GUI. Forcing the use of a declarative language, a JS
>Interpreter, and a virtual machine just makes most of us want to stab
>ourselves in the eye out of principle (our principles differ from yours).

And who says that 100% of the code has to be C++? I bet you are also
happily using Perl/python where it makes sense. .ui files in Qt 4.x are
XML, yet nobody complains about these.

Qt is about finding pragmatic solutions to problems. Yes it comes from a
C++ heritage, but I don't see why we should limit ourselves to purely C++
if we can create better solutions to the problem.

This complaining sounds a bit like all the C++ purists that think Qt is
bad because it includes a code generator (moc) for signals/slots and
properties. Yet they all happily use tools like flex and bison and don't
write their parsers by hand.

>To quote Lars,
>
>We want to make the usage of Javascript supported as well as C++ is
>supported. We are not making it the superior way or even the only way.
>
>
>...except that the javascript way currently is the superior way. If you
>want a hardware accelerated UI (without hacking together your own...
>defeating the purpose of using a UI toolkit), you are forced to use
>javascript (QML).

No, you should be using QML. That doesn't imply that you have to write any
application logic in Javascript. As I said, use it as a better .ui
language. You can still do all your app logic in C++ if you so want.

When you ask for simply exposing all a C++ API to all QML items, you're
missing a point. QML is a language that include states&transitions and a
binding engine. The binding engine works on arbitrary expressions and
needs some backend to evaluate these. That backend happens to be V8.

I don't see a problem with that. You're also not complaining that we have
PCRE as a backend to implement regular expressions.

We are already exposing most of the the C++ APIs that make sense for
application developers to use. Simply exposing the C++ interface of all
QML elements won't buy you anything, as the most important feature of Qt
Quick (bindings) still can't be handled that way.

There's zero value in exposing the C++ class that implements the QML
Rectangle element. There's nothing you can really do with it anyway. If
you need to create your own QML elements in C++ we have QQuickItem and
QQuickPaintedItem, which form a very good and solid basis.

And as others already pointed out, we need to be careful as to what we
expose in C++. Any API we add comes at a large cost (that you probably do
not see) in terms of maintenance and limitations to what we can change
because of binary compatibility.

Cheers,
Lars

>
>
>d3fault
>
>On Fri, Apr 20, 2012 at 3:59 PM, <marius.storm-***@nokia.com> wrote:
>
>That's a strongly biased poll due to the wording. And it's missing the
>points the Lars has been trying convey, but some seem to ignore.
>
>--
>Sent from my Nokia N9On 4/20/12 17:31 ext d3fault wrote:
>*cough*
>
>http://qt-project.org/forums/viewthread/16465/
>
>
>Does Qt need a modern C++ GUI API?
>-No, I am perfectly happy with QML, JavaScript, interpreters, virtual
>machines, glue code, glue abstract and proxy object
>-Yes, I¹d like the option of 100% native development without being left
>behind with a last century GUI API
>
>
>
>Can someone put that poll, or at least a link to it, on the front page of
>qt-project.org <http://qt-project.org>?
>
>
>
>
>
>
>
>_______________________________________________
>Development mailing list
>***@qt-project.org
>http://lists.qt-project.org/mailman/listinfo/development

[Alan Alpert]

On Mon, 23 Apr 2012 17:35:02 ext ***@nokia.com wrote:
> On 4/22/12 9:14 AM, "ext d3fault" <***@gmail.com> wrote:
>
> >...
> ...
> >To quote Lars,
> >
> >We want to make the usage of Javascript supported as well as C++ is
> >supported. We are not making it the superior way or even the only way.
> >
> >
> >...except that the javascript way currently is the superior way. If you
> >want a hardware accelerated UI (without hacking together your own...
> >defeating the purpose of using a UI toolkit), you are forced to use
> >javascript (QML).
>
> No, you should be using QML. That doesn't imply that you have to write any
> application logic in Javascript. As I said, use it as a better .ui
> language. You can still do all your app logic in C++ if you so want.

I don't think Lars emphasized this enough, but QML is *not* JS. In fact, the JS engine is only used when you have non-trivial
bindings. The rule of thumb is that you have to really write code that looks like JS in order to have it interpreted by V8. So if
you use it the same way as a .ui file, the performance characteristics are almost the same too. For example:

Rectangle {
x: 10
y: 10
width: 10
height: 10
}

This is the level of functionality that UI files provided, and it didn't need JS. Well, it still doesn't. That QML code isn't
going to run anything through V8. The QML engine is smart enough to just assign the values and not bother using a JS interpreter.
You end up with a C++ object instantiated, and with some properties set, which is exactly what .ui files did. So if you compare
this to a .ui file, the only difference is that it is being compiled when you load the component instead of during the compile
phase. Oh, and it's easy enough to write by hand as well as with the visual designer.

I understand that run-time compilation is a concrete performance cost for a static UI, and we're looking into ways of storing the
compiled output so that you can just load bytecode to initialize objects (for the same performance characteristics as a .ui file).
But so far our performance metrics show that the compile time is minuscule for QML applications and so it's not high enough on our
priority list for what to optimize. Patches are welcome though :) .

> When you ask for simply exposing all a C++ API to all QML items, you're
> missing a point. QML is a language that include states&transitions and a
> binding engine. The binding engine works on arbitrary expressions and
> needs some backend to evaluate these. That backend happens to be V8.
>
> I don't see a problem with that. You're also not complaining that we have
> PCRE as a backend to implement regular expressions.
>
> We are already exposing most of the the C++ APIs that make sense for
> application developers to use. Simply exposing the C++ interface of all
> QML elements won't buy you anything, as the most important feature of Qt
> Quick (bindings) still can't be handled that way.
>
> There's zero value in exposing the C++ class that implements the QML
> Rectangle element. There's nothing you can really do with it anyway. If
> you need to create your own QML elements in C++ we have QQuickItem and
> QQuickPaintedItem, which form a very good and solid basis.
>
> And as others already pointed out, we need to be careful as to what we
> expose in C++. Any API we add comes at a large cost (that you probably do
> not see) in terms of maintenance and limitations to what we can change
> because of binary compatibility.

I can see the non-zero value in exposing the Rectangle element. It's pretty much equivalent to QGraphicsRectItem then. I don't
know about you, but I didn't find QGraphicsRectItem very useful at all. In a C++ graphics scene, it wasn't worth the bother to
compose images out of multiple QGraphicsRectItems. That approach was cumbersome and inflexible compared to implementing your own
QGraphicsItem and just painting a rectangle in paint(). Note that with QQuickPaintedItem, you can do the exact same thing with
scenegraph today (well, on the day Qt5 is released ;) ) just take your QPainter* and go to town. Or use QQuickItem and paint it
using scenegraph or GL directly, to truly get the sort of hardware acceleration and speed that requires custom C++ code. (NB:
after writing your super-fast C++ native object you can then use QML to instantiate it and set initial properties, if that appeals
to you.)

This is one of the main reasons we aren't exposing the elements to C++. The value for providing these elements in C++, compared to
you doing your own painting in C++, is very ill defined. It's not zero, but there is a large cost in the limitations we have when
we make an API public. Remember that if we change it to expose the C++ API, at even the tiniest expense of the QML API, the C++
haters will come crawling out of the woodwork with unbridled rage. So exposing it to C++ directly provides a very large cost for
very little gain (that I can see). We shouldn't expose it to C++ until we have a good and highly useful C++ API at minimal cost to
the QML API, otherwise we'll not be able to release such an API until Qt 6. I don't know if I'll live that long.

Consider also the current "C++ API" for QtQuick. You can create any QtQuick component in C++ and position it with code like the
following (exercise for the reader, write the equivalent code for QGraphicsView and compare):

QQuickCanvas canvas;
QQmlEngine engine;
QQmlComponent component(&engine);
component.setData("import QtQuick 2.0; Rectangle{}");
QQuickItem* item = qobject_cast<QQuickItem*>(component.createObject());
item->setX(10);
item->setY(10);
item->setWidth(10);
item->setHeight(10);
item->setParent(canvas);
canvas.show();

I think that code is pretty bad. The only material difference to the above ugly code that we'd get by exposing the C++ API as it
stands would be to replace the three component lines with QQuickRectangle* item = new QQuickRectangle; I really don't think that's
good enough to compete even with a stagnating QGraphicsView - which is still available (and can be maintained if anyone really
wants that, as defined by providing patches). Since we have QGV still, it also doesn't make sense to just copy it.

Honestly, I think that
component.setData("import QtQuick 2.0; Rectangle{ border.color: 'green'; color: 'fuchsia'; width: 120; height: 120;}");
is already a little nicer than the QGV equivalent of
rectangle->setPen(QPen(Qt::green)); rectangle->setBrush(QBrush(QColor("fuchsia"))); rectangle->setGeometry(0,0,120,120);
Especially if you're going to have it all on one line like I do ;). I'm not a paragon of coding style though, and that's a highly
subjective point.

The real point is: Is it such a C++ API really that valuable? Do you want a C++ API just like QGraphicsView? If so, why aren't you
happy with QGraphicsView? If not, perhaps you can help us find the perfect C++ API for QtQuick so that we can finally expose it?

--
Alan Alpert
Senior Engineer
Nokia, Qt Development Frameworks

[d3fault]

Ivan Cukic ( http://qt-project.org/forums/viewthread/16465/P15 ):

> (just pulled the last quote regarding C++ and UIs, not replying to that
> post)
>
>> C++ is very capable of creating UIs in a declarative way, it is just that
>> QWidgets are not implemented with that kind of API. One could create an
>> API that would allow this to be a valid C++ code:
>>
>> 1. window (
>> 2. name = "winMain",
>> 3. button (
>> 4. name = "buttonBig",
>> 5. size = parent.size,
>> 6. title = "Click me!",
>> 7. onClicked = something
>> 8. )
>> 9. )
>>
>>
I agree that it's not a wise idea to expose directly the QtQuick back-end.
What we want instead is a C++ front-end to interface with it (like above).
If you look at the above code that Ivan posted, it looks incredibly similar
to QML.

And who says that 100% of the code has to be C++? I bet you are also
> happily using Perl/python where it makes sense. .ui files in Qt 4.x are
> XML, yet nobody complains about these.
>

.ui files don't require a JS Interpreter/VM to load

This complaining sounds a bit like all the C++ purists that think Qt is bad
> because it includes a code generator (moc) for signals/slots and
> properties. Yet they all happily use tools like flex and bison and don't
> write their parsers by hand.
>

A minimalist purist would be more like it. Minimal not meaning I want to
write everything in binary/assembly (or write my owner parsers -_-)... but
minimal in that I want to write the least amount of code for the most
amount of functionality. Additionally, I want to ship my software with the
minimum amount of support packages. I don't deem a JS Interpreter/VM to be
necessary. Think of all the Windows developers that now have to include v8
in every application they distribute. Sure, on a real OS there are system
libraries... but Windows developers (a huge part of Qt users) typically
have to ship the Qt libs (and now v8) with every app they release.

I love MOC because it is done at the pre-compiling stage. I would
absolutely hate MOC if it had to be run every time a user wanted to run my
app.

You're also not complaining that we have PCRE as a backend to implement
> regular expressions.
>

The difference being you aren't forced into using the PCRE just for basic
(modern) GUI functionality (regardless of whether you even use Regular
Expressions). If I don't write my logic in javascript (which I won't), I
still have to ship a javascript interpreter. PCRE is opt-in.


I don't think Lars emphasized this enough, but QML is *not* JS. In fact,
> the JS engine is only used when you have non-trivial bindings. The rule of
> thumb is that you have to really write code that looks like JS in order to
> have it interpreted by V8. So if you use it the same way as a .ui file, the
> performance characteristics are almost the same too. For example:
>
> Rectangle {
> x: 10
> y: 10
> width: 10
> height: 10
> }
>
> This is the level of functionality that UI files provided, and it didn't
> need JS. Well, it still doesn't. That QML code isn't
> going to run anything through V8. The QML engine is smart enough to just
> assign the values and not bother using a JS interpreter.
> You end up with a C++ object instantiated, and with some properties set,
> which is exactly what .ui files did. So if you compare
> this to a .ui file, the only difference is that it is being compiled when
> you load the component instead of during the compile
> phase. Oh, and it's easy enough to write by hand as well as with the
> visual designer.
>
> I understand that run-time compilation is a concrete performance cost for
> a static UI, and we're looking into ways of storing the
> compiled output so that you can just load bytecode to initialize objects
> (for the same performance characteristics as a .ui file).
> But so far our performance metrics show that the compile time is minuscule
> for QML applications and so it's not high enough on our
> priority list for what to optimize. Patches are welcome though :) .
>

It doesn't go through v8? Cool, so why are we forced to use/ship v8
(Rhetorical. I know why: it's for the few who write their app logic in JS
-_-)? Your last paragraph peaked my interest. It would be a good compromise
and would get me to shut up. I would be happy with QML if it was only used
during the pre-compile/compile stage (move the js interpreter into the
toolchain lol idgaf). For all those who want to write their logic in js
(grossssss), maybe have a QT += jsinterpreter option. Your performance
metrics don't indicate a significant value, but they probably don't take
into consideration costs such as added library size (mostly affects windows
developers) or memory consumption. The 'concrete performance cost' of
run-time compilation is unnecessary in principle (regardless of how
insignificant it is)... which is why we don't want it.

Yes yes, tons of work... tons of maintenance... I get that. But it's better
I bitch now than later (after more code has been written).

tl;dr:
QML-like C++ Front-End to QtQuick (like Ivan described)
OR
Pre-Compile QML and only ship bytecode in binary for QtQuick use
plox

d3fault


On Mon, Apr 23, 2012 at 1:59 AM, Alan Alpert <***@nokia.com> wrote:

> On Mon, 23 Apr 2012 17:35:02 ext ***@nokia.com wrote:
> > On 4/22/12 9:14 AM, "ext d3fault" <***@gmail.com> wrote:
> >
> > >...
> > ...
> > >To quote Lars,
> > >
> > >We want to make the usage of Javascript supported as well as C++ is
> > >supported. We are not making it the superior way or even the only way.
> > >
> > >
> > >...except that the javascript way currently is the superior way. If you
> > >want a hardware accelerated UI (without hacking together your own...
> > >defeating the purpose of using a UI toolkit), you are forced to use
> > >javascript (QML).
> >
> > No, you should be using QML. That doesn't imply that you have to write
> any
> > application logic in Javascript. As I said, use it as a better .ui
> > language. You can still do all your app logic in C++ if you so want.
>
> I don't think Lars emphasized this enough, but QML is *not* JS. In fact,
> the JS engine is only used when you have non-trivial
> bindings. The rule of thumb is that you have to really write code that
> looks like JS in order to have it interpreted by V8. So if
> you use it the same way as a .ui file, the performance characteristics are
> almost the same too. For example:
>
> Rectangle {
> x: 10
> y: 10
> width: 10
> height: 10
> }
>
> This is the level of functionality that UI files provided, and it didn't
> need JS. Well, it still doesn't. That QML code isn't
> going to run anything through V8. The QML engine is smart enough to just
> assign the values and not bother using a JS interpreter.
> You end up with a C++ object instantiated, and with some properties set,
> which is exactly what .ui files did. So if you compare
> this to a .ui file, the only difference is that it is being compiled when
> you load the component instead of during the compile
> phase. Oh, and it's easy enough to write by hand as well as with the
> visual designer.
>
> I understand that run-time compilation is a concrete performance cost for
> a static UI, and we're looking into ways of storing the
> compiled output so that you can just load bytecode to initialize objects
> (for the same performance characteristics as a .ui file).
> But so far our performance metrics show that the compile time is minuscule
> for QML applications and so it's not high enough on our
> priority list for what to optimize. Patches are welcome though :) .
>
> > When you ask for simply exposing all a C++ API to all QML items, you're
> > missing a point. QML is a language that include states&transitions and a
> > binding engine. The binding engine works on arbitrary expressions and
> > needs some backend to evaluate these. That backend happens to be V8.
> >
> > I don't see a problem with that. You're also not complaining that we have
> > PCRE as a backend to implement regular expressions.
> >
> > We are already exposing most of the the C++ APIs that make sense for
> > application developers to use. Simply exposing the C++ interface of all
> > QML elements won't buy you anything, as the most important feature of Qt
> > Quick (bindings) still can't be handled that way.
> >
> > There's zero value in exposing the C++ class that implements the QML
> > Rectangle element. There's nothing you can really do with it anyway. If
> > you need to create your own QML elements in C++ we have QQuickItem and
> > QQuickPaintedItem, which form a very good and solid basis.
> >
> > And as others already pointed out, we need to be careful as to what we
> > expose in C++. Any API we add comes at a large cost (that you probably do
> > not see) in terms of maintenance and limitations to what we can change
> > because of binary compatibility.
>
> I can see the non-zero value in exposing the Rectangle element. It's
> pretty much equivalent to QGraphicsRectItem then. I don't
> know about you, but I didn't find QGraphicsRectItem very useful at all. In
> a C++ graphics scene, it wasn't worth the bother to
> compose images out of multiple QGraphicsRectItems. That approach was
> cumbersome and inflexible compared to implementing your own
> QGraphicsItem and just painting a rectangle in paint(). Note that with
> QQuickPaintedItem, you can do the exact same thing with
> scenegraph today (well, on the day Qt5 is released ;) ) just take your
> QPainter* and go to town. Or use QQuickItem and paint it
> using scenegraph or GL directly, to truly get the sort of hardware
> acceleration and speed that requires custom C++ code. (NB:
> after writing your super-fast C++ native object you can then use QML to
> instantiate it and set initial properties, if that appeals
> to you.)
>
> This is one of the main reasons we aren't exposing the elements to C++.
> The value for providing these elements in C++, compared to
> you doing your own painting in C++, is very ill defined. It's not zero,
> but there is a large cost in the limitations we have when
> we make an API public. Remember that if we change it to expose the C++
> API, at even the tiniest expense of the QML API, the C++
> haters will come crawling out of the woodwork with unbridled rage. So
> exposing it to C++ directly provides a very large cost for
> very little gain (that I can see). We shouldn't expose it to C++ until we
> have a good and highly useful C++ API at minimal cost to
> the QML API, otherwise we'll not be able to release such an API until Qt
> 6. I don't know if I'll live that long.
>
> Consider also the current "C++ API" for QtQuick. You can create any
> QtQuick component in C++ and position it with code like the
> following (exercise for the reader, write the equivalent code for
> QGraphicsView and compare):
>
> QQuickCanvas canvas;
> QQmlEngine engine;
> QQmlComponent component(&engine);
> component.setData("import QtQuick 2.0; Rectangle{}");
> QQuickItem* item = qobject_cast<QQuickItem*>(component.createObject());
> item->setX(10);
> item->setY(10);
> item->setWidth(10);
> item->setHeight(10);
> item->setParent(canvas);
> canvas.show();
>
> I think that code is pretty bad. The only material difference to the above
> ugly code that we'd get by exposing the C++ API as it
> stands would be to replace the three component lines with QQuickRectangle*
> item = new QQuickRectangle; I really don't think that's
> good enough to compete even with a stagnating QGraphicsView - which is
> still available (and can be maintained if anyone really
> wants that, as defined by providing patches). Since we have QGV still, it
> also doesn't make sense to just copy it.
>
> Honestly, I think that
> component.setData("import QtQuick 2.0; Rectangle{ border.color: 'green';
> color: 'fuchsia'; width: 120; height: 120;}");
> is already a little nicer than the QGV equivalent of
> rectangle->setPen(QPen(Qt::green));
> rectangle->setBrush(QBrush(QColor("fuchsia")));
> rectangle->setGeometry(0,0,120,120);
> Especially if you're going to have it all on one line like I do ;). I'm
> not a paragon of coding style though, and that's a highly
> subjective point.
>
> The real point is: Is it such a C++ API really that valuable? Do you want
> a C++ API just like QGraphicsView? If so, why aren't you
> happy with QGraphicsView? If not, perhaps you can help us find the perfect
> C++ API for QtQuick so that we can finally expose it?
>
> --
> Alan Alpert
> Senior Engineer
> Nokia, Qt Development Frameworks
>

[a***@nokia.com]

>From: development-bounces+alan.alpert=***@qt-project.org [development->bounces+alan.alpert=***@qt-project.org] on behalf of ext d3fault [***@gmail.com]
> Sent: Monday, April 23, 2012 9:33 PM
> To: ***@qt-project.org
> Subject: Re: [Development] The place of QML
>
>
>I don't think Lars emphasized this enough, but QML is *not* JS. In fact, the JS engine is only used when you have >non-trivial bindings. The rule of thumb is that you have to really write code that looks like JS in order to have it >interpreted by V8. So if
>you use it the same way as a .ui file, the performance characteristics are almost the same too. For example:
>
>
>
>Rectangle {
> x: 10
> y: 10
> width: 10
> height: 10
>}
>
>This is the level of functionality that UI files provided, and it didn't need JS. Well, it still doesn't. That QML code >isn't going to run anything through V8. The QML engine is smart enough to just assign the values and not >bother using a JS interpreter. You end up with a C++ object instantiated, and with some properties set, which is >exactly what .ui files did. So if you compare this to a .ui file, the only difference is that it is being compiled when >you load the component instead of during the compile phase. Oh, and it's easy enough to write by hand as well >as with the visual designer.
>
>I understand that run-time compilation is a concrete performance cost for a static UI, and we're looking into >ways of storing the compiled output so that you can just load bytecode to initialize objects (for the same >performance characteristics as a .ui file). But so far our performance metrics show that the compile time is >minuscule for QML applications and so it's not high enough on our priority list for what to optimize. Patches are >welcome though :) .
>
>It doesn't go through v8? Cool, so why are we forced to use/ship v8 (Rhetorical. I know why: it's for the few who >write their app logic in JS -_-)? Your last paragraph peaked my interest. It would be a good compromise and >would get me to shut up. I would be
> happy with QML if it was only used during the pre-compile/compile stage (move the js interpreter into the >toolchain lol idgaf). For all those who want to write their logic in js (grossssss), maybe have a QT += >jsinterpreter option. Your performance metrics
> don't indicate a significant value, but they probably don't take into consideration costs such as added library >size (mostly affects windows developers) or memory consumption. The 'concrete performance cost' of run-time >compilation is unnecessary in principle
> (regardless of how insignificant it is)... which is why we don't want it.


Your 'rhetorical' question is actually a valid one that has a better answer than you provided. In fact, you probably shouldn't be forced to use V8 if you don't use it. Your gripe isn't with the QML language, it's with our current implementation - which is in continuous development despite already being highly useful.

I can see it as a viable future direction that you can run QML with v8 disabled. You wouldn't even need to link against V8, and any binding which would require V8 to evaluate it produces a compile time error instead. Add that feature to the separate compiler so you can compile QML in the compile phase, and just pass bytecode to your QmlComponent, and then you've pretty much got everything you wanted, plus QML. Which I know you'll all learn to love ;) .

The thing with limited resources is that we don't have time to implement those features right now (they're a lot of work). And for us they are not a priority, so at the very least I don't see my time being allocated to implementing this any time soon. A key point in meritocratic governance structures is that resource allocation can define timetabling, so if you submitted the patches soon then I could see this feature getting into Qt 5.1 (assuming the patches get through the peer-review process of course). Summary: "I look forward to your patch :) ".

>Yes yes, tons of work... tons of maintenance... I get that. But it's better I bitch now than later (after more code >has been written).

I'm not sure that bitching is ever the 'better' option... and if you don't think it's worth your time, why is it worth mine?

>tl;dr:
>
>QML-like C++ Front-End to QtQuick (like Ivan described)

I should probably look at that actual thread, but I have no idea how a C++ API could produce the binding for parent.size - unless we make moc insert a JS VM for runtime processing ;) .

--
Alan Alpert
Senior Engineer
Nokia, Qt Development Frameworks

[Shawn Rutledge]

On Monday, April 23, 2012 06:59:26 PM ext Alan Alpert wrote:
> On Mon, 23 Apr 2012 17:35:02 ext ***@nokia.com wrote:
> > On 4/22/12 9:14 AM, "ext d3fault" <***@gmail.com> wrote:
> > >...
> >
> > ...
> >
> > >To quote Lars,
> > >
> > >We want to make the usage of Javascript supported as well as C++ is
> > >supported. We are not making it the superior way or even the only way.
> > >
> > >
> > >...except that the javascript way currently is the superior way. If you
> > >want a hardware accelerated UI (without hacking together your own...
> > >defeating the purpose of using a UI toolkit), you are forced to use
> > >javascript (QML).
> >
> > No, you should be using QML. That doesn't imply that you have to write any
> > application logic in Javascript. As I said, use it as a better .ui
> > language. You can still do all your app logic in C++ if you so want.
>
> I don't think Lars emphasized this enough, but QML is *not* JS. In fact, the
> JS engine is only used when you have non-trivial bindings. The rule of
> thumb is that you have to really write code that looks like JS in order to
> have it interpreted by V8. So if you use it the same way as a .ui file, the
> performance characteristics are almost the same too. For example:
>
> Rectangle {
> x: 10
> y: 10
> width: 10
> height: 10
> }
>
> This is the level of functionality that UI files provided, and it didn't
> need JS. Well, it still doesn't. That QML code isn't going to run anything
> through V8. The QML engine is smart enough to just assign the values and
> not bother using a JS interpreter. You end up with a C++ object
> instantiated, and with some properties set, which is exactly what .ui files
> did. So if you compare this to a .ui file, the only difference is that it
> is being compiled when you load the component instead of during the compile
> phase. Oh, and it's easy enough to write by hand as well as with the visual
> designer.

Well then it should be possible to write qmlc (like uic), to generate the C++
code which will build the UI, so that it's possible to benefit from the
terseness of the QML syntax but build an app which does not depend on runtime
parsing or interpreted JS. I don't think the majority of real-world Qt4 apps
are loading their UI files at runtime, so it's kindof an unequal comparison;
the main point of Designer was to avoid having to write tedious GUI code by
hand, not to eliminate it from existing or to be required to parse UIs at
runtime.

But can non-constant bindings be evaluated without v8 being involved? e.g.
width: parent.width - 20

It's also nice to be able to continue to think of one application as one file
so that installation is easy. (Usually there is a user conf file, but the app
can create that on the first run.) On MacOS there are app packages; on Linux
though, if an app is distributed as a binary plus some QML plus a bunch of
graphics, you can't just stick it in /usr/bin like you can a normal binary
app. So the installation is messy. Every app might need its own directory
under /opt, or else the app can load the QML etc. from compiled-in resources;
but if that's to be the preferred way, it should be the default way of
packaging an app. Creator and qmake should make it easier to compile-in all
the resources than not.

BTW GTK has also gone down an unfortunate path, that if you design a UI file
in Glade you must parse the XML at runtime; there is no longer a code
generator. This they say is only because there is no Glade developer who
wants to maintain such a thing anymore. So Gnome apps tend to create the same
sort of mess consisting of at least one or more ui files, a binary, icons, and
a desktop file, to be installed in "standard" places which are spread across
the filesystem. If the future really has to be like that, somebody should at
least invent a way to have packages like MacOS has, so that there is again a
possibility of zero-installation. (And on the flip side, maybe there could be
pure QML/JS apps which "just run" without needing a customized binary, due to
being packaged in such a way that the system knows to run qmlscene on the
"main qml".)

But if QML code was just used to generate parts of the binary, that would be
both more efficient and simpler, like desktop apps have always been until
recently; and easier to achieve than getting distros to agree on an OSX-like
package format.

--
MVH, Shawn Rutledge ❖ "ecloud" on IRC

[Girish Ramakrishnan]

Hi Shawn,

On Mon, Apr 23, 2012 at 3:13 PM, Shawn Rutledge
<***@nokia.com> wrote:
>
> But can non-constant bindings be evaluated without v8 being involved? e.g.
> width: parent.width - 20
>

Yes, no v8 involved. I believe it's done our own js evaluator "v4"
(src/qml/qml/v4). See Chris Adams excellent new documentation in
13af00d.

Girish

[Girish Ramakrishnan]

Hi Alan and Lars,

On Mon, Apr 23, 2012 at 10:59 AM, Alan Alpert <***@nokia.com> wrote:
>> And as others already pointed out, we need to be careful as to what we
>> expose in C++. Any API we add comes at a large cost (that you probably do
>> not see) in terms of maintenance and limitations to what we can change
>> because of binary compatibility.
>
> I can see the non-zero value in exposing the Rectangle element. It's pretty much equivalent to QGraphicsRectItem then. I don't
> know about you, but I didn't find QGraphicsRectItem very useful at all. In a C++ graphics scene, it wasn't worth the bother to
> compose images out of multiple QGraphicsRectItems. That approach was cumbersome and inflexible compared to implementing your own
> QGraphicsItem and just painting a rectangle in paint(). Note that with QQuickPaintedItem, you can do the exact same thing with
> scenegraph today (well, on the day Qt5 is released ;) ) just take your QPainter* and go to town. Or use QQuickItem and paint it
> using scenegraph or GL directly, to truly get the sort of hardware acceleration and speed that requires custom C++ code. (NB:
> after writing your super-fast C++ native object you can then use QML to instantiate it and set initial properties, if that appeals
> to you.)
>

Rectangle is not the best example. Exposing any non-trivial QML
element through C++ code is a huge benefit. For example, it would have
been very useful to have the C++ of WebView public so that I can
expose new properties in QML - just see C++ QWebView and QML WebView
for the disparity. Currently, one has to fork the WebView private
implementation which is not nice at all. Another example - adding
wheel event support to our MouseArea.

I do think we should evaluate exposing the QML implementations to C++ for 5.1.

Girish

[Donald Carr]

Hey Girish,

On Mon, Apr 23, 2012 at 9:04 AM, Girish Ramakrishnan
<***@forwardbias.in> wrote:
> On Mon, Apr 23, 2012 at 10:59 AM, Alan Alpert <***@nokia.com> wrote:
>>> And as others already pointed out, we need to be careful as to what we
>>> expose in C++. Any API we add comes at a large cost (that you probably do
>>> not see) in terms of maintenance and limitations to what we can change
>>> because of binary compatibility.
>>
>> I can see the non-zero value in exposing the Rectangle element. It's pretty much equivalent to QGraphicsRectItem then. I don't
>> know about you, but I didn't find QGraphicsRectItem very useful at all. In a C++ graphics scene, it wasn't worth the bother to
>> compose images out of multiple QGraphicsRectItems. That approach was cumbersome and inflexible compared to implementing your own
>> QGraphicsItem and just painting a rectangle in paint(). Note that with QQuickPaintedItem, you can do the exact same thing with
>> scenegraph today (well, on the day Qt5 is released ;) ) just take your QPainter* and go to town. Or use QQuickItem and paint it
>> using scenegraph or GL directly, to truly get the sort of hardware acceleration and speed that requires custom C++ code. (NB:
>> after writing your super-fast C++ native object you can then use QML to instantiate it and set initial properties, if that appeals
>> to you.)
>>
>
> Rectangle is not the best example. Exposing any non-trivial QML
> element through C++ code is a huge benefit. For example, it would have
> been very useful to have the C++ of WebView public so that I can
> expose new properties in QML - just see C++ QWebView and QML WebView
> for the disparity. Currently, one has to fork the WebView private
> implementation which is not nice at all. Another example - adding
> wheel event support to our MouseArea.

Rectangle is a perfect example for people who stand against QML on
principle alone. The idea of a QGraphicsView style API for scenegraph
is certainly the most vocal request from the peanut gallery. Your
request involves extending existing functionality, the peanut gallery
requests duplicating existing functionality so that it can accessed
without them sullying their hands with something other than c++ or
with _any_ runtime cost. Given the resourcing constraints that exist
in any project, where do you want the effort expended? You know we
refuse to be beholden to a C++ API for scenegraph, if people want a
fixed C++ API they have to suggest/drive/implement one themselves
which in turn relies on privates internals we reserve the right to
stomp all over as need be.

Anyone who wrote their app UI in QML1 just got a (free!) rocket
inserted in their tail pipe and a license to pop a perpetual wheelie
with Qt 5; contrast this to PSO's unspoken role in Qt 4 which was to
frog march people through the Indiana Jonesque landscape of spikes,
pits and reptiles that were the API calls required to get
QGraphicsWebView occupying the whole screen and painting optimally. I
am personally relieved our graphics team can perform major overhauls
without cutting all of our customers/users in the process.

True, when using QML 1 there was a necessary leap of faith that QML 2
was not going to be a complete rewrite, but we landed it and
maintained a compelling degree of QML source compatibility while
changing out the entire JS backend and rendering stack. (I did the sed
work required to migrate a chunky codebase from a QML 1 to QML 2, has
anyone here actually had a rough time of migrating from QtQuick 1.* to
QtQuick 2.0)

> I do think we should evaluate exposing the QML implementations to C++ for 5.1.

I think a better question would be; What existing evaluations exist?
And outside of the people seeking a contractual C++ API to scenegraph,
what evident extensibility/functionality issues exist in QML today?

Cheers,
Donald

--
-------------------------------
 °v°  Donald Carr
/(_)\ Vaguely Professional Penguin lover
 ^ ^

Cave canem, te necet lingendo
Chasing my own tail; hate to see me leave, love to watch me go

[Girish Ramakrishnan]

Hi Donald,

On Mon, Apr 23, 2012 at 5:26 PM, Donald Carr <***@gmail.com> wrote:
> Hey Girish,
>
> On Mon, Apr 23, 2012 at 9:04 AM, Girish Ramakrishnan
> <***@forwardbias.in> wrote:
>> On Mon, Apr 23, 2012 at 10:59 AM, Alan Alpert <***@nokia.com> wrote:
>>>> And as others already pointed out, we need to be careful as to what we
>>>> expose in C++. Any API we add comes at a large cost (that you probably do
>>>> not see) in terms of maintenance and limitations to what we can change
>>>> because of binary compatibility.
>>>
>>> I can see the non-zero value in exposing the Rectangle element. It's pretty much equivalent to QGraphicsRectItem then. I don't
>>> know about you, but I didn't find QGraphicsRectItem very useful at all. In a C++ graphics scene, it wasn't worth the bother to
>>> compose images out of multiple QGraphicsRectItems. That approach was cumbersome and inflexible compared to implementing your own
>>> QGraphicsItem and just painting a rectangle in paint(). Note that with QQuickPaintedItem, you can do the exact same thing with
>>> scenegraph today (well, on the day Qt5 is released ;) ) just take your QPainter* and go to town. Or use QQuickItem and paint it
>>> using scenegraph or GL directly, to truly get the sort of hardware acceleration and speed that requires custom C++ code. (NB:
>>> after writing your super-fast C++ native object you can then use QML to instantiate it and set initial properties, if that appeals
>>> to you.)
>>>
>>
>> Rectangle is not the best example. Exposing any non-trivial QML
>> element through C++ code is a huge benefit. For example, it would have
>> been very useful to have the C++ of WebView public so that I can
>> expose new properties in QML - just see C++ QWebView and QML WebView
>> for the disparity. Currently, one has to fork the WebView private
>> implementation which is not nice at all. Another example - adding
>> wheel event support to our MouseArea.
>
> Rectangle is a perfect example for people who stand against QML on
> principle alone. The idea of a QGraphicsView style API for scenegraph
> is certainly the most vocal request from the peanut gallery. Your

I probably removed too much context in my reply. I was specifically
replying to Lars comment below and alan's reply to that:
"We are already exposing most of the the C++ APIs that make sense for
application developers to use. Simply exposing the C++ interface of all
QML elements won't buy you anything, as the most important feature of Qt
Quick (bindings) still can't be handled that way.

There's zero value in exposing the C++ class that implements the QML
Rectangle element. There's nothing you can really do with it anyway. If
you need to create your own QML elements in C++ we have QQuickItem and
QQuickPaintedItem, which form a very good and solid basis."

My reply was certainly not about adding C++ apis equivalents for
scenegraph and C++ bindings apis and what not :)

>> I do think we should evaluate exposing the QML implementations to C++ for 5.1.
>
> I think a better question would be; What existing evaluations exist?
> And outside of the people seeking a contractual C++ API to scenegraph,
> what evident extensibility/functionality issues exist in QML today?
>

My point above is an extensibility issue with our current QML
offering. You cannot extend any existing QML element in C++. You have
to start from scratch. We basically mark all existing QML items as
'final' for C++ use.

Girish

[a***@nokia.com]

>From: ext Girish Ramakrishnan [***@forwardbias.in]
>Sent: Tuesday, April 24, 2012 12:50 PM
>To: Donald Carr
>Cc: Alpert Alan (Nokia-MP/Brisbane); ***@qt-project.org
>Subject: Re: [Development] The place of QML
>>> I do think we should evaluate exposing the QML implementations to C++ for 5.1.
>>
>> I think a better question would be; What existing evaluations exist?
>> And outside of the people seeking a contractual C++ API to scenegraph,
>> what evident extensibility/functionality issues exist in QML today?
>>
>
>My point above is an extensibility issue with our current QML
>offering. You cannot extend any existing QML element in C++. You have
>to start from scratch. We basically mark all existing QML items as
>'final' for C++ use.

I get your point, but exposing the existing C++ APIs is not the answer. I recently tried to write my own QML code editor, which basically meant re-implementing TextEdit. It was not fun. That time I had the option to use private headers if I wanted too, but the current QQuickTextEdit API was just not helpful. I compared it to QTextEdit, which could be easily extended to do what I wanted (all I wanted was syntax highlighting), and the difference was some specific API which QTextEdit has and QQuickTextEdit doesn't. The point being, that the extensibility issue isn't really C++ vs QML. It's the subtly different question of extending the APIs (and thus the maintenance burden and implementation restrictions).

Back to the QTextEdit example: I put a concept up on codereview to share with someone, https://codereview.qt-project.org/#change,23617 , which added the necessary API - but to QML. This allowed me to extend TextEdit in QML just fine, and I could have done it in C++ if I was so inclined. This was purely a question of what API was exposed. For those interested in the implications of how that patch would be used, in my case I created a custom QSyntaxHighlighter in C++ and then exposed it to QML so I could do syntaxHighlighter:MySyntaxHighlighter{}; . Doing something similar with the QTextDocument might be the solution for rich text editing in QML (but I don't think so - that's a separate discussion anyways ;) ).

--
Alan Alpert

[Girish Ramakrishnan]

Hi Alan,

On Wed, Apr 25, 2012 at 6:16 AM, <***@nokia.com> wrote:
>>From: ext Girish Ramakrishnan [***@forwardbias.in]
>>Sent: Tuesday, April 24, 2012 12:50 PM
>>To: Donald Carr
>>Cc: Alpert Alan (Nokia-MP/Brisbane); ***@qt-project.org
>>Subject: Re: [Development] The place of QML
>>>> I do think we should evaluate exposing the QML implementations to C++ for 5.1.
>>>
>>> I think a better question would be; What existing evaluations exist?
>>> And outside of the people seeking a contractual C++ API to scenegraph,
>>> what evident extensibility/functionality issues exist in QML today?
>>>
>>
>>My point above is an extensibility issue with our current QML
>>offering. You cannot extend any existing QML element in C++. You have
>>to start from scratch. We basically mark all existing QML items as
>>'final' for C++ use.
>
> I get your point, but exposing the existing C++ APIs is not the answer. I recently tried to write my own QML code editor, which basically meant re-implementing TextEdit. It was not fun. That time I had the option to use private headers if I wanted too, but the current QQuickTextEdit API was just not helpful. I compared it to QTextEdit, which could be easily extended to do what I wanted (all I wanted was syntax highlighting), and the difference was some specific API which QTextEdit has and QQuickTextEdit doesn't. The point being, that the extensibility issue isn't really C++ vs QML. It's the subtly different question of extending the APIs (and thus the maintenance burden and implementation restrictions).
>
> Back to the QTextEdit example: I put a concept up on codereview to share with someone, https://codereview.qt-project.org/#change,23617 , which added the necessary API - but to QML. This allowed me to extend TextEdit in QML just fine, and I could have done it in C++ if I was so inclined. This was purely a question of what API was exposed. For those interested in the implications of how that patch would be used, in my case I created a custom QSyntaxHighlighter in C++ and then exposed it to QML so I could do syntaxHighlighter:MySyntaxHighlighter{}; . Doing something similar with the QTextDocument might be the solution for rich text editing in QML (but I don't think so - that's a separate discussion anyways ;) ).
>

Isn't exposing the C++ code for QQuickTextEdit the solution to this
problem? IOW, qquicktextedit_p.h should become qquicktextedit.h. For
an end user, who wants to add the synyaxHighlighter property, he/she
would have to a lot of work if they didn't want to modify Qt. What's
the alternate solution?

As you point out, I do understand that the current Quick items have
not been implemented with reuse in mind but that's something that can
be solved case by case (rather, let's do this one class at a time).

Girish

[Alan Alpert]

On Wed, 25 Apr 2012 15:03:21 ext Girish Ramakrishnan wrote:
> Hi Alan,
>
> On Wed, Apr 25, 2012 at 6:16 AM, <***@nokia.com> wrote:
> >>From: ext Girish Ramakrishnan [***@forwardbias.in]
> >>Sent: Tuesday, April 24, 2012 12:50 PM
> >>To: Donald Carr
> >>Cc: Alpert Alan (Nokia-MP/Brisbane); ***@qt-project.org
> >>Subject: Re: [Development] The place of QML
> >>
> >>>> I do think we should evaluate exposing the QML implementations to C++
> >>>> for 5.1.
> >>>
> >>> I think a better question would be; What existing evaluations exist?
> >>> And outside of the people seeking a contractual C++ API to scenegraph,
> >>> what evident extensibility/functionality issues exist in QML today?
> >>
> >>My point above is an extensibility issue with our current QML
> >>offering. You cannot extend any existing QML element in C++. You have
> >>to start from scratch. We basically mark all existing QML items as
> >>'final' for C++ use.
> >>
> > I get your point, but exposing the existing C++ APIs is not the answer. I
> > recently tried to write my own QML code editor, which basically meant
> > re-implementing TextEdit. It was not fun. That time I had the option to
> > use private headers if I wanted too, but the current QQuickTextEdit API
> > was just not helpful. I compared it to QTextEdit, which could be easily
> > extended to do what I wanted (all I wanted was syntax highlighting), and
> > the difference was some specific API which QTextEdit has and
> > QQuickTextEdit doesn't. The point being, that the extensibility issue
> > isn't really C++ vs QML. It's the subtly different question of extending
> > the APIs (and thus the maintenance burden and implementation
> > restrictions).
> >
> > Back to the QTextEdit example: I put a concept up on codereview to share
> > with someone, https://codereview.qt-project.org/#change,23617 , which
> > added the necessary API - but to QML. This allowed me to extend TextEdit
> > in QML just fine, and I could have done it in C++ if I was so inclined.
> > This was purely a question of what API was exposed. For those interested
> > in the implications of how that patch would be used, in my case I
> > created a custom QSyntaxHighlighter in C++ and then exposed it to QML so
> > I could do syntaxHighlighter:MySyntaxHighlighter{}; . Doing something
> > similar with the QTextDocument might be the solution for rich text
> > editing in QML (but I don't think so - that's a separate discussion
> > anyways ;) ).
>
> Isn't exposing the C++ code for QQuickTextEdit the solution to this
> problem? IOW, qquicktextedit_p.h should become qquicktextedit.h. For
> an end user, who wants to add the synyaxHighlighter property, he/she
> would have to a lot of work if they didn't want to modify Qt. What's
> the alternate solution?

https://codereview.qt-project.org/#change,23617 would still require modifying
QQuickTextEdit, it can't be done in a subclass without modifying the
QQuickTextEdit API. So making qquicktextedit_p.h into qquicktextedit.h doesn't
help, you'll still want access to qquicktextedit_p.h (which was
qquicktextedit_p_p.h) and we have the same problem.

The alternate solution, as you point out next, is that we need to make the
APIs extensible case by case. One class at a time. This is the real solution,
simply making the C++ headers public gives us less than nothing.
Unfortunately, making them public requires little work now (just tons of work
later ;) ) and fixing all those individual cases requires tons of work now.
Hopefully we can make some more incremental improvements in QtQuick 2.1
though.

> As you point out, I do understand that the current Quick items have
> not been implemented with reuse in mind but that's something that can
> be solved case by case (rather, let's do this one class at a time).

--
Alan Alpert
Senior Engineer
Nokia, Qt Development Frameworks

[André Pönitz]

On Mon, Apr 23, 2012 at 07:35:02AM +0000, ***@nokia.com wrote:
> [...] And who says that 100% of the code has to be C++?

Nobody reasonably wants that. But people like to have a choice, and
different people will base their choice on different factors.

> I bet you are also happily using Perl/python where it makes sense. .ui
> files in Qt 4.x are XML, yet nobody complains about these.
>
> Qt is about finding pragmatic solutions to problems. Yes it comes from
> a C++ heritage, but I don't see why we should limit ourselves to
> purely C++ if we can create better solutions to the problem.
> [...] No, you should be using QML. [...]

A better language does not automatically translate into a better
solution. The currently envisioned use of QML as a hybrid (at edit
and(!) run time) severely impacts the choice of available tools
to handle ordinary tasks like editing, debugging, profiling, and
whatever else is typically needed to make an application fly.

With old .ui this was not much of a problem because (a) one could
not do much with it anyway i.e. could not get it wrong either, (b) it
had no runtime implications, no need for mixed debugging/profiling
(QUiLoader is not exactly popular), and (c) one could even opt for
not using it at all.

Now we suddenly have an easy to use, yet compulsory, Turing complete
language with essentially no support from off-the-shelf tools.

How are people supposed to handle that? Who is going to provide the
QML enabled substitutes to the emacs-visual studio-xcode-valgrind
-gdb-cdb-purify-doxygen-designer-whatever-tool-hotchpotch people are
happily using? What happens to people who cannot or do not want to
use substitutes? Who is going to support and maintain the substitutes?

Andre'

[Philip Ashmore]

Hi there.

I recently dived into Qml not long after playing around in html5/JavaScript.

I wanted to see what methods I could call in my QAbstractTableModel-derived
class - I wanted to know if Qml code could access headerData() for the
column
headers.

If you're looking for a place for Qml, I would suggest starting somewhere
near there.

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

[Philip Ashmore]

On 07/05/12 01:32, Philip Ashmore wrote:
> Hi there.
>
> I recently dived into Qml not long after playing around in html5/JavaScript.
>
> I wanted to see what methods I could call in my QAbstractTableModel-derived
> class - I wanted to know if Qml code could access headerData() for the
> column
> headers.
>
> If you're looking for a place for Qml, I would suggest starting somewhere
> near there.
>
> 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
Given the lack of comment I'll try to rephrase this.

If I could debug a Qml application the same way I can debug
html5/JavaScript it would help
Qml uptake a lot.

This would require a Qml document object model (DOM) and a debugger
capable of
inspecting Qml, JavaScript and c++.

Is this possible already or is this one of the "Qml tools" being developed?

Regards,
Philip

[k***@nokia.com]

> -----Original Message-----
> [...]
> Given the lack of comment I'll try to rephrase this.
>
> If I could debug a Qml application the same way I can debug html5/JavaScript
> it would help Qml uptake a lot.
>
> This would require a Qml document object model (DOM) and a debugger
> capable of inspecting Qml, JavaScript and c++.
>
> Is this possible already or is this one of the "Qml tools" being developed?

Hi Philip,

Qt Creator features a QML/JS debugger (setting breakpoints, stepping etc). This one can run along the C++ one, so that you can e.g. hit both C++ and js breakpoints in one run.

It also has an 'Inspector' which allows you to explore the QML object tree interactively by either walking the tree or clicking on elements in your app. It also features a profiler that let you trace the state of the QML engine, how bindings are evaluated etc over time. It also has a 'QML Console" that works much like the JS console from web browsers.

Speak up if you're missing some particular feature from the web world, or find bugs.

Regards

Kai

PS: For using the features in Qt 5 you need a fairly recent Qt Creator, 2.5 minimum.

[André Pönitz]

On Wed, May 09, 2012 at 02:38:24PM +0100, Philip Ashmore wrote:
> If I could debug a Qml application the same way I can debug
> html5/JavaScript it would help> Qml uptake a lot.
>
> This would require a Qml document object model (DOM) and a
> debugger capable of inspecting Qml, JavaScript and c++.
>
> Is this possible already or is this one of the "Qml tools"
> being developed?

Let's leave the question open to the ones who have some insight
in the matter. Judging from the discussion so far I am sure you
will get very convincing answers.



Still, a few comments from my side.

Qt Creator currently allows you to run a QML/JS and a C++ debugger
in a kind of time-division multiplexing manner side-by-side, while
trying to appear to the user as a monolithic debugger as much as
possible. Breakpoints in either QML/JS or C++ code are hit,
and continuing execution behaves orderly as if there was a
homogeneous debuggee.

However, all stepping and data inspection is essentially limited
to one world at a time. If you are in QML/JS, the C++ data is not
visible, and single-stepping remains on the QML/JS side, and vice-
versa. This is sort of sufficient in the cases of "very thin QML
Gui which can't possibly be wrong, plus a fat C++ core" and "small
or not-existant C++ core which can't possibly be wrong, plus a fat
QML/JS Gui". Note that this excludes the case "non-trivial gui
plus non-trivial core."

These limitations are kind of intrinsic to the "hybrid runtime"
approach we have with the current incarnation of QML. They can
theoretically be compensated by a bit of tinkering on a case-by-
case base targeting individual combinations of C++ toolchain (at
least the ones with "incompatible" debuggers like gcc and msvc),
and QML "backend" implementations (e.g. v1/v2). In practice, there
are some additional restrictions imposed by the individual tools.
E.g. cdb's ability to call functions in the running process is
rather limited compared to gdb's, so if the JS engine does not
freely give direct access to its data but requires function
calls you are stuck.

About a year ago I had "cross stepping" (i.e. "Step into" on the
QML1/JS side into a function implemented in C++ would end up in the
implementation on the C++ side, with the C++ debugger active) in a
sort-of-working state under "laboratory conditions." As this was
based on direct access to internals of the script engine and some
gdb trickery on the C++ side, moving that to QML2 would take about
half of the total effort again, plus a bit extra for Mac gdb, plus
a multiple of this for cdb. And that is "only" covering stepping.
And it will break again with the next nontrivial backend change.

A viable and maintainable solution from the debugging point of
view would be to _not_ have a (noticable) hybrid at runtime, i.e.
to target a setup where _all_ applications fall into either the
"(almost) QML only" or "(almost) compiled only" categories
mentioned above. That's where ideas like "a complete QML API"
or "compiled QML" come into play.

Andre'

[d3fault]

So, I'm supposed to want to contribute an upgraded C++ GUI API ("Yes,
the Qt Widgets module we have in Qt 5 is right now marked as ‘done’,
which means we don’t have anybody actively working on new features for
the module at this point in time. But this can change any day if
someone has some interest or need to do more active development in
this area." -Lars) to this "open source"' project wherein my
components (upgraded C++ GUI API) can be sold alongside your
components (expensive/unnecessary front-end to your efficient
back-end) and I not receive a single dime of it? (That described
scenario also shows how Nokia will receive false confidence in their
QML product. Qt/C++ attracts the real users, QML/"New"/Flashy gets all
the credit). The Qt Contributor's Agreement is very permissive with
what Nokia (and not you or I) may do with any/all code contributed to
the Qt Project. Not only that, but the money earned from Commercial
sales is used against the majority's interest
(http://qt-project.org/forums/viewthread/16693/ is skewed (this one's
biased, but is still more accurate:
http://qt-project.org/forums/viewthread/16465/ ), because "Desktop
Components" is of course the next logical step for the only language
that interfaces with QtQuick. It's playing catch-up with QWidgets
functionality. Additionally, Desktop Components becomes the
unquestionable winner for anyone not paying attention to the C++ vs.
QML "religious war" -some guy on the forums. We need an un-biased poll
that compares the 2 real issues: Qml/Js/Vm vs. Upgraded C++ GUI with
bindings (made it: http://qt-project.org/forums/viewthread/17137/ )).
Sure, Nokia deserves some moneys for Qt. Equally, they should be
obligated to benefiting the majority of their userbase (Interest -
"List for developers who _use_ Qt"). Nokia is for some reason (driven
by a CEO could be the problem) off creating a "Toy Programming
Language" (QML) targeting their mobile lineup when they should be
focusing strictly on their core customers (C++ developers). The ones
who made Qt what it is today.

I'm sure I'm not the only C++ developer that feels this way. It is the
Qt way (how Trolltech intended it before being gobbled up). Now the
direction is meaningless in terms of the money put into it (investing)
and generated by it (commercial license sales). The money is
meaningless because it is being invested in stuff that the
original/true/still-here Qt way wouldn't want it to be invested. It is
being invested in QML/JS/VM. Nokia overpaid in creating QML/JS/VM at
least in terms of their design (maybe they got a great rate on
programmers). The overpaid cost is of course the the JS and VM.

what's wrong with this code (inb4 someone tells me what's wrong with
it -- i'm sure something similar+workable can be devised):
m_SomeDeclaredView.somePropertyWhichIsBeingUsedDeclarativelyInC++ =
Q_BINDING((Q_BIND(m_SomeOtherObject.someProperty1) +
Q_BIND(m_AnotherObject.someProperty2)) /
Q_BIND(m_YetAnotherObject.someProperty3) + aConstantInteger)
Q_BINDING and Q_BIND work precompiler (make note of for later setting
up elaborate signals/slots "binding" functionality) magic and then
evaluate to nothing, just like emit. "non-trivial bindings", that the
QML camp are so proud of, can be implemented purely in C++.

...aside from the fact that it's incredibly ugly?

long term, i see a fork. qt (and derivs) will suffer

one solution to this is a Qt Charity that receives all Qt Commercial
fundings and puts them toward a) support and b) future development
based on "developers who _USE_ qt" 's needs/wants

Nokia can continue to waste money on QML etc while Commercial sales
drive the development of Modern C++ GUI (now hardware accelerated +
bindings in a C++ declarative-like environment) and other things that
are specifically NOT in the interest of Nokia (first-rate QPA
Android/iOS platform plugins for starters). Everybody's happy.

I keep hearing the argument 'well if you want feature x then go
develop it'. Qt is powerful and useful enough that it can propel it's
own development (a charity works perfect here). Nokia is now in charge
of that 'propelling' and is aiming it at their global corporate
interests.... which are QML/Javascript Toy Apps development for mobile
phones. I can't say I blame them, I mean let's be honest... toy apps
are the hottest thing on all of the app markets.

I would like to hear some feedback on the Fork +/ Charity
('Commercial' license providing support only unfortunately (unless
Nokia supports it which we all know wouldn't happen)... can't release
to customers under anything more permissive than LGPL. Stilll it's
permissive enough for most cases (one notable place stands out: iOS
App Store). And sadly that support money is all we'd have for
investing into future development. Still, I think Qt is popular enough
to warrant profits seeing future development). Forking Qt will also
permanently lower the barrier to entry for contributing to the
derivative of Qt (which would have to be renamed obviously) to only
requiring you to release your code under the LGPL... not having to
sign the Qt Contributor's Agreement.

d3fault

[BRM]

> From: d3fault <***@gmail.com>

> So, I'm supposed to want to contribute an upgraded C++ GUI API ("Yes,
> the Qt Widgets module we have in Qt 5 is right now marked as ‘done’,
> which means we don’t have anybody actively working on new features for
> the module at this point in time. But this can change any day if
> someone has some interest or need to do more active development in
> this area." -Lars) to this "open source"' project wherein my
> components (upgraded C++ GUI API) can be sold alongside your
> components (expensive/unnecessary front-end to your efficient
> back-end) and I not receive a single dime of it? (That described
> scenario also shows how Nokia will receive false confidence in their
> QML product. Qt/C++ attracts the real users, QML/"New"/Flashy gets all
> the credit). The Qt Contributor's Agreement is very permissive with
> what Nokia (and not you or I) may do with any/all code contributed to
> the Qt Project. Not only that, but the money earned from Commercial
> sales is used against the majority's interest
> (http://qt-project.org/forums/viewthread/16693/ is skewed (this one's
> biased, but is still more accurate:
> http://qt-project.org/forums/viewthread/16465/ ), because "Desktop
> Components" is of course the next logical step for the only language
> that interfaces with QtQuick. It's playing catch-up with QWidgets
> functionality. Additionally, Desktop Components becomes the
> unquestionable winner for anyone not paying attention to the C++ vs.
> QML "religious war" -some guy on the forums. We need an un-biased poll
> that compares the 2 real issues: Qml/Js/Vm vs. Upgraded C++ GUI with
> bindings (made it: http://qt-project.org/forums/viewthread/17137/ )).
> Sure, Nokia deserves some moneys for Qt. Equally, they should be
> obligated to benefiting the majority of their userbase (Interest -
> "List for developers who _use_ Qt"). Nokia is for some reason (driven
> by a CEO could be the problem) off creating a "Toy Programming
> Language" (QML) targeting their mobile lineup when they should be
> focusing strictly on their core customers (C++ developers). The ones
> who made Qt what it is today.

1. We are not _Nokia's_ core customers. Never were. Qt is extremely small compared to Nokia at large.
2. Elop's move to the Windows platform side-lines what Nokia did plan on with Qt at the start; so that probably is affecting things.
3. I do agree that QML is being pursued to the demise of QWidget. It's evident in where new functionality is showing up, etc.

Now if QML was free of GPL (e.g. Commercial customers could use it without qualms about licensing) then #3 wouldn't be an issue aside from the migration path.
But that migration path and how far apart QML and QWidgets are leaves a lot to be desired.

That is - looking from the outside, QML is great for when you have a complete display that lacks everything and every kind of widget needs to be rethought (e.g. Embedded).
But it absolutely doesn't do well when you just need a standard set of widgets that ought to look like the platform they are running on for the Desktop - Linux/GNOME/KDE, Windows, Mac.
This is mostly what has kept me personally from trying out QML more; but I'm still undecided on it in whole; I'll wait until Qt5 is out before saying more in that respect, but it's still got a ways go to - which everyone here seems to admit.

Irregardless, I'm just saying the above to show that there are people that do sympathize with your position;
but I'm this discussion is heading in a constructive or useful direction either so I'm going to leave it there.

> long term, i see a fork. qt (and derivs) will suffer
> one solution to this is a Qt Charity that receives all Qt Commercial
> fundings and puts them toward a) support and b) future development
> based on "developers who _USE_ qt" 's needs/wants

For starters, there's already a foundation in place - http://www.kde.org/community/whatiskde/kdefreeqtfoundation.php.
That Foundation has the right to license Qt under a "BSD-style license or under
other open source licenses" regardless of any other licensing.
Qt is protected in that manner for both Open Source _and_ commercial users.

That said, KDE4 uses QML extensively so I'm not sure they (KDE) would necessarily agree with you.

So no new charity/organization is required; and no other fork will get that kind of licensing ability either.

$0.02, FWIW

Ben

[Atlant Schmidt]

Ben:

> For starters, there's already a foundation in place -
> http://www.kde.org/community/whatiskde/kdefreeqtfoundation.php.
> That Foundation has the right to license Qt under a "BSD-style
> license or under other open source licenses" regardless of
> any other licensing. ...

No, there's no current right for KDE to distribute Qt under
other terms (than LGPL 2.1 and GPL 3). What there is is an
"escape clause" if "Nokia discontinue(s) the development
of Qt". Summarized at the site you cited, it reads:

"The Foundation has a license agreement with Nokia. This
agreement ensures that the Qt will continue to be available
under both the LGPL 2.1 and the GPL 3. Should Nokia discontinue
the development of the Qt Free Edition under these licenses,
then the Foundation has the right to release Qt under a BSD-
style license or under other open source licenses. The
agreement stays valid in case of a buy-out, a merger or
bankruptcy."

Now ask yourself how many millions of Euros could be
spent at some future point litigating whether or not
Nokia has "discontinued" the development of Qt. They
could entirely stop work on QWidget but the QML work
would probably prevent the triggering of the escape
clause.

Atlant

-----Original Message-----
From: development-bounces+aschmidt=***@qt-project.org [mailto:development-bounces+aschmidt=***@qt-project.org] On Behalf Of BRM
Sent: Friday, May 11, 2012 10:19
To: d3fault; ***@qt-project.org
Subject: Re: [Development] The place of QML

> From: d3fault <***@gmail.com>

> So, I'm supposed to want to contribute an upgraded C++ GUI API ("Yes,
> the Qt Widgets module we have in Qt 5 is right now marked as ‘done’,
> which means we don’t have anybody actively working on new features for
> the module at this point in time. But this can change any day if
> someone has some interest or need to do more active development in
> this area." -Lars) to this "open source"' project wherein my
> components (upgraded C++ GUI API) can be sold alongside your
> components (expensive/unnecessary front-end to your efficient
> back-end) and I not receive a single dime of it? (That described
> scenario also shows how Nokia will receive false confidence in their
> QML product. Qt/C++ attracts the real users, QML/"New"/Flashy gets all
> the credit). The Qt Contributor's Agreement is very permissive with
> what Nokia (and not you or I) may do with any/all code contributed to
> the Qt Project. Not only that, but the money earned from Commercial
> sales is used against the majority's interest
> (http://qt-project.org/forums/viewthread/16693/ is skewed (this one's
> biased, but is still more accurate:
> http://qt-project.org/forums/viewthread/16465/ ), because "Desktop
> Components" is of course the next logical step for the only language
> that interfaces with QtQuick. It's playing catch-up with QWidgets
> functionality. Additionally, Desktop Components becomes the
> unquestionable winner for anyone not paying attention to the C++ vs.
> QML "religious war" -some guy on the forums. We need an un-biased poll
> that compares the 2 real issues: Qml/Js/Vm vs. Upgraded C++ GUI with
> bindings (made it: http://qt-project.org/forums/viewthread/17137/ )).
> Sure, Nokia deserves some moneys for Qt. Equally, they should be
> obligated to benefiting the majority of their userbase (Interest -
> "List for developers who _use_ Qt"). Nokia is for some reason (driven
> by a CEO could be the problem) off creating a "Toy Programming
> Language" (QML) targeting their mobile lineup when they should be
> focusing strictly on their core customers (C++ developers). The ones
> who made Qt what it is today.

1. We are not _Nokia's_ core customers. Never were. Qt is extremely small compared to Nokia at large.
2. Elop's move to the Windows platform side-lines what Nokia did plan on with Qt at the start; so that probably is affecting things.
3. I do agree that QML is being pursued to the demise of QWidget. It's evident in where new functionality is showing up, etc.

Now if QML was free of GPL (e.g. Commercial customers could use it without qualms about licensing) then #3 wouldn't be an issue aside from the migration path.
But that migration path and how far apart QML and QWidgets are leaves a lot to be desired.

That is - looking from the outside, QML is great for when you have a complete display that lacks everything and every kind of widget needs to be rethought (e.g. Embedded).
But it absolutely doesn't do well when you just need a standard set of widgets that ought to look like the platform they are running on for the Desktop - Linux/GNOME/KDE, Windows, Mac.
This is mostly what has kept me personally from trying out QML more; but I'm still undecided on it in whole; I'll wait until Qt5 is out before saying more in that respect, but it's still got a ways go to - which everyone here seems to admit.

Irregardless, I'm just saying the above to show that there are people that do sympathize with your position;
but I'm this discussion is heading in a constructive or useful direction either so I'm going to leave it there.

> long term, i see a fork. qt (and derivs) will suffer
> one solution to this is a Qt Charity that receives all Qt Commercial
> fundings and puts them toward a) support and b) future development
> based on "developers who _USE_ qt" 's needs/wants

For starters, there's already a foundation in place - http://www.kde.org/community/whatiskde/kdefreeqtfoundation.php.
That Foundation has the right to license Qt under a "BSD-style license or under
other open source licenses" regardless of any other licensing.
Qt is protected in that manner for both Open Source _and_ commercial users.

That said, KDE4 uses QML extensively so I'm not sure they (KDE) would necessarily agree with you.

So no new charity/organization is required; and no other fork will get that kind of licensing ability either.

$0.02, FWIW

Ben


This e-mail and the information, including any attachments, it contains are intended to be a confidential communication only to the person or entity to whom it is addressed and may contain information that is privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender and destroy the original message.

Thank you.

Please consider the environment before printing this email.

[Quim Gil]

What are we discussing, really?

It is clear that the answer "if you don't like the status of a module
then you can contribute to it since its OSS etc" doesn't make happy many
people whenever is written. Still, this is the case.

It would be also the case even after the scenario of Nokia stopping Qt
development, the whole Qt being relicensed to BSD, Qt Commercial paying
some kind of revolutionary tax... You name it. Still someone should go
to that DONE module and develop it further, either by own initiative or
paid by someone.

The great thing about Qt Project is that you don't need to oust Nokia or
anybody or relicense anything to push a Qt module forward. You can Just
Do It (or convince someone to do it, with nice words or green notes).
You can do it inside the Qt Project game through bugs, patches,
approvers, maintenance. You can even fork the code and work on it
somewhere else, if you think that will help your goals. But remember,
you still will need you or someone to work on it.

Another possibility is that Qt Commercial customers demand this service
from their provider (Digia). They have a commercial relationship so if
the deal is commercially viable it probably would happen. Since Digia
seems to be clear about not forking existing Qr Project components, in
that scenario they would probably become contributors of the module.

As you see there are many potential combinations.

Nokia has been asked to develop QWidget further many times, and the
answer has been consistent every time: Nokia is happy with the DONE
status and prefers to focus its resources in other areas that it
considers benefit not only Nokia but the whole Qt Project in today's
World. Nokia's investment in Qt is big (check
http://www.macieira.org/blog/qt-stats/ ) therefore I'm not really sure
the best approach is to put more pressure or requests in that direction.
Why not asking others?

Do you agree? Great. You don't agree? No matter how long the discussion
here, the end point is going to be the same: you are welcome to find the
best way to get that component developed further. The Qt Project offers
the tools for anybody willing to change this situation.

--
Quim

[d3fault]

On 5/11/12, BRM <***@yahoo.com> wrote:
> 1. We are not _Nokia's_ core customers. Never were. Qt is extremely small
> compared to Nokia at large.

Not Nokia's core customers... Qt's core customers. Nokia's core
customers are Mobile end users... which is why they're pushing so hard
for this Toy Programming Language targeting mobile. Nokia takes Qt
profits (which are minimal compared to Nokia sales -- but this point
is irrelevant) and combines them with gross Nokia revenue. Nokia then
invests (perhaps more than Qt profits -- though, again, irrelevant) in
Qt in an area mostly only of interest to Nokia.

> For starters, there's already a foundation in place -
> http://www.kde.org/community/whatiskde/kdefreeqtfoundation.php.
> That Foundation has the right to license Qt under a "BSD-style license or
> under
> other open source licenses" regardless of any other licensing.
> Qt is protected in that manner for both Open Source _and_ commercial users.
>
> That said, KDE4 uses QML extensively so I'm not sure they (KDE) would
> necessarily agree with you.
>
> So no new charity/organization is required; and no other fork will get that
> kind of licensing ability either.

The KDE Free Qt Foundation is more of a backup plan. Should Qt cease
to be released/developed (that wording is so vague it's downright
retarded) under LGPL/GPL for 1 year, the KDE people can release it
under BSD (or other) license. The KDE people actively develop Qt
regardless and are not concerned with the monetization of Qt...
whereas the point I'm trying to make is that the Qt Project generates
*enough* money based purely on Commercial Sales (which mostly just
boil down to support anyways -- the LGPL is good enough for *most*
Commercial uses) to drive it's own development. When thinking about
'what future development should be targeted by the revenue generated
by support sales?', Nokia's concerns (Mobile Platform Toy Programming
Language) should not factor in.

Again and again it is mentioned "if you want it done, code it
yourself". But my response to you is that we are the majority (of Qt
_users_ (developers who use Qt)) and you have an obligation to code it
for us, you being the collectors of any/all revenue generated by said
project (and here's the kicker: you also collect moneys on any code
contributed by us to said project). Nokia letting Digia handle support
for them does not factor in. Nokia still owns Qt.

inb4 idiots in denial saying C++ GUI API is not what the majority of
Qt user's want (see various polls on the forum)

On 5/11/12, Atlant Schmidt <***@dekaresearch.com> wrote:
> Now ask yourself how many millions of Euros could be
> spent at some future point litigating whether or not
> Nokia has "discontinued" the development of Qt. They
> could entirely stop work on QWidget but the QML work
> would probably prevent the triggering of the escape
> clause.
>
> Atlant

Two things (even though we're apparently on the same side):
1) They already have stopped working on QWidgets. One could already
argue that Nokia has already stopped development (I won't make that
argument because there's still a whole lot to Qt 5 aside from QML).
2) Time/money spent litigating would be wasted (unless you _REALLY_
want that BSD license (*cough iOS*)). It should instead be spent on
forking Qt (free: LGPL + commercia: LGPL + Support) -- which, as Quim
pointed out, we don't need Nokia's permission to do:

On 5/11/12, Quim Gil <***@nokia.com> wrote:
> The great thing about Qt Project is that you don't need to oust Nokia or
> anybody or relicense anything to push a Qt module forward. You can Just
> Do It (or convince someone to do it, with nice words or green notes).
> You can do it inside the Qt Project game through bugs, patches,
> approvers, maintenance. You can even fork the code and work on it
> somewhere else, if you think that will help your goals. But remember,
> you still will need you or someone to work on it.

And he also made note "you still will need you or someone to work on
it". Exactly. Qt Commercial Sales (post-fork) will fund the 'someone
working on it'. The difference being the 'someone' will be told what
to do by someone with Qt's real goals in mind... not Nokia's [goals].
Also, Quim: what is your response to the fact that all code
contributed to the Qt Project (as it stands) gives Nokia exclusive
rights to redistribute said contributed code under terms other than
the LGPL? We make it, they sell it (and then use the proceeds towards
some useless short sighted corporate goal)!

> Nokia has been asked to develop QWidget further many times, and the
> answer has been consistent every time: Nokia is happy with the DONE
> status and prefers to focus its resources in other areas that it
> considers benefit not only Nokia but the whole Qt Project in today's
> World.

Disagree. Nokia focuses its resources on areas that benefit Nokia.
That's how a business works. They might make the [marketing] claim
that it's for the whole Qt Project's interests... but multiple polls
have shown otherwise (including one recently shut down by a Nokian).

>Nokia's investment in Qt is big (check
> http://www.macieira.org/blog/qt-stats/ ) therefore I'm not really sure
> the best approach is to put more pressure or requests in that direction.

"Big"
so Money + Manpower = Great Software??
wow I wish I knew that earlier... I could be a million dollars by now

> Why not asking others?

Nokia owns Qt outright and are the only ones capable of preventing a
fork. I don't want a fork. I don't want segregation because it is
expensive and hurts real development.


tl;dr:
You + 3rd Parties --(Contribute Revenue Generating
Modules/Code/Fixes/Enhancements)--> Qt Project/Nokia/Digia --(revenue
generated goes to Nokia's bottom line [mobile] (or Digia's bottom
line, but that's irrelevant))--> Qt Project is Funded by Nokia who is
targeting Nokia's bottom line (mobile)

All in all, I acknowledge I'm wasting my breathe. Nokia doesn't give a
shit about me, only their bottom line. Why bitch, then? Why not just
go out and start a "Qt Charity" and offer support for Qt-deriv/fork
released under LGPL? It could even be classified as a for profit
business. The reason is simple: I'm just one guy. A fork, a
charity/business, and support are a fuck ton of work. I'd rather let
the ideas float on this mailing list before just charging out my front
door with a sword drawn.
Lastly, a fork would hurt the Qt Project/Nokia/Digia the most. The
fork could still PULL all of Qt Project/Nokia/Digia's work to
itself... and accept patches and further contributions directly under
the LGPL (not requiring the Qt Contributor's Agreement, which let's
Nokia do anything they want with your code). Nokia would be unable to
pull said LGPL-only enhancements without convincing the author's to
sign a Qt Project Contributor's Agreement (and why would they?).

d3fault

[Holger Hans Peter Freyther]

On 05/12/2012 08:28 PM, d3fault wrote:

> whereas the point I'm trying to make is that the Qt Project generates
> *enough* money based purely on Commercial Sales (which mostly just
> boil down to support anyways -- the LGPL is good enough for *most*
> Commercial uses) to drive it's own development.

Are you kidding here?

[Thiago Macieira]

On sábado, 12 de maio de 2012 21.57.17, Holger Hans Peter Freyther wrote:
> On 05/12/2012 08:28 PM, d3fault wrote:
> > whereas the point I'm trying to make is that the Qt Project generates
> > *enough* money based purely on Commercial Sales (which mostly just
> > boil down to support anyways -- the LGPL is good enough for *most*
> > Commercial uses) to drive it's own development.
>
> Are you kidding here?

Doesn't matter whether he intended to be kidding or was being intentionally
wrong.

The fact is that he's WRONG and way off the mark.

The Qt sales revenue hasn't paid for Qt development for at least 3 years,
especially since the developers in Brisbane joined the Qt development (as
opposed to Qtopia before). It's just nowhere near enough. The Qt dev team
inside Nokia grew from ~50 people in 2008 to about 200 when I left one year
ago. In the mean time, Qtopia was halted and Qt itself was released as LGPL,
which certainly diminished the commercial sales.

And that's not to mention that Trolltech wasn't profitable before the
acquisition anyway. Trolltech was still at the stage of "invest more money
than current revenues to generate future revenues" of a company's lifetime.
Trolltech ASA was a public company, so the records are public.

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Intel Sweden AB - Registration Number: 556189-6027
Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden

[Robin Burchell]

On Sat, May 12, 2012 at 8:28 PM, d3fault <***@gmail.com> wrote:
> And he also made note "you still will need you or someone to work on
> it". Exactly. Qt Commercial Sales (post-fork) will fund the 'someone
> working on it'.

I gather from this that you're proposing the idea of a fork. Stop
being an idiot.

Let me try explain: as you should already know, some of the work on Qt
is being funded by commercial licensees (via digia) to work on what
those commercial licensees want them to work on - already - _as a part
of the project you're proposing to abandon_. This has nothing to do
with Nokia.

Now, if they're already here, it clearly doesn't need a fork to enable
that to happen, as it's happening already. If someone (you, digia,
Paul McCartney for all I care) have work they want in Qt, then they're
free to push that forward - nobody will stop it, unless there is a
solid technical grounds for that.

A fork doesn't really gain you anything tangible you don't already
have, other than some 200-300 fewer people working on your fork,
meaning you don't have any of their years of Qt expertise in reviewing
your changes, plus the pains of having to run infrastructure (VCS
hosting, website, mailing lists, autotest infrastructure to prevent
regressions - across three major platforms at a minimum), make
releases, merge changes back in, develop and market new branding, etc.

> Disagree. Nokia focuses its resources on areas that benefit Nokia.
> That's how a business works.

You're correct that this is how business works: Nokia's business is
selling mobile devices (and services) - Digia's is in selling
consultancy. Digia has customers who pay them to work on features and
bugs that their customers need, Nokia does not.

> Lastly, a fork would hurt the Qt Project/Nokia/Digia the most. The
> fork could still PULL all of Qt Project/Nokia/Digia's work to
> itself...

A fork would only hurt this project if the majority of the effort was
behind the fork, and frankly, I don't think that's about to happen
nowdays.

[Thiago Macieira]

On sábado, 12 de maio de 2012 14.28.49, d3fault wrote:
> Again and again it is mentioned "if you want it done, code it
> yourself". But my response to you is that we are the majority (of Qt
> users (developers who use Qt)) and you have an obligation to code it

No, you're not.

Developers like you might be the numerical majority, but when it comes to
number of products developed and shipped to customers, I'm pretty sure that no
one will come close to "next billion".

Not to mention that I know of a few proven cases of companies shipping "a few
million" that are very happy with QML.

> for us, you being the collectors of any/all revenue generated by said
> project (and here's the kicker: you also collect moneys on any code
> contributed by us to said project). Nokia letting Digia handle support
> for them does not factor in. Nokia still owns Qt.

I also resent "Nokia still owns Qt". No, it does not. Many people, including
me, worked really hard to create the Qt Project. It's no more Nokia's than
anyone else in that sense.

The only thing that Nokia has is that it retains the right to continue
commercialising under different terms. And they do that by selling to Digia.

So even if you were right about the commercial licensor being the "owner" (and
you're not), you'd still be wrong about collecting the money. Digia collects
the money and reinvests in its own activities. A certain amount may flow back
to Nokia for paying for the right to do that.

Do you REALLY think that this amount that Digia pays back to Nokia is worth
200 full-time top-notch developers? I really want you to tell me with a
straight face that you can do the math and say it does.

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Intel Sweden AB - Registration Number: 556189-6027
Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden

[Thiago Macieira]

On sábado, 12 de maio de 2012 22.28.40, Thiago Macieira wrote:
> Developers like you might be the numerical majority, but when it comes to
> number of products developed and shipped to customers, I'm pretty sure that
> no one will come close to "next billion".

Correcting myself. There is one who has already:
http://www.videolan.org/vlc/stats/downloads.html

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Intel Sweden AB - Registration Number: 556189-6027
Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden

[Stephen Chu]

On 5/12/12 5:01 PM, Thiago Macieira wrote:
> On sábado, 12 de maio de 2012 22.28.40, Thiago Macieira wrote:
>> Developers like you might be the numerical majority, but when it comes to
>> number of products developed and shipped to customers, I'm pretty sure that
>> no one will come close to "next billion".
>
> Correcting myself. There is one who has already:
> http://www.videolan.org/vlc/stats/downloads.html

Are they switching over to QML? jk... :)

[Thiago Macieira]

On sábado, 12 de maio de 2012 17.07.40, Stephen Chu wrote:
> On 5/12/12 5:01 PM, Thiago Macieira wrote:
> > On sábado, 12 de maio de 2012 22.28.40, Thiago Macieira wrote:
> >> Developers like you might be the numerical majority, but when it comes to
> >> number of products developed and shipped to customers, I'm pretty sure
> >> that
> >> no one will come close to "next billion".
> >
> > Correcting myself. There is one who has already:
> > http://www.videolan.org/vlc/stats/downloads.html
>
> Are they switching over to QML? jk... :)

I don't know. But that's the interesting question: what is the VLC team's take
on the direction of Qt and in this thread in particular?

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Intel Sweden AB - Registration Number: 556189-6027
Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden

[d3fault]

On 5/12/12, Robin Burchell <robin+***@viroteck.net> wrote:
> Let me try explain: as you should already know, some of the work on Qt
> is being funded by commercial licensees (via digia) to work on what
> those commercial licensees want them to work on - already - _as a part
> of the project you're proposing to abandon_. This has nothing to do
> with Nokia.
>
> Now, if they're already here, it clearly doesn't need a fork to enable
> that to happen, as it's happening already. If someone (you, digia,
> Paul McCartney for all I care) have work they want in Qt, then they're
> free to push that forward - nobody will stop it, unless there is a
> solid technical grounds for that.

Relevance? Qt... the Qt Project/Trademark... Nokia... encourage you to
contribute. They want to resell your contributions :). They will also
give it back to you and to everyone for free (monetary + libre) under
the LGPL.

> A fork doesn't really gain you anything tangible you don't already
> have,

It regains creative control over the use of revenues generated through
the support of the product (qt, renamed). Trolltech may have been in
the red, but that doesn't mean it would have stayed in the red. And if
would never have seen a profit, then why would Nokia have it?

> other than some 200-300 fewer people working on your fork,
> meaning you don't have any of their years of Qt expertise in reviewing
> your changes, plus the pains of having to run infrastructure (VCS
> hosting, website, mailing lists, autotest infrastructure to prevent
> regressions - across three major platforms at a minimum), make
> releases, merge changes back in, develop and market new branding, etc.

Yea, that does kind of suck. But it isn't a total loss. The fork would
still be able to regularly pull from Qt-Nokia and benefit from all the
money thrown at that. The opposite does not hold true: Qt-Nokia could
not pull from contributions applied directly to the fork.

> You're correct that this is how business works: Nokia's business is
> selling mobile devices (and services) - Digia's is in selling
> consultancy. Digia has customers who pay them to work on features and
> bugs that their customers need, Nokia does not.

It is worth noting that Digia's interest is ONLY in selling
consultancy. There is no R&D department at Digia. They do client work
and also perform support for Qt through bugfixes etc.

Nokia's R&D department is off busy trying to solve Nokia's problem:
Their bottom line. Mobile. They do this by producing QML: The Toy
Programming Language... in hopes that Trivial Farting Apps don't die
off soon (they won't)


On 5/12/12, Thiago Macieira <***@intel.com> wrote:
> On sábado, 12 de maio de 2012 21.57.17, Holger Hans Peter Freyther wrote:
>> On 05/12/2012 08:28 PM, d3fault wrote:
>> > whereas the point I'm trying to make is that the Qt Project generates
>> > *enough* money based purely on Commercial Sales (which mostly just
>> > boil down to support anyways -- the LGPL is good enough for *most*
>> > Commercial uses) to drive it's own development.
>>
>> Are you kidding here?
>
> Doesn't matter whether he intended to be kidding or was being intentionally
>
> wrong.

I was unintentionally wrong, but it doesn't matter. A small team
working on Qt for a company (whose core customer is Qt users:
developers) in the red is better than a large team working on Qt for a
bigger company (whose core customer is NOT Qt users: it's mobile phone
sales), also in the red (and probably redder!!).


On 5/12/12, Thiago Macieira <***@intel.com> wrote:
> On sábado, 12 de maio de 2012 14.28.49, d3fault wrote:
>> Again and again it is mentioned "if you want it done, code it
>> yourself". But my response to you is that we are the majority (of Qt
>> users (developers who use Qt)) and you have an obligation to code it
>
> No, you're not.
>
> Developers like you might be the numerical majority, but when it comes to
> number of products developed and shipped to customers, I'm pretty sure that
> no
> one will come close to "next billion".

The "next billion" toy mobile app market apps
Coded by beginners who like QML/JS and see it as superior to Qt/C++
because it's "easier"

The core Qt user (developers) prefer a C++ GUI API... but Nokia pushes
QML instead.

> Not to mention that I know of a few proven cases of companies shipping "a
> few
> million" that are very happy with QML.

I'm very glad there were 'a few' companies that are happy with QML. I
know even more that are happy with C++.

> I also resent "Nokia still owns Qt". No, it does not. Many people, including
>
> me, worked really hard to create the Qt Project. It's no more Nokia's than
> anyone else in that sense.

The Open Source releasing* of the Qt libraries by the Qt Project
and/or Nokia (Qt SDK) doesn't change the fact that you're giving Nokia
an irrevocable license to sell/sub-license your contributions. It just
so happens that when they give you (distribute-with-qt) your
contributions back to you, they are now under the LGPL license. When
you give contributions to The Qt Trademark/Project, you are not doing
so under the terms of the LGPL... you are doing so under a much more
permissive (to Nokia) Qt Contributor's Agreement. If you only had to
commit via LGPL without signing a contributors agreement... then yes,
it would be "no more Nokia's than anyone else". But that simply isn't
true. Take the following clause from the Contributor's Agreement:

>Subject to the terms and conditions of this Agreement, Licensor (signing contributor) hereby
>grants,[...] to Nokia a sublicensable, irrevocable, perpetual, worldwide, non-exclusive,
>royalty-free and fully paid-up copyright and trade secret license to reproduce, adapt,
>translate, modify, and prepare derivative works of, publicly display, publicly perform,
>sublicense, make available and distribute Licensor Contribution(s) and any derivative works
>thereof under license terms of Nokia’s choosing including any Open Source Software
>license.

Right there you've lost all your rights that releasing under the LGPL
buys you. The part that ruins everything is right here:
>under license terms of Nokia’s choosing including any Open Source Software license

Including... but not required. Nokia can release your content under
any license it chooses (or makes up). Basically Nokia gives back to
you your own contributions (as well as theirs + everyone's) with less
rights than when you gave it to them.

> The only thing that Nokia has is that it retains the right to continue
> commercialising under different terms. And they do that by selling to
> Digia.

The "Qt Trademark", which Nokia owns, is what the Qt Project needs to
own. Profit-generating support, which is being outsourced to Digia,
uses the trademark to provide "Official Qt Support" and can also
sub-license your contributions under any terms that Nokia can.

> Digia collects
> the money and reinvests in its own activities. A certain amount may flow
> back
> to Nokia for paying for the right to do that.
> Do you REALLY think that this amount that Digia pays back to Nokia is worth [...]

We aren't solely talking about the money that Digia pays back to
Nokia. We also include the money that Digia "reinvests in its own
activities" (retirement funds count. Digia has no interest in actively
developing Qt because "that's Nokia's job"... they just provide
support (which luckily includes bug-fixes... and for that I am
grateful)).

> [...] 200 full-time top-notch developers? I really want you to tell me with a
> straight face that you can do the math and say it does.

-_- hello 200 full-time top-notch developers working for Nokia's
bottom line (Mobile XYZ... not Qt Development)

I'd rather have 20 full-time top notch developer working on a C++ GUI
API paid for by a traditional support company (whose 'core' customer
is 'developers who _use_ Qt') at a loss than 200 full-time top notch
developers working on QML paid for by Nokia (whose 'core' customer is
Joe Billy Spongebob playing the next Angry Birds incarnation rewritten
in QML on an n9) also at a loss -- just a bigger one.

On 5/12/12, Thiago Macieira <***@intel.com> wrote:
> On sábado, 12 de maio de 2012 17.07.40, Stephen Chu wrote:
>> On 5/12/12 5:01 PM, Thiago Macieira wrote:
>> > Correcting myself. There is one who has already:
>> > http://www.videolan.org/vlc/stats/downloads.html
>>
>> Are they switching over to QML? jk... :)
>
> I don't know. But that's the interesting question: what is the VLC team's
> take
> on the direction of Qt and in this thread in particular?

We should get Stallman in on the action too... but really, I just want
to watch him stroke his beard.


on another note
Nokia: Use Our Product, Qt!
us: Ok wow this C++ toolkit is pretty nifty
Nokia: LoL C++ GUI now "done" here's this QML experiment/hybrid thing
we've been working on
us: Ok interesting but how about an upgraded/comparable C++ API plox?
Nokia: LoL Nope. You want that make it yourself. We will accept your
contributions and sell them tho ;-)
us: Super Neato Thanks Nokia!

except really Nokia's first line is: "Use Our Product: Windows Mobile
Enabled Smart Phone!"

d3fault
-didn't find Qt through advertising

[Jordi Pujol]

Hi all,

I think starting a flame war against Qt/NoKia/Digia is not good for
anyone.

My current position about Qt-project : I disagree with pushing so much
QML, and yes I also think is a "toy programming language", by now. It
has to evolve & mature a lot. Perhaps this point justifies so much work
on that line.

In the future, perhaps I have to use it for a mobile or embedded
development, but my biggest application, with 280+ dynamic-loading ui
files is too large and mature to change it now. It also manages a lot of
high populated grids ( 50+ columns, 60k rows ) and with QML... well I
didn't tried it, I don't like to shoot my feet ;-P

Somebody asked to have a good C++ - QML API, perhaps is the future, I'm
not a "Qt guru", but I give that my +1.

I was a Digia paying customer in the past. Now I'm not. But I think is
fair to pay for every useful code you get, so I'm trying to contribute
to qt-project in my spare time.

I don't pay for Qt library with money, I pay with my collaboration. If
Qt/Nokia/Digia make money selling the code with my contributions, I
think is fair enough : I use their code for free ( and the code from
other people contributing ), so : do I have to complain about this ?

And I think the option they "get our code and run" is just a little bit
a paranoic way of thinking...

Just my 2ct.

[Atlant Schmidt]

d3fault:

> Trolltech may have been in the red, but that doesn't mean it
> would have stayed in the red. And if would never have seen a
> profit, then why would Nokia have it?

Nokia bought Trolltech for one simple reason: Development
on Symbian/S60/Averell/Avkon was too arcane/too weird and
too difficult. You needed to read several very thick books
to know enough to program an app. The C++-like language
that Symbian is programmed in was always just different
enough from real C++ to be very-off-putting to new developers.
"What do you mean 'clean-up stack'?" "What do you mean
'descriptors'?" "Where are the signals?"

Nokia had never been getting a lot of folks to develop apps
and in a world that suddenly contained iOS and then Android,
they were suddenly getting (essentially) no new apps; even
Nokia's own in-house development was falling woefully far
behind the competition.

Qt offered a way to change that and the change could be
had for relatively little money out of Nokia's pocket.

Suddenly, with Qt, Nokia phones could be programmed in a way
that anyone could understand without needing to know anything
about Avkon arcana. And given that Qt was now captive, the
developers could be targeted towards adding mobile features
and as mobile features were integrated into Qt, all those
cool iPhone and Android apps could (at least theoretically)
be ported to Nokia as well. Not only that, but everything
gained for Symbian would also be gained for Maemo/MeeGo.

At the time, it seemed like a clearly-winning deal.

(This all changed, of course, when Elop stupidly torched
Nokia's existing platforms but that's a whole other
discussion.)

Atlant

-----Original Message-----
From: development-bounces+aschmidt=***@qt-project.org [mailto:development-bounces+aschmidt=***@qt-project.org] On Behalf Of d3fault
Sent: Saturday, May 12, 2012 19:29
To: ***@qt-project.org
Subject: Re: [Development] The place of QML

On 5/12/12, Robin Burchell <robin+***@viroteck.net> wrote:
> Let me try explain: as you should already know, some of the work on Qt
> is being funded by commercial licensees (via digia) to work on what
> those commercial licensees want them to work on - already - _as a part
> of the project you're proposing to abandon_. This has nothing to do
> with Nokia.
>
> Now, if they're already here, it clearly doesn't need a fork to enable
> that to happen, as it's happening already. If someone (you, digia,
> Paul McCartney for all I care) have work they want in Qt, then they're
> free to push that forward - nobody will stop it, unless there is a
> solid technical grounds for that.

Relevance? Qt... the Qt Project/Trademark... Nokia... encourage you to
contribute. They want to resell your contributions :). They will also
give it back to you and to everyone for free (monetary + libre) under
the LGPL.

> A fork doesn't really gain you anything tangible you don't already
> have,

It regains creative control over the use of revenues generated through
the support of the product (qt, renamed). Trolltech may have been in
the red, but that doesn't mean it would have stayed in the red. And if
would never have seen a profit, then why would Nokia have it?

> other than some 200-300 fewer people working on your fork,
> meaning you don't have any of their years of Qt expertise in reviewing
> your changes, plus the pains of having to run infrastructure (VCS
> hosting, website, mailing lists, autotest infrastructure to prevent
> regressions - across three major platforms at a minimum), make
> releases, merge changes back in, develop and market new branding, etc.

Yea, that does kind of suck. But it isn't a total loss. The fork would
still be able to regularly pull from Qt-Nokia and benefit from all the
money thrown at that. The opposite does not hold true: Qt-Nokia could
not pull from contributions applied directly to the fork.

> You're correct that this is how business works: Nokia's business is
> selling mobile devices (and services) - Digia's is in selling
> consultancy. Digia has customers who pay them to work on features and
> bugs that their customers need, Nokia does not.

It is worth noting that Digia's interest is ONLY in selling
consultancy. There is no R&D department at Digia. They do client work
and also perform support for Qt through bugfixes etc.

Nokia's R&D department is off busy trying to solve Nokia's problem:
Their bottom line. Mobile. They do this by producing QML: The Toy
Programming Language... in hopes that Trivial Farting Apps don't die
off soon (they won't)


On 5/12/12, Thiago Macieira <***@intel.com> wrote:
> On sábado, 12 de maio de 2012 21.57.17, Holger Hans Peter Freyther wrote:
>> On 05/12/2012 08:28 PM, d3fault wrote:
>> > whereas the point I'm trying to make is that the Qt Project generates
>> > *enough* money based purely on Commercial Sales (which mostly just
>> > boil down to support anyways -- the LGPL is good enough for *most*
>> > Commercial uses) to drive it's own development.
>>
>> Are you kidding here?
>
> Doesn't matter whether he intended to be kidding or was being intentionally
>
> wrong.

I was unintentionally wrong, but it doesn't matter. A small team
working on Qt for a company (whose core customer is Qt users:
developers) in the red is better than a large team working on Qt for a
bigger company (whose core customer is NOT Qt users: it's mobile phone
sales), also in the red (and probably redder!!).


On 5/12/12, Thiago Macieira <***@intel.com> wrote:
> On sábado, 12 de maio de 2012 14.28.49, d3fault wrote:
>> Again and again it is mentioned "if you want it done, code it
>> yourself". But my response to you is that we are the majority (of Qt
>> users (developers who use Qt)) and you have an obligation to code it
>
> No, you're not.
>
> Developers like you might be the numerical majority, but when it comes to
> number of products developed and shipped to customers, I'm pretty sure that
> no
> one will come close to "next billion".

The "next billion" toy mobile app market apps
Coded by beginners who like QML/JS and see it as superior to Qt/C++
because it's "easier"

The core Qt user (developers) prefer a C++ GUI API... but Nokia pushes
QML instead.

> Not to mention that I know of a few proven cases of companies shipping "a
> few
> million" that are very happy with QML.

I'm very glad there were 'a few' companies that are happy with QML. I
know even more that are happy with C++.

> I also resent "Nokia still owns Qt". No, it does not. Many people, including
>
> me, worked really hard to create the Qt Project. It's no more Nokia's than
> anyone else in that sense.

The Open Source releasing* of the Qt libraries by the Qt Project
and/or Nokia (Qt SDK) doesn't change the fact that you're giving Nokia
an irrevocable license to sell/sub-license your contributions. It just
so happens that when they give you (distribute-with-qt) your
contributions back to you, they are now under the LGPL license. When
you give contributions to The Qt Trademark/Project, you are not doing
so under the terms of the LGPL... you are doing so under a much more
permissive (to Nokia) Qt Contributor's Agreement. If you only had to
commit via LGPL without signing a contributors agreement... then yes,
it would be "no more Nokia's than anyone else". But that simply isn't
true. Take the following clause from the Contributor's Agreement:

>Subject to the terms and conditions of this Agreement, Licensor (signing contributor) hereby
>grants,[...] to Nokia a sublicensable, irrevocable, perpetual, worldwide, non-exclusive,
>royalty-free and fully paid-up copyright and trade secret license to reproduce, adapt,
>translate, modify, and prepare derivative works of, publicly display, publicly perform,
>sublicense, make available and distribute Licensor Contribution(s) and any derivative works
>thereof under license terms of Nokia's choosing including any Open Source Software
>license.

Right there you've lost all your rights that releasing under the LGPL
buys you. The part that ruins everything is right here:
>under license terms of Nokia's choosing including any Open Source Software license

Including... but not required. Nokia can release your content under
any license it chooses (or makes up). Basically Nokia gives back to
you your own contributions (as well as theirs + everyone's) with less
rights than when you gave it to them.

> The only thing that Nokia has is that it retains the right to continue
> commercialising under different terms. And they do that by selling to
> Digia.

The "Qt Trademark", which Nokia owns, is what the Qt Project needs to
own. Profit-generating support, which is being outsourced to Digia,
uses the trademark to provide "Official Qt Support" and can also
sub-license your contributions under any terms that Nokia can.

> Digia collects
> the money and reinvests in its own activities. A certain amount may flow
> back
> to Nokia for paying for the right to do that.
> Do you REALLY think that this amount that Digia pays back to Nokia is worth [...]

We aren't solely talking about the money that Digia pays back to
Nokia. We also include the money that Digia "reinvests in its own
activities" (retirement funds count. Digia has no interest in actively
developing Qt because "that's Nokia's job"... they just provide
support (which luckily includes bug-fixes... and for that I am
grateful)).

> [...] 200 full-time top-notch developers? I really want you to tell me with a
> straight face that you can do the math and say it does.

-_- hello 200 full-time top-notch developers working for Nokia's
bottom line (Mobile XYZ... not Qt Development)

I'd rather have 20 full-time top notch developer working on a C++ GUI
API paid for by a traditional support company (whose 'core' customer
is 'developers who _use_ Qt') at a loss than 200 full-time top notch
developers working on QML paid for by Nokia (whose 'core' customer is
Joe Billy Spongebob playing the next Angry Birds incarnation rewritten
in QML on an n9) also at a loss -- just a bigger one.

On 5/12/12, Thiago Macieira <***@intel.com> wrote:
> On sábado, 12 de maio de 2012 17.07.40, Stephen Chu wrote:
>> On 5/12/12 5:01 PM, Thiago Macieira wrote:
>> > Correcting myself. There is one who has already:
>> > http://www.videolan.org/vlc/stats/downloads.html
>>
>> Are they switching over to QML? jk... :)
>
> I don't know. But that's the interesting question: what is the VLC team's
> take
> on the direction of Qt and in this thread in particular?

We should get Stallman in on the action too... but really, I just want
to watch him stroke his beard.


on another note
Nokia: Use Our Product, Qt!
us: Ok wow this C++ toolkit is pretty nifty
Nokia: LoL C++ GUI now "done" here's this QML experiment/hybrid thing
we've been working on
us: Ok interesting but how about an upgraded/comparable C++ API plox?
Nokia: LoL Nope. You want that make it yourself. We will accept your
contributions and sell them tho ;-)
us: Super Neato Thanks Nokia!

except really Nokia's first line is: "Use Our Product: Windows Mobile
Enabled Smart Phone!"

d3fault
-didn't find Qt through advertising


This e-mail and the information, including any attachments, it contains are intended to be a confidential communication only to the person or entity to whom it is addressed and may contain information that is privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender and destroy the original message.

Thank you.

Please consider the environment before printing this email.

[d3fault]

On 5/14/12, Turunen Tuukka <***@digia.com> wrote:
> Just very short comment to this part - Digia, Qt Commercial does also
> quite significant R&D. Whereas we do have consulting, and support, we do
> also our share of development. For example we are working in making sure
> that Qt runs nicely on those platforms that are important to the
> commercial customers. Some of these are well aligned with Qt Project, for
> example Win, Mac, Linux, and some we work on our own or together with the
> OS vendors (mainly embedded and real-time).

not R&D, but thank you for platform testing!

> We are also investing quite
> much to the releasing and testing, which also benefits the whole Qt
> ecosystem.

not R&D, but thank you for helping the release + testing process!

> We do a hefty amount of error corrections, and contributions to create new
> functionality.

not R&D, but thank you for the bug fixes (<3 4.8.1)!!! The 'create new
functionality' almost counts, except that it's typically only created
upon request by a commercial customer (or customers). Where's a Qt
module that Digia has created from scratch just because they 'thought
it was a good idea and would bring more people to use Qt'? I've seen
the Charts stuff you guys made... it's just so small compared to
Nokia's R&D projects: QML/QtQuick. Nokia is in position to be the ones
pushing R&D... and they are trying too. The problem is that the Nokia
R&D has the objective of solving Nokias financial problems -- not the
bettering of Qt as a whole. Anybody could make the argument that
QML/QtQuick are aimed at bettering Qt as a whole... and I'd agree...
that's where it is aimed. But it is a miss and the core Qt user
(developers) want something else/better... but Nokia just keeps on
trucking along with 'their' vision, blatantly disregarding the core Qt
user.

I have a question for you over at Digia: is your Commercial License
agreement with Nokia permanent? If it is permanent, then I could see
how an R&D department would make sense (hey guys here's a cool idea if
you want to help Qt: Hardware Accelerated C++ GUI API with Bindings).
However, if the agreement is only for a few years, your R&D could be
ripped out from underneath you as Nokia owns all your contributions
:-P. Nokia could simply choose another support company for their next
contract term.

I just don't see Digia R&D being the bleeding edge R&D type that Qt
needs to stay ahead of the game. Digia will focus on/get distracted by
their core business: client work.
Prove me wrong (please (and not with words)).

> Digia has been an active participant in the Qt community
> for well over 5 years. We have created various different solutions with
> Qt, improved Qt in many platforms and created a hefty amount of code for
> Qt 4 and Qt 5. We looked back into some numbers and calculated that in the
> past few years Digia has done well over 3000 contributions to Qt and Qt
> Mobility making Digia the biggest contributor to Qt after Nokia/Trolltech.

and for that, I thank you. Even though it was done in your own
interest, thank you. That's the beauty of open source.

I _don't_ want Qt to fork, it's just a [long-term?] prediction. I want
to eventually be in a position where I am able to contribute to Qt
(this has nothing to do with Qt and everything to do with me). I want
to want to contribute to Qt (this has everything to do with Qt). In
it's current set up, Nokia gets resale rights to my contributions
("get our code and run" is not at all what I'm implying. It's more
like "get our code, profit from it in ways we can't, release it back
to us under a license where we can't profit from it (in the ways they
can)"), and is _NOT_ using the profits (however minimal) towards the
common goals of the core Qt user (which, as polls have shown, is
currently a Hardware Accelerated C++ GUI with Bindings). This does not
make me want to contribute. I don't think it is a healthy open source
project. Err, maybe that's too strong of a way to say it (Nokia or
not, this project isn't dying! Long live Qt [or whatever it is called
in the future]!!!). Better wording: Qt is not as healthy as it could
be. I want to see it thrive. I want to want to contribute... because I
know that if I want to contribute, others will too.

Atlant: thank you for the story/history lesson

d3fault

[Donald Carr]

Please provide a link to your poll when citing it so that people can
look at empirical data:

http://qt-project.org/forums/viewthread/16693/

must be the wrong poll, since that shows QML components being a
primary point of concern. This is out of a sample set of 110 people,
which is infinitesimally small in comparison to the Qt user base. It
would be a stretch to call this a statistically significant poll, even
though it reinforces my own personally opinion/desires. I assume the
poll you are citing has a larger sample size?

I also have to point out that QML is not intended for fart
applications, indeed, QGraphicsView would have given you that quite
heartily. QML will be useful for anyone who wants to have designers
get proactively involved in the UI/system software development of user
interfaces for any number of embedded/dedicated devices. Once the
qmlscene application can run, you can start working directly on the UI
for the final product. We had many Qt customers who attempted to
design competitive UI's with QGraphicsView and ended up throwing away
their work and creating their own canvas type classes from Qt's core
classes due to fundamental constraints in the graphics view
implementation. The first thing most people do is come up with their
own mark up language; XML seems to be popular for this purpose. QML
gets you there out of the box, only with a format which is (arguably)
more readable than XML and with (we hope) a much nicer implementation
than many of our customers will actually produce. QML takes a tricky
problem and, we/(many customers) believe, solves it elegantly. I
expect a much higher success rate for many people who decide to use Qt
and hence QML for their product design. This makes me a very happy
camper, since I am still committed to the "Qt Everywhere" dream, of
which the desktop space is one leg.

Cheers,
Donald

On Mon, May 14, 2012 at 2:20 PM, d3fault <***@gmail.com> wrote:
> On 5/14/12, Turunen Tuukka <***@digia.com> wrote:
>> Just very short comment to this part - Digia, Qt Commercial does also
>> quite significant R&D. Whereas we do have consulting, and support, we do
>> also our share of development. For example we are working in making sure
>> that Qt runs nicely on those platforms that are important to the
>> commercial customers. Some of these are well aligned with Qt Project, for
>> example Win, Mac, Linux, and some we work on our own or together with the
>> OS vendors (mainly embedded and real-time).
>
> not R&D, but thank you for platform testing!
>
>> We are also investing quite
>> much to the releasing and testing, which also benefits the whole Qt
>> ecosystem.
>
> not R&D, but thank you for helping the release + testing process!
>
>> We do a hefty amount of error corrections, and contributions to create new
>> functionality.
>
> not R&D, but thank you for the bug fixes (<3 4.8.1)!!! The 'create new
> functionality' almost counts, except that it's typically only created
> upon request by a commercial customer (or customers). Where's a Qt
> module that Digia has created from scratch just because they 'thought
> it was a good idea and would bring more people to use Qt'? I've seen
> the Charts stuff you guys made... it's just so small compared to
> Nokia's R&D projects: QML/QtQuick. Nokia is in position to be the ones
> pushing R&D... and they are trying too. The problem is that the Nokia
> R&D has the objective of solving Nokias financial problems -- not the
> bettering of Qt as a whole. Anybody could make the argument that
> QML/QtQuick are aimed at bettering Qt as a whole... and I'd agree...
> that's where it is aimed. But it is a miss and the core Qt user
> (developers) want something else/better... but Nokia just keeps on
> trucking along with 'their' vision, blatantly disregarding the core Qt
> user.
>
> I have a question for you over at Digia: is your Commercial License
> agreement with Nokia permanent? If it is permanent, then I could see
> how an R&D department would make sense (hey guys here's a cool idea if
> you want to help Qt: Hardware Accelerated C++ GUI API with Bindings).
> However, if the agreement is only for a few years, your R&D could be
> ripped out from underneath you as Nokia owns all your contributions
> :-P. Nokia could simply choose another support company for their next
> contract term.
>
> I just don't see Digia R&D being the bleeding edge R&D type that Qt
> needs to stay ahead of the game. Digia will focus on/get distracted by
> their core business: client work.
> Prove me wrong (please (and not with words)).
>
>> Digia has been an active participant in the Qt community
>> for well over 5 years. We have created various different solutions with
>> Qt, improved Qt in many platforms and created a hefty amount of code for
>> Qt 4 and Qt 5. We looked back into some numbers and calculated that in the
>> past few years Digia has done well over 3000 contributions to Qt and Qt
>> Mobility making Digia the biggest contributor to Qt after Nokia/Trolltech.
>
> and for that, I thank you. Even though it was done in your own
> interest, thank you. That's the beauty of open source.
>
> I _don't_ want Qt to fork, it's just a [long-term?] prediction. I want
> to eventually be in a position where I am able to contribute to Qt
> (this has nothing to do with Qt and everything to do with me). I want
> to want to contribute to Qt (this has everything to do with Qt). In
> it's current set up, Nokia gets resale rights to my contributions
> ("get our code and run" is not at all what I'm implying. It's more
> like "get our code, profit from it in ways we can't, release it back
> to us under a license where we can't profit from it (in the ways they
> can)"), and is _NOT_ using the profits (however minimal) towards the
> common goals of the core Qt user (which, as polls have shown, is
> currently a Hardware Accelerated C++ GUI with Bindings). This does not
> make me want to contribute. I don't think it is a healthy open source
> project. Err, maybe that's too strong of a way to say it (Nokia or
> not, this project isn't dying! Long live Qt [or whatever it is called
> in the future]!!!). Better wording: Qt is not as healthy as it could
> be. I want to see it thrive. I want to want to contribute... because I
> know that if I want to contribute, others will too.
>
> Atlant: thank you for the story/history lesson
>
> d3fault
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development



--
-------------------------------
 °v°  Donald Carr
/(_)\ Vaguely Professional Penguin lover
 ^ ^

Cave canem, te necet lingendo
Chasing my own tail; hate to see me leave, love to watch me go

[Uwe Rathmann]

On 05/15/2012 02:13 AM, Donald Carr wrote:
> QML will be useful for anyone who wants to have designers
> get proactively involved in the UI/system software development of user
> interfaces for any number of embedded/dedicated devices. Once the
> qmlscene application can run, you can start working directly on the UI
> for the final product.

While I understand the intention I still don't believe, that designers
will be able to implement the complete UI and software engineers can
focus on the rest. Instead I expect a cutting line somewhere in the
middle of the UI code.

My experience is that about 80% of a GUI ( of a large project ) are
trivial and can be done by organizing standard Qt widgets in layouts.
But about 20% of the use cases ( making more than 50 % of the time you
spend on developing a GUI ) are necessary for tweaking the widgets for
some specific behaviour - or look and feel. A C++ framework has always
been a very powerful way to face these requirements. Hope QML doesn't
let us pay more for the last 20% than what we might have won in the
other 80%.

As freelancer I have been part of many commercial Qt projects over the
last 14 years. Please let me add a - maybe surprising - note: none of
them ( really none ! ) used the designer to implement the UI - 100% of
the development teams decided to use plain C++.

Uwe

[BRM]

> From: Donald Carr <***@gmail.com>

> Please provide a link to your poll when citing it so that people can
> look at empirical data:
>
> http://qt-project.org/forums/viewthread/16693/
>
> must be the wrong poll, since that shows QML components being a
> primary point of concern. This is out of a sample set of 110 people,
> which is infinitesimally small in comparison to the Qt user base. It
> would be a stretch to call this a statistically significant poll, even
> though it reinforces my own personally opinion/desires. I assume the
> poll you are citing has a larger sample size?

He did in this e-mail:

http://lists.qt-project.org/pipermail/development/2012-May/003720.html

But the sample sizes are no better than yours - 114/139/19respectively for each poll.
Again, statically insignificant.

It would probably be good for a statistically significant poll to be officially done.
I'd expect that it would probably have a 50/50 split, or may be a 60/40 split in favor of QML
as I do expect there is still a lot of momentum behind the QWidgets and QGraphics* frameworks.
But I doubt that will happen.

> I also have to point out that QML is not intended for fart
> applications, indeed, QGraphicsView would have given you that quite
> heartily. QML will be useful for anyone who wants to have designers
> get proactively involved in the UI/system software development of user
> interfaces for any number of embedded/dedicated devices. Once the
> qmlscene application can run, you can start working directly on the UI
> for the final product. We had many Qt customers who attempted to
> design competitive UI's with QGraphicsView and ended up throwing away
> their work and creating their own canvas type classes from Qt's core
> classes due to fundamental constraints in the graphics view
> implementation. The first thing most people do is come up with their
> own mark up language; XML seems to be popular for this purpose. QML
> gets you there out of the box, only with a format which is (arguably)
> more readable than XML and with (we hope) a much nicer implementation
> than many of our customers will actually produce. QML takes a tricky
> problem and, we/(many customers) believe, solves it elegantly. I
> expect a much higher success rate for many people who decide to use Qt
> and hence QML for their product design. This makes me a very happy
> camper, since I am still committed to the "Qt Everywhere" dream, of
> which the desktop space is one leg.

Interesting tidbit on QGraphicsView. I'm playing around with it now, but not using any thing like that.
Rather, I'm developing some custom widgets that will go into the QGraphicsScene; still learning a lot
in the process - and have a long way to go; but I'm getting comfortable with it now. (That said, I've
only been working with the QGraphics* APIs for about 2 months on and off, perhaps 1 or 2 weeks solid.)
Of course, I am also going this route as the C++ API makes better sense for me, and it leaves open the ability
to later move to the QML API if I wanted.

However, thus far for display I've mostly done customized QWidget derived classes. I still would be except that I have
a use case (some complex display widgets) that benefits from the QGraphics* APIs better.

Ben

[André Pönitz]

On Tue, May 15, 2012 at 07:13:19AM -0700, BRM wrote:
> > From: Donald Carr <***@gmail.com>
> > [...] This is out of a sample set of 110 people, which is
> > infinitesimally small in comparison to the Qt user base. It would
> > be a stretch to call this a statistically significant poll, [...]
>
> [...] But the sample sizes are no better than yours - 114/139/19
> respectively for each poll. Again, statically insignificant.

I wonder how the two of you came to the conclusion of statistical
insignificance, and how you explain the apparent discrepancy of this
result with, say, the section titled "Estimating proportions and means"
on http://en.wikipedia.org/wiki/Sample_size_determination. [1]

I trust the audience would be delighted if you gave some insight
into the calculation.

Andre'

[1] That link is admittedly a random pick, but Wikipedia seems to
be an acceptable replacement for lecture notes nowadays.

[André Somers]

Op 16-5-2012 1:31, André Pönitz schreef:
> On Tue, May 15, 2012 at 07:13:19AM -0700, BRM wrote:
>>> From: Donald Carr<***@gmail.com>
>>> [...] This is out of a sample set of 110 people, which is
>>> infinitesimally small in comparison to the Qt user base. It would
>>> be a stretch to call this a statistically significant poll, [...]
>> [...] But the sample sizes are no better than yours - 114/139/19
>> respectively for each poll. Again, statically insignificant.
> I wonder how the two of you came to the conclusion of statistical
> insignificance, and how you explain the apparent discrepancy of this
> result with, say, the section titled "Estimating proportions and means"
> on http://en.wikipedia.org/wiki/Sample_size_determination. [1]
>
> I trust the audience would be delighted if you gave some insight
> into the calculation.
>
> Andre'
>
> [1] That link is admittedly a random pick, but Wikipedia seems to
> be an acceptable replacement for lecture notes nowadays.
>
If we're throwing wikipedia links back and forth anyway, also consult
http://en.wikipedia.org/wiki/Sampling_%28statistics%29#Errors_in_sample_surveys
please. I agree with you that perhaps the sample _size_ is not an issue,
but the sample suffers from *many* of the errors mentioned on the URL
above, including selection bias, undercoverage and measurement error.
Doing good surveys is just plain hard to do, and the polls discussed so
far certainly don't qualify as "good" or even "acceptable". There are
people getting a PhD on this kind of thing...

However, I think the whole point is moot. I don't think the people who
get to decide - that is, those doing or funding the actual work - care
much about any such statistics, no matter if they are sound or not. And
more generally: facts don't seem to matter much in this discussion
either for some participants, or at least not those facts that tell a
different story than they want to hear.

André

[Samuel Rødal]

On 05/16/2012 11:14 AM, ext André Somers wrote:
> Op 16-5-2012 1:31, André Pönitz schreef:
>> On Tue, May 15, 2012 at 07:13:19AM -0700, BRM wrote:
>>>> From: Donald Carr<***@gmail.com>
>>>> [...] This is out of a sample set of 110 people, which is
>>>> infinitesimally small in comparison to the Qt user base. It would
>>>> be a stretch to call this a statistically significant poll, [...]
>>> [...] But the sample sizes are no better than yours - 114/139/19
>>> respectively for each poll. Again, statically insignificant.
>> I wonder how the two of you came to the conclusion of statistical
>> insignificance, and how you explain the apparent discrepancy of this
>> result with, say, the section titled "Estimating proportions and means"
>> on http://en.wikipedia.org/wiki/Sample_size_determination. [1]
>>
>> I trust the audience would be delighted if you gave some insight
>> into the calculation.
>>
>> Andre'
>>
>> [1] That link is admittedly a random pick, but Wikipedia seems to
>> be an acceptable replacement for lecture notes nowadays.
>>
> If we're throwing wikipedia links back and forth anyway, also consult
> http://en.wikipedia.org/wiki/Sampling_%28statistics%29#Errors_in_sample_surveys
> please. I agree with you that perhaps the sample _size_ is not an issue,
> but the sample suffers from *many* of the errors mentioned on the URL
> above, including selection bias, undercoverage and measurement error.
> Doing good surveys is just plain hard to do, and the polls discussed so
> far certainly don't qualify as "good" or even "acceptable". There are
> people getting a PhD on this kind of thing...
>
> However, I think the whole point is moot. I don't think the people who
> get to decide - that is, those doing or funding the actual work - care
> much about any such statistics, no matter if they are sound or not. And
> more generally: facts don't seem to matter much in this discussion
> either for some participants, or at least not those facts that tell a
> different story than they want to hear.
>
> André

It's worth noting that the Qt project is designed to be a meritocracy,
not a democracy.

--
Samuel

[Giuseppe D'Angelo]

> It's worth noting that the Qt project is designed to be a meritocracy,
> not a democracy.

Most important: a do-cracy. Changes don't happen if everybody talks
and nobody writes the code.

--
Giuseppe D'Angelo

[Atlant Schmidt]

Samuel:

> It's worth noting that the Qt project is designed to
> be a meritocracy, not a democracy.

What this ignores, though, is the fact that the *CONSUMERS*
of the Qt product are not necessarily at all congruent with
the *DEVELOPERS* of the Qt product. (While there's some
cross-over, I'll bet there's a lot less than many assume.)

Qt "the product" may be developed by a meritocracy of devel-
opers but it damned-well better respond in a more-or-less
democratic way to the needs/demands of the consumers of the
product. If it doesn't, those consumers will move on to
using other frameworks.

Atlant


This e-mail and the information, including any attachments, it contains are intended to be a confidential communication only to the person or entity to whom it is addressed and may contain information that is privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender and destroy the original message.

Thank you.

Please consider the environment before printing this email.

[Robin Burchell]

On Wed, May 16, 2012 at 4:42 PM, Atlant Schmidt
<***@dekaresearch.com> wrote:
>  Qt "the product" may be developed by a meritocracy of devel-
>  opers but it damned-well better respond in a more-or-less
>  democratic way to the needs/demands of the consumers of the
>  product. If it doesn't, those consumers will move on to
>  using other frameworks.

That isn't how reality works. You cannot tell me (as a volunteer) what
I ought to be spending my time on any more than I can tell you what
color to paint your livingroom. My interests dictate what I invest my
time into, not random people on the internet. As a developer working
on Qt, I will probably keep users' interests in mind, but at the end
of the day, it's still my decision.

Now, these "consumers" might get lucky a lot of the time and find that
what I consider fun usually matches up with what they desire from an
application development framework, but there's no guarentee for that.
If they want one, then they have to invest time or money into making
it happen - there really is no such thing as a completely free lunch.

[Thiago Macieira]

On quarta-feira, 16 de maio de 2012 16.56.05, Robin Burchell wrote:
> That isn't how reality works. You cannot tell me (as a volunteer) what
> I ought to be spending my time on any more than I can tell you what
> color to paint your livingroom. My interests dictate what I invest my
> time into, not random people on the internet. As a developer working
> on Qt, I will probably keep users' interests in mind, but at the end
> of the day, it's still my decision.
>
> Now, these "consumers" might get lucky a lot of the time and find that
> what I consider fun usually matches up with what they desire from an
> application development framework, but there's no guarentee for that.
> If they want one, then they have to invest time or money into making
> it happen - there really is no such thing as a completely free lunch.

All that you said there is true, but incomplete for the context.

Even though the consumers cannot demand anything from volunteer contributors,
there is a an important overlap between what the consumers want and what the
contributors want to work on. Or, at the very least, there should be.

If we, as the contributors, do not pay attention to what our users want, we'll
produce a toolkit that no one wants to use. Therefore, it is in our best
interest to keep the users present and happy with the functionality. That's
the only way to ensure the long-term survival of the project.

But note also that the overlap is not 100% and will probably never be.
Sometimes, users want too much, or don't know exactly what they want. There
must be room for the contributors to exercise their imaginations and come up
with new, revolutionary solutions.

I firmly believe that QML is in that camp.

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Intel Sweden AB - Registration Number: 556189-6027
Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden

[BRM]

> From: Thiago Macieira <***@intel.com>

>On quarta-feira, 16 de maio de 2012 16.56.05, Robin Burchell wrote:
>> That isn't how reality works. You cannot tell me (as a volunteer) what
>> I ought to be spending my time on any more than I can tell you what
>> color to paint your livingroom. My interests dictate what I invest my
>> time into, not random people on the internet. As a developer working
>> on Qt, I will probably keep users' interests in mind, but at the end
>> of the day, it's still my decision.
>>
>> Now, these "consumers" might get lucky a lot of the time and find that
>> what I consider fun usually matches up with what they desire from an
>> application development framework, but there's no guarentee for that.
>> If they want one, then they have to invest time or money into making
>> it happen - there really is no such thing as a completely free lunch.
>
>All that you said there is true, but incomplete for the context.
>
>Even though the consumers cannot demand anything from volunteer contributors,
>there is a an important overlap between what the consumers want and what the
>contributors want to work on. Or, at the very least, there should be.
>
>If we, as the contributors, do not pay attention to what our users want, we'll
>produce a toolkit that no one wants to use. Therefore, it is in our best
>interest to keep the users present and happy with the functionality. That's
>the only way to ensure the long-term survival of the project.
>
>But note also that the overlap is not 100% and will probably never be.
>Sometimes, users want too much, or don't know exactly what they want. There
>must be room for the contributors to exercise their imaginations and come up
>with new, revolutionary solutions.
>
>I firmly believe that QML is in that camp.
>


I agree that QML is certainly in that camp; though the ignoring of QWidget is the issue.
And as has been said, the "consumers" are typically commercial customers that are paying Digia;
and if it is a big issue, then they should be raising that through their Digia support to get the work done.

If they're a commercial customer, then they either need to become one or do something (volunteer or pay a volunteer) to get the work done.

It's not that they are not contributing (and thus trying to necessarily get a free lunch) - contributing takes many forms - from coding, to documentation, to artwork, to support, and even giving feedback on the direction of things as an end-user of the tool-kit. If the feed back cycle clashes, then it needs to get backed up with contribution in coding, or monetary support of a coder, to get it done.


Ben


P.S. Sadly, I think the person that
keeps the thread mainly alive is more at odds with the CLA than anything else (all else just being a reason to complain about the CLA), which
won't get resolved to their satisfaction any time soon if ever. (At
least, that's the conclusion I've drawn.) If that's the case, then let's please end this thread as it is going to continue going nowhere.

[Thiago Macieira]

On quarta-feira, 16 de maio de 2012 09.51.52, BRM wrote:
> I agree that QML is certainly in that camp; though the ignoring of QWidget
> is the issue.

No one is ignoring QWidget. We know it's there and what it's being used for.
No one here is under the illusion that QWidget isn't important.

It is.

But it's also built on an obsolete architecture. The QPainter architecture is
from the 90s and, through our attempts at optimising it from 2007 to 2010,
we've reached its limits.

Graphics hardware has changed in the past 10 years, especially in the past 5.
We need a new architecture, which means building stuff from the ground up with
it. It requires a scene graph with retained-mode painting.

> And as has been said, the "consumers" are typically
> commercial customers that are paying Digia; and if it is a big issue, then
> they should be raising that through their Digia support to get the work
> done.

That is not what I meant by "consumers" in my email and I doubt that it's what
Robin did either. I meant any developer using the Qt framework, regardless of
whether they're using the Open Source version or they're paying Digia for a
commercial licence.

> If they're a commercial customer, then they either need to become one or do
> something (volunteer or pay a volunteer) to get the work done.

If they're paying any company for a service, they should talk to that company
to make their wishes heard.

> It's not that they are not contributing (and thus trying to necessarily get
> a free lunch) - contributing takes many forms - from coding, to
> documentation, to artwork, to support, and even giving feedback on the
> direction of things as an end-user of the tool-kit. If the feed back cycle
> clashes, then it needs to get backed up with contribution in coding, or
> monetary support of a coder, to get it done.

Agreed.

Trust me, I don't consider anyone in this mailing list as "getting a free
lunch". Even the loudest complainers with no contribution record aren't in
that category. I appreciate all the feedback, I know the project as a whole
does too, even if some individual contributors might feel differently.

That does not equate to abiding by every single suggestion posted. As Robin so
eloquently put it, each developer contributor will choose how best to use
their time and skills, given what they can do, what they know how to do, what
is being asked, what they think should be done. For those of us working for
companies, also what our employers ask of us.

In my case, just to give you an idea, the biggest challenge I get these days
is the ability to productise an application quickly, with a constant and fluid
animated interface, with performance in memory and CPU usage comparable to
other leading toolkits (in particular, EFL). The scene graph and the QML
language are our answers to that, though they have yet to prove it.

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Intel Sweden AB - Registration Number: 556189-6027
Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden

[Atlant Schmidt]

Robin:

Thank you for explaining, succinctly, one of the critical
differences between commercial software and FOSS: Commercial
software contains those features that the customers will pay
for while FOSS only contains features that the developers are
interested in developing (for their own use or as a hobby).

The FOSS developers *HOPE* that their interests are congruent
with those of the mere customers and at least in QT's world,
there's some evidence that this is true for some customers
but there is also mounting evidence that this is decidedly
*NOT TRUE* for other customers, hence our current debate
about QML Qt versus QWidget Qt.

Atlant

-----Original Message-----
From: ***@viroteck.net [mailto:***@viroteck.net] On Behalf Of Robin Burchell
Sent: Wednesday, May 16, 2012 10:56
To: Atlant Schmidt
Cc: Samuel Rødal; ***@qt-project.org
Subject: Re: [Development] The place of QML

On Wed, May 16, 2012 at 4:42 PM, Atlant Schmidt
<***@dekaresearch.com> wrote:
> Qt "the product" may be developed by a meritocracy of devel-
> opers but it damned-well better respond in a more-or-less
> democratic way to the needs/demands of the consumers of the
> product. If it doesn't, those consumers will move on to
> using other frameworks.

That isn't how reality works. You cannot tell me (as a volunteer) what
I ought to be spending my time on any more than I can tell you what
color to paint your livingroom. My interests dictate what I invest my
time into, not random people on the internet. As a developer working
on Qt, I will probably keep users' interests in mind, but at the end
of the day, it's still my decision.

Now, these "consumers" might get lucky a lot of the time and find that
what I consider fun usually matches up with what they desire from an
application development framework, but there's no guarentee for that.
If they want one, then they have to invest time or money into making
it happen - there really is no such thing as a completely free lunch.


Click https://www.mailcontrol.com/sr/!hmStUNsYDfTndxI!oX7UjaeDmea67kXLk1jeKSne4!TD8J5caSzi90WG+xb54nHZ5eSfD5YlkMNL52V0szYFQ== to report this email as spam.

This e-mail and the information, including any attachments, it contains are intended to be a confidential communication only to the person or entity to whom it is addressed and may contain information that is privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender and destroy the original message.

Thank you.

Please consider the environment before printing this emai

[Thiago Macieira]

On quarta-feira, 16 de maio de 2012 13.24.25, Atlant Schmidt wrote:
> The FOSS developers HOPE that their interests are congruent
> with those of the mere customers and at least in QT's world,
> there's some evidence that this is true for some customers
> but there is also mounting evidence that this is decidedly
> NOT TRUE for other customers, hence our current debate
> about QML Qt versus QWidget Qt.

That's not exactly true. The debate isn't about QML vs QWidget. The core of
the debate, as far as I can see, is whether there should be a C++ interface
for making UIs with the new technology.

I haven't seen anyone support QWidget itself in this thread. Moreover, I doubt
most people know the challenges with enhancing QWidget further. Consider this:
the QWidget & QPainter imperative painting technology is Done. It's not a
matter of taste, it's fact: graphical technology has moved on.

Sure, there will still be some uses for QPainter, just as QWidget will remain
there for a few years to come. That's not the point.

But the point is that we need something new to take Qt forward and be the
basis for the next 5-10 years. The suggestion so far is QML & scene graph and
with a few tweaks it could be made to suit most people's requests.

No one has suggested an alternative.

So I suggest we spend our energy discussing those tweaks I mention, what's
necessary to make the technology more attractive to current developers, what
the impact on maintenance will be, etc.

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Intel Sweden AB - Registration Number: 556189-6027
Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden

[qtnext]

I am using Qt since 12 years or more... I have done a lot of work using
qwidget, qgraphiscview, ....
I have done some small apps with qml to display media : it works very
well ... just the animation are a a litlle bit jerky and work not well
on very small computer ...
But now that Qt5 is here : the alpha seems very promising regarding
performance ... and I have started a new big desktop application and I
plan to use only Qml and it seems very promising .. I am sure that
Quick2 is the way for new desktop application : We only need Qt desktop
components, treeview, ... and it will rocks :)

Regarding user wishes : it's sure that we are not at the Trolltech old
good time and at the start of Qt Nokia : in old time, we were important
... there was poll to see what customer wants ..(I was a commercial
customer user and I have now switch to lgpl). Now when you are ok with
what's happen.. the only answer is :"ok, just do it"... time have
changed :( but in fact, I trust what Qt developer thinks that it's good
or not... The only big question for me is "What is the Qt futur
regarding Nokia/Microsoft Relation, Nokia Meltemi or not ..." What is
the commercial future that means that Nokia will continue to invest in
the future in Qt ... I know there is the joke of the fork ... just a
joke ... just try to imagine the resource you need to do "qml
scenegraph" that some people don't like ... you need taleantuous
developer to pay, infrastructure, ... it's not possible to do that as an
hobby open source project .... Fork means nothing without money...


Le 16/05/2012 19:49, Thiago Macieira a écrit :
> On quarta-feira, 16 de maio de 2012 13.24.25, Atlant Schmidt wrote:
>> The FOSS developers HOPE that their interests are congruent
>> with those of the mere customers and at least in QT's world,
>> there's some evidence that this is true for some customers
>> but there is also mounting evidence that this is decidedly
>> NOT TRUE for other customers, hence our current debate
>> about QML Qt versus QWidget Qt.
> That's not exactly true. The debate isn't about QML vs QWidget. The core of
> the debate, as far as I can see, is whether there should be a C++ interface
> for making UIs with the new technology.
>
> I haven't seen anyone support QWidget itself in this thread. Moreover, I doubt
> most people know the challenges with enhancing QWidget further. Consider this:
> the QWidget& QPainter imperative painting technology is Done. It's not a
> matter of taste, it's fact: graphical technology has moved on.
>
> Sure, there will still be some uses for QPainter, just as QWidget will remain
> there for a few years to come. That's not the point.
>
> But the point is that we need something new to take Qt forward and be the
> basis for the next 5-10 years. The suggestion so far is QML& scene graph and
> with a few tweaks it could be made to suit most people's requests.
>
> No one has suggested an alternative.
>
> So I suggest we spend our energy discussing those tweaks I mention, what's
> necessary to make the technology more attractive to current developers, what
> the impact on maintenance will be, etc.
>
>
>
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

[Peter Kümmel]

On 16.05.2012 20:31, qtnext wrote:
> I am using Qt since 12 years or more... I have done a lot of work using qwidget, qgraphiscview, ....
> I have done some small apps with qml to display media : it works very well ... just the animation are a a litlle bit
> jerky and work not well on very small computer ...
> But now that Qt5 is here : the alpha seems very promising regarding performance ... and I have started a new big desktop
> application and I plan to use only Qml and it seems very promising .. I am sure that Quick2 is the way for new desktop
> application : We only need Qt desktop components, treeview, ... and it will rocks :)

Yes, that's the point. Most people don't care what happens under the hood (QWidget or QML)
when good desktop support is available. But currently for desktop apps you have the choice
between a "obsolete architecture" (Thiago) and an incomplete QML stack.

Non technicians don't care about if QWidget is done or not if it fits the needs,
but we are developers! We don't wanna use obsolete stuff with a
"architecture from the 90s" in times where "graphical technology has moved on" (Thiago).
But on the desktop we are forced to when we wanna a feature rich/complete framework.

So all the QML<->QWidget discussions are mainly because there is no complete Qml support on the desktop.

Desktop support has no high priority more anywhere.
It couldn't be so complex to make good Qml support on the desktop, simply throw
5 man years on it (shouldn't be impossible when there are already 200 Qt developers
at Nokia alone). But it doesn't happen because nobody wanna invest in the desktop.

So all you can do is using a system with a "obsolete architecture", diving deep
into QML and writing your own desktop elements, or waiting another one or two years.

And I don't like any of the options.

Peter

[Atlant Schmidt]

Peter, et al.:

> We don't wanna use obsolete stuff with a "architecture from
> the 90s" in times where "graphical technology has moved on" (Thiago).

Computer architectures don't necessarily "become obsolete".
Oh, trends come and trends go, but the fundamental concepts
go on forever. For example, Linux is quite popular even
though it is arguably a "computer architecture from 1970".

Often, the proponents arguing for "new and improved" are
simply arguing for the position they think will be most fun
to work on; after all, it's always more fun to break exciting
new ground than it is to have trod the same old sod yet again.
But many of these new approaches are just "fashion" and if you
wait a few years, fashions will change again and "old and
obsolete" will be back in fashion (and often, simply because
good sense has returned to the design community).


> Most people don't care what happens under the hood (QWidget
> or QML) when good desktop support is available.

And some of us *DO* care very much what goes on under the
hood. Me, I live in an embedded world running on a ~450 MHz
processor with very limited RAM and graphics. There's just
enough "stuff" there to make the traditional Qt approach
work (just barely) but if the only choice Qt intends to
offer me in the future is going to burden me with the
overhead of a JavaScript (or even web) runtime, then I'm
going to need a new graphical framework.

Old and obsolete worked for me; New and improved (in this
case) clearly isn't likely to.

Atlant

-----Original Message-----
From: development-bounces+aschmidt=***@qt-project.org [mailto:development-bounces+aschmidt=***@qt-project.org] On Behalf Of Peter Kümmel
Sent: Thursday, May 17, 2012 02:12
To: ***@qt-project.org
Subject: Re: [Development] The place of QML

On 16.05.2012 20:31, qtnext wrote:
> I am using Qt since 12 years or more... I have done a lot of work using qwidget, qgraphiscview, ....
> I have done some small apps with qml to display media : it works very well ... just the animation are a a litlle bit
> jerky and work not well on very small computer ...
> But now that Qt5 is here : the alpha seems very promising regarding performance ... and I have started a new big desktop
> application and I plan to use only Qml and it seems very promising .. I am sure that Quick2 is the way for new desktop
> application : We only need Qt desktop components, treeview, ... and it will rocks :)

Yes, that's the point. Most people don't care what happens under the hood (QWidget or QML)
when good desktop support is available. But currently for desktop apps you have the choice
between a "obsolete architecture" (Thiago) and an incomplete QML stack.

Non technicians don't care about if QWidget is done or not if it fits the needs,
but we are developers! We don't wanna use obsolete stuff with a
"architecture from the 90s" in times where "graphical technology has moved on" (Thiago).
But on the desktop we are forced to when we wanna a feature rich/complete framework.

So all the QML<->QWidget discussions are mainly because there is no complete Qml support on the desktop.

Desktop support has no high priority more anywhere.
It couldn't be so complex to make good Qml support on the desktop, simply throw
5 man years on it (shouldn't be impossible when there are already 200 Qt developers
at Nokia alone). But it doesn't happen because nobody wanna invest in the desktop.

So all you can do is using a system with a "obsolete architecture", diving deep
into QML and writing your own desktop elements, or waiting another one or two years.

And I don't like any of the options.

Peter


This e-mail and the information, including any attachments, it contains are intended to be a confidential communication only to the person or entity to whom it is addressed and may contain information that is privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender and destroy the original message.

Thank you.

Please consider the environment before printing this email.

[Иван Комиссаров]

Well, i do care about what happen to QWidgets. Maybe i'm old-fashioned (i'm 23 years old, heh), but i do have lot of code based on QWidgets. And that code works. So, you suggest me to thow away all code i've made, because QWidgets have bad design? And whst i got? Unfinished yet QML? Thanks, i'd better won't use Qt anymore.

I don't have anything against QML as a technology - it is really good idea. But it breaks existing code. And provides very few advantages instead - most animations i can implement using QAnimation classes. And desktop applications don't need those animations - even Mac has quite few animations - they don't animate _everything_. Most i see on my mac can be done using QWidgets.

I want to have my code working from now and forever (while qt lives). Alternate technologies are good while i can mix technologies (Qt Creator's start screen is a good example). I want to use beautiful, custom QML interface for contact list/chat window of my (hypotetical) IM Messenger, but i'd still prefer to use plain QWidget's for it's preferences windows and dialogs.
You're trying to tell me that i have to use QML everywhere. I don't like that.

[Quim Gil]

This has been said before, but for the sake of clarity:

On 05/17/2012 05:42 AM, ext Иван Комиссаров wrote:
> i do have lot of code
> based on QWidgets. And that code works. So, you suggest me to thow
> away all code i've made, because QWidgets have bad design?

No, we suggest you to run that code with Qt 5 and let us know if you
found any problem.



> I want to have my code working from now and forever (while qt lives).

Isn't this the current situation? DONE != DEPRECATED

> Alternate technologies are good while i can mix technologies (Qt
> Creator's start screen is a good example). I want to use beautiful,
> custom QML interface for contact list/chat window of my (hypotetical)
> IM Messenger, but i'd still prefer to use plain QWidget's for it's
> preferences windows and dialogs.

You can do exactly this if you wish, isn't it.

> You're trying to tell me that i have
> to use QML everywhere. I don't like that.

What the Qt Project is saying through its releases is that Qt Quick will
be available in any Qt enabled platform, while the inclusion of Qt
Widget is up to the maintainers of each platform (or up to application
developers if they want / can bring the module through dependencies).

For all I could read from Lars and other maintainers, but they are
saying is that Qt Widgets should work, Qt Quick is the present for
mobile and possible the future for everybody, and it is up to you to
decide when or how you want to jump - if you ever need to.

--
Quim

[Quim Gil]

This has been said before, but for the sake of clarity:

On 05/17/2012 05:42 AM, ext Иван Комиссаров wrote:
> i do have lot of code
> based on QWidgets. And that code works. So, you suggest me to thow
> away all code i've made, because QWidgets have bad design?

No, we suggest you to run that code with Qt 5 and let us know if you
found any problem.



> I want to have my code working from now and forever (while qt lives).

Isn't this the current situation? DONE != DEPRECATED

> Alternate technologies are good while i can mix technologies (Qt
> Creator's start screen is a good example). I want to use beautiful,
> custom QML interface for contact list/chat window of my (hypotetical)
> IM Messenger, but i'd still prefer to use plain QWidget's for it's
> preferences windows and dialogs.

You can do exactly this if you wish, isn't it.

> You're trying to tell me that i have
> to use QML everywhere. I don't like that.

What the Qt Project is saying through its releases is that Qt Quick will
be available in any Qt enabled platform, while the inclusion of Qt
Widget is up to the maintainers of each platform (or up to application
developers if they want / can bring the module through dependencies).

For all I could read from Lars and other maintainers, but they are
saying is that Qt Widgets should work, Qt Quick is the present for
mobile and possible the future for everybody, and it is up to you to
decide when or how you want to jump - if you ever need to.

--
Quim

[Peter Kümmel]

On 17.05.2012 14:42, Иван Комиссаров wrote:
> Well, i do care about what happen to QWidgets. Maybe i'm old-fashioned (i'm 23 years old, heh), but i do have lot of code based on QWidgets. And that code works. So, you suggest me to thow away all code i've made, because QWidgets have bad design? And whst i got? Unfinished yet QML? Thanks, i'd better won't use Qt anymore.
>
> I don't have anything against QML as a technology - it is really good idea. But it breaks existing code. And provides very few advantages instead - most animations i can implement using QAnimation classes. And desktop applications don't need those animations - even Mac has quite few animations - they don't animate _everything_. Most i see on my mac can be done using QWidgets.
>
> I want to have my code working from now and forever (while qt lives). Alternate technologies are good while i can mix technologies (Qt Creator's start screen is a good example). I want to use beautiful, custom QML interface for contact list/chat window of my (hypotetical) IM Messenger, but i'd still prefer to use plain QWidget's for it's preferences windows and dialogs.
> You're trying to tell me that i have to use QML everywhere. I don't like that.

No, I didn't say you should replace your QWidget code with QML based.

When you are happy with QWidget, use it. QWidgets will stay for a long
time in Qt. I assume problems with QWidgets will also be a
show-stopper for a new Qt release.

But in Trolltech times, each new Qt release was a event for desktop
developers: new widget, new features, improved widgets.
I could remember the fascination when webkit was added to Qt!

Now a Qt release became a bit boring for QWidget users. All you
get are some bug fixes.

Actually QWidgets is in a feature freeze like mode, because neither
Nokia/Digia nor others are working on new QWidget based stuff.
Only bugs will be fixed. Doesn't other companies call this
mode "maintance".

But this is also a chance: on the long run QWidgets will become
one of the most bug-free parts within Qt. Which is also a benefit for
embedded systems where a update is much more expensive and complicated
than on a desktop system.

This is the good thing about the 'Done' status.

Peter

[Peter Kümmel]

On 17.05.2012 12:35, Atlant Schmidt wrote:
> Peter, et al.:
>
>> We don't wanna use obsolete stuff with a "architecture from
>> the 90s" in times where "graphical technology has moved on" (Thiago).
>
> Computer architectures don't necessarily "become obsolete".
> Oh, trends come and trends go, but the fundamental concepts
> go on forever. For example, Linux is quite popular even
> though it is arguably a "computer architecture from 1970".
>
> Often, the proponents arguing for "new and improved" are
> simply arguing for the position they think will be most fun
> to work on; after all, it's always more fun to break exciting
> new ground than it is to have trod the same old sod yet again.
> But many of these new approaches are just "fashion" and if you
> wait a few years, fashions will change again and "old and
> obsolete" will be back in fashion (and often, simply because
> good sense has returned to the design community).
>
>
>> Most people don't care what happens under the hood (QWidget
>> or QML) when good desktop support is available.
>
> And some of us *DO* care very much what goes on under the
> hood. Me, I live in an embedded world running on a ~450 MHz
> processor with very limited RAM and graphics. There's just
> enough "stuff" there to make the traditional Qt approach
> work (just barely) but if the only choice Qt intends to
> offer me in the future is going to burden me with the
> overhead of a JavaScript (or even web) runtime, then I'm
> going to need a new graphical framework.
>
> Old and obsolete worked for me; New and improved (in this
> case) clearly isn't likely to.

Then Qt Widgets is perfect for you: mature, stable API. You
only would have a problem when you have to implement features
which are much better supported by QML.

>
> Atlant
>
> -----Original Message-----
> From: development-bounces+aschmidt=***@qt-project.org [mailto:development-bounces+aschmidt=***@qt-project.org] On Behalf Of Peter Kümmel
> Sent: Thursday, May 17, 2012 02:12
> To: ***@qt-project.org
> Subject: Re: [Development] The place of QML
>
> On 16.05.2012 20:31, qtnext wrote:
>> I am using Qt since 12 years or more... I have done a lot of work using qwidget, qgraphiscview, ....
>> I have done some small apps with qml to display media : it works very well ... just the animation are a a litlle bit
>> jerky and work not well on very small computer ...
>> But now that Qt5 is here : the alpha seems very promising regarding performance ... and I have started a new big desktop
>> application and I plan to use only Qml and it seems very promising .. I am sure that Quick2 is the way for new desktop
>> application : We only need Qt desktop components, treeview, ... and it will rocks :)
>
> Yes, that's the point. Most people don't care what happens under the hood (QWidget or QML)
> when good desktop support is available. But currently for desktop apps you have the choice
> between a "obsolete architecture" (Thiago) and an incomplete QML stack.
>
> Non technicians don't care about if QWidget is done or not if it fits the needs,
> but we are developers! We don't wanna use obsolete stuff with a
> "architecture from the 90s" in times where "graphical technology has moved on" (Thiago).
> But on the desktop we are forced to when we wanna a feature rich/complete framework.
>
> So all the QML<->QWidget discussions are mainly because there is no complete Qml support on the desktop.
>
> Desktop support has no high priority more anywhere.
> It couldn't be so complex to make good Qml support on the desktop, simply throw
> 5 man years on it (shouldn't be impossible when there are already 200 Qt developers
> at Nokia alone). But it doesn't happen because nobody wanna invest in the desktop.
>
> So all you can do is using a system with a "obsolete architecture", diving deep
> into QML and writing your own desktop elements, or waiting another one or two years.
>
> And I don't like any of the options.
>
> Peter
>
>
> This e-mail and the information, including any attachments, it contains are intended to be a confidential communication only to the person or entity to whom it is addressed and may contain information that is privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender and destroy the original message.
>
> Thank you.
>
> Please consider the environment before printing this email.
>

[Atlant Schmidt]

Peter:

> Then Qt Widgets is perfect for you: mature, stable API. You
> only would have a problem when you have to implement features
> which are much better supported by QML.

Did I mention that we're also coded to depend upon QWS, the
QT Embedded Window System? ;-)

That feature is no longer available in Qt 5.x. And switching
to Lighthouse would require substantial recoding on our part.

Atlant

-----Original Message-----

From: development-bounces+aschmidt=***@qt-project.org [mailto:development-bounces+aschmidt=***@qt-project.org] On Behalf Of Peter Kümmel
Sent: Thursday, May 17, 2012 12:24
Cc: ***@qt-project.org
Subject: Re: [Development] The place of QML

On 17.05.2012 12:35, Atlant Schmidt wrote:
> Peter, et al.:
>
>> We don't wanna use obsolete stuff with a "architecture from
>> the 90s" in times where "graphical technology has moved on" (Thiago).
>
> Computer architectures don't necessarily "become obsolete".
> Oh, trends come and trends go, but the fundamental concepts
> go on forever. For example, Linux is quite popular even
> though it is arguably a "computer architecture from 1970".
>
> Often, the proponents arguing for "new and improved" are
> simply arguing for the position they think will be most fun
> to work on; after all, it's always more fun to break exciting
> new ground than it is to have trod the same old sod yet again.
> But many of these new approaches are just "fashion" and if you
> wait a few years, fashions will change again and "old and
> obsolete" will be back in fashion (and often, simply because
> good sense has returned to the design community).
>
>
>> Most people don't care what happens under the hood (QWidget
>> or QML) when good desktop support is available.
>
> And some of us *DO* care very much what goes on under the
> hood. Me, I live in an embedded world running on a ~450 MHz
> processor with very limited RAM and graphics. There's just
> enough "stuff" there to make the traditional Qt approach
> work (just barely) but if the only choice Qt intends to
> offer me in the future is going to burden me with the
> overhead of a JavaScript (or even web) runtime, then I'm
> going to need a new graphical framework.
>
> Old and obsolete worked for me; New and improved (in this
> case) clearly isn't likely to.

Then Qt Widgets is perfect for you: mature, stable API. You
only would have a problem when you have to implement features
which are much better supported by QML.

>
> Atlant


This e-mail and the information, including any attachments, it contains are intended to be a confidential communication only to the person or entity to whom it is addressed and may contain information that is privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender and destroy the original message.

Thank you.

Please consider the environment before printing this email.

[Girish Ramakrishnan]

Hi Atlant,

On Thu, May 17, 2012 at 11:18 AM, Atlant Schmidt
<***@dekaresearch.com> wrote:
> Peter:
>
>> Then Qt Widgets is perfect for you: mature, stable API. You
>> only would have a problem when you have to implement features
>> which are much better supported by QML.
>
>  Did I mention that we're also coded to depend upon QWS, the
>  QT Embedded Window System? ;-)
>
>  That feature is no longer available in Qt 5.x. And switching
>  to Lighthouse would require substantial recoding on our part.
>

Substantial recoding on the application side? What features of QWS are
you relying on that is missing in QPA?

Girish

[Atlant Schmidt]

Girish:

> Substantial recoding on the application side? What features
> of QWS are you relying on that is missing in QPA?

The ability for multiple processes to share a single
display device (framebuffer).

Atlant

-----Original Message-----
From: Girish Ramakrishnan [mailto:***@forwardbias.in]
Sent: Thursday, May 17, 2012 14:45
To: Atlant Schmidt
Cc: Peter Kümmel; ***@qt-project.org
Subject: Re: [Development] The place of QML

Hi Atlant,

On Thu, May 17, 2012 at 11:18 AM, Atlant Schmidt
<***@dekaresearch.com> wrote:
> Peter:
>
>> Then Qt Widgets is perfect for you: mature, stable API. You
>> only would have a problem when you have to implement features
>> which are much better supported by QML.
>
> Did I mention that we're also coded to depend upon QWS, the
> QT Embedded Window System? ;-)
>
> That feature is no longer available in Qt 5.x. And switching
> to Lighthouse would require substantial recoding on our part.
>

Substantial recoding on the application side? What features of QWS are
you relying on that is missing in QPA?

Girish


Click https://www.mailcontrol.com/sr/!5h1tFjp!BTTndxI!oX7UjaeDmea67kXS6AJ88SEevq917ySvmChLwlntfJopcq6AhIJK9UnN0t8TccP!XTbKg== to report this email as spam.

This e-mail and the information, including any attachments, it contains are intended to be a confidential communication only to the person or entity to whom it is addressed and may contain information that is privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender and destroy the original message.

Thank you.

Please consider the environment before printing this email.

[Thiago Macieira]

On quinta-feira, 17 de maio de 2012 14.46.16, Atlant Schmidt wrote:
> Girish:
> > Substantial recoding on the application side? What features
> > of QWS are you relying on that is missing in QPA?
>
> The ability for multiple processes to share a single
> display device (framebuffer).

Have you ever considered using a display-device-sharing & input-device
multiplexing application, also known as a windowing server or compositor?

Let me tell you how our discussion went about two years ago inside the Qt team
(paraphrasing):
- QWS had a windowing server, QPA doesn't have one
- we need one for QPA
- should we use QWS's protocol or should we have something different?
- QWS was raster, so we need something different
- do we invent our own or is there something that we could use?
- there's Wayland...

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Intel Sweden AB - Registration Number: 556189-6027
Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden

[Иван Комиссаров]

Btw, you're saying that painter technology is outdated? What speedup provides QML scene graph? According to this http://labs.qt.nokia.com/2011/05/31/qml-scene-graph-in-master/ article, speedup is 2.5 times. As for me, it's just a constant optimization, it is not reduces complexity very much, as for me.
If you say you reduced speed 10 times or 100 - it's the other issue. But saying that painter is outdated just because it 3 times slower than new qml... sounds like a marketing.

[Uwe Rathmann]

On 05/18/2012 07:36 AM, Иван Комиссаров wrote:
> Btw, you're saying that painter technology is outdated?

Well it is also the API for rendering PDF ( and other paint devices )
documents. Having common code for screen and PDF rendering is absolutely
not outdated - and is possible using QSGPaintedItem.

I would be careful with terms like "outdated". In the end the desktop is
the concept of the 90s ( widget are much older ) and the current
desktops are the part that doesn't work on smartphones alike devices.
But are keyboard and mouse outdated - only because smartphones and
tablet devices don't have one - or why should a scene graph based
application be more modern, when it runs inside of a Xfce/X11 desktop ?

The controversal discussions about modern desktop environments indicate
that they are not progress for everyone and the expectation that
concepts from smartphones will be the future on all type of desktops (
what is somehow implied in "QPainter is outdated" ) won't necessarily
happen.

Maybe this is where the "code once deploy everywhere" idea has an end
and we will return to having different GUIs for different environments.

> What speedup provides QML scene graph? According to this http://labs.qt.nokia.com/2011/05/31/qml-scene-graph-in-master/ article, speedup is 2.5 times. As for me, it's just a constant optimization, it is not reduces complexity very much, as for me.

With raster QPainter::drawPolygon is significantly faster than
QPolygonF::drawPolygonF. QPolygon::drawPolygon on Qt3/X11 is only a thin
wrapper around X11 methods - something you can't beat performancewise.
But by far the best performance you will have when you can reduce the
number of points before drawPolygon on is called.

What I want to say with this is: speedup numbers heavily depend on the
use case and often doesn't mean much for your application.

Uwe

[Donald Carr]

Wayland with shared memory:

http://qt-project.org/wiki/RaspberryPi

and you are golden. If you are seriously a QWS user, you are a
thousand times better off now than you ever were before, Qt/Embedded
has an order of magnitude more visibility/resources working on it now.
Qt for resource constrained embedded systems is the golden path.

We have removed the Qt monopoly which was in place in the QWS era. QWS
was no standard, it was our own piecemeal solution which filled a
void. This void thankfully no longer exists, and one does not have to
chose between X11 and oblivion.

Cheers,
Donald

On Thu, May 17, 2012 at 11:46 AM, Atlant Schmidt
<***@dekaresearch.com> wrote:
> Girish:
>
>> Substantial recoding on the application side? What features
>> of QWS are you relying on that is missing in QPA?
>
>  The ability for multiple processes to share a single
>  display device (framebuffer).
>
>                         Atlant
>
> -----Original Message-----
> From: Girish Ramakrishnan [mailto:***@forwardbias.in]
> Sent: Thursday, May 17, 2012 14:45
> To: Atlant Schmidt
> Cc: Peter Kümmel; ***@qt-project.org
> Subject: Re: [Development] The place of QML
>
> Hi Atlant,
>
> On Thu, May 17, 2012 at 11:18 AM, Atlant Schmidt
> <***@dekaresearch.com> wrote:
>> Peter:
>>
>>> Then Qt Widgets is perfect for you: mature, stable API. You
>>> only would have a problem when you have to implement features
>>> which are much better supported by QML.
>>
>>  Did I mention that we're also coded to depend upon QWS, the
>>  QT Embedded Window System? ;-)
>>
>>  That feature is no longer available in Qt 5.x. And switching
>>  to Lighthouse would require substantial recoding on our part.
>>
>
> Substantial recoding on the application side? What features of QWS are
> you relying on that is missing in QPA?
>
> Girish
>
>
>  Click https://www.mailcontrol.com/sr/!5h1tFjp!BTTndxI!oX7UjaeDmea67kXS6AJ88SEevq917ySvmChLwlntfJopcq6AhIJK9UnN0t8TccP!XTbKg==  to report this email as spam.
>
> This e-mail and the information, including any attachments, it contains are intended to be a confidential communication only to the person or entity to whom it is addressed and may contain information that is privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender and destroy the original message.
>
> Thank you.
>
> Please consider the environment before printing this email.
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development



--
-------------------------------
 °v°  Donald Carr
/(_)\ Vaguely Professional Penguin lover
 ^ ^

Cave canem, te necet lingendo
Chasing my own tail; hate to see me leave, love to watch me go

[Donald Carr]

This; Widgets is stable API and we will not break your code if you
rely on it. Rejoice!

Qt 4.6 was a performance release;

[Kate Alhola]

On Thu, May 17, 2012 at 1:35 PM, Atlant Schmidt
<***@dekaresearch.com> wrote:
> Peter, et al.:
>
>> We don't wanna use obsolete stuff with a "architecture from
>> the 90s" in times where "graphical technology has moved on" (Thiago).
>
>  Computer architectures don't necessarily "become obsolete".
>  Oh, trends come and trends go, but the fundamental concepts
>  go on forever. For example, Linux is quite popular even
>  though it is arguably a "computer architecture from 1970".

Computer architecture don't necessarily become obsolete but also
it could as easily become obsolete. There is no rule saying either.
Many "core" technologies like how programming languages work ( C/C++)
or how operating systems, filesystems etc work have been very stable
technologies and there has been only minor evolution. C/Unix skills
from 80's are still mostly valid today.

On other sections, mostly in user interface there has been rapid
evolution and several
revolutions that have changed all scene. You can just count, Unix/C
started from typewriter
terminal age when UI was line based fully modal dialog. Now this is
fully obsoleted from mainstream
users and remains as coders programming language. Then age of crt-terminals and
text based forms UI, once again fully obsoleted from everywhere. Then
next revolution was
windowing UI with mouse, it got about current form in first Macintosh
in 1984 and after that
there was been very little evolution. You cant say that moving from
typewriter to windowed UI
is just a trend, it was total paradigm shift. QWidgets are designed
perfectly fit to this 1984 paradigm.

Invention of current mobile finger based UI was a start of next
revolution and once again we
can't say that it is just a trend when users move from
desktops/laptops to tablets and handsets
and all computer market is shared again.

At the moment, Qml is only reasonable solution for mobile applications
for tablets and handsets
but at the moment QWidgets are still perfect match for desktop apps.

There is a big question: why any more make application that runs on
desktop only and needs major rewrite for mobile
platforms. Why make QWidget UI and then rewrite for Qml UI for mobile
or why make application for
desktop only. I agree that there are a many applications that are
desktop only like CAD programs etc
but for all other appls. It would be much better solution to make C++
core and then make Qml UI for
desktop and other for mobile. I have used this method personally and
based on my personal experience
making separate Qml for desktop and mobile is less than 1% of work.
Much less than making desktop UI
with QWidgets and then mobile with Qml.

Then the other big question, what happens in future and should we
prepare for it rather than slowly adapt on it.
It is already known that tablets sell more than desktops and it is
predicted that they outsell laptops on 2015
but i bet that it happens earlier, may be end of 2013. I have been
using iPad since first model and I have also
couple of Android tablets. When I count "normal" usage, web, email
etc, I can do everything with tablet. If
I need write longer mails, I can use bluetooth keyboard. There is
still place for laptops and even high end desktops
for special use like software development, CAD programs etc but that
can be counted as special use.

I would like to say, that in most cases, applications should be
written so that they will also run on mobile because
world is moving to that direction.

>  Often, the proponents arguing for "new and improved" are
>  simply arguing for the position they think will be most fun
>  to work on; after all, it's always more fun to break exciting
>  new ground than it is to have trod the same old sod yet again.
>  But many of these new approaches are just "fashion" and if you
>  wait a few years, fashions will change again and "old and
>  obsolete" will be back in fashion (and often, simply because
>  good sense has returned to the design community).

Moving from typewritter to crt was not a fashion, moving from crt to
windowing UI was not a fashion,
moving to mobile is not a fashion but permanent shange.

>
>> Most people don't care what happens under the hood (QWidget
>> or QML) when good desktop support is available.
>
>  And some of us *DO* care very much what goes on under the
>  hood. Me, I live in an embedded world running on a ~450 MHz
>  processor with very limited RAM and graphics. There's just
>  enough "stuff" there to make the traditional Qt approach
>  work (just barely) but if the only choice Qt intends to
>  offer me in the future is going to burden me with the
>  overhead of a JavaScript (or even web) runtime, then I'm
>  going to need a new graphical framework.

There is always some special cases as there are cases of command line UI
or text-forms UI.


Kate

>  Old and obsolete worked for me; New and improved (in this
>  case) clearly isn't likely to.
>
>                       Atlant
>
> -----Original Message-----
> From: development-bounces+aschmidt=***@qt-project.org [mailto:development-bounces+aschmidt=***@qt-project.org] On Behalf Of Peter Kümmel
> Sent: Thursday, May 17, 2012 02:12
> To: ***@qt-project.org
> Subject: Re: [Development] The place of QML
>
> On 16.05.2012 20:31, qtnext wrote:
>> I am using Qt since 12 years or more... I have done a lot of work using qwidget, qgraphiscview, ....
>> I have done some small apps with qml to display media : it works very well ... just the animation are a a litlle bit
>> jerky and work not well on very small computer ...
>> But now that Qt5 is here : the alpha seems very promising regarding performance ... and I have started a new big desktop
>> application and I plan to use only Qml and it seems very promising .. I am sure that Quick2 is the way for new desktop
>> application : We only need Qt desktop components, treeview, ... and it will rocks :)
>
> Yes, that's the point. Most people don't care what happens under the hood (QWidget or QML)
> when good desktop support is available. But currently for desktop apps you have the choice
> between a "obsolete architecture" (Thiago) and an incomplete QML stack.
>
> Non technicians don't care about if QWidget is done or not if it fits the needs,
> but we are developers! We don't wanna use obsolete stuff with a
> "architecture from the 90s" in times where "graphical technology has moved on" (Thiago).
> But on the desktop we are forced to when we wanna a feature rich/complete framework.
>
> So all the QML<->QWidget discussions are mainly because there is no complete Qml support on the desktop.
>
> Desktop support has no high priority more anywhere.
> It couldn't be so complex to make good Qml support on the desktop, simply throw
> 5 man years on it (shouldn't be impossible when there are already 200 Qt developers
> at Nokia alone). But it doesn't happen because nobody wanna invest in the desktop.
>
> So all you can do is using a system with a "obsolete architecture", diving deep
> into QML and writing your own desktop elements, or waiting another one or two years.
>
> And I don't like any of the options.
>
> Peter
>
>
> This e-mail and the information, including any attachments, it contains are intended to be a confidential communication only to the person or entity to whom it is addressed and may contain information that is privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender and destroy the original message.
>
> Thank you.
>
> Please consider the environment before printing this email.
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

[Atlant Schmidt]

Kate:

> > Often, the proponents arguing for "new and improved" are
> > simply arguing for the position they think will be most fun
> > to work on; after all, it's always more fun to break exciting
> > new ground than it is to have trod the same old sod yet again.
> > But many of these new approaches are just "fashion" and if you
> > wait a few years, fashions will change again and "old and
> > obsolete" will be back in fashion (and often, simply because
> > good sense has returned to the design community).
>
> Moving from typewritter to crt was not a fashion, moving from
> crt to windowing UI was not a fashion, moving to mobile is not
> a fashion but permanent change.

Your view isn't broad enough. Some of us have *ALWAYS*
been using a type-on-something-and-get-soft-text-displayed
metaphor. "Expensive Typewriter" did this on the DEC PDP-1
around 1960 or so. Oh, we've since changed from CRT displays
to LCD or OLED displays, but the basic metaphor hasn't
actually changed at all. Even now as it becomes "speak
something and soft text gets displayed", it's *STILL*
the same basic metaphor.

Elsewhere in your E-mail, you decried command line input as
being obsolete except for coders. Well, what is Siri but
another style of command line input? Sure, the commands
Siri processes are orders-of-magnitude more sophisticated
than, say, those that bash processes, and they're spoken
rather than typed, but the metaphor is still the same:
Issue a command, get an action in response.

Don't be too quick to dismiss old stuff as "obsolete".
Maybe it just needs a little refurbishment (consider
how RISC ("load-store" architectures turbocharged)
emerged as the successor to CISC which had itself
superseded the original load-store architectures.

Atlant

-----Original Message-----
From: development-bounces+aschmidt=***@qt-project.org [mailto:development-bounces+aschmidt=***@qt-project.org] On Behalf Of Kate Alhola
Sent: Friday, May 18, 2012 04:22
To: ***@qt-project.org
Subject: Re: [Development] The place of QML

On Thu, May 17, 2012 at 1:35 PM, Atlant Schmidt
<***@dekaresearch.com> wrote:
> Peter, et al.:
>
>> We don't wanna use obsolete stuff with a "architecture from
>> the 90s" in times where "graphical technology has moved on" (Thiago).
>
> Computer architectures don't necessarily "become obsolete".
> Oh, trends come and trends go, but the fundamental concepts
> go on forever. For example, Linux is quite popular even
> though it is arguably a "computer architecture from 1970".

Computer architecture don't necessarily become obsolete but also
it could as easily become obsolete. There is no rule saying either.
Many "core" technologies like how programming languages work ( C/C++)
or how operating systems, filesystems etc work have been very stable
technologies and there has been only minor evolution. C/Unix skills
from 80's are still mostly valid today.

On other sections, mostly in user interface there has been rapid
evolution and several
revolutions that have changed all scene. You can just count, Unix/C
started from typewriter
terminal age when UI was line based fully modal dialog. Now this is
fully obsoleted from mainstream
users and remains as coders programming language. Then age of crt-terminals and
text based forms UI, once again fully obsoleted from everywhere. Then
next revolution was
windowing UI with mouse, it got about current form in first Macintosh
in 1984 and after that
there was been very little evolution. You cant say that moving from
typewriter to windowed UI
is just a trend, it was total paradigm shift. QWidgets are designed
perfectly fit to this 1984 paradigm.

Invention of current mobile finger based UI was a start of next
revolution and once again we
can't say that it is just a trend when users move from
desktops/laptops to tablets and handsets
and all computer market is shared again.

At the moment, Qml is only reasonable solution for mobile applications
for tablets and handsets
but at the moment QWidgets are still perfect match for desktop apps.

There is a big question: why any more make application that runs on
desktop only and needs major rewrite for mobile
platforms. Why make QWidget UI and then rewrite for Qml UI for mobile
or why make application for
desktop only. I agree that there are a many applications that are
desktop only like CAD programs etc
but for all other appls. It would be much better solution to make C++
core and then make Qml UI for
desktop and other for mobile. I have used this method personally and
based on my personal experience
making separate Qml for desktop and mobile is less than 1% of work.
Much less than making desktop UI
with QWidgets and then mobile with Qml.

Then the other big question, what happens in future and should we
prepare for it rather than slowly adapt on it.
It is already known that tablets sell more than desktops and it is
predicted that they outsell laptops on 2015
but i bet that it happens earlier, may be end of 2013. I have been
using iPad since first model and I have also
couple of Android tablets. When I count "normal" usage, web, email
etc, I can do everything with tablet. If
I need write longer mails, I can use bluetooth keyboard. There is
still place for laptops and even high end desktops
for special use like software development, CAD programs etc but that
can be counted as special use.

I would like to say, that in most cases, applications should be
written so that they will also run on mobile because
world is moving to that direction.

> Often, the proponents arguing for "new and improved" are
> simply arguing for the position they think will be most fun
> to work on; after all, it's always more fun to break exciting
> new ground than it is to have trod the same old sod yet again.
> But many of these new approaches are just "fashion" and if you
> wait a few years, fashions will change again and "old and
> obsolete" will be back in fashion (and often, simply because
> good sense has returned to the design community).

Moving from typewritter to crt was not a fashion, moving from crt to
windowing UI was not a fashion,
moving to mobile is not a fashion but permanent shange.

>
>> Most people don't care what happens under the hood (QWidget
>> or QML) when good desktop support is available.
>
> And some of us *DO* care very much what goes on under the
> hood. Me, I live in an embedded world running on a ~450 MHz
> processor with very limited RAM and graphics. There's just
> enough "stuff" there to make the traditional Qt approach
> work (just barely) but if the only choice Qt intends to
> offer me in the future is going to burden me with the
> overhead of a JavaScript (or even web) runtime, then I'm
> going to need a new graphical framework.

There is always some special cases as there are cases of command line UI
or text-forms UI.


Kate

> Old and obsolete worked for me; New and improved (in this
> case) clearly isn't likely to.
>
> Atlant


This e-mail and the information, including any attachments, it contains are intended to be a confidential communication only to the person or entity to whom it is addressed and may contain information that is privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender and destroy the original message.

Thank you.

Please consider the environment before printing this email.

[Giuseppe D'Angelo]

On 16 May 2012 01:31, André Pönitz
<***@mathematik.tu-chemnitz.de> wrote:
> I trust the audience would be delighted if you gave some insight
> into the calculation.

For the argument's sake, let's say that the poll shows statistical
relevance. That is, there's a huge interest in having a complete set
of C++ bindings for QML (or for an equivalent technology).

The OP:
- doesn't like the fact that QML has not a comprehensive C++ API;
- does want instead that API;
- doesn't like the CLA and the fact that he would be giving to Nokia
more what Nokia gives him back under a free license;
- knows that such an API won't come from Nokia "soon";

The natural consequence is: OP: go ahead and create this technology.

Make a startup, hire 20+ world-top-class developers, work hard for 1-2
years, and release your product as a 3rd-party add on for Qt.

You won't have to sign any CLA, and you'll be free to release it under
any licensing model you want.

And any bank will be happy to back your company, since, as you say,
- it's ok for you / you're willing to run in the red for some time
- the huge number of people wanting your product will make it
completely repay for the initial investment.

Does it sound good?

Cheers,
--
Giuseppe D'Angelo

PS. did anyone say "Cascades"?

[Alan Alpert]

On Mon, 7 May 2012 07:44:56 ext André Pönitz wrote:
> On Mon, Apr 23, 2012 at 07:35:02AM +0000, ***@nokia.com wrote:
> > [...] And who says that 100% of the code has to be C++?
>
> Nobody reasonably wants that. But people like to have a choice, and
> different people will base their choice on different factors.
>
> > I bet you are also happily using Perl/python where it makes sense. .ui
> > files in Qt 4.x are XML, yet nobody complains about these.
> >
> > Qt is about finding pragmatic solutions to problems. Yes it comes from
> > a C++ heritage, but I don't see why we should limit ourselves to
> > purely C++ if we can create better solutions to the problem.
> > [...] No, you should be using QML. [...]
>
> A better language does not automatically translate into a better
> solution. The currently envisioned use of QML as a hybrid (at edit
> and(!) run time) severely impacts the choice of available tools
> to handle ordinary tasks like editing, debugging, profiling, and
> whatever else is typically needed to make an application fly.
>
> With old .ui this was not much of a problem because (a) one could
> not do much with it anyway i.e. could not get it wrong either, (b) it
> had no runtime implications, no need for mixed debugging/profiling
> (QUiLoader is not exactly popular), and (c) one could even opt for
> not using it at all.
>
> Now we suddenly have an easy to use, yet compulsory, Turing complete
> language with essentially no support from off-the-shelf tools.

It's this "compulsory" part that I don't understand. The current situation is
that if you don't want to use QML you don't use it. I understand that we're
talking about transitioning to QML as the primary tool for UIs in Qt5, but
that's both merely 'primary', and also very in-progress (don't make me copy in
a boiler-plate "forward-looking statements" disclaimer ;) ). So these accurate
holes that people are pointing out are issues that should be resolved over the
Qt 5.x lifetime and only then, at the end of the journey, is QML going to be
the only viable option.

Obviously I think QML is viable now, but I've thought that for years. Over
those years I've watched it progress from where I'd seriously suggest it for
10% of applications to where I'd seriously suggest it for 60% of applications.
Once it grows to me thinking 100% of applications should use it (I'll probably
be the first one to think this, if not the only one ;)) then we can talk about
compulsory. I'd hope to reach that point around Qt 5.2, maybe 5.3.

> How are people supposed to handle that? Who is going to provide the
> QML enabled substitutes to the emacs-visual studio-xcode-valgrind
> -gdb-cdb-purify-doxygen-designer-whatever-tool-hotchpotch people are
> happily using? What happens to people who cannot or do not want to
> use substitutes? Who is going to support and maintain the substitutes?

The Qt SDK already is starting to contain profiling and debugging tools for
QML. So there's where and how they'll be provided/maintained.

--
Alan Alpert
Senior Engineer
Nokia, Qt Development Frameworks

[Peter Kuemmel]

> > Now we suddenly have an easy to use, yet compulsory, Turing complete
> > language with essentially no support from off-the-shelf tools.
>
> It's this "compulsory" part that I don't understand.
> The current situation is that if you don't want to use
> QML you don't use it.

Does "don't use it" mean I should use QWidgets?
But who wants to base a new project on a system which
is officially called something that sounds like "obsolete"
and "dead (no new features)"; I know the marketing calls this
only "done".

And AFAIK QML can't be used like .ui files for complete feature rich
desktop applications, or I'm wrong?

There is no smooth migration path for old-school Qt/C++ developers.

Peter
--
NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone!
Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a

[Frank Hemer]

On Tuesday 08 May 2012 09:50:16 Peter Kuemmel wrote:
> > > Now we suddenly have an easy to use, yet compulsory, Turing complete
> > > language with essentially no support from off-the-shelf tools.
> >
> > It's this "compulsory" part that I don't understand.
> > The current situation is that if you don't want to use
> > QML you don't use it.
>
> Does "don't use it" mean I should use QWidgets?
> But who wants to base a new project on a system which
> is officially called something that sounds like "obsolete"
> and "dead (no new features)"; I know the marketing calls this
> only "done".

+1 with a big '!'

> ...
> There is no smooth migration path for old-school Qt/C++ developers.

And I expect porting an application using QWidget & friens to become an qml
application will cause at least equal pain as porting a qt3 application to
qt4:-(

What I miss is the perspective for applications with long sales cycles (expect
this to be 10 to 15 years). Could we see a chance for a smooth migration
here ... like a qml replacement for QWidgets that do NOT imply a complete
redesing?

Having that said, I'm still convinced qml will have a gread future - its just
not a good signal to notice that longterm basic components like QWidget get
suddenly shot out of the dark, end up as 'done' and the replacement AFAIK
comes with a real heavy impact of redesign.

Frank

[Alan Alpert]

On Tue, 8 May 2012 20:08:38 ext Frank Hemer wrote:
> On Tuesday 08 May 2012 09:50:16 Peter Kuemmel wrote:
> > > > Now we suddenly have an easy to use, yet compulsory, Turing complete
> > > > language with essentially no support from off-the-shelf tools.
> > >
> > > It's this "compulsory" part that I don't understand.
> > > The current situation is that if you don't want to use
> > > QML you don't use it.
> >
> > Does "don't use it" mean I should use QWidgets?
> > But who wants to base a new project on a system which
> > is officially called something that sounds like "obsolete"
> > and "dead (no new features)"; I know the marketing calls this
> > only "done".
>
> +1 with a big '!'
>

If you have a better idea for the naming, I'd love to hear it. I'd call it
"Sunshine" status, to evoke the imagery of an elder cat dozing the the sun,
while still able to pounce the instant you approach. (This demonstrates that
at least I need help coming up with good names ;) ).

> > ...
> > There is no smooth migration path for old-school Qt/C++ developers.
>
> And I expect porting an application using QWidget & friens to become an qml
> application will cause at least equal pain as porting a qt3 application to
> qt4:-(
>
> What I miss is the perspective for applications with long sales cycles
> (expect this to be 10 to 15 years). Could we see a chance for a smooth
> migration here ... like a qml replacement for QWidgets that do NOT imply a
> complete redesing?

Of course this was considered and a smooth migration path was developed. It
has been documented here for some time: http://doc.qt.nokia.com/4.7/qml-
integration.html . Just because there is one doesn't mean that it's perfect
(or even addresses your needs), but it will be most constructive to discuss it
from this point, i.e. what's missing from the current migration path.

Unlike Qt3->Qt4, you can transition your UI elements over at your own pace,
while still having a working intermediate product. Want to add some complex
movement behaviors to your button, and think QML is the only solution (it's
not, but it works well for this)? The button can become a QML based widget and
fit into your existing UI. Maybe in five years you'll have replaced enough of
your components with QML versions that it makes sense to drop the Widgets
entirely and have a pure QML UI. But if your application was working fine
before, you don't need a complete rewrite just to get it back to that level -
and you still have options going forwards.

--
Alan Alpert
Senior Engineer
Nokia, Qt Development Frameworks

[Uwe Rathmann]

On 05/08/2012 04:13 AM, Alan Alpert wrote:
> It's this "compulsory" part that I don't understand. The current situation is
> that if you don't want to use QML you don't use it.

Lars wrote in his blog about the vision behind Qt5, but isn't the main
idea behind this one:

a) application development can be divided into a user interface and some
"business logic".
b) QML opens the development user interfaces for non software developers.

If this idea is realistic and how much QML makes things easier is a
difficult question ...

But Qt5 comes also with the scene graph, that is in the first place
completely unrelated to the idea above.
Unfortunately you can't have one without the other - even if QML is not
the right choice for the specific situation of your project.

Uwe

[Frank Hemer]

On Tuesday 08 May 2012 04:13:40 Alan Alpert wrote:
> On Mon, 7 May 2012 07:44:56 ext André Pönitz wrote:
> > On Mon, Apr 23, 2012 at 07:35:02AM +0000, ***@nokia.com wrote:
> > > [...] And who says that 100% of the code has to be C++?
> >
> > Nobody reasonably wants that. But people like to have a choice, and
> > different people will base their choice on different factors.
> >
> > > I bet you are also happily using Perl/python where it makes sense. .ui
> > > files in Qt 4.x are XML, yet nobody complains about these.
> > >
> > > Qt is about finding pragmatic solutions to problems. Yes it comes from
> > > a C++ heritage, but I don't see why we should limit ourselves to
> > > purely C++ if we can create better solutions to the problem.
> > > [...] No, you should be using QML. [...]
> >
> > A better language does not automatically translate into a better
> > solution. The currently envisioned use of QML as a hybrid (at edit
> > and(!) run time) severely impacts the choice of available tools
> > to handle ordinary tasks like editing, debugging, profiling, and
> > whatever else is typically needed to make an application fly.
> >
> > With old .ui this was not much of a problem because (a) one could
> > not do much with it anyway i.e. could not get it wrong either, (b) it
> > had no runtime implications, no need for mixed debugging/profiling
> > (QUiLoader is not exactly popular), and (c) one could even opt for
> > not using it at all.
> >
> > Now we suddenly have an easy to use, yet compulsory, Turing complete
> > language with essentially no support from off-the-shelf tools.
>
> It's this "compulsory" part that I don't understand. The current situation
> is that if you don't want to use QML you don't use it. I understand that
> we're talking about transitioning to QML as the primary tool for UIs in
> Qt5, but that's both merely 'primary', and also very in-progress (don't
> make me copy in a boiler-plate "forward-looking statements" disclaimer ;)
> ). So these accurate holes that people are pointing out are issues that
> should be resolved over the Qt 5.x lifetime and only then, at the end of
> the journey, is QML going to be the only viable option.
>
> Obviously I think QML is viable now, but I've thought that for years. Over
> those years I've watched it progress from where I'd seriously suggest it
> for 10% of applications to where I'd seriously suggest it for 60% of
> applications. Once it grows to me thinking 100% of applications should use
> it (I'll probably be the first one to think this, if not the only one ;))
> then we can talk about compulsory. I'd hope to reach that point around Qt
> 5.2, maybe 5.3.
>
> > How are people supposed to handle that? Who is going to provide the
> > QML enabled substitutes to the emacs-visual studio-xcode-valgrind
> > -gdb-cdb-purify-doxygen-designer-whatever-tool-hotchpotch people are
> > happily using? What happens to people who cannot or do not want to
> > use substitutes? Who is going to support and maintain the substitutes?
>
> The Qt SDK already is starting to contain profiling and debugging tools for
> QML. So there's where and how they'll be provided/maintained.

Nice to hear that there will be qt-related tools in sight.
Still I'm used to develop with emacs for many years now. And I definitely do
not want to be forced to use specific tools which imply new dependencies!

Frank

[a***@nokia.com]

On 19.4.2012 11:15 PM, "ext Richard Moore" <***@kde.org> wrote:

>On 19 April 2012 16:17, <marius.storm-***@nokia.com> wrote:
>>> I think many of us know the 'problems' with planetqt, so I won't voice
>>> it out here because I don't know what is public information.
>>>
>>> I think if we can just have a aggregator on the qt-project, it would
>>> be good enough. Alexandra, what do you think?
>>
>> We already have blog aggregation on qt-project, on the right-hand side
>> of the front page. Alexandra can add more there, afaik.
>
>I don't know which blogs are added here, but it is very misleading -
>the title is 'Planet Qt' and at the bottom it links to planetqt.org,
>but the actual feed is not planetqt. I've no idea what problems you're
>referring to, but right now the aggregation is essentially just nokia
>stuff and not really either planetqt or qt-project.
>
>>
>> Thiago's blog has already been added, as well as the Qt Labs ones, and
>> The Qt Blog.
>
>In fact this seems to be the stuff that was previously nokia and thiago.

Correct. The whole thing is work in progress. See http://bit.ly/wHByAf :)

It's not that simple to pick feeds that are relevant and high-profile
enough for "expensive" homepage real estate but I'm happy to hear your
suggestions.

Cheers,
Alex

[Richard Moore]

On 23 April 2012 09:17, <***@nokia.com> wrote:
> On 19.4.2012 11:15 PM, "ext Richard Moore" <***@kde.org> wrote:
>>In fact this seems to be the stuff that was previously nokia and thiago.
>
> Correct. The whole thing is work in progress. See http://bit.ly/wHByAf :)
>
> It's not that simple to pick feeds that are relevant and high-profile
> enough for "expensive" homepage real estate but I'm happy to hear your
> suggestions.

Ok. A couple of ideas:

http://www.fioniasoftware.dk/blog
http://www.kdab.com/category/kdab-on-qt/feed/

Both of these are regular and of a very high quality.

Regards

Rich.

[l***@nokia.com]

On 5/8/12 12:08 PM, "ext Frank Hemer" <***@hemer.org> wrote:

>On Tuesday 08 May 2012 09:50:16 Peter Kuemmel wrote:
>> > > Now we suddenly have an easy to use, yet compulsory, Turing complete
>> > > language with essentially no support from off-the-shelf tools.
>> >
>> > It's this "compulsory" part that I don't understand.
>> > The current situation is that if you don't want to use
>> > QML you don't use it.
>>
>> Does "don't use it" mean I should use QWidgets?
>> But who wants to base a new project on a system which
>> is officially called something that sounds like "obsolete"
>> and "dead (no new features)"; I know the marketing calls this
>> only "done".
>
>+1 with a big '!'

There's quite some work ongoing right now to get the QPA layer for the
desktop platforms just right, so that widgets work as they did in Qt 4.x.
They are being tested for regressions etc., so they won't suddenly stop
working.

Nokia has stated that the company doesn't see QWidget's as their area of
focus for the future. Since nobody else has stepped up yet, this implies
that widgets have a 'done' status (which is *not* deprecated or even
dead).

Neither me nor anybody else in the Qt project is stopping anybody from
doing more work there. Actually I personally will be very happy if someone
continues to work on them and improve them.

But it won't magically happen by itself. This has been stated before, I'll
repeat it nevertheless:

If you have an interest in new features here, you should consider stepping
up and investing. Either by investing your time and developing yourself or
by funding someone else to do the work (e.g. by buying a commercial
license or working with one of the many Qt partner companies).


>> ...
>> There is no smooth migration path for old-school Qt/C++ developers.
>
>And I expect porting an application using QWidget & friens to become an
>qml
>application will cause at least equal pain as porting a qt3 application
>to
>qt4:-(
>
>What I miss is the perspective for applications with long sales cycles
>(expect
>this to be 10 to 15 years). Could we see a chance for a smooth migration
>here ... like a qml replacement for QWidgets that do NOT imply a complete
>redesing?
>
>Having that said, I'm still convinced qml will have a gread future - its
>just
>not a good signal to notice that longterm basic components like QWidget
>get
>suddenly shot out of the dark, end up as 'done' and the replacement AFAIK
>
>comes with a real heavy impact of redesign.

QML components for the desktop are still work in progress. Because of that
let's wait and see what kind of migration path can be offered. I know it's
possible to create something that would allow for a stepwise migration and
a peaceful coexistence. This is also what I'd like to aim for, but as
anything else also this requires someone to invest time or money into it.

Cheers,
Lars

[Frank Hemer]

On Tuesday 08 May 2012 13:18:26 ***@nokia.com wrote:
> On 5/8/12 12:08 PM, "ext Frank Hemer" <***@hemer.org> wrote:
> >On Tuesday 08 May 2012 09:50:16 Peter Kuemmel wrote:
> >> > > Now we suddenly have an easy to use, yet compulsory, Turing complete
> >> > > language with essentially no support from off-the-shelf tools.
> >> >
> >> > It's this "compulsory" part that I don't understand.
> >> > The current situation is that if you don't want to use
> >> > QML you don't use it.
> >>
> >> Does "don't use it" mean I should use QWidgets?
> >> But who wants to base a new project on a system which
> >> is officially called something that sounds like "obsolete"
> >> and "dead (no new features)"; I know the marketing calls this
> >> only "done".
> >
> >+1 with a big '!'
>
> There's quite some work ongoing right now to get the QPA layer for the
> desktop platforms just right, so that widgets work as they did in Qt 4.x.
> They are being tested for regressions etc., so they won't suddenly stop
> working.
>
> Nokia has stated that the company doesn't see QWidget's as their area of
> focus for the future. Since nobody else has stepped up yet, this implies
> that widgets have a 'done' status (which is *not* deprecated or even
> dead).
>
> Neither me nor anybody else in the Qt project is stopping anybody from
> doing more work there. Actually I personally will be very happy if someone
> continues to work on them and improve them.
>
> But it won't magically happen by itself. This has been stated before, I'll
> repeat it nevertheless:
>
> If you have an interest in new features here, you should consider stepping
> up and investing. Either by investing your time and developing yourself or
> by funding someone else to do the work (e.g. by buying a commercial
> license or working with one of the many Qt partner companies).

... which I have for many years now ...

> >> ...
> >> There is no smooth migration path for old-school Qt/C++ developers.
> >
> >And I expect porting an application using QWidget & friens to become an
> >qml
> >application will cause at least equal pain as porting a qt3 application
> >to
> >qt4:-(
> >
> >What I miss is the perspective for applications with long sales cycles
> >(expect
> >this to be 10 to 15 years). Could we see a chance for a smooth migration
> >here ... like a qml replacement for QWidgets that do NOT imply a complete
> >redesing?
> >
> >Having that said, I'm still convinced qml will have a gread future - its
> >just
> >not a good signal to notice that longterm basic components like QWidget
> >get
> >suddenly shot out of the dark, end up as 'done' and the replacement AFAIK
> >
> >comes with a real heavy impact of redesign.
>
> QML components for the desktop are still work in progress. Because of that
> let's wait and see what kind of migration path can be offered. I know it's
> possible to create something that would allow for a stepwise migration and
> a peaceful coexistence. This is also what I'd like to aim for, but as
> anything else also this requires someone to invest time or money into it.

I've been following this thread for quite a while now - and I felt like
speaking up as this is probably of a major concern not just for me.
I simply want to encourage the need for a smooth migration path - I'm a
commercial user (hello digia;-) but due to non-existent public lists at digia
I felt like adding this somewhere in public.

I appreciate your work on qt a lot and want to add my 2ct for keeping it at
the high level it already is.

Frank

[Turunen Tuukka]

>
>
>
>> You're correct that this is how business works: Nokia's business is
>> selling mobile devices (and services) - Digia's is in selling
>> consultancy. Digia has customers who pay them to work on features and
>> bugs that their customers need, Nokia does not.
>
>It is worth noting that Digia's interest is ONLY in selling
>consultancy. There is no R&D department at Digia. They do client work
>and also perform support for Qt through bugfixes etc.

Just very short comment to this part - Digia, Qt Commercial does also
quite significant R&D. Whereas we do have consulting, and support, we do
also our share of development. For example we are working in making sure
that Qt runs nicely on those platforms that are important to the
commercial customers. Some of these are well aligned with Qt Project, for
example Win, Mac, Linux, and some we work on our own or together with the
OS vendors (mainly embedded and real-time). We are also investing quite
much to the releasing and testing, which also benefits the whole Qt
ecosystem.

We do a hefty amount of error corrections, and contributions to create new
functionality. Digia has been an active participant in the Qt community
for well over 5 years. We have created various different solutions with
Qt, improved Qt in many platforms and created a hefty amount of code for
Qt 4 and Qt 5. We looked back into some numbers and calculated that in the
past few years Digia has done well over 3000 contributions to Qt and Qt
Mobility making Digia the biggest contributor to Qt after Nokia/Trolltech.

Yours,

Tuukka Turunen
Director, R&D
Digia, Qt Commercial

[m***@nokia.com]

Sounds like marketing?

It might be a 'constant' in the grand scheme of big-O notations. However,
if the result is that you can only get 24 fps on low-end HW with large
power footprint vs. 60 fps with HW acceleration, lower power footprint and
leaving the main CPU to do more important tasks, what would you call the
former? That's right, outdated technology. Scene graph is very much based
on what todays graphics cards are optimized for, while QPainter.. well,
it's not. We have gone as far as we could with QPainter, and needed
something new to survive the next 5-10 years. It's not about marketing, I
assure you.

--
.marius


On 5/18/12 7:36 AM, "ext Иван Комиссаров" <***@gmail.com> wrote:

>Btw, you're saying that painter technology is outdated? What speedup
>provides QML scene graph? According to this
>http://labs.qt.nokia.com/2011/05/31/qml-scene-graph-in-master/ article,
>speedup is 2.5 times. As for me, it's just a constant optimization, it is
>not reduces complexity very much, as for me.
>If you say you reduced speed 10 times or 100 - it's the other issue. But
>saying that painter is outdated just because it 3 times slower than new
>qml... sounds like a marketing.
>_______________________________________________
>Development mailing list
>***@qt-project.org
>http://lists.qt-project.org/mailman/listinfo/development
>

[d3fault]

On 5/15/12, BRM <***@yahoo.com> wrote:
> It would probably be good for a statistically significant poll to be
> officially done.
> I'd expect that it would probably have a 50/50 split, or may be a 60/40
> split in favor of QML
> as I do expect there is still a lot of momentum behind the QWidgets and
> QGraphics* frameworks.
> But I doubt that will happen.

The polls consistently show a 3:2 lead for C++ GUI... but I agree we
need a bigger sample size. I don't think even with thousands of votes
that the ratio would change much.
Thiago: can you use your godlike yet neutral powers in this "open
governance" project to put a neutral poll on the front page?
Really, the big issue is that Nokia has in effect killed the
development of the Qt (sans maintenance, bug fixes, small-medium size
features, and R&D that tries to solve Nokias financial problems).
...but there's no better way to emphasize that fact than to highlight
the giant split in a) what the Qt _users_ want and b) what Nokia wants


On 5/16/12, Robin Burchell <robin+***@viroteck.net> wrote:
> On Wed, May 16, 2012 at 4:42 PM, Atlant Schmidt
> <***@dekaresearch.com> wrote:
>> Qt "the product" may be developed by a meritocracy of devel-
>> opers but it damned-well better respond in a more-or-less
>> democratic way to the needs/demands of the consumers of the
>> product. If it doesn't, those consumers will move on to
>> using other frameworks.
>
> That isn't how reality works. You cannot tell me (as a volunteer) what
> I ought to be spending my time on any more than I can tell you what
> color to paint your livingroom. My interests dictate what I invest my
> time into, not random people on the internet. As a developer working
> on Qt, I will probably keep users' interests in mind, but at the end
> of the day, it's still my decision.

For individual contributors + 3rd party contributors, yes, nobody can
or should tell you what to work on. This is obvious. But Qt at one
point had people who were paid by investors to work on Qt. Improving
it, satisfying the _users_, etc. Those developers had an implicit
obligation to serve the Qt _users_. It was in their interest to do so
and their R&D would reflect it. Trolltech gets gobbled up and all of
the sudden the goal shifts from attracting more Qt _users_ (hoping
they convert to Commercial someday... or just contribute really) to a
highly experimental/obtrusive-to-existing-code/not-source-compatible+not-binary-compatible
Toy Programming Language (that is forced upon you if you want to use
the recent/updated/enhanced/efficient QtQuick) to hopefully save Nokia
in the mobile market (It won't. Microsoft has Nokia by the balls).


On 5/16/12, Thiago Macieira <***@intel.com> wrote:
> Even though the consumers cannot demand anything from volunteer
> contributors, there is a an important overlap between what the consumers want and what the
> contributors want to work on. Or, at the very least, there should be.
>
> If we, as the contributors, do not pay attention to what our users want,
> we'll produce a toolkit that no one wants to use. Therefore, it is in our best
> interest to keep the users present and happy with the functionality. That's
> the only way to ensure the long-term survival of the project.

I think it's in Qt's overall interest for a company to be responsible
for paying attention to what the users want. Nokia has the job but is
not performing it. Qt is suffering and will continue to suffer,
perhaps even until Nokia's inevitable death.

> But note also that the overlap is not 100% and will probably never be.
> Sometimes, users want too much, or don't know exactly what they want. There
> must be room for the contributors to exercise their imaginations and come up
> with new, revolutionary solutions.
>
> I firmly believe that QML is in that camp.

QML may be revolutionary, but it does not target the right camp. It
targets the designer/amateur-coder audience. "Awww, poor baby. C++ too
hard for you? Here's some meta-descriptive-GUI language where you can
use simple javascript statements/code to implement all your back-end
(and subsequently, perform non-trivial bindings)".
Where's the direct/developer/1337h4x0r interface to using the same
thing that makes QML so bitchin (QtQuick/Scene Graph)? QML _is_
revolutionary... it just isn't what the average C++/Qt dev (user)
wants.


On 5/16/12, Thiago Macieira <***@intel.com> wrote:
> We need a new architecture, which means building stuff from the ground up
> with it. It requires a scene graph with retained-mode painting.

Yes, QtQuick is this new architecture. I just wish it wasn't exclusive
to QML. I agree QWidgets should be 'Done' (because it is)... but it
shouldn't be just left their to die. Imperative Declaration of UI
structure from within C++ is how us programmers prefer to do it
(QWidgets C++ API). It isn't so much to ask for something similar for
the future of Qt GUIs (not just for porting ease... but also for
familiarity). The imperative declaration of GUI that C++ developers
like to use in QWidgets is there for a reason: preference (it might
also be the 'defining' way to do it... as in, the xml .ui might
translate into C++ calls, idk tbh). Don't remove/ignore our preference
and force your own.


On 5/16/12, Thiago Macieira <***@intel.com> wrote:
> On quarta-feira, 16 de maio de 2012 13.24.25, Atlant Schmidt wrote:
>> The FOSS developers HOPE that their interests are congruent
>> with those of the mere customers and at least in QT's world,
>> there's some evidence that this is true for some customers
>> but there is also mounting evidence that this is decidedly
>> NOT TRUE for other customers, hence our current debate
>> about QML Qt versus QWidget Qt.
>
> That's not exactly true. The debate isn't about QML vs QWidget. The core of
> the debate, as far as I can see, is whether there should be a C++ interface
> for making UIs with the new technology.
>
> I haven't seen anyone support QWidget itself in this thread. Moreover, I
> doubt most people know the challenges with enhancing QWidget further. Consider
> this: the QWidget & QPainter imperative painting technology is Done. It's not a
> matter of taste, it's fact: graphical technology has moved on.

Imperative painting is done, yes... but imperative declaring (how i'd
refer to the QWidgets C++ API) isn't.
I am sure someone can design a new imperative C++ interface (with huge
similarities to QWidget) that uses Scene Graph/QtQuick.

> But the point is that we need something new to take Qt forward and be the
> basis for the next 5-10 years. The suggestion so far is QML & scene graph
> and with a few tweaks it could be made to suit most people's requests.
>
> No one has suggested an alternative.

The suggested alternative is the Upgraded C++ GUI API! Nobody has
funded/researched/developed the alternative, however :(

> So I suggest we spend our energy discussing those tweaks I mention, what's
> necessary to make the technology more attractive to current developers, what
> the impact on maintenance will be, etc.

This C++ vs QML discussion is moderately important to Qt as a whole...
but what about the "I do not want to contribute" (and therefore I'm
assuming/extrapolating that others also won't) problem? I think that's
a much larger issue. Sure, who the fuck am I? I am an independent
developer who is a _user_ of Qt. I hope to one day be in the position
where I can (and want to) contribute to Qt. There are many like us and
Qt needs the individual developer to want to contribute if it plans on
staying ahead of the market. Ok maybe "needs" is a stretch (companies
can/will dump money into it for yeeeeeeaaaaaars, keeping it alive
support-wise)... but it will definitely improve the overall Qt
experience to have individual contributors WANTING to contribute fresh
ideas (without the feeling that Nokia would be wasting the profits
said contribution would bring to Qt) and code.
The Qt Trademark is what it really boils down to. The Qt Project needs
to own the Qt trademark, else it will always be shoveling money into
the black hole that is Nokia. How much power do the people "at the
top" of the open governance meritocracy really have? Can they change
Trademark agreements (doubtful)? How about specific portions of the
QCA (perhaps more likely)?


On 5/17/12, Peter Kümmel <***@gmx.net> wrote:
> On 16.05.2012 20:31, qtnext wrote:
> So all you can do is using a system with a "obsolete architecture", diving
> deep into QML and writing your own desktop elements, or waiting another one or
> two years.

I think you hit the problem square on the head... except that a lot of
us don't feel like QML Desktop Components are the answer to the
obsolete architecture problem... so we're even more aggravated knowing
that we have to wait even longer for a solution. Maybe someone will
make a C++ interface to QML (using precompiler or whatever)... which
would be possible but makes me want to LoL at such a terrible design
decision. Thiago, are these the tweaks you speak of to make QML usable
for most? A C++ interface to QML + no-v8-requirement + QML bytecode
embedded in executable resources. I think I'd actually settle for that
(I'd just lmao at the toolchain). It just seems silly to have the QML
be the defining interface for communication to QtQuick. A QML
extension to a C++ interface (just like how [I assume] .ui XML
extends/translates-into C++ calls) makes much more sense from a design
and maintenance perspective (I could be wrong).


On 5/17/12, Peter Kümmel <***@gmx.net> wrote:
> Then Qt Widgets is perfect for you: mature, stable API. You
> only would have a problem when you have to implement features
> which are much better supported by QML.

QWidgets may be more stable, but it is NOT the more performant of the
two. QML/QtQuick uses hardware acceleration whereas QWidgets uses your
CPU. Now tell me better which is better in an emedded scenario. For a
very recent example of a low-capable-CPU/highly-capable-GPU Qt 5
device, look no further than the Raspberry Pi. You can't get a Pi and
then use QWidgets. I mean you can... but then you're wasting the Pi. I
don't know what GUI language I'm going to write Pi apps in tbh:
Obsolete/stable/slow QWidgets or New/untested/fast QML/QtQuick. The
slow/fast difference will probably be visibly notable for certain GUI
events on certain programs -- most notably on the Pi.


On 5/16/12, Giuseppe D'Angelo <***@gmail.com> wrote:
> The OP:
> - doesn't like the fact that QML has not a comprehensive C++ API;
> - does want instead that API;
> - doesn't like the CLA and the fact that he would be giving to Nokia
> more what Nokia gives him back under a free license;
> - knows that such an API won't come from Nokia "soon";
>
> The natural consequence is: OP: go ahead and create this technology.
>
> Make a startup, hire 20+ world-top-class developers, work hard for 1-2
> years, and release your product as a 3rd-party add on for Qt.
>
> You won't have to sign any CLA, and you'll be free to release it under
> any licensing model you want.
>
> And any bank will be happy to back your company, since, as you say,
> - it's ok for you / you're willing to run in the red for some time
> - the huge number of people wanting your product will make it
> completely repay for the initial investment.
>
> Does it sound good?

Sounds Great. Can you provide funding ;-)? I've already said that all
that's needed is a Charity/Business. But in saying this you are pretty
much admitting that Nokia themselves do not have a vested interest.
The mere fact that it should be contributed as a 3rd party module
should signal a problem with the Qt Project infrastructure. Do we want
Qt to have amazing 1st party/supported/maintained/tested modules or do
we want to have to rely on the community to contribute BASIC
FUNCTIONALITY (modern C++ gui -_-) through 3rd party modules?
A huge disadvantage (though also an advantage) would be that said
charity/business couldn't use the Qt Trademark. Their 3rd party module
would probably be specific to Qt. They could refer to Qt... but they
couldn't not call themselves Qt. Profits would suffer (this is also an
advantage because of the current work required to
support/maintain/fork Qt).


On 5/18/12, Uwe Rathmann <***@tigertal.de> wrote:
> What I want to say with this is: speedup numbers heavily depend on the
> use case and often doesn't mean much for your application.

Well obviously. The difference is that hardware acceleration almost
always brings the additional advantage of freeing up the CPU.
Let's not even get started on how much better a GPU scales under heavier load.
Hardware acceleration can speed up your processes (not referring to
CPU processes... but the overall task) by an order of magnitude
compared to cpu-based rendering. 2.5x sounds like a safe low estimate
to me...

Hardware Acceleration is something the C++ and QML camp both
definitely agree on.
Uwe, if you don't think the performance difference between CPU/GPU is
that much... you should be perfectly happy sticking to the 'Done'
(which almost actually kind of means perfected... so long as you're ok
with obsolete) QWidgets.


to end,
Qt would never have appealed to me (maybe I would have landed on GTK+
instead idk) if the use of QWidgets required me to define my UI in
XML. This is essentially what QML is requiring.
d3fault

[Donald Carr]

> QML may be revolutionary, but it does not target the right camp. It
> targets the designer/amateur-coder audience. "Awww, poor baby. C++ too
> hard for you? Here's some meta-descriptive-GUI language where you can
> use simple javascript statements/code to implement all your back-end
> (and subsequently, perform non-trivial bindings)".

I am one of the dumbdumbs who like QML. Many of our devs find it
remarkably productive.
Maybe there was insufficient air flow in the Oslo office?

If we get the tooling correct we should be infinitely more
approachable to designers. QML is very human readable and hence lends
itself to tinkering/polishing by designers, but I think one should
probably have honed one's coding chops prior to writing a complex QML
project from scratch.

My $0.02 in any case

--
-------------------------------
 °v°  Donald Carr
/(_)\ Vaguely Professional Penguin lover
 ^ ^

Cave canem, te necet lingendo
Chasing my own tail; hate to see me leave, love to watch me go

[Иван Комиссаров]

You need users who will use Qt to survive. And those are desktop developers. Show me lot of not "hello world" apps writte using qml. Where are they? On symbian? Maybe in MeeGo? I don't see any on the desktop. But i see Guitar Pro right now which is based on QWidgets.

About O-notations. Article i mentioned shows that Quick-1 showed 90 FPS using QPainter. Why do we need to raize up performance to 250 FPS, if user can't see more than 24 frames per second? Excpecially in static UI. In my IPhone i don't see where i need such a big frame rate. I don't mention games (they need such FPS to freen CPU resource), and i think it really can be useful there. But NOT on the desktop. Almost all advantages of QML are gone there - batteries are big, CPU are fast. Painter works perfectly. And yes, i need _native_ interface here which is done using painter/styles. I don't want to implement 3 different interfaces for each platform. I want to use my old code. And you telling me to throw it away. Why the hell i should do that? First let microsoft deprecate winapi and reimplement whole OS from scratch. Then you can start telling me what to do.
And what about KDE? It is all based on QWidgets. And it took them many years to make stable release for KDE 4 (KDE 4.4 was the first release i could use). You want them to reimplement whole KDE using QML? And spent next 4-5 years fixing bugs that already occured in QWidget stack? No, thanks. Finish QML first, create big declarative item library (with all functionaloty that present in QWidgets, fix all bugs and only then say that painter and widgets are outdated).
Last qt releases (4.8) are crap - they give only bugs. Lot of people still prefer to use 4.7.4 (not me, however). As for Qt5 - even examples from Qt Demo crash. Even "outdated, but stable" widgets. And, which is more important, qt5 release is delayed.

What i'm trying to say - you stop maintaining qwidgets, but giving us promises about "beautiful qml" for 3 (three!!) years. And it is still not here. I don't believe it can replace qwidgets, sorry. In qt6, maybe, but not now. So continue adding new widgets and fixing old bugs, please.

18.05.2012, â 10:29, <marius.storm-***@nokia.com> <marius.storm-***@nokia.com> íàïèñàë(à):

Sounds like marketing?

It might be a 'constant' in the grand scheme of big-O notations. However,
if the result is that you can only get 24 fps on low-end HW with large
power footprint vs. 60 fps with HW acceleration, lower power footprint and
leaving the main CPU to do more important tasks, what would you call the
former? That's right, outdated technology. Scene graph is very much based
on what todays graphics cards are optimized for, while QPainter.. well,
it's not. We have gone as far as we could with QPainter, and needed
something new to survive the next 5-10 years. It's not about marketing, I
assure you.

--
.marius


On 5/18/12 7:36 AM, "ext Èâàí Êîìèññàðîâ" <***@gmail.com> wrote:

> Btw, you're saying that painter technology is outdated? What speedup
> provides QML scene graph? According to this
> http://labs.qt.nokia.com/2011/05/31/qml-scene-graph-in-master/ article,
> speedup is 2.5 times. As for me, it's just a constant optimization, it is
> not reduces complexity very much, as for me.
> If you say you reduced speed 10 times or 100 - it's the other issue. But
> saying that painter is outdated just because it 3 times slower than new
> qml... sounds like a marketing.
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>

[Ariel Molina]

Hello,

I've been following this thread since it started. My impression is that Qt
people believes we (users-devs) want to force you into further developing a
C++ toolkit (which might or might not be outdated). But I understand that
you will do work on what are *ordered* to work on, by your boss. It's
understandable.

Others think, that this discussion is about Qt Devs & team forcing QML (a
still immature & incomplete toolkit) into the community. While Qt Widgets
have been serving this community very well since years ago, these people
think this is a step backwards. QML *might* have a great future but it's
not even complete yet. Now it seems it's a fight between QPainter and QSG
(it think that's irrelevant).

Qt Devs have made pretty clear that QML will be a first class citizen along
C++, but in reality, there is a sense about Qt C++ being abandoned.
Specially when QML is still difficult to use from C++ and no work is
planned to be done (unless the community wants to step in) and even those
modules are marked as "done" (no further work by Qt Devs).

My point is a bit different, it's about the apparent disregard for Desktop
Components or 'legacy' widgets, I think it will contribute a little. QML
seems to be "the future" or at least that's how you want to market it.
Good, i like it myself. But even when "the future" now seems to be plagued
of futuristic "natural" interfaces, animated tiles and what not (I've
working hard on this as my PhD is about Human-Computer Interfaces (HCI)),
there are several strong critiques about it, by very renowned people, see
Donald Norman's: "Natural interfaces are not natural" [1]. Yes, he mainly
talks about gestures & touch, but that's the central point in creating
interfaces with QML. Years, decades, --no, centuries of man-hours-- have
been poured into the current interfaces, they work just fine because of
this. Incomplete, delayed or ignored support for so called 'legacy' widgets
is a heavy decision, is it based on reliable/exhaustive research? Other
have been studying Apple interfaces and have found they are nice, but, in
fact, difficult to use for many people, specially those >30yrs. People are
dropping well researched interfaces and replacing them with MS Bob[2] style
interfaces.

MS Bob/Touch friendly interfaces will not replace traditional interfaces.
So QML/Silverlight/Cocoa's flashy UI's will not fully replace traditional
apps. At the end, millions of real apps for real work will safely rest in
well researched UI grounds. So please, i love QML, but think twice before
really ignoring legacy QWidgets, make it easy to use current C++ API's with
the new QML elements (QML's base items are not even available to subclass),
pour a little more work on Desktop Components or, if not, at least create
*real* tools for us to develop UI's. No, you can't develop a serious UI
just in Creator, and the PS exporter script is really far from perfect,
even Blackberry has a better exporter with it's Cascades QML Exporter [3],
maybe you could coop, why 2 exporters?.

Ariel

[1] http://jnd.org/dn.mss/natural_user_interfaces_are_not_natural.html
[2] http://youtu.be/5teG6ou8mWU?t=2m54s
[3] http://devblog.blackberry.com/2012/05/cascades-builder/

On Fri, May 18, 2012 at 5:40 AM, ИваМ КПЌОссарПв <***@gmail.com> wrote:

> You need users who will use Qt to survive. And those are desktop
> developers. Show me lot of not "hello world" apps writte using qml. Where
> are they? On symbian? Maybe in MeeGo? I don't see any on the desktop. But i
> see Guitar Pro right now which is based on QWidgets.
>
> About O-notations. Article i mentioned shows that Quick-1 showed 90 FPS
> using QPainter. Why do we need to raize up performance to 250 FPS, if user
> can't see more than 24 frames per second? Excpecially in static UI. In my
> IPhone i don't see where i need such a big frame rate. I don't mention
> games (they need such FPS to freen CPU resource), and i think it really can
> be useful there. But NOT on the desktop. Almost all advantages of QML are
> gone there - batteries are big, CPU are fast. Painter works perfectly. And
> yes, i need _native_ interface here which is done using painter/styles. I
> don't want to implement 3 different interfaces for each platform. I want to
> use my old code. And you telling me to throw it away. Why the hell i should
> do that? First let microsoft deprecate winapi and reimplement whole OS from
> scratch. Then you can start telling me what to do.
> And what about KDE? It is all based on QWidgets. And it took them many
> years to make stable release for KDE 4 (KDE 4.4 was the first release i
> could use). You want them to reimplement whole KDE using QML? And spent
> next 4-5 years fixing bugs that already occured in QWidget stack? No,
> thanks. Finish QML first, create big declarative item library (with *all* functionaloty
> that present in QWidgets, fix *all *bugs and only then say that painter
> and widgets are outdated).
> Last qt releases (4.8) are crap - they give only bugs. Lot of people still
> prefer to use 4.7.4 (not me, however). As for Qt5 - even examples from Qt
> Demo crash. Even "outdated, but stable" widgets. And, which is more
> important, qt5 release is delayed.
>
> What i'm trying to say - you stop maintaining qwidgets, but giving us
> promises about "beautiful qml" for 3 (three!!) years. And it is still not
> here. I don't believe it can replace qwidgets, sorry. In qt6, maybe, but
> not now. So continue adding new widgets and fixing old bugs, please.
>
> 18.05.2012, в 10:29, <marius.storm-***@nokia.com> <
> marius.storm-***@nokia.com> МапОсал(а):
>
> Sounds like marketing?
>
> It might be a 'constant' in the grand scheme of big-O notations. However,
> if the result is that you can only get 24 fps on low-end HW with large
> power footprint vs. 60 fps with HW acceleration, lower power footprint and
> leaving the main CPU to do more important tasks, what would you call the
> former? That's right, outdated technology. Scene graph is very much based
> on what todays graphics cards are optimized for, while QPainter.. well,
> it's not. We have gone as far as we could with QPainter, and needed
> something new to survive the next 5-10 years. It's not about marketing, I
> assure you.
>
> --
> .marius
>
>
> On 5/18/12 7:36 AM, "ext ИваМ КПЌОссарПв" <***@gmail.com> wrote:
>
> Btw, you're saying that painter technology is outdated? What speedup
>
> provides QML scene graph? According to this
>
> http://labs.qt.nokia.com/2011/05/31/qml-scene-graph-in-master/ article,
>
> speedup is 2.5 times. As for me, it's just a constant optimization, it is
>
> not reduces complexity very much, as for me.
>
> If you say you reduced speed 10 times or 100 - it's the other issue. But
>
> saying that painter is outdated just because it 3 times slower than new
>
> qml... sounds like a marketing.
>
> _______________________________________________
>
> 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
>
>

[Donald Carr]

Hey,

On Fri, May 18, 2012 at 3:40 AM, Иван Комиссаров <***@gmail.com> wrote:
> And what about KDE? It is all based on QWidgets. And it took them many years
> to make stable release for KDE 4 (KDE 4.4 was the first release i could
> use). You want them to reimplement whole KDE using QML?

I thought the KDE dudes were already testing it against Qt 5. Anyone
on this list in a position to comment as to the current state of
things?

In any case, KDE 5 should clearly not re-invent the wheel, and Qt 4 ->
Qt 5 and not the same as Qt 3 -> Qt 4, which is the fear this kind of
mail evokes.

Many KDE apps will continue to be widget based, some might migrate to
QML if it is appropriate, or proves to be the correct technology in
the coming years. Of course, desktop components when they land will
push QML increasingly into the zone of widgets in the grand Venn
diagram.

Cheers,
Donald

--
-------------------------------
 °v°  Donald Carr
/(_)\ Vaguely Professional Penguin lover
 ^ ^

Cave canem, te necet lingendo
Chasing my own tail; hate to see me leave, love to watch me go

[Laszlo Papp]

> I thought the KDE dudes were already testing it against Qt 5. Anyone
> on this list in a position to comment as to the current state of
> things?

Well, we have been using Harmattan, Plasma Components and so forth for
experiments. QML and the component theory are way immature for using
this KDE wise. It would be just pointless to try to use this for
certain applications.

> In any case, KDE 5 should clearly not re-invent the wheel, and Qt 4 ->
> Qt 5 and not the same as Qt 3 -> Qt 4, which is the fear this kind of
> mail evokes.

There is no KDE 5. You may mean KDE Frameworks.

Best Regards,
Laszlo Papp

[d3fault]

DEFIB.

all of these are replies to comments in
http://labs.qt.nokia.com/2012/04/18/qt-5-c-and-qt-widgets/
which Marius Storm-Olsen decided to close


Donald
http://labs.qt.nokia.com/2012/04/18/qt-5-c-and-qt-widgets/#comment-72564
+ others
>We are putting serious effort into QML and hope to disrupt existing development paradigms. We are the same trolls we always were, and we are excited about our tech, like we always were. Shoot us. (I keep on seeing this straw man fallacy where people blame Nokia for our technical direction)

See: http://www.macieira.org/blog/2012/04/qt-project-statistics/
You being a 3rd party developer (thx btw (edit: wait I'm confused on
whether you're under Nokia's employ or not -- but it's irrelevant))
means yes, you do get to choose your own direction. You will always be
who you are, and you will always be excited about your tech. I don't
want to shoot you though. Keep making whatever you want. I'll keep on
getting lucky that I can benefit from your contributions (as well as
contributions from thousands (maybe millions someday) of others').
But how can you claim that Nokia does not drive the technical
direction? The move to open governance helped... but did not solve the
problem entirely. First, Nokia controls all Qt R&D funds (aside:
another company could do R&D for Qt... but they would then have to
allow Nokia to sell their R&D under a commercial license... while not
even being able to sell the [assumed-first-party] module under
commercial licensing themselves (not because they don't have the
rights to their own code... but because their contribution depends
entirely on the Qt library itself... which they (well, mainly each and
every one of their prospective customers... not 'they') need to
purchase a Qt commercial license for)). Second, the majority of the
'people in power' in the open governance project are Nokians. Sure,
the 2nd point is less relevant and time will hopefully change that.
Looking at the above Qt Project Statistics, you can see that Nokia
does the vast majority of the work on Qt. Although I don't have any
hard numbers, I don't think it would be much of a stretch to say that
over 50% of those Nokia contributors are working 8 hours a day, 5 days
a week on Qt Declarative, given it's size and ambition.
Nokia contributors do not get to choose what they work on (even if
they were the original Trolltech developers who invented Qt). The
corporation that is Nokia (*cough*irrelevant*cough* who happens to
depend HEAVILY on Microsoft for it's survival....
*cough*more-irrelevant-info*cough* who happens to hate Qt because it
directly competes with (and kicks the shit out of) their .Net
framework)) tells them what to do. Given the above numbers, it is safe
to say that Nokia is to blame for the technical direction. It is a
stretch to blame any of their business partners, however ;-).

One half of the argument: don't blame Nokia for Qt's direction
The other half (not made by you): Qt needs Nokia because of all of
their contributions
lol.

>QML bypasses the binary contract issue. I have personally ported a lot of code from QML 1 o QML 2, it was rather pleasant and involved me dusting off my sed skills. We do this via a hand behind the curtain which switched out the rendering engine and JS backend when you weren’t looking. You want us to drop the curtain, and yet still perform magic?

Yes, I do. The undocumented complexity of the QML->QtQuick
interpretation/structure-generation is [probably?] the main thing
stopping someone from writing a proper C++ front end to QtQuick.
As far as switching out the back-end 'magically'... ever heard of a
C++ interface? A v1 of a C++ Front-End to the QtQuickv1 back-end could
have been just as easy to port to the v2 C++ Front-End whenever
QtQuickv2 came about.

>You will find shouting at us as productive as shouting at people in the real world tends to be.

It seems hitting the devs with a barrage of logically sound arguments
is just as effective.

>Our (paid) development time is dictated strategically by technical concerns, a road map, laid out by technical people with a set agenda.

Nope. Sure, it might appear that way... but at the end of the day,
your boss tells you what to do.
The person who gives you money.

...the person who gives you money...
....the person you depend on.........
.....Nokia depends on who again.......?
<3 conspiracy theories xD

>If you were my manager, and assigned me task A, you would be happy with me working on task B instead because thousands (read 10?)

Bullshit, Donald. You and I both know that it's > 50% of the Qt
_users_ that want a C++ API. Nokia does too. Pro-QML camp just doesn't
want to be statistically called out. They're scared (lol @
kindergarten tactics) of the results. Prove me wrong ;-).


Dave
http://labs.qt.nokia.com/2012/04/18/qt-5-c-and-qt-widgets/#comment-72598
>I assume that if the people involved in the debate were capable of proposing a Qt-style C++ API for the QML functionality that the comment thread would look significantly different.

Incorrect. If the people involved in the debate were capable of
proposing a Qt-style C++ API for the QML functionality (meaning, a C++
front-end to the QtQuick back-end similar to the QML front-end), then
we'd already have a C++ Front-End to the QtQuick Back-End and there
would be no need for debate. The problem is that QtQuick is an
undocumented and complex beast. It's 'state of the art'. Without
QtQuick, QML is [essentially] worthless. The genius' behind
QML/QtQuick (yes, QtQuick was created with QML in mind :-/) are
[essentially] the only ones who know how it works... so they'd need to
be the ones to either a) create said C++ front-end, or b) properly
document the QtQuick internals (as well as overall design - what
happens when) so someone else can create said C++ front-end. Hopefully
this will be done after Qt 5.0 ships and we can begin playing catch up
with all the QML-specific functionality that has been created (lol,
talk about wasted effort. Qt is/will-be split in half).

QtQuick was developed with QML in mind, and also depends on it (for now).
QML was developed with JavaScript in mind, and also depends on it (for now).

We just want to hurry up and get both of those "for now"s out of the
way. Being fellow developers, we understand that decoupling a design's
dependencies is a lot harder than designing it to be decoupled in the
first place (say, for example, if QtQuick was designed with both a
QML/C++ front-end in mind). At this rate (and especially considering
the lack of interest from practically all of Nokia (hello Nokian who
agrees with us. I don't blame you for keeping your mouth shut. Jobs
are a hard thing to come by these days ;-))), it's going to take a
very long time before we have a C++ front-end to the QtQuick back-end.

Allegedly (according to Caspicse... although he suggests using it
directly like a troll), we just want a front-end to QtQuick that uses
QQuickView, QQuickItem, QSGNode and provides the QML functionality...
but in C++. Sounds easy... except looking at those 3 public classes, I
wouldn't have the slightest clue where to start. What's the difference
between an Item and a Node? They are both used interchangeably in
various contexts. Don't respond to this. Instead, put the
documentation where it belongs ;-).
I actually just spent a few minutes looking at the source code and
already found a problem with this approach: QQuickItem.h #includes
<QtQml/qqml.h> and <QtQml/qqmlcomponent.h> ... LOL WUT? QtQuick
depends on QML internally too? Great. That's as far as I read because
I already knew the design was fucked. lol @ 'decoupling' statement a
few sentences back.


Domino
http://labs.qt.nokia.com/2012/04/18/qt-5-c-and-qt-widgets/#comment-72628
>The decision regarding the C++ API seems to be based on the lack of resources and on time constraints.

"Lack of resources and time constraints" would also make an excellent
cover while still being true. It doesn't account for the fact that the
finite resources/time are already being used on something the majority
don't want.

What happens to QML/QtQuick if/when Nokia goes out of business this
year ( http://articles.businessinsider.com/2012-04-19/tech/31365445_1_nokia-ceo-stephen-elop-oil-platform
)? Ok probably bought out by Microsoft, but sameshit. We'll have an
unfinished/undocumented/incomplete QML/QtQuick implementation and
QML/QtQuick will be practically worthless. Microsoft will own the Qt
trademark at that point and will just sit on it (could be wrong, but
at the very least they're just going to ruin it more (could be wrong
again.. maybe Microsoft will see it for what it is and embrace/develop
it further, now that they own the trademark (pigs fly))).
QtQuick will still be too complicated to just up and create a C++
front-end for and we'd have to decide whether it's worth the effort of
reverse engineering the design of QtQuick or if we should create a
replacement from scratch using similar a design


Marius Storm-Olsen
http://labs.qt.nokia.com/2012/04/18/qt-5-c-and-qt-widgets/#comment-72629
>However, if you feel strongly for it, feel free to work on a code suggestion, submit it for peer-review and discussion at https://codereview.qt-project.org/

Oh, it's that easy eh I just come up with a 'code suggestion' for some
complex undocumented back-end and then just commit it and then it just
works just like that? What am I waiting for!?!?!?!? *codes randomly*
Thanks for closing the comments btw. More discussion is exactly what
we don't need. As you've pointed out, we just need 'code suggestions'
to be submitted from random independent developers.


d3fault

[m***@nokia.com]

On 5/18/12 8:22 AM, "ext Uwe Rathmann" <***@tigertal.de> wrote:
>I would be careful with terms like "outdated". In the end the desktop is
>the concept of the 90s ( widget are much older ) and the current
>desktops are the part that doesn't work on smartphones alike devices.
>But are keyboard and mouse outdated - only because smartphones and
>tablet devices don't have one - or why should a scene graph based
>application be more modern, when it runs inside of a Xfce/X11 desktop ?

Most "desktops" (Windows w/DWM, OSX w/Quartz Compositor, Linux
w/Compiz,Kwin) use compositing window managers these days, so running on
HW accelerated graphics cards using things like OpenGL and the like to
off-load as much as possible to the GPU, and enable very advanced effects,
while at the same time freeing up the main CPU to do other things than
creating a drop-shadow for a window pane etc.


>> What speedup provides QML scene graph? According to this
>>http://labs.qt.nokia.com/2011/05/31/qml-scene-graph-in-master/ article,
>>speedup is 2.5 times. As for me, it's just a constant optimization, it
>>is not reduces complexity very much, as for me.
>
>With raster QPainter::drawPolygon is significantly faster than
>QPolygonF::drawPolygonF. QPolygon::drawPolygon on Qt3/X11 is only a thin
>wrapper around X11 methods - something you can't beat performancewise.

Often it's hard to beat the performance of the main CPU(s for most people
these days) filling in a polygon directly, rather than handing it off to a
GPU. However, that's just a very very very tiny piece of the whole
picture. There are so many more collaborating parts of a whole application
which you are simply ignoring here.

>But by far the best performance you will have when you can reduce the
>number of points before drawPolygon on is called.

Even more performance you'd get by instead of flooding your main CPU with
polygon fills etc, you leave that up to the GPU and let the main CPU
update your business logic, think about the next frame in the animation,
etc; especially if that polygon you just filled is not even going to be
displayed in the scene because you paint something over it with the next
item needed in the same frame. Scene graph is designed to avoid all this
and give you the full HW accelerated benefits.

Just look at what can be done on the Raspberry Pi with scene graph +
wayland, and tell me you can do the same with QPainter + X11 through the
Pi's main CPU!
http://www.youtube.com/watch?v=HItv4HX5r3k - Qt 5 and Wayland on the
Raspberry Pi

--
.marius

[Uwe Rathmann]

On 05/18/2012 09:07 AM, marius.storm-***@nokia.com wrote:
> Often it's hard to beat the performance of the main CPU(s for most people
> these days) filling in a polygon directly, rather than handing it off to a
> GPU.

Guess this is the reason behind the decision why in Qt 4.8 raster has
become the default graphics system on X11 - what more or less means
turning hardware acceleration off
( maybe it's worth to mention that QPainter is not synonym for software
renderer - QPainter/X11 and QPainter/OpenGL are usually hardware
accelerated ).

While I can't confirm that the CPU does things faster for the most
relevant use cases I have in the Qwt library ( + the result is terrible
for remote X11 or NX ), I can imagine that there are other use cases
where this is true. F.e. on my box it is way faster to fill a QImage
with a gradient + converting it expensively to a QPixmap, than to fill
the QPixmap with the X11 paint engine. Don't know why - but, maybe this
is an example where a scene graph could do things better ?

But before you read me wrong: I'm absolutely not against having a new
and better graphic system - all I wanted to say is to be careful with
performance statistics.

Uwe

[Donald Carr]

> Just look at what can be done on the Raspberry Pi with scene graph +
> wayland, and tell me you can do the same with QPainter + X11 through the
> Pi's main CPU!
>    http://www.youtube.com/watch?v=HItv4HX5r3k - Qt 5 and Wayland on the
> Raspberry Pi

This succinctly summarizes our sentiments; We can do things we could
not dream of before. We produce more, while drawing less. You can
claim this sounds like Marketing, but when we trot Qt 5 out the door
on this $35 dollar ARM11 computer and it runs better than your Qt 4
applications on a current generation desktop machine, you have to
realize we are not peddling snake oil :)

Cheers,
Donald

--
-------------------------------
 °v°  Donald Carr
/(_)\ Vaguely Professional Penguin lover
 ^ ^

Cave canem, te necet lingendo
Chasing my own tail; hate to see me leave, love to watch me go