gui

[Gernot Frisch]

Hi,

there's a lot of different GUI libraries for x-platform programming
out there. We have a standard set of C/C++ functions for console
programs. Why isnt't there any such interface for window containers,
yet? Imagine a very simple window creation/handling set in std C++,
that would be platoform independent one day. You can build all this
GTK/Qt/MFC stuff around if you wish to, but there would be a
x-platform library for GUI programming.
<blink, blink>
Why does std C++ not try to invent this? Very, very simple functions
would do (create window, text out, line drawing, mouse pointer state)


--
-Gernot
int main(int argc, char** argv) {printf
("%silto%c%cf%cgl%ssic%ccom%c", "ma", 58, 'g', 64, "ba", 46, 10);}

________________________________________
Looking for a good game? Do it yourself!
GLBasic - you can do
www.GLBasic.com

 

[Ioannis Vranos]

Hi,

there's a lot of different GUI libraries for x-platform programming
out there. We have a standard set of C/C++ functions for console
programs. Why isnt't there any such interface for window containers,
yet? Imagine a very simple window creation/handling set in std C++,
that would be platoform independent one day. You can build all this
GTK/Qt/MFC stuff around if you wish to, but there would be a
x-platform library for GUI programming.
<blink, blink>
Why does std C++ not try to invent this? Very, very simple functions
would do (create window, text out, line drawing, mouse pointer state)

How that would be applied to embedded systems without GUIs?

 

[Gernot Frisch]

How that would be applied to embedded systems without GUIs?

void _getgraphics_display(&somestruct);

if(somestruct.IsAvailable)
{
...
}

maybe you can alter it, so the text mode console can be used as a
"graphical window". So, you get window size = 80x40 and font-size is
1x1?

 

[Thomas Matthews]

void _getgraphics_display(&somestruct);

if(somestruct.IsAvailable)
{
...
}

maybe you can alter it, so the text mode console can be used as a
"graphical window". So, you get window size = 80x40 and font-size is
1x1?

So that means that a program has to check to see if it has
graphics capability before it launches a GUI widget.

Also, there has to be standardized graphical interfaces, such
as raster vs. vector, color vs. grayscale, RGB vs. CMYK vs. HSB
(Hue, Saturation & Brillance). There are other factors too, such
as aspect ratio, pixels per length, colors per pixel, event processing
capability, etc. As you can see, there are a lot of attributes to
graphics which need to be standardized. So far, there doesn't appear
to be any standard. Some come close, but no graphics standard.
Also, if you use named colors, such as blue, how does one standardize
that color? Is aqua close enough? At what range or percentage does
blue become light blue, dark blue or another shade of blue?

If you have a proposal, please submit it to the C++ standards
newsgroup and let them have a take at it. If it is really good,
it may be adopted in the next standard. Or you could create an
open-source library, like BOOST, and let it creep into the standard.

Just remember than small 8-bit embedded systems with no displays
also use C++ and don't want any mandatory "frilly" stuff added in.
In many embedded systems, memory (code and variable) space is at
a premium and small in size.


--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.comeaucomputing.com/learn/faq/
Other sites:
http://www.josuttis.com -- C++ STL Library book

 

[Gernot Frisch]

on systems without a screen?
(for example an LCD clock, a toaster, a temperature
micro controller, etc)

Now. That's why K&R didn't make printf part of the C programming
language. It's a function of standard libraries and the
user including <stdio.h> expects that the program will
run on a system with a screen.
Agree.

I seriously agree that C++ and C do need <stdgui.h>.
It is very important for their future.

I'm not sure if it's future depending, but it would really really
relief all of us.

Moreover, java which is supposed to be a language
for embeded targets (cell phones for example), has
menus and gui stuff. So? Let's be realistic. All computers
have graphics nowdays. Instead of wasting time with
STL (which is a library of some data types the programmer
can create for their own), spend the energy *defining*
the functions/classes interface of an <stdgui.h> header file.
Good.

Avoid templates if possible.

Nah!! Please, please templates and std-containers.
Make it std::c++, not std::c.

-Gernot

 

[Gernot Frisch]

So that means that a program has to check to see if it has

graphics capability before it launches a GUI widget.

Sure. You have to check if you have a console of you want to use
printf.

Also, there has to be standardized graphical interfaces, such
as raster vs. vector, color vs. grayscale, RGB vs. CMYK vs. HSB
(Hue, Saturation & Brillance).

pixel graphics. Colors in RGB. Conversion (if not possible by device)
should be made by the framework internally. RGB(255,0,0) will be
converted to grayscale if only w/b is available.

