QML/JS engine in QtCore?

[l***@nokia.com]

Hi,

here comes the mail that I promised on the weekend. Let the flamewars
begin!

More seriously, I have been playing with the idea of moving both our basic
script integration (QJS* in the declarative module) as well as the QML
engine into QtCore.

As I outlined before, I consider it vital for Qt's success going forward
that we move QML into the center of what we do with Qt.

The classical widget model we have been successfully using for so many
years has reached it's limits and will not carry us forward any longer. I
have so far not heard a single person who seriously tried using QML and
would want to go back to Qt's classical way of building user interfaces.

But QML itself is not bound to graphical user interfaces. It's a generic
declarative language that could just as well be used for many other, non
graphical tasks. Having this powerful engine available everywhere will
open up many possibilities.

At the same time JavaScript is also getting more and more used, and there
are nowadays many developers that do want to do as little as possible in
C++. With the speed that modern JS engines such as V8 have reached, this
is also possible even on lower end systems.

The current split between Qt's object model living in one place and the
QML/JS engine in another has in Qt 4.x lead to suboptimal implementations
of the C++/JS bridge. Moving them into the same library gives us many more
possibilities to align the object models and really get the best
performance out of the binding engine and the bridging code between native
and C++. Getting as much as possible performance out of this will be
crucial to QMLs (and thus Qt's) success.

It would longer term also allow things such as using property bindings
from C++. This would allow app developers to save a lot of glue code.
Connecting signals to a piece of JS code also becomes possible (yes,
lambdas solve that problem to some extent as well).

As a side effect, this could also open up a few possibilities to use
implementations inside V8 in Qt. So far options are the RegExp engine,
dtoa, strtod code. This would reduce the size of the total Qt stack,
something that is important on many platforms where Qt is not preinstalled.

We could also solve certain pieces like proxy autoconfiguration without
requiring plugins that then pull in the JS engine anyways.


There's two main downsides I can see:

* People doing daemons/servers with Qt might see the JS engine as
problematic.

But if not used it doesn't really add any runtime overhead, so I wonder
how big of an issue this would be in practice.

* V8 is not yet working on some CPU architectures that Qt 4.x supports.

This sounds more severe, but if we get MIPS support for V8 (it's actively
being developed and it looks like it'll be there before we release 5.0),
the remaining CPU architectures account most likely for less than 1% of
the current Qt use cases. This is IMO not a good enough reason to hold the
other 99% back.

Comments?

Cheers,
Lars

[Konstantin Tokarev]

Post by l***@nokia.com
Hi,
here comes the mail that I promised on the weekend. Let the flamewars
begin!
More seriously, I have been playing with the idea of moving both our basic
script integration (QJS* in the declarative module) as well as the QML
engine into QtCore.
As I outlined before, I consider it vital for Qt's success going forward
that we move QML into the center of what we do with Qt.
The classical widget model we have been successfully using for so many
years has reached it's limits and will not carry us forward any longer. I
have so far not heard a single person who seriously tried using QML and
would want to go back to Qt's classical way of building user interfaces.
But QML itself is not bound to graphical user interfaces. It's a generic
declarative language that could just as well be used for many other, non
graphical tasks. Having this powerful engine available everywhere will
open up many possibilities.
At the same time JavaScript is also getting more and more used, and there
are nowadays many developers that do want to do as little as possible in
C++. With the speed that modern JS engines such as V8 have reached, this
is also possible even on lower end systems.
The current split between Qt's object model living in one place and the
QML/JS engine in another has in Qt 4.x lead to suboptimal implementations
of the C++/JS bridge. Moving them into the same library gives us many more
possibilities to align the object models and really get the best
performance out of the binding engine and the bridging code between native
and C++. Getting as much as possible performance out of this will be
crucial to QMLs (and thus Qt's) success.
It would longer term also allow things such as using property bindings
from C++. This would allow app developers to save a lot of glue code.
Connecting signals to a piece of JS code also becomes possible (yes,
lambdas solve that problem to some extent as well).
As a side effect, this could also open up a few possibilities to use
implementations inside V8 in Qt. So far options are the RegExp engine,
dtoa, strtod code. This would reduce the size of the total Qt stack,
something that is important on many platforms where Qt is not preinstalled.
We could also solve certain pieces like proxy autoconfiguration without
requiring plugins that then pull in the JS engine anyways.
* People doing daemons/servers with Qt might see the JS engine as
problematic.
But if not used it doesn't really add any runtime overhead, so I wonder
how big of an issue this would be in practice.
* V8 is not yet working on some CPU architectures that Qt 4.x supports.
This sounds more severe, but if we get MIPS support for V8 (it's actively
being developed and it looks like it'll be there before we release 5.0),
the remaining CPU architectures account most likely for less than 1% of
the current Qt use cases. This is IMO not a good enough reason to hold the
other 99% back.

Hi Lars,

Qt was known as a C++ framework. What the heck JavaScript is doing here
in QtCore?

[Robin Burchell]

hi,

Post by Konstantin Tokarev
Qt was known as a C++ framework. What the heck JavaScript is doing here
in QtCore?

let's stick to the technical points, please

Post by Konstantin Tokarev

Post by l***@nokia.com
The current split between Qt's object model living in one place and the
QML/JS engine in another has in Qt 4.x lead to suboptimal implementations
of the C++/JS bridge.

i'd like to hear more details on how exactly this was suboptimal. most
of the issues i've heard about QtScript have revolved around two major
points:

1) JSC being patched in upstream-incompatible ways (causing pain, even
to Qt - in that two copies of JSC were built)
2) the Qt-ish API that was wrapped around JSC was not capable to be
completely performant in some ways (I don't know details)

I don't see how either of these would be addressed by having V8 in
QtCore, so perhaps there's something I'm missing. AFAIK, the
advantages of merging would be that the compiler would have a better
chance to optimise (since they're all going into one compilation
unit), but will that actually provide *measurable* gain?

I guess I should be colored mildly sceptical about this, not because
I'm not drinking the QML coolaid, but because I like my pieces in
logically ordered places.

BR,

--
Robin Burchell
http://rburchell.com

[Thiago Macieira]

Post by l***@nokia.com
This sounds more severe, but if we get MIPS support for V8 (it's actively
being developed and it looks like it'll be there before we release 5.0),
the remaining CPU architectures account most likely for less than 1% of
the current Qt use cases. This is IMO not a good enough reason to hold the
other 99% back.

I agree with most of what you said.

What I don't agree with is the dropping forever *ALL* other architectures that
aren't x86, x86-64, ARM and MIPS.

Right now, there's simply no way that V8 will work on those architectures
without writing at least 20k lines of code. And I'm being optimistic here,
assuming that a generic p-code or AST runner will be half the size of each of
the currently well-supported architectures (40k-45k LOC each)

I don't mind an implementation that runs very slowly on other platforms, as
long as it's just the JS and QML code. People on those platforms will simply
avoid using those technologies.

In the long run, they may abandon Qt, as QML becomes necessary for everything
and it's unbearably slow.

But I cannot in good conscience agree with dropping them all right now, for
5.0.

[Thiago Macieira]

Post by l***@nokia.com
But if not used it doesn't really add any runtime overhead, so I wonder
how big of an issue this would be in practice.

That's not actually true. There is an impact at runtime regardless of whether
you use it or not. You may judge the numbers to see if they are big or small,
produce

The first impact is the size of the non-sharable sections.

$ eu-readelf -l libQt{Core,V8}.so.5.0.0 /lib64/libpcre.so.0 | grep LOAD.*RW
Type Offset VirtAddr PhysAddr FileSiz MemSiz
Flg Align
LOAD 0x2dd000 0x00000000004dd000 0x00000000004dd000 0x0106d0
0x011f38 RW 0x200000
LOAD 0x437228 0x0000000000637228 0x0000000000637228 0x065840
0x069020 RW 0x200000
LOAD 0x03b610 0x0000003c7183b610 0x0000003c7183b610 0x000470
0x000488 RW 0x200000

Compare the size of QtCore's RW section (0x106d0 -> 0x11000 = 68kB) to QtV8's
RW section (0x65840 -> 0x66000 = 408 kB). That's per process.


If I LD_PRELOAD QtCore and QtV8 into cat, which is a program that uses neither
library, I can find out how much memory needs to be faulted in simply because
of the library being present. The totals are:

QtCore: 432 kB sharable + 56 kB non-sharable
QtV8: 1552 kB sharable + 440 kB non-sharable

Those are pages that need to read from the mass storage into main memory.


The next impact is the relocations to be processed at load-time:
$ relinfo.pl libQt{Core,V8}.so.5.0.0 /lib64/libpcre.so.0
libQtCore.so.5.0.0: 3395 relocations, 2595 relative (76%), 223 PLT entries, 4
for local syms (1%), 0 users
libQtV8.so.5.0.0: 47923 relocations, 46880 relative (97%), 120 PLT entries, 0
for local syms (0%), 0 users
/lib64/libpcre.so.0: 46 relocations, 23 relative (50%), 25 PLT entries, 13 for
local syms (52%), 37 users

V8 has 18x more relative relocations than QtCore. All of those must be
processed at load-time, unless prelinking was executed. It's about the size of
the current QtGui (pre-refactor) and QtXmlPatterns combined:

libQtGui.so.5.0.0: 27781 relocations, 22008 relative (79%), 1473 PLT entries,
1 for local syms (0%), 0 users
libQtXmlPatterns.so.5.0.0: 26012 relocations, 23240 relative (89%), 360 PLT
entries, 0 for local syms (0%), 0 users

[l***@nokia.com]

Yes, you're right that it adds some memory and startup overhead. The
question that comes up is when you look at a whole system on whether this
matters. If 95% of the apps anyway link to QtDeclarative or scripting in
some way, it might not be a huge issue.

The relocations you mention below might be fixable by using -Bsymbolic and
-Bsymbolic-functions when linking QtV8.

Cheers,
Lars

Post by Thiago Macieira

Post by l***@nokia.com
But if not used it doesn't really add any runtime overhead, so I wonder
how big of an issue this would be in practice.

That's not actually true. There is an impact at runtime regardless of whether
you use it or not. You may judge the numbers to see if they are big or small,
produce
The first impact is the size of the non-sharable sections.
$ eu-readelf -l libQt{Core,V8}.so.5.0.0 /lib64/libpcre.so.0 | grep LOAD.*RW
Type Offset VirtAddr PhysAddr FileSiz
MemSiz
Flg Align
LOAD 0x2dd000 0x00000000004dd000 0x00000000004dd000 0x0106d0
0x011f38 RW 0x200000
LOAD 0x437228 0x0000000000637228 0x0000000000637228 0x065840
0x069020 RW 0x200000
LOAD 0x03b610 0x0000003c7183b610 0x0000003c7183b610 0x000470
0x000488 RW 0x200000
Compare the size of QtCore's RW section (0x106d0 -> 0x11000 = 68kB) to QtV8's
RW section (0x65840 -> 0x66000 = 408 kB). That's per process.
If I LD_PRELOAD QtCore and QtV8 into cat, which is a program that uses neither
library, I can find out how much memory needs to be faulted in simply because
QtCore: 432 kB sharable + 56 kB non-sharable
QtV8: 1552 kB sharable + 440 kB non-sharable
Those are pages that need to read from the mass storage into main memory.
$ relinfo.pl libQt{Core,V8}.so.5.0.0 /lib64/libpcre.so.0
libQtCore.so.5.0.0: 3395 relocations, 2595 relative (76%), 223 PLT entries, 4
for local syms (1%), 0 users
libQtV8.so.5.0.0: 47923 relocations, 46880 relative (97%), 120 PLT entries, 0
for local syms (0%), 0 users
/lib64/libpcre.so.0: 46 relocations, 23 relative (50%), 25 PLT entries, 13 for
local syms (52%), 37 users
V8 has 18x more relative relocations than QtCore. All of those must be
processed at load-time, unless prelinking was executed. It's about the size of
libQtGui.so.5.0.0: 27781 relocations, 22008 relative (79%), 1473 PLT entries,
1 for local syms (0%), 0 users
libQtXmlPatterns.so.5.0.0: 26012 relocations, 23240 relative (89%), 360 PLT
entries, 0 for local syms (0%), 0 users
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358

[Thiago Macieira]

Post by l***@nokia.com
Yes, you're right that it adds some memory and startup overhead. The
question that comes up is when you look at a whole system on whether this
matters. If 95% of the apps anyway link to QtDeclarative or scripting in
some way, it might not be a huge issue.
The relocations you mention below might be fixable by using -Bsymbolic and
-Bsymbolic-functions when linking QtV8.

These numbers are with -Bsymbolic-functions already.

Without it, the number of non-relative relocations would increase, but I don't
think by much. There aren't many exported classes.

The vast majority of these relocations are caused by the virtual tables of
non-exported classes, with no exported base class:

$ objdump -R libQtV8.so.5.0.0| awk '/__cxxabi/ || /__cxa_pure_virtual/{ print
$3 }' | uniq -c
525 _ZTVN10__cxxabiv120__si_class_type_infoE+0x0000000000000010
56 _ZTVN10__cxxabiv117__class_type_infoE+0x0000000000000010
2 _ZTVN10__cxxabiv121__vmi_class_type_infoE+0x0000000000000010
319 __cxa_pure_virtual

This is caused by the code design: the visitor pattern that calls back into
the the current class.

I was just pointing out that it isn't free. But I agree that the impact will
be there if people want to use QML anyway.

It will just be nearly impossible convincing anyone not already using Qt that
QtCore is acceptable (for example, to write system services on Linux).

The major problem I have is that it makes any port to a new architecture
require 40k lines of code.

[l***@nokia.com]

Post by Thiago Macieira

Post by l***@nokia.com
Yes, you're right that it adds some memory and startup overhead. The
question that comes up is when you look at a whole system on whether this
matters. If 95% of the apps anyway link to QtDeclarative or scripting in
some way, it might not be a huge issue.
The relocations you mention below might be fixable by using -Bsymbolic and
-Bsymbolic-functions when linking QtV8.

These numbers are with -Bsymbolic-functions already.
Without it, the number of non-relative relocations would increase, but I don't
think by much. There aren't many exported classes.
The vast majority of these relocations are caused by the virtual tables of
$ objdump -R libQtV8.so.5.0.0| awk '/__cxxabi/ || /__cxa_pure_virtual/{ print
$3 }' | uniq -c
525 _ZTVN10__cxxabiv120__si_class_type_infoE+0x0000000000000010
56 _ZTVN10__cxxabiv117__class_type_infoE+0x0000000000000010
2 _ZTVN10__cxxabiv121__vmi_class_type_infoE+0x0000000000000010
319 __cxa_pure_virtual
This is caused by the code design: the visitor pattern that calls back into
the the current class.
I was just pointing out that it isn't free. But I agree that the impact will
be there if people want to use QML anyway.
It will just be nearly impossible convincing anyone not already using Qt that
QtCore is acceptable (for example, to write system services on Linux).
The major problem I have is that it makes any port to a new architecture
require 40k lines of code.

Agree, the last two arguments are probably the most severe ones. A
bytecode/p-code backend in V8 would really help here.

The other option I've been discussing a bit with a few people would be to
split libQtDeclarative into a part containing the engine (JS and QML) and
one containing the graphical items. I don't think that would be
problematic for anybody. The engine would then purely depend on QtCore
(and maybe network).

It doesn't give us everything, but is probably better than the current
situation with the JS engine only being available with a Gui dependency.

Kent and Jedrzej will look into this right now so we can get a clean split
between the engine and the QML items. Let's see how we move on once that's
done.

Cheers,
Lars

[Jason H]

My cracked mind once came up with the idea of using QML to render HTML/XML pages. So I would support any such decision to split it and put it maybe not into core, but a gui-less module.

I imaging doing web pages as QML components, served by a HTTP server that has the QML/JS bound to it.

Page {
    Head { }

    Body {
        Header { }
        MainContent { }

        Footer { }
    }

}

Where Header, Body, MainContent Footer are user QML files, and Page and Head are part of a QML/XHTML library. Other uses are possible, as you should be able to create your own output serialization (binary formats?) Movie { Frames { Overlay{} Frame {} ... } } etc.




________________________________
From: "***@nokia.com" <***@nokia.com>
To: ***@kde.org; qt5-***@qt.nokia.com
Sent: Tuesday, September 6, 2011 11:33 AM
Subject: Re: [Qt5-feedback] QML/JS engine in QtCore?

Post by Thiago Macieira

Post by l***@nokia.com
Yes, you're right that it adds some memory and startup overhead. The
question that comes up is when you look at a whole system on whether this
matters. If 95% of the apps anyway link to QtDeclarative or scripting in
some way, it might not be a huge issue.
The relocations you mention below might be fixable by using -Bsymbolic and
-Bsymbolic-functions when linking QtV8.

These numbers are with -Bsymbolic-functions already.
Without it, the number of non-relative relocations would increase, but I don't
think by much. There aren't many exported classes.
The vast majority of these relocations are caused by the virtual tables of
$ objdump -R libQtV8.so.5.0.0| awk '/__cxxabi/ || /__cxa_pure_virtual/{ print
$3 }' | uniq -c
    525 _ZTVN10__cxxabiv120__si_class_type_infoE+0x0000000000000010
    56 _ZTVN10__cxxabiv117__class_type_infoE+0x0000000000000010
      2 _ZTVN10__cxxabiv121__vmi_class_type_infoE+0x0000000000000010
    319 __cxa_pure_virtual
This is caused by the code design: the visitor pattern that calls back into
the the current class.
I was just pointing out that it isn't free. But I agree that the impact will
be there if people want to use QML anyway.
It will just be nearly impossible convincing anyone not already using Qt that
QtCore is acceptable (for example, to write system services on Linux).
The major problem I have is that it makes any port to a new architecture
require 40k lines of code.

Agree, the last two arguments are probably the most severe ones. A
bytecode/p-code backend in V8 would really help here.

The other option I've been discussing a bit with a few people would be to
split libQtDeclarative into a part containing the engine (JS and QML) and
one containing the graphical items. I don't think that would be
problematic for anybody. The engine would then purely depend on QtCore
(and maybe network).

It doesn't give us everything, but is probably better than the current
situation with the JS engine only being available with a Gui dependency.

Kent and Jedrzej will look into this right now so we can get a clean split
between the engine and the QML items. Let's see how we move on once that's
done.

Cheers,
Lars

[Marcus D. Hanwell]

Post by l***@nokia.com

Post by Thiago Macieira

Post by l***@nokia.com
Yes, you're right that it adds some memory and startup overhead. The
question that comes up is when you look at a whole system on whether this
matters. If 95% of the apps anyway link to QtDeclarative or scripting in
some way, it might not be a huge issue.
The relocations you mention below might be fixable by using -Bsymbolic and
-Bsymbolic-functions when linking QtV8.

These numbers are with -Bsymbolic-functions already.
Without it, the number of non-relative relocations would increase, but I don't
think by much. There aren't many exported classes.
The vast majority of these relocations are caused by the virtual tables of
$ objdump -R libQtV8.so.5.0.0| awk '/__cxxabi/ || /__cxa_pure_virtual/{ print
$3 }' | uniq -c
   525 _ZTVN10__cxxabiv120__si_class_type_infoE+0x0000000000000010
    56 _ZTVN10__cxxabiv117__class_type_infoE+0x0000000000000010
     2 _ZTVN10__cxxabiv121__vmi_class_type_infoE+0x0000000000000010
   319 __cxa_pure_virtual
