GUI compatibility in C++

[arunvnk]

What are the methods to implemnt a GUI in C++?What are the extra heder
files to be added?
Is C++ as strong as Java in animation and graphics?What about the Linux
compiler's compatibility in graphic programes?

 

[Alf P. Steinbach]

* (e-mail address removed):

What are the methods to implemnt a GUI in C++?

All that exist.

What are the extra heder files to be added?

Depends on which library you're using.

Is C++ as strong as Java in animation and graphics?

Stronger. Java graphics is implemented in C and/or C++.

What about the Linux compiler's compatibility in graphic programes?

Ask in a Linux group, /if/ there is any such beast as "the Linux compuiler".

 

[Tejas Kokje]

What are the methods to implemnt a GUI in C++?What are the extra heder
files to be added?

C++ standard does not have GUI libraries (AFAIK). You have to use
libraries developed by other people which have c++ bindings. One such
library is QT used by KDE and wxwidgets.

Is C++ as strong as Java in animation and graphics?

Again strength depends on how strongly the third party library is
implemented. C++ standard does not have animation or graphics library.

What about the Linux compiler's compatibility in graphic programes?

There is no such thing is Linux Compiler. Most of the programs on Linux
use venerable GCC compiler which is also available on many other
platforms like BSD.


Tejas Kokje

 

[Alf P. Steinbach]

* Tejas Kokje:

[quoting earlier posting without attribution]

Please study how to quote properly.

Please also study how to reply to the message you're intending to reply to.

In this case you have implicitly attributed some questions to me; please
don't do that.

 

[loufoque]

What are the methods to implemnt a GUI in C++?What are the extra heder
files to be added?
Is C++ as strong as Java in animation and graphics?What about the Linux
compiler's compatibility in graphic programes?

I advise GTKmm.

 

[andy]

What are the methods to implemnt a GUI in C++?What are the extra heder
files to be added?

Currently there is no standard way to implement a GUI in C++. There are
various commercial and non-commercial GUI libraries available, but IMO
the most satisfactory solution (from we the users point of view rather
than anyone elses) would seem to me to be to have a standard C++ GUI.

I have asked about the lack of a C++ GUI in comp.lang.c++.moderated.
The opinion of the powers that be seems to be that a standard C++ GUI
is desirable. The problem is in someone taking the time to get such a
project running.

I enclose a thin paper that I put in the Vault at http://www.boost.org
just because I felt that doing very little about the situation was
better than doing nothing. Here is the main text of the current version

------------------------------------

A standard graphical user interface for C++?

Newcomers to C++ often wonder why C++ doesnt have a standard GUI.
Posing the question on comp.lang.c++.moderated recently, the reasons
seem to be that C++ missed the boat around the 1990's. The C+ committee
seems to be suggesting that they would like a standard GUI in an ideal
world but that they are unlikely to have the resources to look into
this themselves. A C++ GUI is not traditional standard library
territory nor even on the horizon it seems.

In informal discussions so far the main issues that came up are:

* boost.org is the best place for such a library could be developed.
Not everyone around boost is in favour of trying to produce such a
library, (Nor is there a specific majority against) nevertheless the
know how, tools (especially cross platform tools and test facilities)
etc to do this are here. Boost excels in cross-platform development.
Recently boost libraries have started to push outside the traditional
single-threaded sealed application model that the C++ standard is based
on with libraries such as Boost.Threads, Boost.Asio, and Boost.Shmem
all of which I would think break the current model.

* Must be seamlessly cross-platform.
Write once run anywhere. Sounds simple right? In practise Graphical
output devices are a wide spectrum of sizes and hardware. There will
probably have to be various hardware models, minimal hardware
requirements etc, for example classification by gross number of pixels
with the broad intent to distinguish desktop and laptop pc's from
mobile phones and down from there to wristwatch sized screens. Is there
a need for desktop applications to be ported to devices with smaller
screens or is the paradigm sufficiently different that the refactoring
the code would be more work than reworking it. There are reports from
various GUI libraries that they have ben ported to small devices. It
would be interesting to find out how this works out in practise.

