declarative -> quick

[Girish Ramakrishnan]

Hi,
Is there a plan to rename declarative module to quick? I would prefer
saying "QT += quick" or "QT += quick2" instead of "QT += declarative".
Isn't declarative more like a programming style?

Also, maybe rename QtGui to QtGraphics/QtGraphicsBase/QtPlatform since
it doesn't provide ui elements these days and a base to build
graphics?

Thanks,
Girish

[Ville M. Vainio]

Bikeshed time!

The whole term "Qt Quick " becomes redundant and annoying when qml becomes
the default way to use Qt. "Qt Quick " Should be just Qt.

Post by Girish Ramakrishnan
Hi,
Is there a plan to rename declarative module to quick? I would prefer
saying "QT += quick" or "QT += quick2" instead of "QT += declarative".
Isn't declarative more like a programming style?
Also, maybe rename QtGui to QtGraphics/QtGraphicsBase/QtPlatform since
it doesn't provide ui elements these days and a base to build
graphics?
Thanks,
Girish
_______________________________________________
Qt5-feedback mailing list
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback

[Girish Ramakrishnan]

Post by Ville M. Vainio
Bikeshed time!
The whole term "Qt Quick " becomes redundant and annoying when qml becomes
the default way to use Qt. "Qt Quick " Should be just Qt.

Qt Quick can be default, for all I care, but right now having QT +=
declarative in .pro file seems a bit strange to me. It's like QT +=
imperative. I am specifically referring to what we do in the .pro
files and the name of the libraries (the source can still reside in
qtdeclarative/, I don't care). If Quick is the name of the technology,
why not just use that?

My suggestion to rename Gui was more practical. When we ported our
codebase to Qt5, it was filled with:
#ifdef QT5
#include <QtWidgets>
#else
#include <QtGui>
#endif

After we made the above change, things just worked. I am guessing most
Qt based apps have to do the above for no real reason (and similar
change in the .pro files). So, what I was going to suggest later on
was: Keep 'gui' as an alias to 'widgets' module and rename current gui
to something else. This way people can try out Qt5 with their existing
Qt4 code with very minimal changes (and we can avoid the whole widgets
are second rate citizens thread since people can try it out
themselves).

Girish

Post by Ville M. Vainio

Post by Girish Ramakrishnan
Hi,
Is there a plan to rename declarative module to quick? I would prefer
saying "QT += quick" or "QT += quick2" instead of "QT += declarative".
Isn't declarative more like a programming style?
Also, maybe rename QtGui to QtGraphics/QtGraphicsBase/QtPlatform since
it doesn't provide ui elements these days and a base to build
graphics?
Thanks,
Girish
_______________________________________________
Qt5-feedback mailing list
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback

[Joerg Bornemann]

Post by Girish Ramakrishnan
Qt Quick can be default, for all I care, but right now having QT +=
declarative in .pro file seems a bit strange to me. It's like QT +=
imperative. I am specifically referring to what we do in the .pro
files and the name of the libraries (the source can still reside in
qtdeclarative/, I don't care). If Quick is the name of the technology,
why not just use that?

+1 from me.
Even if QML becomes the default like core and gui are default in Qt4,
one would have to do
QT -= declarative
to turn it off.

This is the only place where "declarative" refers to QML / Qt Quick.
Well, apart from the library names of course.

Like Girish said, "Quick" or "QML" is the name of the technology.
"Declarative" was just a working title when it didn't have a name yet.
After all .ui and .qrc files are purely declarative other than QML. ;)

Post by Girish Ramakrishnan
My suggestion to rename Gui was more practical.

[...]

Another way would be to provide a (very simple) qt4support module that
maps the old headers to the new names.
Then you must have a Qt4/Qt5 section in your .pro file though to use
that module.


BR,

Jörg

[Girish Ramakrishnan]

Hi,

On Mon, Oct 10, 2011 at 3:58 PM, Joerg Bornemann

Post by Joerg Bornemann

Post by Girish Ramakrishnan
My suggestion to rename Gui was more practical.

[...]
Another way would be to provide a (very simple) qt4support module that
maps the old headers to the new names.
Then you must have a Qt4/Qt5 section in your .pro file though to use
that module.

Yes, one approach to have compat headers. I think we that approach
though it's hard to see which is the "latest" and which is
"deprecated" (this is unlike the qt3support where things had a Q3
prefix)
#include <QtGui/QLabel> // compat header by qt4support
#include <QtGui/QWindow> // new header

Or is there a better approach than above?

There's a lot of apps out there that use <QtGui> and <QtGui/*>. I
think we should be considerate and not have them change it all to
QtWidget for no real benefit. Here's some stats:
http://codesearch.google.com/#search/&q=%23include%20%3CQtGui%3E&type=cs
http://codesearch.google.com/#search/&q=%23include%20%3CQtGui/%5Cw*%3E&type=cs

Girish

[Girish Ramakrishnan]

Hi Guys,

On Mon, Oct 10, 2011 at 6:15 PM, Girish Ramakrishnan

Post by Girish Ramakrishnan
Hi,
On Mon, Oct 10, 2011 at 3:58 PM, Joerg Bornemann

Post by Joerg Bornemann

Post by Girish Ramakrishnan
My suggestion to rename Gui was more practical.

[...]
Another way would be to provide a (very simple) qt4support module that
maps the old headers to the new names.
Then you must have a Qt4/Qt5 section in your .pro file though to use
that module.

Yes, one approach to have compat headers. I think we that approach
though it's hard to see which is the "latest" and which is
"deprecated" (this is unlike the qt3support where things had a Q3
prefix)
#include <QtGui/QLabel> // compat header by qt4support
#include <QtGui/QWindow> // new header
Or is there a better approach than above?
There's a lot of apps out there that use <QtGui> and <QtGui/*>. I
think we should be considerate and not have them change it all to
http://codesearch.google.com/#search/&q=%23include%20%3CQtGui%3E&type=cs
http://codesearch.google.com/#search/&q=%23include%20%3CQtGui/%5Cw*%3E&type=cs

Did we reach any conclusion on this? Is this idea of renaming gui to
something else:
a) Awesome but nobody cares though to do it (...in which case I volunteer)
or
b) Good but it's too late. We are going to make the world change the
include headers and we are probably going to have a qt4to5 script that
makes this change? (...I do think this change is unnecessary though)
or
c) Just plain horrible (If there is a problem with the above idea,
please let me know)

