c++ guis

[Rui Maciel]

AFAIK the Qt containers originated from a time when use of the STL
was pretty much ``at your own risk'' and its cross-platform usability
was so pathetic it was far easier to write and maintain your own than
deal with its drama.

That's at least the official justification which I've heard since I first
heard of Qt. Another reason which was frequently pointed out was that
Trolltech was desperately avoiding templates.

Yet, we must bear in mind that Qt has underwent a few rewrites, the last
major one in 2005[1]. I don't believe that in 2005 support for the STL
was "pathetic". Moreover, in 2005 Trolltech introduced containers which
didn't existed in previous releases of Qt and duplicated STL's components.
It is safe to say that at that time neither issue justified reinventing
the STL. But they did it anyway.

Second, all of the Qt classes you mentioned have
implicit sharing and copy-on-write semantics, which the STL classes
don't have.

Qt's container classes weren't introduced with that in mind[2]. The
reasons which, at the time of release, were given amounted to nothing more
than using a different syntax than the one employed in the STL and other
irrelevant details.

While its use for the generic containers is arguable,
it's without a doubt a huge bonus for QString. Third and foremost of
all: QString is so much more than std::string, the comparison isn't
even funny anymore.

Can you please point out any feature which the QString class is able to
provide but it's impossible to provide with std::string? Bear in mind
that Qt has recently been rewritten from scratch.

The most important thing is not the class itself
but the interfaces the Qt lib provides for this class (and conversely
what interfaces the STL does _not_ provide for std::string)

Bear in mind that Qt has been rewritten from scratch. Therefore,
preserving interfaces wouldn't be an issue.

: filesystem
(i.e. portable unicode filename handling, not the ``implementation-
defined''-crap the standard lib tries to get away with)

Qt handles files through the QFile class. That means that at least it
would be quite possible to handle file names without having to deal
directly with std::string objects.

command line
(same here: unicode-transparent)

That's handled by the QCoreApplication and QApplication classes, among
others. Adding to that, the command line arguments are passed directly as
a car ** object. So, that does not force Qt to implement a std::string
replacement.

a huge zoo of text codecs for the
(rare within Qt-)cases where you have to explicitly deal with character
encodings and so on.

If Qt had to implement that stuff for Qt, what leads you to believe that
having to implement them for the std::string in the first place would
force them to develop a replacement for the std::string class?

In other words: no, QtCore doesn't ``duplicate''
the STL, it fills some huge, gaping holes the STL won't touch (at
least the current one).

If it does, you failed to provide the faintest example that indicates
that.



Rui Maciel


[1] http://dot.kde.org/2005/06/28/trolltech-releases-qt-40
[2] http://doc.trolltech.com/4.0/qt4-tulip.html

 

[Rui Maciel]

Why, exactly? Is it a vestige of the bad old days when STL tended to be
less reliably available?

Qt has since been rewritten from scratch in 2005. I don't believe that
the STL only began to become usable in the past years.



Rui Maciel

 

[Miles Bader]

Qt has since been rewritten from scratch in 2005. I don't believe that
the STL only began to become usable in the past years.

I suppose even with a complete rewrite, there's a certain amount of
inertia behind old ways of doing things if the same team is doing it,
especially in non-core areas like that where their attention probably
isn't focused...

-Miles

 

[Andreas Dehmel]

Andreas Dehmel wrote:
[...]
Yet, we must bear in mind that Qt has underwent a few rewrites, the last
major one in 2005[1]. I don't believe that in 2005 support for the STL
was "pathetic". Moreover, in 2005 Trolltech introduced containers which
didn't existed in previous releases of Qt and duplicated STL's components.
It is safe to say that at that time neither issue justified reinventing
the STL. But they did it anyway.

At the time of the last major rewrite, the existing Qt-containers were
already implicitly shared (at least for the most part). So introducing
new implicitly shared containers is hardly duplicating the STL but merely
expanding the Qt container system in a consistent way within the Qt library.
Furthermore, binary compatibility is very important to the Qt maintainers,
and achieving binary compatibility while using STL containers ranges
from ``tricky'' to ``impossible'', since your binary will invariably depend
on compiler version, STL version and build target.


[...]

Can you please point out any feature which the QString class is able to
provide but it's impossible to provide with std::string? Bear in mind
that Qt has recently been rewritten from scratch.