There are other factors too, such
as aspect ratio, pixels per length, colors per pixel, event
processing
capability, etc.

I don't understand the problem here...

Also, if you use named colors, such as blue, how does one
standardize
that color? Is aqua close enough? At what range or percentage does
blue become light blue, dark blue or another shade of blue?

The closest value that can be used.
-Gernot

 

[Ioannis Vranos]

Sure. You have to check if you have a console of you want to use
printf.

Actually printf() and more precisely the standard input, output, error
streams are used even to systems without a console. Like robotic arms
taking special escape sequences.


Actually what you are looking for, are standardised graphics libraries.
One great example is OpenGL which takes advantage of modern GPUs on
modern PCs.

Quake is written in OpenGL.


http://www.opengl.org

 

[Ioannis Vranos]

Agree.




I'm not sure if it's future depending, but it would really really
relief all of us.

Myself would not find bad the existence of facilities about coffee machines.

Fortunately for you though, one of C++ aims is to be a general purpose
language with general purpose facilities.


Check this standardised modern library about serious graphics (where
companies producing modern GPUs like NVIDIA participate).

 

[Ioannis Vranos]

Myself would not find bad the existence of facilities about coffee
machines.

Fortunately for you though, one of C++ aims is to be a general purpose
language with general purpose facilities.


Check this standardised modern library about serious graphics (where
companies producing modern GPUs like NVIDIA participate).

http://www.opengl.org

 

[Denis Remezov]

there's a lot of different GUI libraries for x-platform programming
out there. We have a standard set of C/C++ functions for console
programs.

Don't mistaken the standard streams for console programming API.
For one thing, when used as such, they give you only rudimentary
functionality, which is good in lots of simple cases, but is
insufficient for more general console programming.
For another, the standard streams don't need to be attached to
any console at all (and they can still be indispensable); the
notion of console itself is non-standard.

Denis

 

[Gernot Frisch]

Actually what you are looking for, are standardised graphics

libraries. One great example is OpenGL which takes advantage of
modern GPUs on modern PCs.

Quake is written in OpenGL.


http://www.opengl.org

Not really. OpenGL is a graphics library for rendering _inside_ a
window. What I wish to have is a standart _for_ the window. It's
really nive to have to write a program only once for OpenGL. But then
you need platform specific stuff for the creation of the window,
keyboard input, mouse events...
Really a standard gui would be great. Because C++ standard will live
forever you would have a library you can rely on. What about using one
of these geek-gui-libs when the author will die? The company get's
bankrupt? What about a new OS they don't want to support?
In std::C++ the OS programmers would have (and happily will) provide
the std libs for the gui.
Sorry, I don't understand why you don't agree with me? I would if I
knew you were working for a company that is keen on getting a monopol
situation in operating systems, but otherwise I can't see any reason
not to have the desire for a std gui command set...

 

[Ioannis Vranos]

Gernot Frisch wrote:

Not really. OpenGL is a graphics library for rendering _inside_ a
window. What I wish to have is a standart _for_ the window. It's
really nive to have to write a program only once for OpenGL. But then
you need platform specific stuff for the creation of the window,
keyboard input, mouse events...
Really a standard gui would be great. Because C++ standard will live
forever you would have a library you can rely on. What about using one
of these geek-gui-libs when the author will die? The company get's
bankrupt? What about a new OS they don't want to support?
In std::C++ the OS programmers would have (and happily will) provide
the std libs for the gui.
Sorry, I don't understand why you don't agree with me? I would if I
knew you were working for a company that is keen on getting a monopol
situation in operating systems, but otherwise I can't see any reason
not to have the desire for a std gui command set...

Because the most efficient way of things (and part of C++ success), is
that specialisation produces the best results.


You use the general purpose language which is very good on that, and
"plug" in a local efficient API for doing system specific stuff.


For example if you want efficient 3D graphics you may use OpenGL.

If I want Windows applications I "plug" in .NET. If I want simple 2D
graphics on that, I "plug" in also GDI+ API.


Even if C++ provided some minimal GUI API I bet all various system
programmers would use the more efficient ones provided by their systems.


If C++ were to provide a full GUI API, a full Database API etc, then its
applications would suffer from efficiency, and would not take advantage
of all facilities provided by every platform.

 

[Howard]

maybe you can alter it, so the text mode console can be used as a
"graphical window". So, you get window size = 80x40 and font-size is
1x1?

1x1? That's pretty small. Just one pixel wide and one tall. So, pretty
much the screen (assuming one exists at all) would be just "on" or "off"
pixels. Doesn't give you much of an alphabet to work with, does it?