Girish

[l***@nokia.com]

Post by Girish Ramakrishnan
Hi Guys,
On Mon, Oct 10, 2011 at 6:15 PM, Girish Ramakrishnan

Post by Girish Ramakrishnan
Hi,
On Mon, Oct 10, 2011 at 3:58 PM, Joerg Bornemann

Post by Joerg Bornemann

Post by Girish Ramakrishnan
My suggestion to rename Gui was more practical.

[...]
Another way would be to provide a (very simple) qt4support module that
maps the old headers to the new names.
Then you must have a Qt4/Qt5 section in your .pro file though to use
that module.

Yes, one approach to have compat headers. I think we that approach
though it's hard to see which is the "latest" and which is
"deprecated" (this is unlike the qt3support where things had a Q3
prefix)
#include <QtGui/QLabel> // compat header by qt4support
#include <QtGui/QWindow> // new header
Or is there a better approach than above?
There's a lot of apps out there that use <QtGui> and <QtGui/*>. I
think we should be considerate and not have them change it all to
http://codesearch.google.com/#search/&q=%23include%20%3CQtGui%3E&type=cs
http://codesearch.google.com/#search/&q=%23include%20%3CQtGui/%5Cw*%3E&ty
pe=cs

Did we reach any conclusion on this? Is this idea of renaming gui to
a) Awesome but nobody cares though to do it (...in which case I volunteer)
or
b) Good but it's too late. We are going to make the world change the
include headers and we are probably going to have a qt4to5 script that
makes this change? (...I do think this change is unnecessary though)
or
c) Just plain horrible (If there is a problem with the above idea,
please let me know)