I gave examples: first up the QString class is implicitly shared, meaning
copying a string is O(1) rather than O(n). Furthermore the QString class
resides in an environment which suppports it for pretty much all string
handling, from command line over file system to all GUI-string handling;
this means all components using it support portable unicode string handling.
Now where do you think the current STL provides portable unicode handling?
Via std::wstring? You gotta be kidding me, that class is nothing but a
data structure hanging in thin air, with none of the connections QString
has; it's pretty much the footnote of an afterthought. Ever seen an STL-
function accepting a std::wstring as filename? I haven't. Via std::string
with UTF-8 encoding? Then where does the standard demand that platforms
support the UTF-8 locale? That'd be news to me, and it definitely doesn't
work on older Windows versions (haven't tried in Visa/Win7 yet, but XP
certainly doesn't like it).
Anyway, using std::string with UTF-8 encoded strings is an extremely ugly
hack because ``character'' in the context of a string class is something
completely different than the data type which, for historical reasons, is
called ``char''. So, if anything, Qt could have used std::wstring; but then
the QString class is far older than the last major rewrite (i.e. predates
STL-usability) and still more powerful/efficient than any of the std::*string-
classes due to implicit sharing, so (binary compatibility issues aside) why
migrate to something clearly inferior to what you already have? Makes no sense
whatsoever. Especially since most of these containers are hardly more than
an undergrad homework, so it's really quite comical what fuzz some people cook
up over ``reinventing'' something this trivial in the context of a huge cross-
platform library such as Qt, where 10 container classes more or less aren't
even worth a footnote.


[...]

That's handled by the QCoreApplication and QApplication classes, among
others. Adding to that, the command line arguments are passed directly as
a car ** object. So, that does not force Qt to implement a std::string
replacement.

QCoreApplication has a method that returns the command line as QStrings,
which are fully unicode preserving and will therefore differ from the
standard argv[]-parameter passed to main() on some platforms (Windows
for instance). You're quite wrong assuming any of this is char*-based.
Now where does the STL provide an interface to the command line with
full unicode encoding, wstring-based or otherwise? Oh, it doesn't...


[...]

If it does, you failed to provide the faintest example that indicates
that.

If you still haven't grasped that, no one can help you.



Andreas

 

[Öö Tiib]

AFAIK the Qt containers originated from a time when use of the STL
was pretty much ``at your own risk'' and its cross-platform usability
was so pathetic it was far easier to write and maintain your own than
deal with its drama.

That's at least the official justification which I've heard since I first
heard of Qt.  Another reason which was frequently pointed out was that
Trolltech was desperately avoiding templates.

Yet, we must bear in mind that Qt has underwent a  few rewrites, the last
major one in 2005[1].  I don't believe that in 2005 support for the STL
was "pathetic".  Moreover, in 2005 Trolltech introduced containers which
didn't existed in previous releases of Qt and duplicated STL's components..  
It is safe to say that at that time neither issue justified reinventing
the STL.  But they did it anyway.

You judge looking from your standpoint. You should always try to look
at things from their standpoint before judging what they do.

Trolltech is adjusting QT design since 2000 or so to be *really*
*multi-platform* with various portable and hand-held devices in mind.
If you have some experience with some of such embedded stuff then you
know that the compilers do not optimize templates so aggressively for
embedded platforms as for desktops. Therefore template libraries are
not that good in code for these.

Since Nokia owns that product now they can not care less how good is
template support of compilers for your Intel-based desktop computer.
What matters for them is how good is QT on the Nokia phones running
that hand-held Linux or Symbian.

Indeed ... do you know how well and efficiently STL is supported now,
2011, on Symbian?

 

[Richard]

[Please do not mail me a copy of your followup]

Rolf Magnus <[email protected]> spake the secret code

Under Windows, Qt uses the Windows style engine to draw widgets.

What exactly do you mean by "Windows style engine"?

 

[Öö Tiib]

Rolf Magnus <[email protected]> spake the secret code


What exactly do you mean by "Windows style engine"?

Probably he means using controls provided by ComCtl32.dll version 6 or
later that have enabled dynamic changing of visual styles of these
controls.

 

[Cholo Lennon]

Surely for each GUI toolkit out there you can find someone who hates it.

But I *do* agree that those "good" tags with no rationale or explanation
show some ... lack of judgement.

Yeah, I agree with you. Also the list is a bit outdated, and lacks some
libraries like WTL, but IMHO it is still useful as a guide.

Regards

 

[Richard]

[Please do not mail me a copy of your followup]

=?ISO-8859-1?Q?=D6=F6_Tiib?= <[email protected]> spake the secret code

Probably he means using controls provided by ComCtl32.dll version 6 or
later that have enabled dynamic changing of visual styles of these
controls.

Well, I've just looked at the "What's New in Qt" pages for each Qt
release since the last release I used in detail (4.4) and not on any
of those pages does it say that Qt now uses the native widgets. In
fact, it appears that Qt is doing what it has always done: render
things down into pixmaps which it bitblasts to the screen.

In Qt parlance "Windows style engine" refers to their bundle of code
that renders Widgets with a Windows visual style. That's why I asked
what the original poster meant by that phrase. In Qt land, there is a
style engine for each visual rendering style for widgets. They boast
about how this allows them to do things like apply perspective
transformations to drop-down comboboxes and the like. Because they
cook everything into pixels themselves, they can do this fairly
easily. (Why you would want to do it is a separate question.)

I just downloaded Qt 4.7.1 and looked at the source for the text
control. (qt\src\gui\qtextcontrol.cpp). I see absolutely no
indication that it is using the native widgets anywhere. All the
event handling, focus handling, selection logic and rendering logic is
just the way its always been in Qt.

 

[Miles Bader]

Surely for each GUI toolkit out there you can find someone who hates it.

But I *do* agree that those "good" tags with no rationale or explanation
show some ... lack of judgement.

haha, that's what I thought when I saw it marked Qt as "best"... :]

It still seems a potentially useful page if you ignore the editorial
pronouncements though.

-Miles

 

[Öö Tiib]

[Please do not mail me a copy of your followup]

=?ISO-8859-1?Q?=D6=F6_Tiib?= <[email protected]> spake the secret code

On Jan 3, 8:57=A0pm, (e-mail address removed) (Richard) wrote:

Probably he means using controls provided by ComCtl32.dll version 6 or
later that have enabled dynamic changing of visual styles of these
controls.

Well, I've just looked at the "What's New in Qt" pages for each Qt
release since the last release I used in detail (4.4) and not on any
of those pages does it say that Qt now uses the native widgets.  In
fact, it appears that Qt is doing what it has always done: render
things down into pixmaps which it bitblasts to the screen.

In Qt parlance "Windows style engine" refers to their bundle of code
that renders Widgets with a Windows visual style.  That's why I asked
what the original poster meant by that phrase.  In Qt land, there is a
style engine for each visual rendering style for widgets.  They boast
about how this allows them to do things like apply perspective
transformations to drop-down comboboxes and the like.  Because they
cook everything into pixels themselves, they can do this fairly
easily.  (Why you would want to do it is a separate question.)

I just downloaded Qt 4.7.1 and looked at the source for the text
control. (qt\src\gui\qtextcontrol.cpp).  I see absolutely no
indication that it is using the native widgets anywhere.  All the
event handling, focus handling, selection logic and rendering logic is
just the way its always been in Qt.

Yes, you are right, he meant that Qt has style engine that makes the
app to look like Windows app that is exactly what you said on the
first place. Interesting. I tried latest wxWidgets and that creates
even larger binaries than QT. Whatever our choice is the best idea
seems still to have application logic separated from GUI. That makes
it possible to switch GUI engine to WTL or MFC or whatever new thing
pops out when smaller size of binary starts to benefit our customers.

 

[Richard]

[Please do not mail me a copy of your followup]

"Jarrick Chagma" <[email protected]> spake the secret code

"Richard" wrote in message
[...]

I just downloaded Qt 4.7.1 and looked at the source for the text
control. (qt\src\gui\qtextcontrol.cpp). I see absolutely no
indication that it is using the native widgets anywhere. All the
event handling, focus handling, selection logic and rendering logic is
just the way its always been in Qt.

I am still confused. This from the Qt website itself:

"Qt uses the native graphics APIs of each platform it supports, taking full
advantage of system resources and ensuring that applications have native
look and feel."

Its true that Qt queries things like foreground color, background
color, drop shadow color, drop shadow thickness, etc., from the host
environment so that its *own* rendering of those attributes is
consistent with the host OS. However, to the best of my knowledge, Qt
hasn't ever and doesn't currently use native widgets for the controls
that you see.

So does this mean Qt uses the native graphics APIs but not the native
widgets themselves?

That's how it has always been in the past with Qt.

 

[ptyxs]

AFAIK the Qt containers originated from a time when use of the STL
was pretty much ``at your own risk'' and its cross-platform usability
was so pathetic it was far easier to write and maintain your own than
deal with its drama. Second, all of the Qt classes you mentioned have
implicit sharing and copy-on-write semantics, which the STL classes
don't have. While its use for the generic containers is arguable,
it's without a doubt a huge bonus for QString. Third and foremost of
all: QString is so much more than std::string, the comparison isn't
even funny anymore. The most important thing is not the class itself
but the interfaces the Qt lib provides for this class (and conversely
what interfaces the STL does _not_ provide for std::string): filesystem
(i.e. portable unicode filename handling, not the ``implementation-
defined''-crap the standard lib tries to get away with), command line
(same here: unicode-transparent), a huge zoo of text codecs for the
(rare within Qt-)cases where you have to explicitly deal with character
encodings and so on. In other words: no, QtCore doesn't ``duplicate''
the STL, it fills some huge, gaping holes the STL won't touch (at
least the current one).

