R
Robin
anyone know where I can get new c++ gui libs....
it would be a good idea to design some.
-r
it would be a good idea to design some.
-r
Ö
Öö Tiib
C++ language does not have GUI libs. GUI libs are often platform
specific, so you have to tell your platform when making such request.
There are some GUI frameworks that work on lot of platforms. For
example one highly popular cross-plaform GUI framework is QT. See
http://qt.nokia.com/ for more information. It is quite large framework
so it may take you months to find out if you like it or not.
D
Dombo
Op 30-Dec-10 12:35, Öö Tiib schreef:
Other examples are:
wxWidgets: http://www.wxwidgets.org/
FLTK: http://www.fltk.org/
GTK+: http://www.gtk.org/
FOX Toolkit: http://www.fox-toolkit.org/
MFC: http://msdn.microsoft.com/en-us/library/d06h2x6e(VS.80).aspx
In other words: there is no need to design yet another C++ GUI
toolkit/library yourself.
Other examples are:
wxWidgets: http://www.wxwidgets.org/
FLTK: http://www.fltk.org/
GTK+: http://www.gtk.org/
FOX Toolkit: http://www.fox-toolkit.org/
MFC: http://msdn.microsoft.com/en-us/library/d06h2x6e(VS.80).aspx
In other words: there is no need to design yet another C++ GUI
toolkit/library yourself.
F
Felix Bytow
Am 30.12.2010 12:52, schrieb Dombo:
ofcourse MFC is not cross-platform so I would not suggest this library.
also it is Microsoft specific and usable oonly with a bought Microsoft
Visual Studio.
The Express Version of Microsoft Visual C++ does not include MFC.
ofcourse MFC is not cross-platform so I would not suggest this library.
also it is Microsoft specific and usable oonly with a bought Microsoft
Visual Studio.
The Express Version of Microsoft Visual C++ does not include MFC.
D
Dombo
Op 30-Dec-10 13:37, Felix Bytow schreef:
The OP did not state that he required a cross-platform solution nor
which development environment he is using. In organisations that develop
for the Windows platform typically use (a non-Express edition of)
Microsoft Visual Studio.
That being said there was reason why I put MFC at the bottom of the
list; besides the issues you mentioned there are other reasons why MFC
wouldn't be my first choice. Unfortunately I know of no C++ GUI
library/toolkit which I would recommend without reservations.
The OP did not state that he required a cross-platform solution nor
which development environment he is using. In organisations that develop
for the Windows platform typically use (a non-Express edition of)
Microsoft Visual Studio.
That being said there was reason why I put MFC at the bottom of the
list; besides the issues you mentioned there are other reasons why MFC
wouldn't be my first choice. Unfortunately I know of no C++ GUI
library/toolkit which I would recommend without reservations.
B
Balog Pal
Cholo Lennon said:
Fine list, though after it marks gtk as 'good' I wouldn't take
qualifications seriously.
K
Keith H Duggar
What are your specific reservations with Qt?
Thanks!
KHD
R
Richard
[Please do not mail me a copy of your followup]
Christian Hackl <[email protected]> spake the secret code
I've used wxWidgets and Qt. I prefer wxWidgets.
Christian Hackl <[email protected]> spake the secret code
I've used wxWidgets and Qt. I prefer wxWidgets.
R
Richard
[Please do not mail me a copy of your followup]
Keith H Duggar <[email protected]> spake the secret code
I've worked on a very large application which used Qt extensively.
From a look-and-feel perspective, my reservations with Qt are that it
doesn't use anything from the platform and reinvents all look and feel
itself. That means that on all platforms its just slightly wrong.
Now that I know this about Qt, I can typically spot a Qt application
just by looking at it. They talk about how you can run a Qt
application with a command-line argument to get a Mac look and feel on
Windows. They talk about this as if it were a feature, but seriously
if you're on Windows you want things to look like Windows, not like a
Mac and vice-versa. This is more of a side-effect of them
reimplementing/immitating the look and feel of the platforms they
support, not a feature.
Because Qt reimplements everything itself, including event
dispatching, widgets, rendering, etc., it is a very large and complex
code base. Amazgingly, it ships with zero unit tests and there isn't
any indication that they have a suite of unit tests that they use
internally, so that implies that everything is hand tested when new
releases come out. This explains why major new releases are full of
problems when they come out.
Looking through the code base, I'm rather horrified. I've seen a
tendency to use reinterpret_cast<> to just "jam it in" all throughout
their code. If we had a program that could enumerate all the
instances of undefined behavior in a C++ source application, I'm
willing to bet there would be hundreds if not thousands of instances
throughout the Qt code base.
The documentation can also get a bit sketchy. Since they reimplement
all UI behavior themselves, you can't rely on the platform's UI
behavior documentation. Documentation and books on Qt will tell you
that two ways of doing things are equivalent and from the implied
semantics of the methods, you'd draw that conclusion as well.
However, in reality they are not equivalent and one will work and the
other won't. There's no way to know which will work and which won't
work without finding out the hard way.
Their widget layout system is complex and featureful. This may seem
like a good thing, but in practice it means that you have to tread
carefully when doing complex layouts of widgets. Two seemingly
equivalent layotu incantations produce different results, so there is
a lot of iterating through layout incantations in order to find the
proper one.
Some people don't like the moc preprocessor thing and while that
never particularly bothered me, it does have some implementation
downsides. The names of signals and slots are just turned into
strings, so there isn't any static type checking on them. You can
easily have a bug because you have a typo in a signal name or a slot
name and you won't find out until you test things manually.
Their unit test frame work that they introduced in Qt4 sucks ass.
I could probably come up with some more things if I thought about it
more, but that's what I remember off the top of my head since I last
worked on this application about a year ago.
Keith H Duggar <[email protected]> spake the secret code
I've worked on a very large application which used Qt extensively.
From a look-and-feel perspective, my reservations with Qt are that it
doesn't use anything from the platform and reinvents all look and feel
itself. That means that on all platforms its just slightly wrong.
Now that I know this about Qt, I can typically spot a Qt application
just by looking at it. They talk about how you can run a Qt
application with a command-line argument to get a Mac look and feel on
Windows. They talk about this as if it were a feature, but seriously
if you're on Windows you want things to look like Windows, not like a
Mac and vice-versa. This is more of a side-effect of them
reimplementing/immitating the look and feel of the platforms they
support, not a feature.
Because Qt reimplements everything itself, including event
dispatching, widgets, rendering, etc., it is a very large and complex
code base. Amazgingly, it ships with zero unit tests and there isn't
any indication that they have a suite of unit tests that they use
internally, so that implies that everything is hand tested when new
releases come out. This explains why major new releases are full of
problems when they come out.
Looking through the code base, I'm rather horrified. I've seen a
tendency to use reinterpret_cast<> to just "jam it in" all throughout
their code. If we had a program that could enumerate all the
instances of undefined behavior in a C++ source application, I'm
willing to bet there would be hundreds if not thousands of instances
throughout the Qt code base.
The documentation can also get a bit sketchy. Since they reimplement
all UI behavior themselves, you can't rely on the platform's UI
behavior documentation. Documentation and books on Qt will tell you
that two ways of doing things are equivalent and from the implied
semantics of the methods, you'd draw that conclusion as well.
However, in reality they are not equivalent and one will work and the
other won't. There's no way to know which will work and which won't
work without finding out the hard way.
Their widget layout system is complex and featureful. This may seem
like a good thing, but in practice it means that you have to tread
carefully when doing complex layouts of widgets. Two seemingly
equivalent layotu incantations produce different results, so there is
a lot of iterating through layout incantations in order to find the
proper one.
Some people don't like the moc preprocessor thing and while that
never particularly bothered me, it does have some implementation
downsides. The names of signals and slots are just turned into
strings, so there isn't any static type checking on them. You can
easily have a bug because you have a typo in a signal name or a slot
name and you won't find out until you test things manually.
Their unit test frame work that they introduced in Qt4 sucks ass.
I could probably come up with some more things if I thought about it
more, but that's what I remember off the top of my head since I last
worked on this application about a year ago.
R
Richard
[Please do not mail me a copy of your followup]
Dombo <[email protected]> spake the secret code
WTL is a free, open source alternative for Windows platforms.
<http://en.wikipedia.org/wiki/WTL> Unfortunately it depends on ATL
for some things, and I don't think ATL is available for use with the
Express editions of Visual Studio.
Still, WTL is a nice C++ style library for accessing the underlying
Win32 API stuff and using the controls that exist. It allows you to
create very small GUI applications, just like ATL allows you to create
very small COM objects. It has its strengths and its weaknesses and
its not for everyone, but for those of you that like things small and
efficient, I'd recommend looking at it.
Dombo <[email protected]> spake the secret code
WTL is a free, open source alternative for Windows platforms.
<http://en.wikipedia.org/wiki/WTL> Unfortunately it depends on ATL
for some things, and I don't think ATL is available for use with the
Express editions of Visual Studio.
Still, WTL is a nice C++ style library for accessing the underlying
Win32 API stuff and using the controls that exist. It allows you to
create very small GUI applications, just like ATL allows you to create
very small COM objects. It has its strengths and its weaknesses and
its not for everyone, but for those of you that like things small and
efficient, I'd recommend looking at it.
J
Jorgen Grahn
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.
/Jorgen
P
Paul Brettschneider
Richard said:
Why do you think so? Qt applications look perfectly fine under KDE.
IMHO, the problem with Qt is that it's showing its age and that it tries to
do too many things. I'm not aware of any modern idiosyncratic C++ GUI
toolkit. It seems that most are merely wrappers for other toolkits. I fear a
project to build such a beast is in great danger of the second system
effect. :-( Designing GUIs is hard, I can only imagine that designing GUI
toolkits is even harder.
B
Balog Pal
Paul Brettschneider said:
It definitely is. Especially if done on the arrogant/coolguy way, not
learning ins and outs of the already existing stuff to collect the benefits
and avoid what was proven wrong in practice.
R
Richard
[Please do not mail me a copy of your followup]
Paul Brettschneider <[email protected]> spake the secret code
This seems to be the end result of any library that attemps to address
"the platform". Both wxWidgets and Qt try to address the entire
platform of services and not just GUI services. For instance, they
both have mechanisms of dealing with the file system and sockets, two
things that don't have anything to do with the UI.
Agreed. Its also true that what programmers expect from their GUI
toolkit isn't a fixed target; its an evolving target. Therefore the
work is never done on the "GUI toolkit".
Having switched to test-driven development I find that writing unit
tests for GUI behavior is possible, but that its obvious that the
existing toolkits and support infrastructure are not written to make
this easy. This is even true for C# where the GUI toolkit and
supporting infrastructure is much newer than it is for C++. If I want
to follow the "humble dialog" pattern[1], I find that I have to create
lots of interfaces or other ways to decouple myself from the concrete
GUI classes.
Doing this repeatedly has made me wonder why there aren't any GUI
toolkits that specify *all* the UI objects as interfaces instead of
concrete classes. If this were the case, then making test doubles for
those UI objects would be trivial making it much easier to write
tests.
[1] <http://xunitpatterns.com/Humble Object.html>
Paul Brettschneider <[email protected]> spake the secret code
This seems to be the end result of any library that attemps to address
"the platform". Both wxWidgets and Qt try to address the entire
platform of services and not just GUI services. For instance, they
both have mechanisms of dealing with the file system and sockets, two
things that don't have anything to do with the UI.
Agreed. Its also true that what programmers expect from their GUI
toolkit isn't a fixed target; its an evolving target. Therefore the
work is never done on the "GUI toolkit".
Having switched to test-driven development I find that writing unit
tests for GUI behavior is possible, but that its obvious that the
existing toolkits and support infrastructure are not written to make
this easy. This is even true for C# where the GUI toolkit and
supporting infrastructure is much newer than it is for C++. If I want
to follow the "humble dialog" pattern[1], I find that I have to create
lots of interfaces or other ways to decouple myself from the concrete
GUI classes.
Doing this repeatedly has made me wonder why there aren't any GUI
toolkits that specify *all* the UI objects as interfaces instead of
concrete classes. If this were the case, then making test doubles for
those UI objects would be trivial making it much easier to write
tests.
[1] <http://xunitpatterns.com/Humble Object.html>
R
Richard
[Please do not mail me a copy of your followup]
"Jarrick Chagma" <[email protected]> spake the secret code
Unless they changed it in the past year, no, they don't. I've stepped
through the code many times; they render everything themselves down
into pixels that are blasted to the screen.
"Jarrick Chagma" <[email protected]> spake the secret code
Unless they changed it in the past year, no, they don't. I've stepped
through the code many times; they render everything themselves down
into pixels that are blasted to the screen.
P
ptyxs
I don't understand your point : by default, Qt4 uses of course the
style of the platform the application is designed for. What you are
alluding to is just an optional trick, probably rarely used. So what
is the problem ??
As said before by other people, this is no longer true.
I never heard that recent releases 4.6 and 4.7 were that problemful,
rather the opposite.
Qt documentation is remarkably clear and searchable. One of the best I
ever saw.
R
Rolf Magnus
Richard said:
Under Windows, Qt uses the Windows style engine to draw widgets. And for
standard dialogs like the file dialog, it also uses the native ones by
default.
R
Rui Maciel
ptyxs said:
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.
Rui Maciel
M
Miles Bader
Rui Maciel said:
Why, exactly? Is it a vestige of the bad old days when STL tended to be
less reliably available?
-Miles
A
Andreas Dehmel
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