This is caused by the code design: the visitor pattern that calls back into
the the current class.
I was just pointing out that it isn't free. But I agree that the impact will
be there if people want to use QML anyway.
It will just be nearly impossible convincing anyone not already using Qt that
QtCore is acceptable (for example, to write system services on Linux).
The major problem I have is that it makes any port to a new architecture
require 40k lines of code.

Agree, the last two arguments are probably the most severe ones. A
bytecode/p-code backend in V8 would really help here.
The other option I've been discussing a bit with a few people would be to
split libQtDeclarative into a part containing the engine (JS and QML) and
one containing the graphical items. I don't think that would be
problematic for anybody. The engine would then purely depend on QtCore
(and maybe network).
It doesn't give us everything, but is probably better than the current
situation with the JS engine only being available with a Gui dependency.

Adding it to core certainly seems like a step backwards from greater
modularization, where as this approach seems ideal to me. As a
developer who would like to use QtCore, I would like it to remain
pretty small. If I have projects that need the interpreter linking an
extra library in seems fairly sensible.

Looking forward to seeing what you come up with.

Marcus

[Kent Hansen]

Post by l***@nokia.com
Agree, the last two arguments are probably the most severe ones. A
bytecode/p-code backend in V8 would really help here.
The other option I've been discussing a bit with a few people would be to
split libQtDeclarative into a part containing the engine (JS and QML) and
one containing the graphical items. I don't think that would be
problematic for anybody. The engine would then purely depend on QtCore
(and maybe network).
It doesn't give us everything, but is probably better than the current
situation with the JS engine only being available with a Gui dependency.
Kent and Jedrzej will look into this right now so we can get a clean split
between the engine and the QML items. Let's see how we move on once that's
done.
Cheers,
Lars