Andreas

Note that, when programming with Qt, it is in no way necessary to use
QVector, QList, QString and so on. It is quite possible to use pure C+
+ for the non graphical parts of your programs.

 

[ptyxs]

AFAIK the Qt containers originated from a time when use of the STL
was pretty much ``at your own risk'' and its cross-platform usability
was so pathetic it was far easier to write and maintain your own than
deal with its drama. Second, all of the Qt classes you mentioned have
implicit sharing and copy-on-write semantics, which the STL classes
don't have. While its use for the generic containers is arguable,
it's without a doubt a huge bonus for QString. Third and foremost of
all: QString is so much more than std::string, the comparison isn't
even funny anymore. The most important thing is not the class itself
but the interfaces the Qt lib provides for this class (and conversely
what interfaces the STL does _not_ provide for std::string): filesystem
(i.e. portable unicode filename handling, not the ``implementation-
defined''-crap the standard lib tries to get away with), command line
(same here: unicode-transparent), a huge zoo of text codecs for the
(rare within Qt-)cases where you have to explicitly deal with character
encodings and so on. In other words: no, QtCore doesn't ``duplicate''
the STL, it fills some huge, gaping holes the STL won't touch (at
least the current one).

Andreas

BTW I think something is blatantly lacking in the current
litterature : systematic and detailed comparison of all the non-
graphic tools Qt makes available to replace some C++/STL tools with
the corresponding C++/STL tools (be it classes or functions) :
QString vs std::string etc. I never found anywhere such a comparative
description.

 