-Howard

 

[Karl Heinz Buchegger]

1x1? That's pretty small. Just one pixel wide and one tall.

Depends on your definition of 'pixel' in this case.
After the all the whole screen has only 80x40 'pixels'. But each
'pixel' can take various shapes

 

[Howard]

...Let's be realistic. All computers
have graphics nowdays.
Gerald

Only if you define a "computer" as a processor that *does* have a screen.
I've got a lot of hardware here that has no graphical output, and yet I
write programs for it.

I do agree that some kind of standard would be "nice", but who's going to
define it, and what kind of output would it define? Same question regarding
inputs...what would it define? Mice? (Two-button, three-button,
scrolling?) Joysticks? (DIscrete or continuous?) Numeric keypads?
Chinese keyboards? Then there's the operating system model to
consider...the Carbon Events model on Mac OS X is hardly compatible with
polling schemes, or even the Windows event handler model. I for one suggest
we leave such platform-specific stuff to those writing code *for* those
specific platforms, and keep C++ itself "pure" as much as possible.

-Howard

 

[Phlip]

there's a lot of different GUI libraries for x-platform programming
out there. We have a standard set of C/C++ functions for console
programs. Why isnt't there any such interface for window containers,
yet? Imagine a very simple window creation/handling set in std C++,
that would be platoform independent one day. You can build all this
GTK/Qt/MFC stuff around if you wish to, but there would be a
x-platform library for GUI programming.
<blink, blink>
Why does std C++ not try to invent this? Very, very simple functions
would do (create window, text out, line drawing, mouse pointer state)

Because very simple functions would be "jack of all trades, master of none".

A stream is a one-dimensional interface. Bytes come out, and a program
spools them and interprets them. The mechanisms are so simple that a
language can cover all their permutations in only a handful of functions.

A GUI is a two-dimensional interface that animates in time. It is orders of
magnitude more complex. All GUIs interface with both their users and their
source code using a bunch of simplifying assumptions. HTML, for example,
simplifies by assuming only text and graphics in output, only <form> and
<input> tags for input, and all other IO offloads into platform-specific
alternative GUI libraries.

Win32 simplifies by assuming windows, buttons, and menus. If you want,
instead, bungie cords and parachutes, you must again add a library that
provides them, and this must, again, make simplifying assumptions about the
graphics driver layer.

There is no way to cover the full complexities of all possible permutations
of GUIs under the enforced legitimacy of an international standard. Each
time a programmer needed to something in some way this hypothetical GUI did
not cover, they once again must go back to platform-specific code.

 

[Jerald]

Ioannis Vranos wrote:

How that would be applied to embedded systems without GUIs?

Well, with the same logic how can <stdio.h> be applied
on systems without a screen?
(for example an LCD clock, a toaster, a temperature
micro controller, etc)

Now. That's why K&R didn't make printf part of the C programming
language. It's a function of standard libraries and the
user including <stdio.h> expects that the program will
run on a system with a screen.

I seriously agree that C++ and C do need <stdgui.h>.
It is very important for their future.

Moreover, java which is supposed to be a language
for embeded targets (cell phones for example), has
menus and gui stuff. So? Let's be realistic. All computers
have graphics nowdays. Instead of wasting time with
STL (which is a library of some data types the programmer
can create for their own), spend the energy *defining*
the functions/classes interface of an <stdgui.h> header file.
Avoid templates if possible.

Gerald

 

[Ioannis Vranos]

If C#, Java, etc are gaining users that's only because they
have standard gui libraries while in C++ there are dozens
of different guis for each platform. An stdgui would really
''boost'' C++ IMHO

C# has no GUI library. It uses the GUI library of the CLI machine used
(the same GUI library with the rest languages).

I do not know Java, but I am sure the GUI belongs to the VM used too.
Although that VM is tied together with the language and all-together are
called Java.

 

[Phlip]

I do not know Java, but I am sure the GUI belongs to the VM used too.
Although that VM is tied together with the language and all-together are
called Java.

Oh, yeah - I almost forgot.

Java's first "standard, cross-platform" GUI, AWT, failed. It brought a
clumsy architecture, and everyone suffered with it.

Then their second one, Swing, took off. But, like everyone said, it's still
not _standard_, and I suspect there are several flavors of it.

 

[Gernot Frisch]

Java's first "standard, cross-platform" GUI, AWT, failed. It brought

a
clumsy architecture, and everyone suffered with it.

AWT would be a good starting point. If only it had template support
and extesibility. The gréat thing was the layout technique, which
allowed you to make guis without a visual designer, but soucr code.
Just like html's <table> command.