Qt-interest Archive, March 2002
A Survey on the QT Design Philosophy
Message 1 in thread
The QT approach to widget design seems to be err on the side of extensibility. Most of the
widgets provide a nice base of functionality that can most of the time be easily built upon. And
QT's design (styles, event filters, signal/slot mechanism) allows for those extensions to be
easily grafted on.
However, it seems that sometimes QT is almost too minimalistic in its approach to providing
widgets that can easily create a rich GUI. I mean geez, you have to derive or install an event
filter to get the lostfocus event for a line and/or text widget. In the case of the lineedit
widget you can derive, while the textedit widget swallows the focusout event, so you have to
install the event filter. Running across small differences like this potentially consumes a lot
of development time.
I would say there is an initial learning curve investment in most programmers coming to QT. You
will spend time creating a library of widgets that in other environments like Delphi, MFC, KDE
simply already exist.
I have posted messages to this list that have lamented the uselessness of widgets like QTable
compared to their Win32 counterparts and received messages back in return that amounted to "We
looked at QTable and decided that its pretty much worthless. It would take too much of our
development time to make it a useful widget. If I open a Programmer's Paradise magazine, I can
find 10 widgets that provide more functionality than QTable."
I'd like to gauge other developers opinion on how well QT pulls off the difficult balancing act of
being lightweight and extensible while at the same time providing the minimal functionality that
is needed from a UI widget library.
How does it compare in your opinion to other cross platform libraries? What QT widgets are really
lacking in this respect?
__________________________________________________
Do You Yahoo!?
Yahoo! Sports - live college hoops coverage
http://sports.yahoo.com/
Message 2 in thread
Overall, I am VERY happy with Qt. I'm primarily a
Linux user, but also like to run Solaris and have had
no problem at all compiling and running Qt apps on
Solaris. The cross platform nature is perfectly
executed.
The mechanisms that Qt includes (primarily
signals/slots) are wonderful. I'd never done any GUI
programming prior to learning Qt, and I don't think I
would want to program with any other toolset. Signals
and slots make writing complex applications so much
easier.
As far as some of the widgets are concerned, I do feel
that Qt is lacking. SQL, HTML, etc. support is great
for a library. But, I'd also like to see some more
advancements in the interface aspect of Qt. The
original poster's comment about QTable is one such
example. I'd also like to see Qt evolve out of the
traditional Microsoft/Motif GUI feel and incorporate
some more advanced painting features so that advanced
GUIs can be created more easily. Things like
alpha-blended images, gradient handling, widget
transparency, etc. would go a long way to enhancing
the look and feel of Qt apps.
While most of my wants are trivial and not really
necessary for developing solid applications, they
would help Qt developers implement some really
innovative products. Qt is great, and Trolltech
should be commended for churning out release after
release of such a solid product.
--- Bryan Brunton <bryanbrun@yahoo.com> wrote:
> The QT approach to widget design seems to be err on
> the side of extensibility. Most of the
> widgets provide a nice base of functionality that
> can most of the time be easily built upon. And
> QT's design (styles, event filters, signal/slot
> mechanism) allows for those extensions to be
> easily grafted on.
>
> However, it seems that sometimes QT is almost too
> minimalistic in its approach to providing
> widgets that can easily create a rich GUI. I mean
> geez, you have to derive or install an event
> filter to get the lostfocus event for a line and/or
> text widget. In the case of the lineedit
> widget you can derive, while the textedit widget
> swallows the focusout event, so you have to
> install the event filter. Running across small
> differences like this potentially consumes a lot
> of development time.
>
> I would say there is an initial learning curve
> investment in most programmers coming to QT. You
> will spend time creating a library of widgets that
> in other environments like Delphi, MFC, KDE
> simply already exist.
>
> I have posted messages to this list that have
> lamented the uselessness of widgets like QTable
> compared to their Win32 counterparts and received
> messages back in return that amounted to "We
> looked at QTable and decided that its pretty much
> worthless. It would take too much of our
> development time to make it a useful widget. If I
> open a Programmer's Paradise magazine, I can
> find 10 widgets that provide more functionality than
> QTable."
>
> I'd like to gauge other developers opinion on how
> well QT pulls off the difficult balancing act of
> being lightweight and extensible while at the same
> time providing the minimal functionality that
> is needed from a UI widget library.
>
> How does it compare in your opinion to other cross
> platform libraries? What QT widgets are really
> lacking in this respect?
>
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Sports - live college hoops coverage
> http://sports.yahoo.com/
>
> --
> List archive and information:
http://qt-interest.trolltech.com
__________________________________________________
Do You Yahoo!?
Yahoo! Sports - live college hoops coverage
http://sports.yahoo.com/
Message 3 in thread
On Wednesday 20 March 2002 01:56 pm, you wrote:
> Overall, I am VERY happy with Qt. I'm primarily a
> Linux user, but also like to run Solaris and have had
> no problem at all compiling and running Qt apps on
> Solaris. The cross platform nature is perfectly
> executed.
Same here. Will be porting to Windows, so cross-platform is a must.
>
> The mechanisms that Qt includes (primarily
> signals/slots) are wonderful. I'd never done any GUI
> programming prior to learning Qt, and I don't think I
> would want to program with any other toolset. Signals
> and slots make writing complex applications so much
> easier.
Signals and slot are nice, but I wish the whole moc thing would go away.
Widgets. Some are a total loss, like QTable. I'm no real fan of Java, but I
think the Swing classes are well thought out and executed, and they walk the
fine line between extensibility and support for everyday actions. A pet peave
of mine for QTable is that there is no way short of subclassing to get table
to sort wholeRows. This seems like it should be an obvious property, but it's
not. QTableHeader is buried in the source module for QTable, so
attaching/overriding slots there is impossible without some hacking while
QComboTableItem is present in the QTable header file, and I've never used it.
Some decisions just seem arbitrary or not well thought out, while some seem
quite well done.
Header explosion also is an issue, as it raises compile times *a lot*. A lot
of the widget code uses the pimpl idiom (pointer to private implementation),
but a lot do not. Some use class members, and then also have a pimpl (Qt
likes to name this d for some reason)!
Documentation layout could use some work to. I know it comes from doxygen,
but finding a function in the list of member functions for something like
QString is a pain. Alphabetizing might be nice!
The insistance for binary compatability is nice, but in some ways is a pain
in the butt. Esp. when some of the code is not written with binary
compatibility in mind.
Perhaps the most annoying thing I encounter in Qt is interfacing to older
code or code that is "engine" code that I'm trying to add a GUI to. Mostly,
this code is ANSI C++, uses STL containers, string class, I/O streams. None
of which easily marry up to Qt, which has its own versions of these Standard
classes: there's no easy conversion between QString and char* (call
latin1()), between string and QString. Why QMap, what was wrong with
std::map? And so on. I *know* std::vector, I don't *know* QValueVector. I'd
really like it if Qt wasn't so darned dependent on all those NIH classes, and
used std:: classes, even if it might mean some middling difficulty somewhere.
And I think I'd like boost:: support like any rather than QVariant, for
example, as boost:: stuff is much more likely to be adopted in a future
standard (see above...).
Message 4 in thread
I'm only commenting on the documentation point.
On Wednesday 20 March 2002 21:33 pm, Mike Percy wrote:
[snip]
> Documentation layout could use some work to. I know it comes from doxygen,
> but finding a function in the list of member functions for something like
> QString is a pain. Alphabetizing might be nice!
[snip]
Actually we use an in-house tool; doxygen seems to be able to process
our markup though.
We have had the alphabetizing argument many times, but it has always
been lost against the argument for 'logical' ordering. Certainly our
tool can produce alphabetical ordering. Many of our users are not native
English speakers, so ordering by inheritance and importance may make
more sense to some of them, whereas English alphabeticisation may appear
arbitrary.
I doubt that there is any complete solution for a class like QString. We
want to show the signatures in the list (rather than just the names)
because for people who know what they want, but are just checking the
arguments, this is fast. But if you don't know what you're after a table
of function names would be a better solution, but that would mean a
second click to find the signature. Maybe we could have both approaches,
using a table for classes that have more than, say 50 functions.
If you can come up with a better solution you're welcome to mail it
(e.g. a page mockup) to doc@trolltech.com for us to try out!
--
[ signature omitted ]
Message 5 in thread
Am Donnerstag, 21. März 2002 13:33 schrieb Mark Summerfield:
> I'm only commenting on the documentation point.
>
> On Wednesday 20 March 2002 21:33 pm, Mike Percy wrote:
> [snip]
>
> > Documentation layout could use some work to. I know it comes from
> > doxygen, but finding a function in the list of member functions for
> > something like QString is a pain. Alphabetizing might be nice!
>
[...]
> We have had the alphabetizing argument many times, but it has always
> been lost against the argument for 'logical' ordering. Certainly our
> tool can produce alphabetical ordering. Many of our users are not native
> English speakers, so ordering by inheritance and importance may make
> more sense to some of them, whereas English alphabeticisation may appear
> arbitrary.
So use both! Where is the problem to insert lists of links in
any order you find appropriate at the end of the documentation?
klaus
--
[ signature omitted ]
Message 6 in thread
> [...]
> > We have had the alphabetizing argument many times, but it has always
> > been lost against the argument for 'logical' ordering. Certainly our
> > tool can produce alphabetical ordering. Many of our users are not native
> > English speakers, so ordering by inheritance and importance may make
> > more sense to some of them, whereas English alphabeticisation may appear
> > arbitrary.
> So use both! Where is the problem to insert lists of links in
> any order you find appropriate at the end of the documentation?
The "List of all memeber functions" is sorted alphabetically.
And if you already know the name of the function you are looking for
(more or less at least), I would recommend to simply look in the index
of the Qt Assistant for it (which is IMO faster than everything else).
Rainer
--
[ signature omitted ]
Message 7 in thread
"Rainer M. Schmid" <rms@trolltech.com> writes:
| > [...]
| > > We have had the alphabetizing argument many times, but it has always
| > > been lost against the argument for 'logical' ordering. Certainly our
| > > tool can produce alphabetical ordering. Many of our users are not native
| > > English speakers, so ordering by inheritance and importance may make
| > > more sense to some of them, whereas English alphabeticisation may appear
| > > arbitrary.
| > So use both! Where is the problem to insert lists of links in
| > any order you find appropriate at the end of the documentation?
|
| The "List of all memeber functions" is sorted alphabetically.
I like to put my vote in here too....
The "List of all memeber functions" is in no way a good solution to the
sorting problems, as the list is very long for anything inheriting QObject
and QWidget. Besides its not sorted for type (public/protected,
signal/slot), and it do not include types of arguments!
How about generating two sets of hierarchies: one with topic sort order,
and one with alphabetic sort order.
doc/html/* (topic sort)
doc/html-for-those-annoying-people-complaining-about-sort/* (for alphabetic
sort ;-)
Please count this not just as my vote, but as a vote from most of the
people I do Qt training for. (I've heard this complain many times during
classes)
Kind Regards
Jesper.
--
[ signature omitted ]
Message 8 in thread
Greetings, all,
>>> I'm only commenting on the documentation point.
May I nominate the Java API javadoc format -- not necessarilly the
details of presentation, but the way information is organized.
That's my two cents worth.
Regards,
Jerry Barenholtz
jerryb@saltspring.com
Message 9 in thread
I have only been evaluating Qt for a couple of weeks, so I can't speak from
vast experience, but it seems to me that *for what it is trying to do* Qt is
doing an excellent job. Though Qt shouldn't be regarded as solely a UI
library (what with the network, xml, db, etc. modules), I would say that it
does far more than provide the minimal functionality needed from a widget
toolkit. Sacrificing some functionality in specific areas will always be
the cost of trying to create a general-purpose tool.
Re: QTable - You're right, it's not all fun and games out of the box, but I
just did a (brief) scan of programmersparadise.com and none of the table
products I found provide the same cross-platform capabilities that Qt
offers. If I wanted to write the world's greatest combo-box widget for
(say) Win32, Qt probably would not be able to compete with that, (assuming I
knew anything about combo-boxes, or Win32..) but obviously, that's not the
idea.
>>I would say there is an initial learning curve
Qt *may* not be the right tool if your goal is to rapidly develop a (for
example) Windows app with minimal learning and coding.
It seems as though Trolltech is commited to staying as current as possible
with the look-and-feel standards of the platforms they support. This is
more important to me than knowing that I can write the fanciest UI for a
particular platform. (Though this would be nice)
-Chris
-----Original Message-----
From: owner-qt-interest@trolltech.com
[mailto:owner-qt-interest@trolltech.com]On Behalf Of Bryan Brunton
Sent: Wednesday, March 20, 2002 8:09 AM
To: qt-interest@trolltech.com
Subject: A Survey on the QT Design Philosophy
The QT approach to widget design seems to be err on the side of
extensibility. Most of the
widgets provide a nice base of functionality that can most of the time be
easily built upon. And
QT's design (styles, event filters, signal/slot mechanism) allows for those
extensions to be
easily grafted on.
However, it seems that sometimes QT is almost too minimalistic in its
approach to providing
widgets that can easily create a rich GUI. I mean geez, you have to derive
or install an event
filter to get the lostfocus event for a line and/or text widget. In the
case of the lineedit
widget you can derive, while the textedit widget swallows the focusout
event, so you have to
install the event filter. Running across small differences like this
potentially consumes a lot
of development time.
I would say there is an initial learning curve investment in most
programmers coming to QT. You
will spend time creating a library of widgets that in other environments
like Delphi, MFC, KDE
simply already exist.
I have posted messages to this list that have lamented the uselessness of
widgets like QTable
compared to their Win32 counterparts and received messages back in return
that amounted to "We
looked at QTable and decided that its pretty much worthless. It would take
too much of our
development time to make it a useful widget. If I open a Programmer's
Paradise magazine, I can
find 10 widgets that provide more functionality than QTable."
I'd like to gauge other developers opinion on how well QT pulls off the
difficult balancing act of
being lightweight and extensible while at the same time providing the
minimal functionality that
is needed from a UI widget library.
How does it compare in your opinion to other cross platform libraries? What
QT widgets are really
lacking in this respect?
__________________________________________________
Do You Yahoo!?
Yahoo! Sports - live college hoops coverage
http://sports.yahoo.com/
--
[ signature omitted ]
Message 10 in thread
I agree.
Especially since we went to Qt3 everything is in a mess.
A lot of changes were making things worse than better, some of the new
thinggies are more or less useless.
QHttp for example implements only HTTP1.0. Try to connect to a virtual
server and u will already fail. And a lot of server are running virtual
these days.
Qt lacks a proper Text Edit widget at all right now. QTextEdit memory
consumption is ridiculous. Inserting a file which has some thousand lines
need some 100MB of memory. Sorry, that I am everrepeating complaining in
this list about this, but that is catastrophic. Some of our tools need to
display (and some also to edit) larger Text files, which isn't possible
right now, unless u have a big machine with a lot of RAM.
Also some widgets became to slow. An append to a QTextEdit for displaying a
log or debug messages takes some minutes. For that we worked around to store
it in a QString first and then perform a setText ... this takes then only
seconds. But that is not a nice design, also the text is twice in the
memory. One time in a QString, another time in the widget. (OK ... the
widget consumes that much of RAM, that nobody here is really annoyed about
the 'some lost' Kb in QStrings).
On the other hand I really like the QDict, QRegExp and QSql classes and
really don't want to miss them again.
Also I am already so used to SIGNAL/SLOTS that it would be difficult to fall
back to another Api. I really don't know anymore when I had my lost touch
with MFC. (And that is likely a decision which will be done the next days
here in my company)
Falling back to Qt2.x would mean no QRegExp and no QSql ... so we can then
also fallback directly to another API like Gtk, or if they drop the
Multiplatform idea here too, to MFC (which is for sure faster in
productivity than Gtk).
I still have the hope that Trolltech is aware of all this and comes to the
decision to make some major changes in there Api. I am a Qt-Fan and ever
pleading for Qt. But right now, I cannot really advize somebody to try Qt
Greetz
Message 11 in thread
> QHttp for example implements only HTTP1.0. Try to connect to a virtual
> server and u will already fail. And a lot of server are running virtual
> these days.
Newer versions of QHttp supports virtual servers (Qt 3.0.2 and later
does for sure, I am not sure if Qt 3.0.1 already did).
Rainer
--
[ signature omitted ]
Message 12 in thread
Then I have to apologize .. after we found out that it didn't do in the past
we skipped that completely and used a complete different Api for that.
I am not sure with which version itactually was as we tried that last (could
be that it still was beta). Our request to trolltech that time was answered
on 10/11/2001 this way (by pure chance it was answered by you ;-) ):
> If you are using IP-based virutal hosts, everything should work. If you
are
> using name-based virtual hosts, then this won't work since QHttp
implements
> plain HTTP/1.0, and this does not support name-based virtual hosts.
> Bye, Rainer.
Pity, we couldn't recognize that it was only a temporarily issue and on the
'to-do'-list. However .. that is past anyway.
Maybe you can bring some light into the future and give us a statement if we
could expect that QTextEdit will come back to a better level of memory
consumption.
Give me some hope, at all I really would love to stay with Qt for several
reasons ... but that QTextEdit prob is really a major issue here in my
company.
Greetz Andre
> -----Original Message-----
> From: owner-qt-interest@trolltech.com
> [mailto:owner-qt-interest@trolltech.com]On Behalf Of Rainer M. Schmid
> Sent: Friday, March 22, 2002 7:16 PM
> To: qt-interest@trolltech.com
> Subject: Re: A Survey on the QT Design Philosophy
>
>
> > QHttp for example implements only HTTP1.0. Try to connect to a virtual
> > server and u will already fail. And a lot of server are running virtual
> > these days.
>
> Newer versions of QHttp supports virtual servers (Qt 3.0.2 and later
> does for sure, I am not sure if Qt 3.0.1 already did).
>
> Rainer
>
> --
> "Corn beef should not be blue." (Isaac Davis)
>
> --
> List archive and information: http://qt-interest.trolltech.com
>
Message 13 in thread
>>> Bryan Brunton <bryanbrun@yahoo.com> 03/20/02 06:09pm >>>
> install the event filter. Running across small differences like this potentially consumes a lot
> of development time.
Some consistency would be nice, but of all the GUI toolkits I've used so far Qt remains the most sane, once you get past the initial learning curve.
> I would say there is an initial learning curve investment in most programmers coming to QT. You
> will spend time creating a library of widgets that in other environments like Delphi, MFC, KDE
It was my experience that it was much quicker to get up and running with MFC or Delphi, but try extending what they do or doing it your way rather than the Borland or Microsoft dictated way, then suddenly it gets very difficult and those toolkits will fight you every step of the way.
> I have posted messages to this list that have lamented the uselessness of widgets like QTable
> compared to their Win32 counterparts and received messages back in return that amounted to "We
If you mean the table object you get free in Visual Studio I have to completely disagree and the ones you buy are either useless or extremely expensive. I agree however that QTable is weird and not easy to use either.
> looked at QTable and decided that its pretty much worthless. It would take too much of our
I guess that depends on what you want. It worked perfectly well for me as a simple edit in place grid of information.
> How does it compare in your opinion to other cross platform libraries? What QT widgets are really
Well it is better than Zinc.
Ian
**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.
This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.
www.mimesweeper.com
**********************************************************************