If QColor were in QtCore, this split would be a breeze :D (QML has
intrinsic support for it)
(Yes, moving QColor to core would be a violation of all we hold holy --
but hey, there's already precedence with QPoint and friends)
(And no, it can't be moved anyway because it depends on X11 (for
translating strings to colors))
(But yes, we could have a runtime hook in QApplication to still support
that)
(Or how about just nuking the X11 color support for Qt 5 --
QColor::allowX11ColorNames(), wtf?)

Kent

[Samuel Rødal]

Post by Kent Hansen
If QColor were in QtCore, this split would be a breeze :D (QML has
intrinsic support for it)
(Yes, moving QColor to core would be a violation of all we hold holy --
but hey, there's already precedence with QPoint and friends)
(And no, it can't be moved anyway because it depends on X11 (for
translating strings to colors))
(But yes, we could have a runtime hook in QApplication to still support
that)
(Or how about just nuking the X11 color support for Qt 5 --
QColor::allowX11ColorNames(), wtf?)
Kent

Q_WS_X11 will never be defined in Qt 5, the windowing system is
Lighthouse, or Q_WS_QPA (I guess we can eventually get rid of that one
though since it's the only supported one).

Thus I guess the X11 color names path is never run and the API can be
removed.

--
Samuel

[Thiago Macieira]

Post by Samuel Rødal

Post by Kent Hansen
If QColor were in QtCore, this split would be a breeze :D (QML has
intrinsic support for it)
(Yes, moving QColor to core would be a violation of all we hold holy --
but hey, there's already precedence with QPoint and friends)
(And no, it can't be moved anyway because it depends on X11 (for
translating strings to colors))
(But yes, we could have a runtime hook in QApplication to still support
that)
(Or how about just nuking the X11 color support for Qt 5 --
QColor::allowX11ColorNames(), wtf?)
Kent

Q_WS_X11 will never be defined in Qt 5, the windowing system is
Lighthouse, or Q_WS_QPA (I guess we can eventually get rid of that one
though since it's the only supported one).
Thus I guess the X11 color names path is never run and the API can be
removed.

Make QColor a simple value class, independent of WS.

If necessary, we can add a function to a GUI class somewhere that fetches a
named colour from the WS and returns in QColor. QDesktopServices, QPalette are
candidates.

[Bjørn Erik Nilsen]

Post by Thiago Macieira
I was just pointing out that it isn't free. But I agree that the impact will
be there if people want to use QML anyway.

From http://labs.qt.nokia.com/2011/05/09/thoughts-about-qt-5/:

"Vision

Qt 5 should be the foundation for a new way of developing applications.
While offering all of the power of native Qt using C++, the focus should
shift to a model, where C++ is mainly used to implement modular backend
functionality for Qt Quick."


If that's still our vision (and I hope it is) - then it doesn't make
sense to talk about:

1) Platforms not supporting QML in the first place
2) Load times / memory usage for application not using QML

[Artur Souza (MoRpHeUz)]

Post by Bjørn Erik Nilsen
"Vision
Qt 5 should be the foundation for a new way of developing applications.
While offering all of the power of native Qt using C++, the focus should
shift to a model, where C++ is mainly used to implement modular backend
functionality for Qt Quick."

While this may be completely true for GUI applications, it's not true
for applications that doesn't have a GUI at all. The vision is great
when we talk about technologies of the same "level" (QWidgets vs QML)
and if this discussion was about QWidgets I would understand your
point.

But QtCore goes way far QML can go and IMHO we should support these use cases...

[Artur Souza (MoRpHeUz)]

Yes, we will continue to support these use cases (if possible), it's just
that our main focus is shifted towards QtQuick-based applications which
means that is the use case we are going to optimize for.

Sure, but if we can optimize for QtQuick based applications *and*
still provide a good solution for QtCore only apps, it looks like a
good way to go ;)

[Harri Porten]

Post by Artur Souza (MoRpHeUz)

Post by Bjørn Erik Nilsen
Qt 5 should be the foundation for a new way of developing applications.
While offering all of the power of native Qt using C++, the focus should
shift to a model, where C++ is mainly used to implement modular backend
functionality for Qt Quick."

While this may be completely true for GUI applications, it's not true
for applications that doesn't have a GUI at all. The vision is great
when we talk about technologies of the same "level" (QWidgets vs QML)
and if this discussion was about QWidgets I would understand your
point.

Right. And - to maybe cover BjÞrn's concern - such GUI-less applications
are not necessarily completely separate from the GUI. Looking at a complex
system like the KDE desktop or semi-complex standalone application's
you'll find a set of tools (command line helper tools, daemons)
complementing the GUI. I'm seeing this every scenario every day with
application's from customers and our own. The split done in Qt 4 was a
good thing and shouldn't be reversed imo.

Harri.

[Bjørn Erik Nilsen]

Post by Artur Souza (MoRpHeUz)
While this may be completely true for GUI applications, it's not true
for applications that doesn't have a GUI at all. The vision is great
when we talk about technologies of the same "level" (QWidgets vs QML)
and if this discussion was about QWidgets I would understand your
point.
But QtCore goes way far QML can go and IMHO we should support these use cases...

Yes, we will continue to support these use cases (if possible), it's
just that our main focus is shifted towards QtQuick-based applications
which means that is the use case we are going to optimize for.

[BRM]

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

Post by Artur Souza (MoRpHeUz)

Post by Artur Souza (MoRpHeUz)
While this may be completely true for GUI applications, it's not true
for applications that doesn't have a GUI at all. The vision is great
when we talk about technologies of the same "level" (QWidgets vs

QML)

Post by Artur Souza (MoRpHeUz)
and if this discussion was about QWidgets I would understand your
point.
But QtCore goes way far QML can go and IMHO we should support these use

cases...
Yes, we will continue to support these use cases (if possible), it's
just that our main focus is shifted towards QtQuick-based applications
which means that is the use case we are going to optimize for.

Out of curiosity, how much of the user-base of Qt would that be for? 40%? 60%?

It's certainly not 100%, and as otherwise noted in one of the threads over the last few days, Qt Commercial users would have a problem using QtQuick given licensing issues. (Not unsolvable for them; but still an issue.)
I do realize that Qt Commercial users are probably <10% of Qt users right now, the biggest being KDE users. I'm just curious how this all falls out.

Personally I haven't gotten into using QML yet - namely b/c it would be too big an overhaul of my one GUI application to do so; and most of my applications are closer to QtCore - being daemons via the QtService Component.

$0.02

Ben

[l***@nokia.com]

Post by BRM
----- Original Message -----

Post by Artur Souza (MoRpHeUz)

Post by Artur Souza (MoRpHeUz)
While this may be completely true for GUI applications, it's not true
for applications that doesn't have a GUI at all. The vision is great
when we talk about technologies of the same "level" (QWidgets vs

QML)

Post by Artur Souza (MoRpHeUz)
and if this discussion was about QWidgets I would understand your
point.
But QtCore goes way far QML can go and IMHO we should support these use

cases...
Yes, we will continue to support these use cases (if possible), it's
just that our main focus is shifted towards QtQuick-based applications
which means that is the use case we are going to optimize for.

Out of curiosity, how much of the user-base of Qt would that be for? 40%? 60%?
It's certainly not 100%, and as otherwise noted in one of the threads
over the last few days, Qt Commercial users would have a problem using
QtQuick given licensing issues. (Not unsolvable for them; but still an
issue.)
I do realize that Qt Commercial users are probably <10% of Qt users right
now, the biggest being KDE users. I'm just curious how this all falls out.

Licensing might be better with Qt 5 actually, as V8 is BSD licensed, so it
doesn't have a forced LGPL dependency as with 4.x.

Cheers,
Lars

Post by BRM
Personally I haven't gotten into using QML yet - namely b/c it would be
too big an overhaul of my one GUI application to do so; and most of my
applications are closer to QtCore - being daemons via the QtService
Component.
$0.02
Ben
_______________________________________________
Qt5-feedback mailing list
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback

[Peter Kuemmel]

JS in QtCore is not needed in headless embedded software.
But it would be a reason to not use Qt in such a project if JS couldn't be disabled.

I think "Core" is a the wrong name for a library with a complete JS interpreter/jit compiler.
Maybe it is possible to introduce an additional library (QtMicroCore?)
a level below QtCore which really has only core functionality: signal slot, reflection, QString, ... but absolutely nothing gui related (QSize, QPoint,
QState*, QAnimationGroup, QTranslation, ...)


Peter

[Bjørn Erik Nilsen]

Post by Peter Kuemmel
JS in QtCore is not needed in headless embedded software.
But it would be a reason to not use Qt in such a project if JS couldn't be disabled.

Exactly. It would be a good reason to not use *Qt5* in such a project.
Qt4 is more suitable for that use case.

Post by Peter Kuemmel
I think "Core" is a the wrong name for a library with a complete JS interpreter/jit compiler.
Maybe it is possible to introduce an additional library (QtMicroCore?)
a level below QtCore which really has only core functionality: signal slot, reflection, QString, ... but absolutely nothing gui related (QSize, QPoint,
QState*, QAnimationGroup, QTranslation, ...)

With the vision of Qt5 fresh in mind, it makes perfectly sense to move
JS into QtCore. It *is* the core of all Qt5 applications.

[Michael Hasselmann]

Post by Bjørn Erik Nilsen

Post by Peter Kuemmel
JS in QtCore is not needed in headless embedded software.
But it would be a reason to not use Qt in such a project if JS couldn't be disabled.

Exactly. It would be a good reason to not use *Qt5* in such a project.
Qt4 is more suitable for that use case.

Huh? You want them to stick with Qt4? For how long? One year? Three?
Five? Putting entirely needless extra obstacles in the Qt5 migration
path is not very promising.

Qt5 was also about better modularization so that different modules can
move at different speeds. Binding QML/JS to the core means you can only
move with the development speed of core, whereas I would assume QML/JS
development currently progresses a bit faster than that.

