Topic: gui libraries
Author: phalpern@truffle.ma.ultranet.com (Pablo Halpern)
Date: 1998/05/22 Raw View
paul@mbed.com (Paul Hamilton) wrote:
>
>I think the key point that I was making is that we shouldn't have a
>standard X-platform GUI framework (can't exist), we should have a standard
>GUI template library.
But such a standard doesn't need to be part of the C++ standard, does
it? In fact, it seems that such a standard can support C++, C, Java,
Pascal and other bindings and be independent of the individual
languages' standard libraries. Examples: POSIX is a standard separate
from the C standard, as is X windows (aleit not a very good one).
STL supports much more basic functionality than GTL. In order to have
reasonable data exchange between different 3rd party libraries, you need
a standard string library and a standard containers/interators library.
GTL is much further from the language core, and is more appropriate as a
separate standard. (Personally, I think valarray falls into a grey area
between the two.)
-------------------------------------------------------------
Pablo Halpern phalpern@truffle.ultranet.com
I am self-employed. Therefore, my opinions *do* represent
those of my employer.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Gabriel Dos Reis <dosreis@DPTMaths.ens-cachan.fr>
Date: 1998/05/20 Raw View
>>>>> =ABValentin=BB, Valentin Bonnard <bonnardv@pratique.fr> wrote:
Valentin> I personnaly thinks that it would be useful in the C++ standard=
.=20
True.
Valentin> IMHO, GUI programming concerns more programmers than classes=20
Valentin> like valarray.
It just happens that GUI concerns a set of programmers and
valarray<> concerns another set of programmers (probably with
non-empty intersection). It just happens that there are a lot of
programms which do not need a GUI. This doesn't imply the committee
should not look a the GUI problem. But one *should not* minimize the
valarray<> need. =20
BTW, GUI is not a simple matter IMHO and it involves more
system-dependant issues than valarray<> does.
-- Gaby
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "Daniel Parker" <danielp@nospam.com>
Date: 1998/05/20 Raw View
Valentin Bonnard wrote in message <355EF6EC.4D1F@pratique.fr>...
>Greg Bonney <gbonney@gms.mar.lmco.com> writes:
>
>> There are a hand-full of cross-platform portable GUI frameworks
available,
>> including wxWindows and V. With standard C++ adding so many features,
why
>> not add a standard GUI library?
>I personnaly thinks that it would be useful in the C++ standard.
>IMHO, GUI programming concerns more programmers than classes
>like valarray.
Does anyone really want a monolithic C++ standard? How long would the
approval process take? Especially, as you say, people would care more about
this stuff than they would care about auto_ptr and valarray?
How about having a distinct standard for a platform independent GUI
interface separate from the C++ standard? So a tools vendor could write
something to it and have some hope of selling any? I've been involved in
GUI framework evaluations, and most of my clients have shied away from
purchasing third party frameworks on the grounds that they were too risky,
being non-standard, and choosing to work with Microsoft's MFC instead.
Less and less GUI programming, however, seems to be done in C++ these days,
but rather in languages like Visual Basic and, to a lesser extent, JAVA.
Companies that make high level GUI development tools appear to be abandoning
their BASIC like proprietory languages in favour of JAVA. So, it may simply
cease to be important to have a C++ standard for GUI, if that isn't already
the case.
--
Regards,
Daniel Parker danielp@no_spam.anabasis.com.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: paul@mbed.com (Paul Hamilton)
Date: 1998/05/21 Raw View
In article <6jtfe6$hh3$1@news.interlog.com>, "Daniel Parker"
<danielp@nospam.com> wrote:
> Valentin Bonnard wrote in message <355EF6EC.4D1F@pratique.fr>...
> >Greg Bonney <gbonney@gms.mar.lmco.com> writes:
> >
> >> There are a hand-full of cross-platform portable GUI frameworks
> available,
> >> including wxWindows and V. With standard C++ adding so many features,
> why
> >> not add a standard GUI library?
>
> >I personnaly thinks that it would be useful in the C++ standard.
> >IMHO, GUI programming concerns more programmers than classes
> >like valarray.
>
> Does anyone really want a monolithic C++ standard? How long would the
> approval process take? Especially, as you say, people would care more about
> this stuff than they would care about auto_ptr and valarray?
>
We aren't talking about a monolithic C++ standard. We are talking about
something akin to the STL, but for GUI work.
Just like the STL, it will grow and become more useful and eventually
become standard.
Ok, so I guess I'm splitting straws :-)
But making STL part of the standard doesn't make it monolithic. You can
use parts of STL in isolation, and you can certainly use C++ without STL.
This would be the same. You can use C++ or STL without GTL (coined
phrase), an you can still use the platform framework directly if you so
desire.
> How about having a distinct standard for a platform independent GUI
> interface separate from the C++ standard? So a tools vendor could write
> something to it and have some hope of selling any? I've been involved in
> GUI framework evaluations, and most of my clients have shied away from
> purchasing third party frameworks on the grounds that they were too risky,
> being non-standard, and choosing to work with Microsoft's MFC instead.
>
I think you are wrong at the start of this sentence, and then hit upon it
at the end.
Any sort of "GUI Template Library" would need to interact with the
Framework on different platforms, MFC, wxWindows, V, PowerPlant, MacApp
etc.
That way people wouldn't have to ditch significant investment in code that
supported the framework.
> Less and less GUI programming, however, seems to be done in C++ these days,
> but rather in languages like Visual Basic and, to a lesser extent, JAVA.
> Companies that make high level GUI development tools appear to be abandoning
> their BASIC like proprietory languages in favour of JAVA. So, it may simply
> cease to be important to have a C++ standard for GUI, if that isn't already
> the case.
>
I'm not sure if this is so true. In my area of work, Commercial software,
they all have GUI's, and most of them are written in C++ (or C).
Most of the work to use Java as an application development language has
not been fruitful so far.
I still think that C++ has the most chance of being widely used and USEFUL
as a GUI development language.
I think the key point that I was making is that we shouldn't have a
standard X-platform GUI framework (can't exist), we should have a standard
GUI template library.
Paul.
--
Paul Hamilton
Software Engineer
mBED Software
paul@mbed.com
http://www.mbed.com
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: paul@mbed.com (Paul Hamilton)
Date: 1998/05/19 Raw View
In article <35588A4F.ADA51ADD@gms.mar.lmco.com>, Greg Bonney
<gbonney@gms.mar.lmco.com> wrote:
> There are a hand-full of cross-platform portable GUI frameworks
available, including
> wxWindows and V. With standard C++ adding so many features, why not add
a standard
> GUI library?
>
Greg,
Another possibility is that we provide an STL over the top frameworks that
are available on different platforms.
Think of it as a "Framework adapter library".
You could write code that would sit nicely inside MFC on windows,
PowerPlant/MacApp on the Macintosh, YellowBox yada, yada.
One of the problems of GUI design is that it's a visual pirsuit rather
than being just about the manipulation of text files (writing code).
The main tool when codeing is some type of "Visual Constructor". This
would be the dialog editor/Template wizard on Windows, Metrowerks
"Constructor", MacApp's ViewEdit etc. This is one of the hardest pieces to
write, and they already exist.
Each of these frameworks has a View heirarchy, command routing etc.
So taking the idea that this stuff has already been done, we just need to
work out the details of an adapter library that would let you create a
"view" and have it live inside a CView in MFC, LPane in PowerPlant etc.
At mBED we currently ship a product called Interactor (Multimedia
development tool) that actually run's common code within MFC on Windows
and PowerPlant on the macintosh.
We chose to actually use a cut-down version of MFC as the baseline, but I
am getting a really good feel for how an adapter framework would work for
doing cross-platform work.
Once the adapter framework existed, then we could write an STL-like
library to implement GUI "algorithms".
Things like:
- double/triple buffered drawing
- rect-list update region support
- bezier curve manipulation
- multiple levels of undo (no framework does this well).
- time-line manipulation
- command routing/UI element activation (toolbars, menus etc)
- change propogation
- visual alignment
- visual tree views
- other cool things that I don't know about but others do :-)
The framework elements would simply extend the current STL so that you
could create a vector of display objects and sort them by some
characteristc using sort.
This product is about the 3rd one I've done on three different frameworks,
and I'm getting sick of it. It's actually been very liberating to use two
different frameworks for the same application. There is some things that
MFC is great for on Windows, and PowerPlant is great for on the mac.
Either of the two would suck on the other platform.
Paul.
--
Paul Hamilton
Software Engineer
mBED Software
paul@mbed.com
http://www.mbed.com
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Greg Bonney <gbonney@gms.mar.lmco.com>
Date: 1998/05/12 Raw View
There are a hand-full of cross-platform portable GUI frameworks available, including
wxWindows and V. With standard C++ adding so many features, why not add a standard
GUI library?
My apologies if this is a FAQ.
--
Greg Bonney - Greg.Bonney@hercii.mar.lmco.com
Disclaimer: Opinions are strictly my own, not those of my employer, and
should not be construed as legal advice, etc. E-mail can be forged.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Valentin Bonnard <bonnardv@pratique.fr>
Date: 1998/05/17 Raw View
Greg Bonney <gbonney@gms.mar.lmco.com> writes:
> There are a hand-full of cross-platform portable GUI frameworks available,
> including wxWindows and V. With standard C++ adding so many features, why
> not add a standard GUI library?
>
> My apologies if this is a FAQ.
This question comes up regulary, but less often then questions
about auto_ptr (I don't know why people get so excited about
auto_ptr, BTW.)
I personnaly thinks that it would be useful in the C++ standard.
IMHO, GUI programming concerns more programmers than classes
like valarray.
I am currently writting a portable GUI library called AGIL++.
You can read some docs about it at:
http://www.eleves.ens.fr:8080/home/bonnard/agil/
--
Valentin Bonnard mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://pages.pratique.fr/~bonnardv/
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]