* Abstracting away hardware.
The physical problems of output devices have been previously been
tackled by interposing a layer of abstraction between the programmer
and the hardware. The obvious example that springs to mind is Windows
GDI , now augmented by GDI+. I would expect identifying suitable
abstractions to be a common methodology for solving many platform
dependent GUI problems.

* Must be capable of (at least) local platform look'n feel.
Comes up time and time again. Existing practise of interest are
Java.AWT and Swing as well as current C++ GUI's. There are two ways to
achieve native look and Feel. The first is just to call the platform
dependent API's and let the platform do it for you. This approach is
taken in WxWidgets and AWT. Its fine but not very flexible. Java Swing
does it the other way by simulating everything from the ground up. This
is very flexible (1 platform can be made to look like another for
example or individual skin can be used) but it has been criticised for
not getting it quite right. It would seem that some suitable pictorial
evidence might help to identify fact and fiction here.

* Must use existing standard libraries.
This sounds obvious but in many pre-existing GUI libraries this is not
the case. For example in case of Ultimate++ GUI<url
http://upp.sourceforge.net/www$uppweb$overview$en-us.html> they say
that it isnt really feasible to use the standard containers for a GUI
because they require a type with a copy-constructor.

* Arguments against a standard GUI

The main argument against a standard C++ GUI is that there is a wide
range of GUI libraries out there already that are adequate to do the
job or that a standard GUI library would not be agile enough to keep up
with developments. I think that the basic elements of a GUI are quite
well established and may be tweaked but are fairly stable. Newer
elements such as docking windows can be built out of these more basic
building blocks.

I hope try to enumerate some of the major hardware graphics/ GUI layers
and identify some common GUI building blocks and features in the next
version of this document

Links to further Information about at least a boost GUI.

Boost Wiki on GUI
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostGUI

Boost Wiki on Threads about GUI on the boost developers list.
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostDevelGuiThreads


Keep dragging n' dropping!

regards
Andy Little

------------------------------------------------------------------------------

(Thats it so far on my contribution to a standard C++ GUI)

Is C++ as strong as Java in animation and graphics?

I would guess no because of the lack of common standard components.

What about the Linux
compiler's compatibility in graphic programes?

Linux OS has good graphics hardware support AFAIK.

cheers
Andy Little

 

[Chris Hills]

Currently there is no standard way to implement a GUI in C++. There are
various commercial and non-commercial GUI libraries available, but IMO
the most satisfactory solution (from we the users point of view rather
than anyone elses) would seem to me to be to have a standard C++ GUI.

I have asked about the lack of a C++ GUI in comp.lang.c++.moderated.
The opinion of the powers that be seems to be that a standard C++ GUI
is desirable.

No, we didn't say that!!!!

In theory it *might* have been a good Idea if it had been done when the
language was specified but it is far too late now.

In the lengthy discussion you had AFAIR it was you pushing for a
standard GUI and the rest of us explaining why it was not a practical
idea. The usual method of dealing with some one who will not listen is
to say you go and write it yourself then....

Of course once you write it there is no guarantee that you can even get
it as an ISO TR let alone ever become part of the standard.

If you ever did get it to be part of the standard (best guess a minimum
of 5 years from now) there is absolutely no commercial reason why anyone
would implement it.

You also have the problem that as soon as you submit it to ISO as a TR
ALL the worlds GUI vendors are going to get involved to stop you
proposing something that is counter to their system. This could hold it
up for ever and a day. It is unlikely to ever come out of the committee
stage. If it does you will find all the current GUIs will be ISO
compatible anyway

In informal discussions so far the main issues that came up are:

* boost.org is the best place for such a library could be developed.
Not everyone around boost is in favour of trying to produce such a
library,

* Must be seamlessly cross-platform.
Write once run anywhere. Sounds simple right? In practise Graphical
output devices are a wide spectrum of sizes and hardware.

8 to 128 bit with and without an OS with a 1.5 inch mono LCD upwards.