regards,
Michael

[André Pönitz]

Post by Bjørn Erik Nilsen

Post by Peter Kuemmel
JS in QtCore is not needed in headless embedded software.
But it would be a reason to not use Qt in such a project if JS couldn't be disabled.

Exactly. It would be a good reason to not use *Qt5* in such a project.
Qt4 is more suitable for that use case.

People want to use an actively developed and maintained version of Qt for
their projects - Gui or non-Gui. A significant part of the Qt 5 effort is also
to fix things that could not be fixed in Qt 4 for "compatibility reasons".

Staying at Qt 4 will not be a _long-term_ option for actively developed
projects, pretty much as staying with Qt 3 has not been an option for
most of the Qt projects that have survived the last decade.

Post by Bjørn Erik Nilsen

Post by Peter Kuemmel
I think "Core" is a the wrong name for a library with a complete JS interpreter/jit compiler.
Maybe it is possible to introduce an additional library (QtMicroCore?)
a level below QtCore which really has only core functionality: signal slot,
reflection, QString, ... but absolutely nothing gui related (QSize, QPoint,
QState*, QAnimationGroup, QTranslation, ...)

With the vision of Qt5 fresh in mind, it makes perfectly sense to move
JS into QtCore. It *is* the core of all Qt5 applications.

That vision is far from being universally shared.

Andre'

[Not speaking for my employer etc.]

[Thomas McGuire]

Hi,

Post by Bjørn Erik Nilsen

Post by Peter Kuemmel
JS in QtCore is not needed in headless embedded software.
But it would be a reason to not use Qt in such a project if JS couldn't be disabled.

Exactly. It would be a good reason to not use *Qt5* in such a project.
Qt4 is more suitable for that use case.

No one sane would use an unmaintained library, which Qt4 will be once Qt5 is
there.
People will not use Qt4 in these cases, they will just use an entirely
different library.

And frankly, I don't buy the argument that everyone will use QML in the
future. Nokia is focused on QML and mobile use cases right now, so they
probably see it as important. Touch interfaces will indeed be much more
important in the future, especially with the advance of tablets, still there
will always be traditional widget-based applications, and I think a huge
number of Qt developers are either ignoring or underestimating their
importance.
I have used QML in embedded touch-based projects and I think it is a really
nice fit for them, and I enjoy working with QML. However, I don't think QML is
a good fit for traditional applications.
Are you porting QtCreator to QML? If not, why not?

There will be many people still wanting to develop widget-based applications.
With people talking about deprecating everything widget-related and moving the
QML interpreter to QtCore, I fear the widget part of Qt is being neglected.

Please keep the widget-based UI as a first-class citizen in Qt, that is one of
its big strengths and also a big userbase.

Just my 2 cents.

Regards,
Thomas

[Konstantin Tokarev]

Post by Thomas McGuire
Hi,

 JS in QtCore is not needed in headless embedded software.
 But it would be a reason to not use Qt in such a project if JS couldn't
 be disabled.

 Exactly. It would be a good reason to not use *Qt5* in such a project.
 Qt4 is more suitable for that use case.

No one sane would use an unmaintained library, which Qt4 will be once Qt5 is
there.
People will not use Qt4 in these cases, they will just use an entirely
different library.

I hope Qt 4.8 will be supported for some time after Qt 5 release, e.g. like Qt 3.3.x

[Peter Kuemmel]

Post by Thomas McGuire
No one sane would use an unmaintained library, which Qt4 will be once Qt5 is
there.
People will not use Qt4 in these cases, they will just use an entirely
different library.
And frankly, I don't buy the argument that everyone will use QML in the
future. Nokia is focused on QML and mobile use cases right now, so they
probably see it as important. Touch interfaces will indeed be much more
important in the future, especially with the advance of tablets, still there

And there is still no mainstream device which uses Qt (only some "beta" quality MeeGo tablets). So QML is a Nokia/Symbian only story, and in some years there are only low-end phones with Symbian and smartphones with Windows. Maybe then QML is not interesting any more to Nokia and is dropped.

Post by Thomas McGuire
will always be traditional widget-based applications, and I think a huge
number of Qt developers are either ignoring or underestimating their
importance.
I have used QML in embedded touch-based projects and I think it is a really
nice fit for them, and I enjoy working with QML. However, I don't think QML is
a good fit for traditional applications.
Are you porting QtCreator to QML? If not, why not?

Without fully supporting QML for desktop applications, there always will be
widget-based apps. The best way to promote QML would have been to provide
great desktop QML elements, but Nokia only drops widgets and thinks this
is the best way to convince desktop-app developers.

Post by Thomas McGuire
There will be many people still wanting to develop widget-based applications.
With people talking about deprecating everything widget-related and moving the
QML interpreter to QtCore, I fear the widget part of Qt is being neglected.

Isn't desktop support still a creative Friday project? ;)

Peter

Post by Thomas McGuire
Please keep the widget-based UI as a first-class citizen in Qt, that is one of
its big strengths and also a big userbase.
Just my 2 cents.
Regards,
Thomas

[Pau Garcia i Quiles]

Post by Peter Kuemmel
And there is still no mainstream device which uses Qt (only some "beta"
quality MeeGo tablets). So QML is a Nokia/Symbian only story, and in some
years there are only low-end phones with Symbian and smartphones with
Windows. Maybe then QML is not interesting any more to Nokia and is dropped.

A while ago I proposed to use QML instead of XAML for WPF, which would make
QML relevant in Windows Phone devices, and in any .NET device in general:

http://www.elpauer.org/?p=660

QML => Replaces XAML
Javascript => Replaces C# "code behind" for WPF

It would require some serious work, of course.

[BRM]

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

Post by Peter Kuemmel

Post by Thomas McGuire
No one sane would use an unmaintained library, which Qt4 will be once Qt5 is
there.
People will not use Qt4 in these cases, they will just use an entirely
different library.
And frankly, I don't buy the argument that everyone will use QML in the
future. Nokia is focused on QML and mobile use cases right now, so they
probably see it as important. Touch interfaces will indeed be much more
important in the future, especially with the advance of tablets, still there

And there is still no mainstream device which uses Qt (only some
"beta" quality MeeGo tablets). So QML is a Nokia/Symbian only story,
and in some years there are only low-end phones with Symbian and smartphones
with Windows. Maybe then QML is not interesting any more to Nokia and is
dropped.

When talking about Mobile, yes. QML to my understanding is used quite a bit for KDE4, especially in Plasma. I could be wrong though.
Though, of course, while Nokia may be pursuing WP7 while Elop is in charge, there is nothing in the agreement from preventing them from moving to Android or back to Meego once he leaves.
(Some of his lieutenants might..but that's a different issue.) So don't count on Nokia being WP7 only, especially with the abysmal adoption of WP7 that is out there - which isn't going to improve.

Whoever replaces Elop would be suicidal not to move away from WP7 and to MeeGo or Android. (Elop has too much interesting in Microsoft succeeding to do that, and should be fired for conflict of interest alone; but that's diverting from the discussion.)
 

Post by Peter Kuemmel

Post by Thomas McGuire
will always be traditional widget-based applications, and I think a huge
number of Qt developers are either ignoring or underestimating their
importance.
I have used QML in embedded touch-based projects and I think it is a really
nice fit for them, and I enjoy working with QML. However, I don't think QML is
a good fit for traditional applications.
Are you porting QtCreator to QML? If not, why not?

Without fully supporting QML for desktop applications, there always will be
widget-based apps. The best way to promote QML would have been to provide
great desktop QML elements, but Nokia only drops widgets and thinks this
is the best way to convince desktop-app developers. 

Even with full support for QML for desktop applications there will still be a need for QWidget/QGraphicsWidget based applications.
QML doesn't meet the needs of certain functionalities - like drawing to the widget pixel by pixel; nor is that really a good use-case for QML either - since those applications typically need to be high performing too (more performant than JS would allow), and you typically need to be accessing data structures that are not easily transferred to a JS environment (since JS has no concept of byte alignment, etc.)
 

Post by Peter Kuemmel

Post by Thomas McGuire
There will be many people still wanting to develop widget-based applications.
With people talking about deprecating everything widget-related and moving the
QML interpreter to QtCore, I fear the widget part of Qt is being neglected.

Isn't desktop support still a creative Friday project? ;)

Desktop and Embedded are the two primary uses of Qt. Between KDE and the extensive embedding of Qt in all kinds of everyday appliances they are probably pretty equal.
Mobile has no where near the same foot print.
 
Ben

[Attila Csipa]

Post by BRM
Even with full support for QML for desktop applications there will still be
a need for QWidget/QGraphicsWidget based applications. QML doesn't meet the
needs of certain functionalities - like drawing to the widget pixel by
pixel; nor is that really a good use-case for QML either - since those
applications typically need to be high performing too (more performant than
JS would allow), and you typically need to be accessing data structures
that are not easily transferred to a JS environment (since JS has no
concept of byte alignment, etc.)

QWidget != (Q)Painter. Very important difference.

Post by BRM
Desktop and Embedded are the two primary uses of Qt. Between KDE and the
extensive embedding of Qt in all kinds of everyday appliances they are
probably pretty equal. Mobile has no where near the same foot print.

The footprint talk is mostly pointless given there is no real way to publicly
measure it. The only thing somewhat certain is that desktop and
mobile(/embedded) userbases are in the millions, which kind-of makes the point
of (not so) primary uses fairly moot.


Best regards,
Attila

[Thiago Macieira]

Post by Peter Kuemmel
And there is still no mainstream device which uses Qt (only some "beta"
quality MeeGo tablets). So QML is a Nokia/Symbian only story, and in some
years there are only low-end phones with Symbian and smartphones with
Windows. Maybe then QML is not interesting any more to Nokia and is
dropped.

Everyone who has tried to use QML has said it's much beyond any other
technology in terms of ease of development. I have friends making applications
professionally and that's what they tell me.

And yes, they are doing that on mobile devices...

Post by Peter Kuemmel
Without fully supporting QML for desktop applications, there always will be
widget-based apps. The best way to promote QML would have been to provide
great desktop QML elements, but Nokia only drops widgets and thinks this
is the best way to convince desktop-app developers.

I agree desktop components are necessary. They are being worked on and that's
what the Qt 5 vision is asking for: that we converge on QML for desktop too.
The technology is so great that we (the developer community) see value in
bringing it to the desktop and to all other types of devices.

It's not there yet, we can all see it. That's why QtWidgets is there in Qt 5.0
-- not to mention to ease the transition. But it will be there, some day.

Finally, stop saying "Nokia drops". With the open governance, the community
decides. If someone wants to maintain and improve the widgets, they can. Just
listen to the people currently working on it who say you should think twice:
stability, compatibility, best use of resources, etc. And the vision says we
should try and use QML.

And it's not being dropped. So saying that is technically a lie.

Post by Peter Kuemmel
Isn't desktop support still a creative Friday project? ;)

There haven't been Creative Fridays for over a year now. Research projects are
managed differently.

[Jason H]

The only two things holding QML back right now are
1) No one except usknows about it.
2) a NSAPI browser plugin.