We've been discussing that, but the conclusion was to stick with QtGui.
The problem is that whatever you do, you'd break something (since we do
split up the old QtGui).

The best thing we could think of are Qt4 compatibility headers, ie. a Qt4
compatible directory structure for headers that you can enable with a
switch in your profile. But someone would need to do the work in syncqt
and probably a few other places to enable it.

I however found out that a script for fixing the headers is not that big a
problem. Only place where this wouldn't work is if you want one code base
to support both Qt4 and Qt5.

Cheers,
Lars

[Kent Hansen]

Hi Girish,

Post by Girish Ramakrishnan
Hi,
Is there a plan to rename declarative module to quick? I would prefer
saying "QT += quick" or "QT += quick2" instead of "QT += declarative".
Isn't declarative more like a programming style?

The idea is to move the graphical parts of declarative (e.g. scenegraph
items) into a "quick" or "quick2" library, and keep the "core"
declarative stuff in the existing library. Coincidentially, this makes
the .pro file's "QT += qtquick" correspond to the "import QtQuick" that
you do in qml. It also means you'll need to add both in your .pro file
(e.g. "QT += declarative qtquick"), unless we automagically add
declarative when qtquick is added (not a fan of that).

Regards,
Kent

[Thiago Macieira]

Post by Kent Hansen
It also means you'll need to add both in your .pro file
(e.g. "QT += declarative qtquick"), unless we automagically add
declarative when qtquick is added (not a fan of that).

If A depends publicly on B and you do:
QT += A

Then B is also automatically imported.

It has to because by construction B's classes are used in A, so you have to
use B to use A.

[Simon Hausmann]

Post by Thiago Macieira

Post by Kent Hansen
It also means you'll need to add both in your .pro file
(e.g. "QT += declarative qtquick"), unless we automagically add
declarative when qtquick is added (not a fan of that).

QT += A
Then B is also automatically imported.
It has to because by construction B's classes are used in A, so you have to
use B to use A.

Not quite, it doesn't mean that you can do #include <ClassFromB> if you do
QT += A.

Simon

[Thiago Macieira]

Post by Simon Hausmann

Post by Thiago Macieira
It has to because by construction B's classes are used in A, so you have to
use B to use A.

Not quite, it doesn't mean that you can do #include <ClassFromB> if you do
QT += A.

But shouldn't it? If I have:

#include <ClassFromA>

which in turn has:

#include <B/ClassFromB>

Then I am using that class from B. More importantly, if I use that class from
B, then my application has to link to B *directly*, so the buildsystem must
know this dependency.

[Lincoln Ramsay]

Post by Thiago Macieira

Post by Kent Hansen
It also means you'll need to add both in your .pro file
(e.g. "QT += declarative qtquick"), unless we automagically add
declarative when qtquick is added (not a fan of that).

QT += A
Then B is also automatically imported.

In theory, yes. In practice, no.

This definitely breaks on Windows and possibly in other situations too.


For a practical example, you can't do:

QT = core declarative

It does seem to work fine on Linux but not on Windows. Since declarative
depends on gui you must explicitly list it:

QT = core gui declarative

[Girish Ramakrishnan]

Post by Kent Hansen
Hi Girish,

Post by Girish Ramakrishnan
Hi,
Is there a plan to rename declarative module to quick? I would prefer
saying "QT += quick" or "QT += quick2" instead of "QT += declarative".
Isn't declarative more like a programming style?

The idea is to move the graphical parts of declarative (e.g. scenegraph
items) into a "quick" or "quick2" library, and keep the "core"
declarative stuff in the existing library. Coincidentially, this makes
the .pro file's "QT += qtquick" correspond to the "import QtQuick" that
you do in qml. It also means you'll need to add both in your .pro file
(e.g. "QT += declarative qtquick"), unless we automagically add
declarative when qtquick is added (not a fan of that).

I really like the idea of separating the graphical parts to separate
library. Still, please do consider renaming 'declarative' in QT +=
declarative to something else. QT += qml or quickcore or something? We
should take the whole "Quick" terminology to heart and use it all over
:-)

Girish