* Arguments against a standard GUI
The main argument against a standard C++ GUI is that there is a wide
range of GUI libraries out there already that are adequate to do the
job

This is true.

with developments. I think that the basic elements of a GUI are quite
well established and may be tweaked but are fairly stable. Newer
elements such as docking windows can be built out of these more basic
building blocks.

What docking windows? You have presupposed you will have windows in this
gui... It is a GUI not a windows system.

 

[andy]

Chris Hills wrote:

No, we didn't say that!!!!

Hi troll! Trying to pretend you are "the powers that be" this time?

ho ho ho
Andy Little

 

[Phlip]

Hi troll! Trying to pretend you are "the powers that be" this time?

ho ho ho
Andy Little

Guess which of you two now gets plonked.

 

[Chris Hills]

Chris Hills wrote:



Hi troll! Trying to pretend you are "the powers that be" this time?

ho ho ho
Andy Little

I was part of your discussion on the comp.lang.c++.moderated hence the
"we". As you will recall you were the only voice pushing got this std
graphics library / GUI the rest of us were explaining why not, as part
of the standard.

Don't take my word for it but also don't come out with things like:
"The opinion of the powers that be seems to be that a standard C++ GUI
is desirable."

Because that is blatantly un-true. Which members of WG21 did support
you? comp.lang.c++.moderated is NOT the "powers that be" in C++ and
nothing has come up on the WG21 mail lists. "might have been a good
idea" if it had been done at the beginning of C++ does not mean it is
desirable now.

The problem is as several of us explained to you (at length) is that
there are already many GUIs and graphics libraries out there now.

A GUI and a graphics library are two different things.

If you wanted to do a standard graphics library as part of the standard
it is not in the interests of any of the commercial vendors to have a
standard that does not encompass their system.

AFAIR you wanted a simple system for helping beginners. You would not
get that out of the system now. It is far too late as it has to be done
as part of the original spec.

So you would find that the minute you started the graphics library you
will find EVERY other graphics library vendor will be involved making
sure the resultant library standard is either in line with their system
or does not see the light of day. The result will be either a library
that never comes out or one that is so wide and open it is pointless. Ie
5 or 6 options at every point.

However I note you are now saying a GUI not a graphics library... that
is different. Now you are looking for a portable GUI that will work
with and without and OS on multiple architectures. These already exist
though they are not widely used. This is because most OS and many
embedded RTOS have their own that people now.

The same thing will apply here. As soon as you start all the current
commercial vendors with either widen the work to encompass their system
as well or simply slow it down to a standstill.

It may be a Very Good Idea if it had been implemented when C++ was first
done but it is well past the point where a standard GUI or graphics
library is an option.

However if you want to do one no one is stopping you but I can tell you
no one on the standards bodies is going to spend any time on it. There
are too many other things to do.

 

[andy]

I was part of your discussion on the comp.lang.c++.moderated hence the
"we". As you will recall you were the only voice pushing got this std
graphics library / GUI the rest of us were explaining why not, as part
of the standard.

Don't take my word for it but also don't come out with things like:
"The opinion of the powers that be seems to be that a standard C++ GUI
is desirable."

Because that is blatantly un-true. Which members of WG21 did support
you? comp.lang.c++.moderated is NOT the "powers that be" in C++ and
nothing has come up on the WG21 mail lists. "might have been a good
idea" if it had been done at the beginning of C++ does not mean it is
desirable now.

Youre a troll and I dont waste time on trolls.

( For morbidly interested third parties the original
comp.lang.c++.moderated thread is here. There are of course various
committee members voices in there AFAIK, as well as several others
expressing various opinions on the subject in the other links in my
previous but 1 post):

http://tinyurl.com/lewuj

cheers
Andy Little

 

[Chris Hills]

Youre a troll and I dont waste time on trolls.

thanks for the reply

( For morbidly interested third parties the original
comp.lang.c++.moderated thread is here. There are of course various
committee members voices in there AFAIK,

Yes... Me for one. Who were the others?