Java Swing style C++ library
Marcin Mueller
I've recently looked around for portable C++ GUI libraries, but it
seems
there aren't any very nice libraries around. Well, there are a few
like
gtk, qt, wxWindows but it seems that they all have their strengths and
weakness. So wouldn't it be nice to have one standard library/inteface
for writing graphical/windows applications in C++ as it is quite
tedious to learn new libraries all the time. Furthermore, I was very
surprised that there
isn't a single finished C++ port of the Java Swing library. There are
jtk, jLib and jlWindows but they are all unfinished!
I wonder what the reason for this might be? Is there actually no need
for
a standard C++ GUI library? Is Sun preventing any ports of Swing
through copyrights?
Regards,
Marcin
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Sebastian Moleski
news:788e4c13.03062...@posting.google.com...
> Hi,
>
> I've recently looked around for portable C++ GUI libraries, but it
> seems
> there aren't any very nice libraries around. Well, there are a few
> like
> gtk, qt, wxWindows but it seems that they all have their strengths and
> weakness. So wouldn't it be nice to have one standard library/inteface
> for writing graphical/windows applications in C++ as it is quite
> tedious to learn new libraries all the time. Furthermore, I was very
> surprised that there
> isn't a single finished C++ port of the Java Swing library. There are
> jtk, jLib and jlWindows but they are all unfinished!
>
> I wonder what the reason for this might be?
different GUI framework that fits the needs of that particular
situation/circumstance. Another problem is that C++ runs on fare more
platforms than Java ever has or was intended for. Many of those platforms
have no GUI and thus no need for a GUI framework in the language. Finally,
different GUI's often have very different architectures. Swing tries to
encaspulate that by providing the greatest common denominator and emulating
those features not available on a particular system. Often, Swing UI's look
very distinct from an Operating System's native UI, both in style and in
functionality and regularly run slower than many applications written in
C/C++ using the system API.
> Is there actually no need for a standard C++ GUI library?
There might be some use for it. But as the development process of Swing and
the final outcome have shown, the ambition for such a project is rather high
and the payoff not necessarily worth it.
> Is Sun preventing any ports of Swing through copyrights?
I do not know that is true, but I have my doubts. Obviously, the library
couldn't be called Swing but I doubt Sun has any legal hold on Swing's
general structure and design.
sm
Timo Geusch
> Hi,
>
> I've recently looked around for portable C++ GUI libraries, but it
> seems
> there aren't any very nice libraries around. Well, there are a few
> like
> gtk, qt, wxWindows but it seems that they all have their strengths and
> weakness.
Well, that's a feature of *all* libraries IMO. Pick the one that works
best for you and learn its quirks?
> So wouldn't it be nice to have one standard library/inteface
> for writing graphical/windows applications in C++ as it is quite
> tedious to learn new libraries all the time.
Nice it would be, but keep in mind that C++ apps are often used in
environments where speed is very important, so losing part of your
speed advantage because your GUI has several layers between the
abstraction and the underlying display mechanisms might simply be
unacceptable.
> Furthermore, I was very surprised that there
> isn't a single finished C++ port of the Java Swing library. There are
> jtk, jLib and jlWindows but they are all unfinished!
Probably because it's a lot of work and the folks involved had
other/better things to do? I assume that you're talking about Open
Source implementations - most of the people working on them actually
have to do some 'real' work to earn a crust.
> I wonder what the reason for this might be? Is there actually no need
> for a standard C++ GUI library?
I'd say that once you are entering the realm of 'nice' GUI application
programming, you might want to split the front-end from the computing
back-end, write the former using good GUI tools and implement the
back-end in C++. Usually, creating the GUI using an environment that's
designed to facilitate this means that you'll spend the minimum amount
of time necessary to get the GUI done.
--
Timo Geusch
Marcin Mueller
I agree that performance is a very important issue regarding C++. But
i don't see this automatically excluding high level API's. Of course
if you need to get most of your hardware, you would use a platform
specify library as any level of abstraction requires extra processing.
(e.g. for games)
The main reason why i have posted this article is that i quite often
find
myself in a situation where i want e.g. draw a line (a high level
concept) but to achieve this you ususally need to write 10-200 extra
lines of code for initialization and clean up which differs for every
GUI library. (I believe DirectDraw might be here a winner :-)
Thus, from a productivity point of view a high level API would enable
me to concentrate on the actual task (the what) instead of being
bogged down in doing research on how to draw a line. (which is not
very intectually challenging)
Taken this concept further, it seems to be nice to have just one
standard library as this reduces the learning curve and facilitates
portability.
I believe it is actually very hard to divide your application into a
domain and presentation layer (where the presentation would be
implemented using different libraries) without sacrified the
performance of it. In order to efficiently use an API you have to
supply the data in the right format (e.g. an array of POINT's) which
might be library specific. Thus, either your domain layer is library
specify but fast or you have to perform some conversions which will
impact performance.
Thus it seems that having portable GUI applications will always
sacrify some performance. But it many cases it might be a small price
compared to the learning effort and time spent to learn yet another
API.
Maybe one solution could be a library based on common standards
supported directly in hardware. (e.g. OpenGL) I've once read that the
upcoming new C++ standard (sometimes in 2008 or so) might include a
standard GUI library. Does anyone know more about this?
Regards,
Marcin
Maciej Sobczak
Timo Geusch wrote:
>> I wonder what the reason for this might be? Is there actually no
need
>> for a standard C++ GUI library?
>
>
>
> I'd say that once you are entering the realm of 'nice' GUI
application
> programming, you might want to split the front-end from the computing
> back-end, write the former using good GUI tools and implement the
> back-end in C++. Usually, creating the GUI using an environment
that's
> designed to facilitate this means that you'll spend the minimum
amount
> of time necessary to get the GUI done.
I find it very productive to split the app this way and use *different*
technologies (not just specialized libs in the same technology/language)
to handle the two layers (front-end and back-end).
I use Tcl/Tk to handle the GUI part. Putting the pieces together is even
easier than in Swing (but why we take Java as a reference?), both in
terms of conceptual clarity and the resulting number of lines of code.
There are GUI builders for mouse-lovers, too.
The actual back-end of application is written as a loadable module
(which is just a .dll or .so) implemented in plain C++. Moreover, it is
only my decision where to draw the line between Tcl and C++:
- sometimes the front-end is thicker, when the advantages of scripts are
still higher than their disadvantages and when the back-end part is, for
example, computation-oriented and does not care about the user-related
stuff, but
- sometimes the front-end is as thin as a simple button that only calls
some C++ function.
It only depends on what kind of C++ stuff I want to expose in the form
of GUI. On the extreme, the GUI part in the form of Tcl script does not
contain any procedural code, it is just declarative code that tells what
widget should be placed where and to what procedure and variable (in
C++) it is linked. You'd be astonished how little code it takes -
sometimes just one or two lines per widget.
Do I need to say that such application is perfectly portable across
Windows and Unix/Linux? Only Makefiles for the backend (C++) are
different (because MS VC++ compiler is different than gcc).
Of course, the target platform needs to have Tcl/Tk run-time installed
(Unices usually have it in standard installations, anyway), but:
- it is possible to make a plain .exe out of it, and distribute it to
people that do not have the interpreter installed,
- it is no more a hassle than Java VM, so why care?
Also, I do not close myself in the realms of a single vendor, since
Tcl/Tk is completely open and free and has very big community of users.
(Everything above applies also to Python/C++ mix, I'm just more inclined
to Tcl.)
Anyway - my own short experience (previously Windows API, MFC) and tries
(Swing) shows me that the problem of GUI for C++ cannot and *should not*
be solved with a single library. Nothing should be "solved" this way.
The variety of approaches is what makes C++ such a powerful language.
Of course, there is a problem what should then go into the standard
library, but for me GUI does not belong to it. GUI, in its variety of
expectations, should be also open to variety of implementations. Do not
put GUI into standard library.
The expectation that *everything* should be shipped in a single box,
redy to use for the sake of ill-meant productivity, is like expectation
that all we eat should be fast-food, thoughtlessly yielding our fate to
those few who've prepared it. ;)
--
Maciej Sobczak
http://www.maciejsobczak.com/
Distributed programming lib for C, C++, Python & Tcl:
http://www.maciejsobczak.com/prog/yami/
Maciej Sobczak
Timo Geusch wrote:
>>I wonder what the reason for this might be? Is there actually no need
>>for a standard C++ GUI library?
>
>
> I'd say that once you are entering the realm of 'nice' GUI application
> programming, you might want to split the front-end from the computing
> back-end, write the former using good GUI tools and implement the
> back-end in C++. Usually, creating the GUI using an environment that's
> designed to facilitate this means that you'll spend the minimum amount
> of time necessary to get the GUI done.
I find it very productive to split the app this way and use *different*
technologies (not specialized libs in the same technology) to handle the
two layers (front-end and back-end).
I use Tcl/Tk to handle the GUI part. Putting the pieces together is even
easier than in Swing (but why we take Java as a reference?), both in
terms of conceptual clarity and the resulting number of lines of code.
There are GUI builders for mouse-lovers, too.
The actual back-end of application is written as a loadable module
(which is just a .dll or .so) implemented in plain C++. Moreover, it is
only my decision where to draw the line between Tcl and C++:
- sometimes the front-end is thicker, when the advantages of scripts are
still higher than their disadvantages and when the back-end part is, for
example, computation-oriented and does not care about the user-related
stuff, but
- sometimes it is as thin as a simple button that only calls some C++
function.
It only depends on what kind of C++ stuff do I want to expose in the
form of GUI.
Do I need to say that such application is perfectly portable across
Windows and Unix/Linux? Only Makefiles for the backend (C++) are
different.
Of course, the target platform needs to have Tcl/Tk run-time installed
(Unices usually have it, anyway), but:
- it is possible to make a plain .exe out of it, and distribute it to
people that do not have the interpreter installed,
- it is no more a hassle than, say, Java VM, so why care?
Also, I do not close myself in the realms of a single vendor, since
Tcl/Tk is completely open and free.
(Everything above applies also to Python/C++ mix, I'm just more inclined
to Tcl.)
Anyway - my own short experience (previously Windows API, MFC) and tries
(Swing) shows me that the problem of GUI for C++ cannot and *should not*
be solved with a single library. Nothing should be "solved" this way.
The variety of approaches is what makes C++ such a powerful language.
Of course, there is a problem what should then go into the standard
library, but for me GUI does not belong to it.
The expectation that *everything* should be shipped in a single box,
redy to use for the sake of ill-meant productivity, is like expectation
that all we eat should be fast-food, thoughtlessly yielding our fate to
those few who've prepared it. ;)
--
Maciej Sobczak
http://www.maciejsobczak.com/
Distributed programming lib for C, C++, Python & Tcl:
http://www.maciejsobczak.com/prog/yami/
Troll_King
> Hi,
>
> I've recently looked around for portable C++ GUI libraries, but it
> seems
> there aren't any very nice libraries around. Well, there are a few
> like
> gtk, qt, wxWindows but it seems that they all have their strengths and
> weakness. So wouldn't it be nice to have one standard library/inteface
> for writing graphical/windows applications in C++ as it is quite
> tedious to learn new libraries all the time.
You can use Standard C++ containers with Gtkmm. It's a wrapper of
Gtk+. The documentation and support is not strong. There is a mailing
list, and there is a tutorial, and development is active, but there is
a stronger support structure based on Qt, although Qt doesn't support
modern C++. Yet Qt is not a wapper, it is built directly ontop of xlib
primitives as far as I know. There is nothing at all wrong with using
a wrapper, for example Gtk+ is an object oriented C Widget Toolkit,
the widgets are based on an object oriented heirarchy that takes
advantage of inheritance. The problem though is support. I think that
most people who use Standard C++ are Microsoft users, so they are all
stranded on MFC.
As far as I can tell X is a great base to construct a pure Standard
C++ Widget Toolkit built on the minimal xlib interface. They did this
in C with Gtk+ so there is no reason why it can't be done in Standard
C++. The documentation of X doesn't appear to be that great, however
with enough digging around, I'm sure that all the answers are there.
Mr. Stroustrup told me that support was one of the most important
factors, and he liked Qt, but what really burns me about Qt is that it
doesn't support modern C++. I can't force myself to use it.
>Furthermore, I was very
> surprised that there
> isn't a single finished C++ port of the Java Swing library. There are
> jtk, jLib and jlWindows but they are all unfinished!
>
> I wonder what the reason for this might be? Is there actually no need
> for
> a standard C++ GUI library? Is Sun preventing any ports of Swing
> through copyrights?
>
> Regards,
>
> Marcin
Java is 100% controlled by Sun Microsystems. I know about the
community process, however with all vendor libraries, the vendor
retains all rights and control. I don't know why anyone would want to
invest their time in a port, when we could build an open source Widget
Toolkit and sove the problem once and for all. I would like the
control structure to be organic, that way one person doesn't hold all
of the power.
Uwe Schnitker
>
<SNIP>
> Thus, from a productivity point of view a high level API would enable
> me to concentrate on the actual task (the what) instead of being
> bogged down in doing research on how to draw a line. (which is not
> very intectually challenging)
>
> Taken this concept further, it seems to be nice to have just one
> standard library as this reduces the learning curve and facilitates
> portability.
<SNIP>
> Thus it seems that having portable GUI applications will always
> sacrify some performance. But it many cases it might be a small price
> compared to the learning effort and time spent to learn yet another
> API.
>
> Maybe one solution could be a library based on common standards
> supported directly in hardware. (e.g. OpenGL) I've once read that the
> upcoming new C++ standard (sometimes in 2008 or so) might include a
> standard GUI library. Does anyone know more about this?
Well, you might be interested in Stroustrups own view on that issue,
as he expressed it in an interview to be found at:
http://www.research.att.com/~bs/01chinese.html
This was two years ago, when the process of "upgrading the standard"
was just about to be initialized, but I don't think either his views
nore the real situation have changed much regarding the issue.
Regards,
Uwe