[antred]

Personally, I tend to go with Qt. Out of the GUI kits I've tried it sure is the cleanest and most modern (IMHO). My one gripe is that, like every other damned GUI kit I've ever seen, it tries to be God. I wish someone would make a PURE GUI kit of the same quality as Qt, i.e. one that concentrates solely on GUI programming. If I want sockets, internationalization, file system stuff, etc. I'll go look for that elsewhere, thank you very much.

 

[Rolf Magnus]

[Please do not mail me a copy of your followup]

Rolf Magnus <[email protected]> spake the secret code

Under Windows, Qt uses the Windows style engine to draw widgets.

What exactly do you mean by "Windows style engine"?

Whatever Qt means by it, I guess. The following can be found in the
documentation of the QWindowsXPStyle class that is used by default on
Windows XP: ( http://doc.qt.nokia.com/latest/qwindowsxpstyle.html )

The QWindowsXPStyle class provides a Microsoft Windows XP-like look and
feel.
Warning: This style is only available on the Windows XP platform because
it makes use of Windows XP's style engine.

Similar for QWindowsVistaStyle:
( http://doc.qt.nokia.com/latest/qwindowsvistastyle.html )

The QWindowsVistaStyle class provides a look and feel suitable for
applications on Microsoft Windows Vista.
Warning: This style is only available on the Windows Vista platform
because it makes use of Windows Vista's style engine.

According to that documentation, QWindowsVistaStyle was added in Qt 4.3.
QWindowsXPStyle has been in ever 4.x release of Qt AFAIK.

 

[Richard]

[Please do not mail me a copy of your followup]

Rolf Magnus <[email protected]> spake the secret code

[Please do not mail me a copy of your followup]

Rolf Magnus <[email protected]> spake the secret code

Under Windows, Qt uses the Windows style engine to draw widgets.

What exactly do you mean by "Windows style engine"?

Whatever Qt means by it, I guess.

Well, what Qt means by Windows style engine is a piece of software
that cooks the entire visual representation of a widget into pixels
and then does a BitBlt style operation to get it on the screen. I
would hardly call this "using the native graphics API to render
widgets".

The QWindowsXPStyle class provides a Microsoft Windows XP-like look and
feel.
Warning: This style is only available on the Windows XP platform because
it makes use of Windows XP's style engine.

Similar for QWindowsVistaStyle:
( http://doc.qt.nokia.com/latest/qwindowsvistastyle.html )

The QWindowsVistaStyle class provides a look and feel suitable for
applications on Microsoft Windows Vista.
Warning: This style is only available on the Windows Vista platform
because it makes use of Windows Vista's style engine.

Well, its the source code that matters, not documentation. Looking at
the source code for the XP theme style I see that they get the
function pointer for DrawThemeBackground and DrawThemeBackgroundEx, so
presumably they use those functions. Otherwise, all the function
pointers are Get functions used to query the theme for its parameters
so that they can cook them into pixels themselves. Even then, the
background is only drawn with these functions in certain cases and in
other cases, they cook the background into pixels themselves and blt
that to the screen. When they do use these functions, its to draw the
background of the pixel buffer on top of which they will compose their
own pixel rendering.

The bottom line is that Qt, just like it has always done, does not use
native controls and can't be fairly said to use the native API for
the rendering of its own controls.