«

On Jan 4, 12:05*am, legalize+jee...@mail.xmission.com (Richard) wrote:
> [Please do not mail me a copy of your followup]
>
> =?ISO-8859-1?Q?=D6=F6_Tiib?= <oot...@hot.ee> spake the secret code
> <362fce65-5266-4ef0-86b2-19d1b0e80...@k13g2000vbq.googlegroups.com> thusly:
>
> >On Jan 3, 8:57=A0pm, legalize+jee...@mail.xmission.com (Richard) wrote:
>
> >> Rolf Magnus <ramag...@t-online.de> spake the secret code
> >> <ifkt1s$re1$0...@news.t-online.com> thusly:
>
> >> >Under Windows, Qt uses the Windows style engine to draw widgets.
>
> >> 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.
>
> 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.

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

"Jarrick Chagma" <> spake the secret code
< > thusly:

>"Richard" wrote in message news:ifth73$gib$...
>
>[...]
>
>> 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.
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/>

Legalize Adulthood! <http://legalizeadulthood.wordpress.com>

On Jan 3, 2:09*am, Andreas Dehmel <blackhole.
8.zarquo...@spamgourmet.com> wrote:
> On Sun, 02 Jan 2011 23:14:46 +0000, Rui Maciel wrote:
> > ptyxs wrote:
>
> > >> Because Qt reimplements everything itself,
> > > As said before by other people, this is no longer true.
>
> > Not quite. *Qt still implements classes such as QString, QVector, QList,
> > QMap and others, although standard C++ containers are either ignored or
> > supported only as far as it is possible to convert them to Qt's own
> > components. *
>
> 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
> --
> Dr. Andreas Dehmel * * * * * * * * * * * * * Ceterum censeo
> FLIPME(ed.enilno-t@nouqraz) * * * * * * * * *Microsoft esse delendamhttp://www.zarquon.homepage.t-online.de* * * * *(Cato the Much Younger)

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.

On Jan 3, 2:09*am, Andreas Dehmel <blackhole.
8.zarquo...@spamgourmet.com> wrote:
> On Sun, 02 Jan 2011 23:14:46 +0000, Rui Maciel wrote:
> > ptyxs wrote:
>
> > >> Because Qt reimplements everything itself,
> > > As said before by other people, this is no longer true.
>
> > Not quite. *Qt still implements classes such as QString, QVector, QList,
> > QMap and others, although standard C++ containers are either ignored or
> > supported only as far as it is possible to convert them to Qt's own
> > components. *
>
> 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
> --
> Dr. Andreas Dehmel * * * * * * * * * * * * * Ceterum censeo
> FLIPME(ed.enilno-t@nouqraz) * * * * * * * * *Microsoft esse delendamhttp://www.zarquon.homepage.t-online.de* * * * *(Cato the Much Younger)

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.

Richard wrote:

> [Please do not mail me a copy of your followup]
>
> Rolf Magnus <> spake the secret code
> <ifkt1s$re1$02$> thusly:
>
>>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.

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

Rolf Magnus <> spake the secret code
<ig8g1a$p3g$02$> thusly:

>Richard wrote:
>
>> [Please do not mail me a copy of your followup]
>>
>> Rolf Magnus <> spake the secret code
>> <ifkt1s$re1$02$> thusly:
>>
>>>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.
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/>

Legalize Adulthood! <http://legalizeadulthood.wordpress.com>