Both of which would be fixed with a NSAPI browser plugin.



________________________________
From: Thiago Macieira <***@kde.org>
To: qt5-***@qt.nokia.com
Sent: Friday, September 9, 2011 9:59 AM
Subject: Re: [Qt5-feedback] QML/JS engine in QtCore?

Post by Peter Kuemmel
And there is still no mainstream device which uses Qt (only some "beta"
quality MeeGo tablets). So QML is a Nokia/Symbian only story, and in some
years there are only low-end phones with Symbian and smartphones with
Windows. Maybe then QML is not interesting any more to Nokia and is
dropped.

Everyone who has tried to use QML has said it's much beyond any other
technology in terms of ease of development. I have friends making applications
professionally and that's what they tell me.

And yes, they are doing that on mobile devices...

Post by Peter Kuemmel
Without fully supporting QML for desktop applications, there always will be
widget-based apps. The best way to promote QML would have been to provide
great desktop QML elements, but Nokia only drops widgets and thinks this
is the best way to convince desktop-app developers.

I agree desktop components are necessary. They are being worked on and that's
what the Qt 5 vision is asking for: that we converge on QML for desktop too.
The technology is so great that we (the developer community) see value in
bringing it to the desktop and to all other types of devices.

It's not there yet, we can all see it. That's why QtWidgets is there in Qt 5.0
-- not to mention to ease the transition. But it will be there, some day.

Finally, stop saying "Nokia drops". With the open governance, the community
decides. If someone wants to maintain and improve the widgets, they can. Just
listen to the people currently working on it who say you should think twice:
stability, compatibility, best use of resources, etc. And the vision says we
should try and use QML.

And it's not being dropped. So saying that is technically a lie.

Post by Peter Kuemmel
Isn't desktop support still a creative Friday project? ;)

There haven't been Creative Fridays for over a year now. Research projects are
managed differently.

[Pau Garcia i Quiles]

Post by Jason H
The only two things holding QML back right now are
1) No one except usknows about it.
2) a NSAPI browser plugin.

I guess you meant an NPAPI plugin (client-side), not an NSAPI plugin (server
side). Like this one:

http://sites.google.com/site/qtqmlbrowserplugin/home

[Jason H]

Ah yes. But that one has never worked for me.



________________________________
From: Pau Garcia i Quiles <***@elpauer.org>
To: Jason H <***@yahoo.com>
Cc: Thiago Macieira <***@kde.org>; "qt5-***@qt.nokia.com" <qt5-***@qt.nokia.com>
Sent: Friday, September 9, 2011 7:42 PM
Subject: Re: [Qt5-feedback] QML/JS engine in QtCore?





On Fri, Sep 9, 2011 at 5:08 PM, Jason H <***@yahoo.com> wrote:

The only two things holding QML back right now are

Post by Jason H
1) No one except usknows about it.
2) a NSAPI browser plugin.

I guess you meant an NPAPI plugin (client-side), not an NSAPI plugin (server side). Like this one:

http://sites.google.com/site/qtqmlbrowserplugin/home

[Thiago Macieira]

Post by Jason H
Ah yes. But that one has never worked for me.

Sounds like you need to join the project and help them.

[Peter Kuemmel]

Post by Thiago Macieira
Everyone who has tried to use QML has said it's much beyond any other
technology in terms of ease of development. I have friends making
applications professionally and that's what they tell me.

I don't know if I'm alone, but without fully supported QML-Desktop
elements I assume I will never try QML, because I don't care about
this app-hype.

Post by Thiago Macieira

Post by Peter Kuemmel
Isn't desktop support still a creative Friday project? ;)

There haven't been Creative Fridays for over a year now.
Research projects are managed different.

Desktop support was the most important feature in Trolltech times,
but now Desktop support is 'Done' (QWidget) or only a research project.

Qt5 should come with fully Nokia-supported QML Desktop Components.
This would also help the acceptance of QML, because it is technically
the next step.

Peter

[Thiago Macieira]

Post by Peter Kuemmel

Post by Thiago Macieira
Everyone who has tried to use QML has said it's much beyond any other
technology in terms of ease of development. I have friends making
applications professionally and that's what they tell me.

I don't know if I'm alone, but without fully supported QML-Desktop
elements I assume I will never try QML, because I don't care about
this app-hype.

I understand that sentiment. What I was saying is that I want to bring that
ease of making applications to the desktop too. Not because I think mobile UIs
are better (or worse, they are just different), but because I've seen how
productive people are with QML.

Post by Peter Kuemmel
Desktop support was the most important feature in Trolltech times,
but now Desktop support is 'Done' (QWidget) or only a research project.

Don't mix things. No one said desktop support is Done. The QWidget
infrastructure is Done. By equating the two, you're saying there can never be
anything other than widgets for the desktop. And I disagree.

Post by Peter Kuemmel
Qt5 should come with fully Nokia-supported QML Desktop Components.
This would also help the acceptance of QML, because it is technically
the next step.

So if it comes with a Digia-supported Desktop Components, you won't be happy?

Stop thinking about Nokia terms. What's important is that the technology
exists and someone is backing it up.

And no, the technology isn't there yet and won't be there for 5.0. Maybe not
even 5.1. But we want it to be there, eventually. I also get that you won't be
joining the development.

Maybe you'll volunteer to maintain the widget classes and bring it back up
from Done to Maintained?

[Uwe Rathmann]

Post by Thiago Macieira
I understand that sentiment. What I was saying is that I want to bring
that ease of making applications to the desktop too. Not because I think
mobile UIs are better (or worse, they are just different), but because
I've seen how productive people are with QML.

I can imagine that this is true for smaller applications with common
requirements - but probably not for applications that are developed in
months or years.

For the second type of applications it is not that important how to
configure widgets/components, organize them in layouts and set up some
signal/slots. It takes much more time to do things against the toolkit -
something Qt was always pretty good because of its many hooks, where
application code can interfere.

Don't know how good QML components will be in this category, but for my
productivity this counts more than how many lines I need for writing
trivial stuff.

Uwe

[Thiago Macieira]

Post by Uwe Rathmann

Post by Thiago Macieira
I understand that sentiment. What I was saying is that I want to bring
that ease of making applications to the desktop too. Not because I think
mobile UIs are better (or worse, they are just different), but because
I've seen how productive people are with QML.

I can imagine that this is true for smaller applications with common
requirements - but probably not for applications that are developed in
months or years.

How do you know this? Have you tried developing a QML application for years
and failed?

Post by Uwe Rathmann
For the second type of applications it is not that important how to
configure widgets/components, organize them in layouts and set up some
signal/slots. It takes much more time to do things against the toolkit -
something Qt was always pretty good because of its many hooks, where
application code can interfere.
Don't know how good QML components will be in this category, but for my
productivity this counts more than how many lines I need for writing
trivial stuff.

I didn't get what you meant. You said that for the second type of applications
(those that take years to develop) configuring the components and organising
them in layouts is not that important. You said that it takes more time to "do
things against the toolkit".

First, that's extremely vague. I can simply answer that with QML it's easier
to "do things against the toolkit", so it should take less time than it has
taken previously.

Second, you're comparing importance to what takes time. They're orthogonal.
What is important is important anyway, regardless of how long it takes to make
them. If QML can make the important things easier to do and take less time, we
should have more productivity, more time to do other things, like polish up
the application, debug, optimise, etc.

If you meant that tasks other than the UI are more important, you'll get mixed
replies. Some will argue that the UI is what users see and that's what you'll
be judged on, that in this world of iPhone if your app isn't good looking,
you'll lose points. Some others will argue that a beautiful UI is useless if
it doesn't do what it's supposed to do. I'll stay in the middle and say you
have to do both equally well.

With that in mind, if making the UI is easier and more productive, you get to
spend more time in the business logic and perfecting it. The rest of Qt (non-
UI) remains as it is today and will only improve.

So what are you complaining about?

[Uwe Rathmann]

Post by Thiago Macieira
So what are you complaining about?

I'm not positive or negative about QML - I simply don't know enough about
this technology and won't probably spent much time on it before a Qt 5
preview is available. But I know my average daily work with implementing/
maintaining Qt applications ( + Qwt ) since Qt 1.1.

Anyway, when you know about the situation of developing software beasts -
like you find them often in the industry - feel free to ignore my comment.

Uwe

[Uwe Rathmann]

Post by Thiago Macieira
First, that's extremely vague. I can simply answer that with QML it's
easier to "do things against the toolkit", so it should take less time
than it has taken previously.

I don't want get lost in a discussion of specific problems - just to give
you an idea:

I had to implement an application where the customer wanted to have a
user interface with rounded borders ( a requirement from the marketing ).
So the development decided to use a style sheet with backgrounds with
rounded borders.

Now we had a custom widget, where a spectrogram was displayed ( done with
QwtPlot, but this doesn't matter ). Because of aesthetic aspects and we
couldn't waste pixels ( Qt/Embedded on a small display ) it was not
acceptable to avoid the rounded corners by having contents margins - the
spectrogram had to fill all pixels inside the borders.

So I had to solve the following problems:

- How to know radius and width of the border to clip the spectrogram
- How to rearrange the drawing order, so the the background color is
below and the border is painted above the spectrogram( antialiasing )

There were a couple of other problems I had to solve ( f.e. performance
issues because Qt::WA_StyledBackground has an effect on update regions )
and in in the end it took me a week.

On the other side I needed less than a day to implement all the usual UI
stuff ( menus, widgets in layout + signals/slots ).

Again: this is no positive or negative statement about QML. All I want to
say is that every type of application I was working on has its own very
special weird requirements, that take the majority of my development
time. That's why I would always decide to use the API that helps me best
to do these things.

Uwe

[Adriano Rezende]

Post by Uwe Rathmann
Again: this is no positive or negative statement about QML. All I want to
say is that every type of application I was working on has its own very
special weird requirements, that take the majority of my development
time. That's why I would always decide to use the API that helps me best
to do these things.

There will be always weird requirements. QML doesn't block you from
implementing these specific components, since you can always fallback to C++
to create a spectrogram or whatever you need.
And yes, QML can scale for huge applications if you use it right. I've been
working in some pretty big projects, for desktop and mobile, during the last
years and I didn't reach any blocker issue. Even though QML still need some
refinements and maturation, it's far better than the old imperative way of
doing things.

Br,
Adriano

[Till Oliver Knoll]

Post by Uwe Rathmann

Post by Thiago Macieira
First, that's extremely vague. I can simply answer that with QML it's
easier to "do things against the toolkit"

I had to implement an application where the customer wanted to have a
user interface with rounded borders ( a requirement from the marketing ).

...

Post by Uwe Rathmann
in in the end it took me a week.

So what we have learned today: "don't let marketing get involved into development!"

;)

(And I won't even start to rant about personally how much I hate "custom-looking windows etc. - "Nokia, you hear me?! Your PC Suite visually sucked big time!") >;)

[Peter Kuemmel]

Post by Thiago Macieira
Don't mix things. No one said desktop support is Done. The QWidget
infrastructure is Done.

This is what I have meant with: 'Done' (QWidget)

Post by Thiago Macieira

Post by Peter Kuemmel
Qt5 should come with fully Nokia-supported QML Desktop Components.
This would also help the acceptance of QML, because it is technically
the next step.

So if it comes with a Digia-supported Desktop Components, you won't be happy?
Stop thinking about Nokia terms. What's important is that the
technology exists and someone is backing it up.

OK, but it is important that there are some fulltime developers.

Post by Thiago Macieira
And no, the technology isn't there yet and won't be there for 5.0. Maybe not
even 5.1. But we want it to be there, eventually. I also get that you won't be
joining the development.
Maybe you'll volunteer to maintain the widget classes and bring it
back up from Done to Maintained?

Have to think about it.


My main concern is to make Qt again more attractive for
desktop development. Most Qt developers came to Qt because
of desktop support, but since several releases nearly nothing
happens. A new Qt release isn't interesting any more
for desktop developers.

Peter

[Thiago Macieira]

Post by Peter Kuemmel

Post by Thiago Macieira
Don't mix things. No one said desktop support is Done. The QWidget
infrastructure is Done.

This is what I have meant with: 'Done' (QWidget)

That may be, but it's not what you said before.

Post by Peter Kuemmel

Post by Thiago Macieira
So if it comes with a Digia-supported Desktop Components, you won't be happy?
Stop thinking about Nokia terms. What's important is that the
technology exists and someone is backing it up.

OK, but it is important that there are some fulltime developers.

Why? Why are 2 full-time developers better than 20 part-time ones?

I'd love to have full-time developers working on this, but I'll take what I
can get. Besides, if you look at any feature over a reasonably long period of
time (6 months or more), there isn't a single one that has a full-time
developer. All developers multiplex between features.

Did you mean full-time equivalents? 20 developers devoting 10% of their time
is equivalent to 2 FTEs (in theory, of course).

Post by Peter Kuemmel

Post by Thiago Macieira
Maybe you'll volunteer to maintain the widget classes and bring it
back up from Done to Maintained?

Have to think about it.
My main concern is to make Qt again more attractive for
desktop development. Most Qt developers came to Qt because
of desktop support, but since several releases nearly nothing
happens. A new Qt release isn't interesting any more
for desktop developers.

And it's mine too. Except my strategy isn't to continue to add features to the
widget classes, but to make QML on desktop a first-class feature.

And you make it sound like desktop developers are *only* interested about
widgets. Improvements in performance in QObject aren't interesting? The new
improved file engine? How about new networking features? QtSql also had a
number of bugfixes... Not to mention, of course, QtWebKit 2.2 for the hybrid
application development.

[Peter Kuemmel]

Post by Thiago Macieira

Post by Peter Kuemmel
OK, but it is important that there are some fulltime developers.

Why? Why are 2 full-time developers better than 20 part-time ones?
I'd love to have full-time developers working on this, but I'll take what I
can get. Besides, if you look at any feature over a reasonably long period of
time (6 months or more), there isn't a single one that has a full-time
developer. All developers multiplex between features.
Did you mean full-time equivalents? 20 developers devoting 10% of their
time is equivalent to 2 FTEs (in theory, of course).

Fulltime or not, something should happen, but ATM nothing happens.

Post by Thiago Macieira

Post by Peter Kuemmel

Post by Thiago Macieira
Maybe you'll volunteer to maintain the widget classes and bring it
back up from Done to Maintained?

Have to think about it.
My main concern is to make Qt again more attractive for
desktop development. Most Qt developers came to Qt because
of desktop support, but since several releases nearly nothing
happens. A new Qt release isn't interesting any more
for desktop developers.

And it's mine too. Except my strategy isn't to continue to add features to the
widget classes, but to make QML on desktop a first-class feature.
And you make it sound like desktop developers are *only* interested about
widgets. Improvements in performance in QObject aren't interesting? The new
improved file engine? How about new networking features? QtSql also had a
number of bugfixes... Not to mention, of course, QtWebKit 2.2 for the hybrid
application development.

Sure non-GUI improvements are welcome, but having no progress on
desktop GUI elements for years (4.2? until 5.2?) decreases my
interest in Qt.

Peter

[Stefan Majewsky]

Post by Thomas McGuire
Please keep the widget-based UI as a first-class citizen in Qt, that is one of
its big strengths and also a big userbase.

And not only the widget-based UI: Please consider the cases where
QtCore is used as a direct alternative to the C++ standard library.
For example, I like to use QtCore in my numerical applications,
because of its implicitly shared container classes and its string
handling.

In the field of scientific applications, every additional dependency
turns science into rocket science when you try to get it to compile on
a high-performance cluster.

Greetings
Stefan

[Jason H]

I wholly disagree. It is the core of *your* Qt5 apps, but probably won't be mine.
It is also a poor decision to say "let them eat cake" and by cake I mean Qt4.

If you put JS into QtCore, then you need to make a QtKernel, however I also advise against this because this would create confusion between QtCore 4 and QtCore 5.

I've been a proponent of non-gui QML, meaning JS in QCoreApplication apps. However as I see it, the JS should be a separate component that is included just as SQL is. I even think there is a better argument that QtNetwork be put in core, since it is rare not to have any kind of network connectivity in this day and age. However, please note that recommendation is based on actual observation, whereas your reasoning that Qt5 apps will all need JS is based on anticipation. I prefer not to be wrong, and when you guess based on supposed future behavior, you will very likely be wrong. Let there be a QtJavaScript or QtQMLCore module.






________________________________
From: Bjørn Erik Nilsen <***@nokia.com>
To: qt5-***@qt.nokia.com
Sent: Thursday, September 8, 2011 7:25 AM
Subject: Re: [Qt5-feedback] QML/JS engine in QtCore?

Post by Peter Kuemmel
JS in QtCore is not needed in headless embedded software.
But it would be a reason to not use Qt in such a project if JS couldn't be disabled.

Exactly. It would be a good reason to not use *Qt5* in such a project.
Qt4 is more suitable for that use case.

Post by Peter Kuemmel
I think "Core" is a the wrong name for a library with a complete JS interpreter/jit compiler.
Maybe it is possible to introduce an additional library (QtMicroCore?)
a level below QtCore which really has only core functionality: signal slot, reflection, QString, ... but absolutely nothing gui related (QSize, QPoint,
QState*, QAnimationGroup, QTranslation, ...)

With the vision of Qt5 fresh in mind, it makes perfectly sense to move
JS into QtCore. It *is* the core of all Qt5 applications.

[l***@nokia.com]

Post by Jason H
I wholly disagree. It is the core of *your* Qt5 apps, but probably won't be mine.
It is also a poor decision to say "let them eat cake" and by cake I mean Qt4.
If you put JS into QtCore, then you need to make a QtKernel, however I
also advise against this because this would create confusion between
QtCore 4 and QtCore 5.
I've been a proponent of non-gui QML, meaning JS in QCoreApplication
apps. However as I see it, the JS should be a separate component that is
included just as SQL is. I even think there is a better argument that
QtNetwork be put in core, since it is rare not to have any kind of
network connectivity in this day and age. However, please note that
recommendation is based
on actual observation, whereas your reasoning that Qt5 apps will all
need JS is based on anticipation. I prefer not to be wrong, and when you
guess based on supposed future behavior, you will very likely be wrong.
Let there be a QtJavaScript or QtQMLCore module.

To bring the discussion to an end: Sounds like most people currently
prefer keeping the separation and rather have a lib QtJS or QMLCore.

Kent and Jedrzej are looking into this idea right now. Let's see how this
works out and where the problems are. We can still re-evaluate later on if
we find new arguments.

Cheers,
Lars

Post by Jason H
________________________________________
Sent: Thursday, September 8, 2011 7:25 AM
[Qt5-feedback] QML/JS engine in QtCore?

Post by Peter Kuemmel
JS in QtCore is not needed in headless embedded software.
But it would be a reason to not use Qt in such a project if JS couldn't be disabled.

Exactly. It would be a good reason to not use *Qt5* in such a project.
Qt4 is more suitable for that use case.

Post by Peter Kuemmel
I think "Core" is a the wrong name for a library with a complete JS
interpreter/jit compiler.
Maybe it is possible to introduce an additional library (QtMicroCore?)
a level below QtCore which really has only core functionality: signal
slot, reflection, QString, ... but absolutely nothing gui related
(QSize, QPoint,
QState*, QAnimationGroup, QTranslation, ...)

With the vision of Qt5 fresh in mind, it makes perfectly sense to move
JS into QtCore. It *is* the core of all Qt5 applications.
--
Bjørn Erik
Nilsen
Software Engineer
Nokia, Qt Development Frameworks
_______________________________________________
Qt5-feedback mailing list
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback

[Jason H]

Awesome, thanks.  The embedded market thanks you too.



________________________________
From: "***@nokia.com" <***@nokia.com>
To: qt5-***@qt.nokia.com
Sent: Thursday, September 8, 2011 9:44 AM
Subject: Re: [Qt5-feedback] QML/JS engine in QtCore?

Post by Jason H
I wholly disagree. It is the core of *your* Qt5 apps, but probably won't be mine.
It is also a poor decision to say "let them eat cake" and by cake I mean Qt4.
If you put JS into QtCore, then you need to make a QtKernel, however I
also advise against this because this would create confusion between
QtCore 4 and QtCore 5.
I've been a proponent of non-gui QML, meaning JS in QCoreApplication
apps. However as I see it, the JS should be a separate component that is
included just as SQL is. I even think there is a better argument that
QtNetwork be put in core, since it is rare not to have any kind of
network connectivity in this day and age. However, please note that
recommendation is based
on actual observation, whereas your reasoning that Qt5 apps will all
need JS is based on anticipation. I prefer not to be wrong, and when you
guess based on supposed future behavior, you will very likely be wrong.
Let there be a QtJavaScript or QtQMLCore module.

To bring the discussion to an end: Sounds like most people currently
prefer keeping the separation and rather have a lib QtJS or QMLCore.

Kent and Jedrzej are looking into this idea right now. Let's see how this
works out and where the problems are. We can still re-evaluate later on if
we find new arguments.

Cheers,
Lars

Post by Jason H
________________________________________
Sent: Thursday, September 8, 2011 7:25 AM
[Qt5-feedback] QML/JS engine in QtCore?

Post by Peter Kuemmel
JS in QtCore is not needed in headless embedded software.
But it would be a reason to not use Qt in such a project if JS couldn't be disabled.

Exactly. It would be a good reason to not use *Qt5* in such a project.
Qt4 is more suitable for that use case.

Post by Peter Kuemmel
I think "Core" is a the wrong name for a library with a complete JS
interpreter/jit compiler.
Maybe it is possible to introduce an additional library (QtMicroCore?)
a level below QtCore which really has only core functionality: signal
slot, reflection, QString, ... but absolutely nothing gui related
(QSize, QPoint,
QState*, QAnimationGroup, QTranslation, ...)

With the vision of Qt5 fresh in mind, it makes perfectly sense to move
JS into QtCore. It *is* the core of all Qt5 applications.
--
Bjørn Erik
Nilsen
Software Engineer
Nokia, Qt Development Frameworks
_______________________________________________
Qt5-feedback mailing list
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback

[Richard Moore]

Post by l***@nokia.com
To bring the discussion to an end: Sounds like most people currently
prefer keeping the separation and rather have a lib QtJS or QMLCore.
Kent and Jedrzej are looking into this idea right now. Let's see how this
works out and where the problems are. We can still re-evaluate later on if
we find new arguments.

Sounds sensible to me.

Rich.

[Bjørn Erik Nilsen]

Post by Jason H
I wholly disagree. It is the core of *your* Qt5 apps, but probably won't be mine.
It is also a poor decision to say "let them eat cake" and by cake I mean Qt4.

The root of the problem is that we are not aligned on the vision for Qt5.

If the vision for Qt5 is to create a paradigm shift and move QtQuick to
the core of all future Qt applications, then the only sane option is to
move JS into QtCore.

If we disagree on the vision, we better start figuring out what our
vision should be so that we can all work towards the same goal.

[BRM]

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

Post by Jason H

Post by Jason H
I wholly disagree. It is the core of *your* Qt5 apps, but probably

won't

Post by Jason H
be mine.
It is also a poor decision to say "let them eat cake" and by cake

I mean

Post by Jason H
Qt4.

The root of the problem is that we are not aligned on the vision for Qt5.
If the vision for Qt5 is to create a paradigm shift and move QtQuick to
the core of all future Qt applications, then the only sane option is to
move JS into QtCore.
If we disagree on the vision, we better start figuring out what our
vision should be so that we can all work towards the same goal.

I would say that in general the community disagrees with you, especially the embedded community, and most likely the commercial Qt community too.

I think the general consensus is that there is no problem with your stated "vision" supposing that applies to GUI applications only.
However, the Qt community is a lot larger than GUI applications.

Even in the GUI community, I would be quite surprised if the majority where even close to using QML/JS right now; something that with Qt4 is problematic per licensing for commercial users (LGPL only code for the JS - yeah, that's been quoted as being fixed for Qt5).

And yes, there are still a lot of applications that require integrating the standard QWidget model. For example, I have an application that draws points to a QWidget-derived object. I have a very hard time seeing how I would be able to do the same thing under QML, especially at the performance levels I need. Yes, I'm planning on eventually drawing to a QPixMap (I have a lot of work and research to do before I can do that), which may make it easier but still requires the QPainter methodology. I'm sure I'm not alone in that requirement.

Ben

[Jason H]

"If the vision for Qt5 is to create a paradigm shift and move QtQuick to
the core of all future Qt applications, then the only sane option is to
move JS into QtCore."

Non sequitur? I don't see how you or anyone else can create a paradigm shift on how people write their apps. I DO NOT WANT anyone forcing their paradigm on me. Just make it available, and let it shift the paradigm on its own. Things succeed because of adoption not because they were forced on people. And where the forcing does happen you get people complaining. No one forced people to by the iPhone but people did because it was way better, never mind that WinCE, BlackBerry, etc, already existed. The paradigm shift was organic. Why people adopted the iPhone was because the implementation was superior. And I do think QML will be a game changer, and its implementation is solid. That's why I'm sure you'll get your paradigm shift, but I need to be able to leave it out where not appropriate, because if forced in, that is where it works against itself.


I am really really excited about the JS/QML additions. I do think it'll be a paradigm shift in many more ways than are even being thought of (I can think of a bunch of non-GUI use cases) But I can think of why I don't want it in my Core. Why does it belong in things that Qt is already great for:
- Command line utilities
- Non DOM oriented network services
- Daemons

- Embedded devices

- iPhones (Can't have a interpreted code on an iPhone)



Thanks for listening.




________________________________
From: Bjørn Erik Nilsen <***@nokia.com>
To: Jason H <***@yahoo.com>
Cc: "qt5-***@qt.nokia.com" <qt5-***@qt.nokia.com>
Sent: Thursday, September 8, 2011 9:56 AM
Subject: Re: [Qt5-feedback] QML/JS engine in QtCore?

Post by Jason H
I wholly disagree. It is the core of *your* Qt5 apps, but probably won't be mine.
It is also a poor decision to say "let them eat cake" and by cake I mean Qt4.

The root of the problem is that we are not aligned on the vision for Qt5.

If the vision for Qt5 is to create a paradigm shift and move QtQuick to the core of all future Qt applications, then the only sane option is to move JS into QtCore.

If we disagree on the vision, we better start figuring out what our vision should be so that we can all work towards the same goal.

-- Bjørn Erik Nilsen
Software Engineer
Nokia, Qt Development Frameworks

[Matthias Ettrich]

Post by Jason H
- iPhones (Can't have a interpreted code on an iPhone)

Are not seriously suggesting that apple's lawyers should have a say on how we
design Qt in the future?

Matthias

[BRM]

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

Sent: Thursday, September 8, 2011 10:46 AM
Subject: Re: [Qt5-feedback] QML/JS engine in QtCore?

Post by Jason H
- iPhones (Can't have a interpreted code on an iPhone)

Are not seriously suggesting that apple's lawyers should have a say on how we
design Qt in the future?

Has nothing to do with Apple. That's just one example, and there's probably a thousand more like it.

Ben

[Jason H]

I'm saying a decision to include JS in QtCore would forcibly prohibit any deployment on iOS, as far as AppStore apps are concerned. 

It's not Apple saying how to design Qt its just Apple's policy running a muck with what I think is a poor decision to include JS in our core, even if we don't need/want it.




________________________________
From: Matthias Ettrich <***@nokia.com>
To: qt5-***@qt.nokia.com
Sent: Thursday, September 8, 2011 10:46 AM
Subject: Re: [Qt5-feedback] QML/JS engine in QtCore?

Post by Jason H
- iPhones (Can't have a interpreted code on an iPhone)

Are not seriously suggesting that apple's lawyers should have a say on how we
design Qt in the future?

Matthias

[g***@nokia.com]

Post by Jason H
I'm saying a decision to include JS in QtCore would forcibly prohibit any deployment on iOS, as far as AppStore apps are concerned.
It's not Apple saying how to design Qt its just Apple's policy running a muck with what I think is a poor decision to include JS in our core, even if we don't need/want it.

Though this used to be the case, the Apple statement was changed last year:
http://www.apple.com/pr/library/2010/09/09Statement-by-Apple-on-App-Store-Review-Guidelines.html

As long as you are not downloading code to execute you are safe

-
Gunnar

Post by Jason H
Sent: Thursday, September 8, 2011 10:46 AM
Subject: Re: [Qt5-feedback] QML/JS engine in QtCore?

Post by Jason H
- iPhones (Can't have a interpreted code on an iPhone)

Are not seriously suggesting that apple's lawyers should have a say on how we
design Qt in the future?
Matthias
_______________________________________________
Qt5-feedback mailing list
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
_______________________________________________
Qt5-feedback mailing list
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback

[Samuel Rødal]

Post by Jason H
I wholly disagree. It is the core of *your* Qt5 apps, but probably won't be mine.
It is also a poor decision to say "let them eat cake" and by cake I mean Qt4.
If you put JS into QtCore, then you need to make a QtKernel, however I
also advise against this because this would create confusion between
QtCore 4 and QtCore 5.
I've been a proponent of non-gui QML, meaning JS in QCoreApplication
apps. However as I see it, the JS should be a separate component that is
included just as SQL is. I even think there is a better argument that
QtNetwork be put in core, since it is rare not to have any kind of
network connectivity in this day and age. However, please note that
recommendation is based on actual observation, whereas your reasoning
that Qt5 apps will all need JS is based on anticipation. I prefer not to
be wrong, and when you guess based on supposed future behavior, you will
very likely be wrong. Let there be a QtJavaScript or QtQMLCore module.

From my point of view the best argument for having v8 in QtCore is to
have an as efficient as possible bridge between the QObject model and
the QML / JavaScript object model.

I don't see why v8 couldn't be in QtCore but potentially with a
configure option to disable it for when it's not needed. At least if
it's not possible to get the optimal performance with the v8 / QML
integration outside QtCore.

A QtKernel that doesn't include QObject also doesn't make much sense, so
if QObject and JS need to live in the same module that wouldn't solve
anything.

--
Samuel

[BRM]

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

Post by Jason H

Post by Jason H
I wholly disagree. It is the core of *your* Qt5 apps, but probably

won't

Post by Jason H
be mine.
It is also a poor decision to say "let them eat cake" and by cake

I mean

Post by Jason H
Qt4.
If you put JS into QtCore, then you need to make a QtKernel, however I
also advise against this because this would create confusion between
QtCore 4 and QtCore 5.
I've been a proponent of non-gui QML, meaning JS in QCoreApplication
apps. However as I see it, the JS should be a separate component that is
included just as SQL is. I even think there is a better argument that
QtNetwork be put in core, since it is rare not to have any kind of
network connectivity in this day and age. However, please note that
recommendation is based on actual observation, whereas your reasoning
that Qt5 apps will all need JS is based on anticipation. I prefer not to
be wrong, and when you guess based on supposed future behavior, you will
very likely be wrong. Let there be a QtJavaScript or QtQMLCore module.

From my point of view the best argument for having v8 in QtCore is to
have an as efficient as possible bridge between the QObject model and
the QML / JavaScript object model.
I don't see why v8 couldn't be in QtCore but potentially with a
configure option to disable it for when it's not needed. At least if
it's not possible to get the optimal performance with the v8 / QML
integration outside QtCore.
A QtKernel that doesn't include QObject also doesn't make much sense, so
if QObject and JS need to live in the same module that wouldn't solve
anything.

What I don't get is this whole argument that they need to be in the same module to bridge the object model.
I don't buy it.

There is nothing preventing the QML/JS object model and the QObject model from being the same while living in different modules.
QML/JS should be a very useful addition to the QtCore, much like QtSQL, QtNetwork, etc. are.

The fact that there is even a valid argument for being able to disable it should it be part of QtCore underscores that it shouldn't be in QtCore to start with.

And I quite agree with Lars - let's see how the two new modules for QML/JS work out.
I'd add that for Qt5, QML/JS should not be part of QtCore, and rather than trying to force it into QtCore now, let's see how it gets used throughout Qt5,
and if there is sufficient usage among the community where having it in a separate module in Qt5 becomes a big hurdle, then we can re-evaluate that position down the line, e.g. Qt6,
and change accordingly.

The big point here, is let the community and its usage of QML/JS drive the requirement for it being in QtCore. That is part of having open governance, is it not?

Ben

[Harri Porten]

Post by BRM
[...]
The big point here, is let the community and its usage of QML/JS drive
the requirement for it being in QtCore.

All very well said in my opinion. And let me add another point that just
crossed my mind and is meant to support both points of view:

A bit of decoupling would bring additional flexibility for both QML and
JavaScript users (not even speaking of other languages here...). What if a
generation of QML is considered worthwile soon? Easier to be done in a
new, seperate library. Same with a JS engine. Looking at how many Qt has
been featuring during the last years once cannot help but being hesitant
about sticking to a particular one too closely. Unlike QObject and friends
both technologies are *very* much in a flux right now.

Harri.

[Davide Bettio]

Post by Bjørn Erik Nilsen

Post by Peter Kuemmel
JS in QtCore is not needed in headless embedded software.
But it would be a reason to not use Qt in such a project if JS couldn't be disabled.

Exactly. It would be a good reason to not use *Qt5* in such a project.
Qt4 is more suitable for that use case.

Who's going to take care of an old version of Qt forever? who wants to keep 2
different versions of the same library on the same system? and who wants to
continue to ship an old version? No one.

You are telling people "you have few years to move away from Qt" while you
should tell people "next version will be the best version ever with more
features". I think that beeing able to write lightweight system components
with QtCore is a great feature and that isn't happening thanks to a widespread
bad perception about Qt modularity that can get worse. I would love to see the
next generation init system or the next device management daemon using QtCore
and QtDBus instead of g* libraries. If you will move all the V8 stuff inside
QtCore no one will write a system component with QtCore 5.

Please keep making a good framework that works nicely also on systems without
a screen.

Bye,
Davide Bettio.

[Alex Strickland]

Post by Peter Kuemmel
JS in QtCore is not needed in headless embedded software.
But it would be a reason to not use Qt in such a project if JS couldn't be disabled.
I think "Core" is a the wrong name for a library with a complete JS interpreter/jit compiler.
Maybe it is possible to introduce an additional library (QtMicroCore?)

QtKernel?

Post by Peter Kuemmel
a level below QtCore which really has only core functionality: signal slot, reflection, QString, ... but absolutely nothing gui related (QSize, QPoint,
QState*, QAnimationGroup, QTranslation, ...)

[Harald Fernengel]

Hi,

Post by Peter Kuemmel
JS in QtCore is not needed in headless embedded software.
But it would be a reason to not use Qt in such a project if JS couldn't be disabled.

There's one level below QtCore, and that's the boot-strapped mini-lib that is
used in uic, moc, rcc and so on.

Would that be a reasonable compromise for small headless tools?

Harald

[s***@accenture.com]

Post by Harald Fernengel
There's one level below QtCore, and that's the boot-strapped mini-lib that is
used in uic, moc, rcc and so on.
Would that be a reasonable compromise for small headless tools?
Harald

Unfortunately not, as it doesn't support QObject (due to the circular dependency that would introduce for moc)
That means no signals, slots, event loops etc.
The bootstrap lib is too stripped for many headless tools.

- Shane Kearns

________________________________
This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited.

[c***@nokia.com]

Post by l***@nokia.com
But QML itself is not bound to graphical user interfaces. It's a generic
declarative language that could just as well be used for many other, non
graphical tasks. Having this powerful engine available everywhere will
open up many possibilities.
It would longer term also allow things such as using property bindings
from C++. This would allow app developers to save a lot of glue code.
Connecting signals to a piece of JS code also becomes possible (yes,
lambdas solve that problem to some extent as well).

For us in documentation moving the parser to QtCore would give significant
benefits. We are implementing a QML Documentation parser currently which
allows people to put qdoc comments inside qml files.

This parser currently has an older copy of
qtdeclarative/src/declarative/qml/parser in
qtdoc/tools/qdoc3/declarativeparser since we do not really want to have
qdoc to depend on the whole qtdeclarative stack.

Moving the parser part to QtCore would allow us to stay on just depending
on QtBase (We depend on core + xml)

Casper

[Thiago Macieira]

Post by c***@nokia.com
Moving the parser part to QtCore would allow us to stay on just depending
on QtBase (We depend on core + xml)

Can I suggest moving QtDBus into QtCore too and make it mandatory on all
platforms?

[Joerg Bornemann]

Post by c***@nokia.com
For us in documentation moving the parser to QtCore would give significant
benefits. We are implementing a QML Documentation parser currently which
allows people to put qdoc comments inside qml files.
This parser currently has an older copy of
qtdeclarative/src/declarative/qml/parser in
qtdoc/tools/qdoc3/declarativeparser since we do not really want to have
qdoc to depend on the whole qtdeclarative stack.

If you're just depending on the parser - that one is really lightweight
and doesn't introduce much overhead. Another way to solve your
dependency issue might be to split up qdoc in a C++ dependent- and
QML-dependent part.

But if putting QML/JS into QtCore really gives us significant
performance improvements that are hardly possible another way (e.g. by
minimizing the cost of QVariant/JS conversions) *and* we keep Qt working
if a user opt-outs QML/JS *and* we get V8 running on platforms the Qt
project is committed to [1], then personally I am okay with doing so.
Though it is kind of contrary to what this whole modularization practice
was all about...


BR,

Jörg

[1] more than Ubuntu 1x.x

[Pau Garcia i Quiles]

Hi,

Assuming V8 goes into QtCore (and even if it does not), would it be fully
wrapped into a QtV8 API, or would symbols be exported?

If the latter, what happens if in two years IonMonkey, JSC or a new player
is 10 times better than V8? Either stick to V8 or move to Qt6 to break ABI?

Given the current development frenzy around Javascript engines, how tightly
tied to a particular player can Qt afford to be? V8 is 3 years old, Qt4 is 6
years old and it will be 1 year before Qt 5.0 is out. Assuming Qt5 has the
same lifespan as Qt4, is betting on V8 for the next 7 years a wise decision?

Post by l***@nokia.com
Hi,
here comes the mail that I promised on the weekend. Let the flamewars
begin!
More seriously, I have been playing with the idea of moving both our basic
script integration (QJS* in the declarative module) as well as the QML
engine into QtCore.
As I outlined before, I consider it vital for Qt's success going forward
that we move QML into the center of what we do with Qt.
The classical widget model we have been successfully using for so many
years has reached it's limits and will not carry us forward any longer. I
have so far not heard a single person who seriously tried using QML and
would want to go back to Qt's classical way of building user interfaces.
But QML itself is not bound to graphical user interfaces. It's a generic
declarative language that could just as well be used for many other, non
graphical tasks. Having this powerful engine available everywhere will
open up many possibilities.
At the same time JavaScript is also getting more and more used, and there
are nowadays many developers that do want to do as little as possible in
C++. With the speed that modern JS engines such as V8 have reached, this
is also possible even on lower end systems.
The current split between Qt's object model living in one place and the
QML/JS engine in another has in Qt 4.x lead to suboptimal implementations
of the C++/JS bridge. Moving them into the same library gives us many more
possibilities to align the object models and really get the best
performance out of the binding engine and the bridging code between native
and C++. Getting as much as possible performance out of this will be
crucial to QMLs (and thus Qt's) success.
It would longer term also allow things such as using property bindings
from C++. This would allow app developers to save a lot of glue code.
Connecting signals to a piece of JS code also becomes possible (yes,
lambdas solve that problem to some extent as well).
As a side effect, this could also open up a few possibilities to use
implementations inside V8 in Qt. So far options are the RegExp engine,
dtoa, strtod code. This would reduce the size of the total Qt stack,
something that is important on many platforms where Qt is not preinstalled.
We could also solve certain pieces like proxy autoconfiguration without
requiring plugins that then pull in the JS engine anyways.
* People doing daemons/servers with Qt might see the JS engine as
problematic.
But if not used it doesn't really add any runtime overhead, so I wonder
how big of an issue this would be in practice.
* V8 is not yet working on some CPU architectures that Qt 4.x supports.
This sounds more severe, but if we get MIPS support for V8 (it's actively
being developed and it looks like it'll be there before we release 5.0),
the remaining CPU architectures account most likely for less than 1% of
the current Qt use cases. This is IMO not a good enough reason to hold the
other 99% back.
Comments?
Cheers,
Lars
_______________________________________________
Qt5-feedback mailing list
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback