I think it a good idea to have a standard on user interfaces to.
Having this would increase portability, but.
But it won't be easy.

Having the idea of a UIL (user interface library) let's me
want a GLB (graphics library) to. With UIL I mean a windowing
system, with GLB I mean a more low level drawing system.
Now, there are (like other participants already mentioned)
libraries that do that, but as also mentioned, a great deal
of them are vendor owned, and so not that interesting.
PHIGS is for the moment the best available, being ISO
backuped, it's safe to use. However, it's not powerful
enough (at least, that's my opinion).

Another topic that is somewhat indirectly related to graphics,
are threads. There is no support for threads in the C++ standard, nor
the language.
Maybe somebody of the commision should look deeper into that,
so more multi-threaded applications can be made portable.

Chris

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own
---
[ 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              ]

simon wrote:
>
> A Standard Graphics Library...
>
> I think 99% of people will say that not all computers have a graphics
> display - so there could be no such thing.
>
> However, from a coders perspective 99% of customers want a GUI with
> all the features of a 'modern' (motif/mfc) windowing system.

I think you are mixing two things here:

- A GUI library (the thing that does windows, buttons, menus, dialogs,
  mouse and keyboard handling, ...)

- A graphics library (the thing which draws lines, rectangles,
  circles, ellipses, ...)

On some systems (e.g. DOS), the GUI library will build on the
graphics library; on other systems (e.g. Windows), the graphics
library will use the GUI library for getting its drawing context.

IMHO anything that doesn't clearly separate those two issues
should not get standardized.

[...]


[ 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              ]

In article <7cj2e3$nrn$1@nnrp1.dejanews.com>,
  chris_minnoy@my-dejanews.com wrote:
> I think it a good idea to have a standard on user interfaces to.
> Having this would increase portability, but.

It's been done. In the "good 'ol days" when IBM and Microsoft were
best friends, IBM issued a guidebook called something like "CUA:
Common User Access guidelines." They defined thousands of
user-interface guidelines, describing how OS/2 menus and scrollbars
work and the common guidelines for use of F-keys and mouse clicks.
I think that some people in IBM (at least the author) expected to
define all GUI's for the rest of time.

It didn't work. It was about that time that GUI acceptance moved from
a small band of first-adopters (the Mac users) to a larger band of
sheep (the Microsoft users). [No offense intended -- I include myself
in the latter category.] Which meant that program vendors were just
starting to explore the GUI world for their own use. Which meant that
they were blazing new trails, either because they had to face
problems not dealt with in the CUA, or (more often) because they
didn't like what IBM had written. Many vendors tried to distinguish
their software by looking better or being easier to use than their
competitors; in other words, they ignored the CUA (if they even had
it!)

But that was then; surely by now most interactive platforms have a
GUI available, right? But no, we're still not ready for this.

There are differences in hardware. What keys are there on the
keyboard? Besides CTRL and SHIFT, what other "combination" keys
are there? If CAPS LOCK is on, does SHIFT+A produce a lower-case
'a'? How do we accept key combinations that don't have ASCII
codes, such as ALT+Z? How many F-keys can we assume all users
have, and what's the maximum that they might ever have? How many
buttons on the mouse? Does heavy I/O or computation cause the
mouse or other concurrent programs to freeze? What's the
"Standard" minimum screen resolution and number of colors? What's
the real screen resolution right now? Is there more than one
screen for this single user? Can the user change screen
resolutions or maximum colors while the program is running?
Do I need a semaphore or other lock when I do [insert difficult
programming task here]? These questions all have different answers
on different platforms.

There are differences in conventions. What key is usually associated
with Help? Are there other commands that users will expect to be able
to use, and be disappointed if they're missing? Where does the menu
go and what does it look like? How do you install the program; how do
you start running it? Should we use the "flat look" or the "3d look"
or the "3d-chiseled look" or something else? Does the system supply
some sort of standard help-file mechanism? Is it possible to send two
different files to the printer at the same time, without getting the
output mixed together? Does program loading take long enough to make
a "now loading" message meaningful? Can I disable and re-enable any
screen saver, or at least 'wake it up'? These questions all have
different answers on different platforms.

Any attempt to standardize a GUI will have to answer all of these
questions for all platforms, including ones you've never heard of,
in a way that doesn't favor one vendor over another. That's a very
tall order.

----
Allan_W@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


[ 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              ]

In article <7cj2e3$nrn$1@nnrp1.dejanews.com>,
  chris_minnoy@my-dejanews.com wrote:
> I think it a good idea to have a standard on user interfaces to.
> Having this would increase portability, but.

It's been done. In the "good 'ol days" when IBM and Microsoft were
best friends, IBM issued a guidebook called something like "CUA:
Common User Access guidelines." They defined thousands of
user-interface guidelines, describing how OS/2 menus and scrollbars
work and the common guidelines for use of F-keys and mouse clicks.
I think that some people in IBM (at least the author) expected to
define all GUI's for the rest of time.

It didn't work. It was about that time that GUI acceptance moved from
a small band of first-adopters (the Mac users) to a larger band of
sheep (the Microsoft users). [No offense intended -- I include myself
in the latter category.] Which meant that program vendors were just
starting to explore the GUI world for their own use. Which meant that
they were blazing new trails, either because they had to face
problems not dealt with in the CUA, or (more often) because they
didn't like what IBM had written. Many vendors tried to distinguish
their software by looking better or being easier to use than their
competitors; in other words, they ignored the CUA (if they even had
it!)

But that was then; surely by now most interactive platforms have a
GUI available, right? But no, we're still not ready for this.

There are differences in hardware. What keys are there on the
keyboard? Besides CTRL and SHIFT, what other "combination" keys
are there? If CAPS LOCK is on, does SHIFT+A produce a lower-case
'a'? How do we accept key combinations that don't have ASCII
codes, such as ALT+Z? How many F-keys can we assume all users
have, and what's the maximum that they might ever have? How many
buttons on the mouse? Does heavy I/O or computation cause the
mouse or other concurrent programs to freeze? What's the
"Standard" minimum screen resolution and number of colors? What's
the real screen resolution right now? Is there more than one
screen for this single user? Can the user change screen
resolutions or maximum colors while the program is running?
Do I need a semaphore or other lock when I do [insert difficult
programming task here]? These questions all have different answers
on different platforms.

There are differences in conventions. What key is usually associated
with Help? Are there other commands that users will expect to be able
to use, and be disappointed if they're missing? Where does the menu
go and what does it look like? How do you install the program; how do
you start running it? Should we use the "flat look" or the "3d look"
or the "3d-chiseled look" or something else? Does the system supply
some sort of standard help-file mechanism? Is it possible to send two
different files to the printer at the same time, without getting the
output mixed together? Does program loading take long enough to make
a "now loading" message meaningful? Can I disable and re-enable any
screen saver, or at least 'wake it up'? These questions all have
different answers on different platforms.

Any attempt to standardize a GUI will have to answer all of these
questions for all platforms, including ones you've never heard of,
in a way that doesn't favor one vendor over another. That's a very
tall order.

----
Allan_W@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own
---
[ 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              ]

In article <7cp60f$40o$1@nnrp1.dejanews.com>, AllanW@dejanews.com
says...

[ ... ]

> It's been done. In the "good 'ol days" when IBM and Microsoft were
> best friends, IBM issued a guidebook called something like "CUA:
> Common User Access guidelines." They defined thousands of
> user-interface guidelines, describing how OS/2 menus and scrollbars
> work and the common guidelines for use of F-keys and mouse clicks.

...and this was far from the first time.  There was (at one time) a
set of UI guidelines for the Lilith, one of the first graphics
workstations ever (for those who don't remember, Modula II was
invented in conjunction with the Lilith project).

> I think that some people in IBM (at least the author) expected to
> define all GUI's for the rest of time.

I doubt it.

[ ... ]

> But that was then; surely by now most interactive platforms have a
> GUI available, right? But no, we're still not ready for this.

Despite this, virtually every GUI vendor has a set of UI guidelines,
which gets updated quite regularly.  E.g. for Windows, MacOS, Motif,
etc.  As you'd probably guess, Motif's tries to take different
hardware into account the most, and Apple's takes it into account the
least.  E.g. Motif's recommends a 3-button mouse, but has guidelines
for what to do when there are only two.  MS's assumes there'll be two
mouse buttons, and with suggestions for how to make things accessible
without a mouse, and (IIRC) perhaps even a few suggestions on how to
use the third mouse button if there is on.  As far as Apple cares,
every computer on earth has a mouse with exactly one button...

> Any attempt to standardize a GUI will have to answer all of these
> questions for all platforms, including ones you've never heard of,
> in a way that doesn't favor one vendor over another. That's a very
> tall order.

For anybody who cares, the most recent Motif version I have is ISBN 0-
13-643123-2, which is the "OSF/Motif Style Guide, Release 1.2".
That's a couple of years old, so there may be a newer version -- I'm
not sure.  In any case, if somebody wants to standardize this sort of
thing, that's probably as good of a base document as any, and better
than most.  OTOH, I certainly hope they _don't_ contemplate doing this
as part of the C++ standard...
---
[ 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              ]

simon wrote:

> A Standard Graphics Library...
>
> I think 99% of people will say that not all computers have a graphics
> display - so there could be no such thing.
>
> However, from a coders perspective 99% of customers want a GUI with
> all the features of a 'modern' (motif/mfc) windowing system.
>
> There are lots of good (but DIFFERENT) libraries out there, all do
> much the same thing, and function in a very similar manner, with a
> similar set of 'common controls'.

There already exist graphics standards called PHIGS and PHIGS+;I don't know
if these meet your requirements.

If you are going to create a new standard, I personally would prefer
that this standard be clean and simple, i.e. contain only the minimum
set of basic operations required to perform common graphics
operations.  More complex operations could then be created as needed
from this basic set of building blocks.  Keeping things simple will make
the standard graphics library much easier to learn and use.

Having various parameters default to sensible, well-thought-out values
can potentially greatly reduce the number of these parameters that
users of the library need to know about and explicitly specify.  This also
improves ease of use.

On the other hand, it should be flexible enough that people seldom have
to code their own replacements for the standard classes.  For example,
library routines for drawing shapes such as rectangles and ellipses are
often  limited to drawing these only in the horizontal or vertical
orientations.  If you want to draw them rotated at arbitrary angles, you
have to write your own routine.  This limitation makes these routines
useless for many common applications such as rendering 3D scenes
seen from arbitrary viewpoints.

Initially, the standard library could be implemented in terms of existing
systems such as X windows or Borland's Object Window Library.
But it would be better if vendors adopted the standard for the graphics
libraries they shipped with their C++ compilers.

--- Brian



[ 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              ]

simon wrote:

> A Standard Graphics Library...

Sounds good, but I don't think it is particularly in the purview
of the C++ standard.

There are a number of standard graphics libraries, and even some
that are object oriented.

--
Andy V (OpenGL Alpha Geek)
"In order to make progress, one must leave the door to the unknown ajar."
Richard P. Feynman, quoted by Jagdish Mehra in _The Beat of a Different Drum_.




[ 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              ]

In article <36e554a8.3420448@news.supernews.com>,
  gv19@dial.pipex.com (simon) wrote:
> A Standard Graphics Library...
>
> I think 99% of people will say that not all computers have a graphics
> display - so there could be no such thing.

Not all computers have floating-point coprocessors, either. And yet
there are standards on floating-point representations.

> However, from a coders perspective 99% of customers want a GUI with
> all the features of a 'modern' (motif/mfc) windowing system.

I'm not sure it's anywhere near 99%, but your point is well taken.

> There are lots of good (but DIFFERENT) libraries out there, all do
> much the same thing, and function in a very similar manner, with a
> similar set of 'common controls'.

Similar needs, different and incompatible implementations. If anything
deserves a standard, this does.

> Traditionally any GUI is made up of 'Containers' (forms,dialog
> boxes,menubars), 'Widgets' (buttons,text boxes), and the engine for
> handling events, dispatching redraws, drag & drop etc..

I doubt that STL Containers are the right model for this concept.

> The question is, is it possible to translate the function into the
> Container/Iterator/Algorithm based approach of the stl?

That concept is not appropriate for the interaction between on-screen
elements (forms, windows, widgets, et. al.).

> The simplest way to think of it would be to make all 'Widgets'
> containers.

Let them be the head of their own derivation tree.

> Some methods may be redraw(), redraw_region(),
> add_object(). Those are all very simple, it gets more tricky when
> widgets become sash bars (dividing window panes) - here the widget
> must recieve & despatch events up through its container, we also touch
> the subject of 'is a scrolled window a type of window or a window
> containing 2 scrollbars?' (borand .vs. MFC).

As existing art shows, either way is acceptable -- so long as the
decision is consistent throughout.

> For me I hate endless derivation, the Ilog views library
> (www.ilog.com) has seemingly infinite levels. I hate to think about
> the overhead this creates in function tables :(

I don't know the Ilog views library.

Since virtual function tables are quite small, and are not maintained
directly by the programmer, complexity there is of little concern.

> Let's get everything sorted out at compile time.
>
> So our containers become widgets, our events become iterators, our
> event driver & management system (c.f. Ilog interactors) are the
> algorithms. (and the event queue knows about the 'this' pointer).
> Want to be able to pick up that button & drag it onto the text box?
> No problem.

Just as the library has containers, iterators, and algorithms, it
would also have windows, forms, widgets, and events. It might have
a heirarchy similar to this:

    Window (Size, position, visible, menu)
    |__ Form (event handler, container of 0 or more widgets)
        |__ Widget (notifies parent form about events)
            |__ Button
            |   |__ Push Button
            |   |__ Radio Button
            |   |__ Check box
            |__ Text box
            |__ List box
            |__ Scroll Bar
            |__ Lots more, I'm sure

> So why the post to c.s.c++ ? Well I didn't want to start hacking until
> at least one other person thinks its a good idea.
> Where will I start?
> The Athena Widgets of course!

I'm not familiar with this.

If you're going to get people to adopt your GUI as a standard, you will
have to make people believe that:

   * There's not already a standard
     (is X-Windows a standard? I know very little about it...)
   * We need a standard (I'm with you on this, but it will be a hard sell)
   * It's worth all the time, effort, and money that will need to be spent
   * The standard won't bias towards or against any particular company
     (i.e. if your purpose is to "knock MFC off it's pedestal" you're
      doomed to failure)
   * The new standard can be implemented almost everywhere (not just on
     whatever brand of computer you happen to use)
   * No one company will profit from this directly (i.e. if Athena is
     copyrighted, either get permanent rights to use it for free or do
     NOT use it as a base!)

One simple 8-step plan to accomplish all of this is:
  1. Write the first version yourself. Be sure it's high quality (this
     is essential for steps 2-???).
  2. Make it public domain. Give out free copies to anyone that wants it.
  3. convince a lot of people to use it on their projects.
  4. Port it to several other systems (or have someone else port it). Be
     sure to include the latest features in all of the platforms, including
     the original one.
  5. Make the ports public domain. Give out free copies to anyone that
     wants it.
  6. Convince a lot of people to use the ports on their projects, especially
     (but not exclusively) those that were written on the original system.
  7. Convince several large compiler vendors (or MANY smaller compiler
     vendors) to bundle your library with their products. Convince even more
     people to use it.
  8. Suggest to ISO that they standardize it, in order to reduce the number
     of incompatibilities.

Simple, no? This is not the only possible 8-step plan, of course.

> simon
>
> p.s. do a search for 'Linfile' on altavista for my Xlib based GUI
> modelled on Windows that needed a c++ widget set - so I gave up :|
>
> p.p.s. Lots of seemingly obvious containers have been left out of the
> STL, I've written a hash_map & a 'muti_tree' (my name for a tree with
> any number of branches), the muti_tree comes with a stack (sic) of
> iterators. Are these too specialised for stl?

One reason why hash_map and other useful containers weren't included in
the standard is that the participants were feeling a lot of time pressure.
However, the STL is extensible, so it's easy to add a hash_map of your own.
I'm not sure if muti_tree would be considered general purpose, and I
certainly wouldn't call it a "seemingly obvious container." But if you
find a use for it, there's no reason not to go ahead and use it!

----
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


[ 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              ]

A Standard Graphics Library...

I think 99% of people will say that not all computers have a graphics
display - so there could be no such thing.

However, from a coders perspective 99% of customers want a GUI with
all the features of a 'modern' (motif/mfc) windowing system.

There are lots of good (but DIFFERENT) libraries out there, all do
much the same thing, and function in a very similar manner, with a
similar set of 'common controls'.

Traditionally any GUI is made up of 'Containers' (forms,dialog
boxes,menubars), 'Widgets' (buttons,text boxes), and the engine for
handling events, dispatching redraws, drag & drop etc..

The question is, is it possible to translate the function into the
Container/Iterator/Algorithm based approach of the stl?

The simplest way to think of it would be to make all 'Widgets'
containers. Some methods may be redraw(), redraw_region(),
add_object(). Those are all very simple, it gets more tricky when
widgets become sash bars (dividing window panes) - here the widget
must recieve & despatch events up through its container, we also touch
the subject of 'is a scrolled window a type of window or a window
containing 2 scrollbars?' (borand .vs. MFC).

For me I hate endless derivation, the Ilog views library
(www.ilog.com) has seemingly infinite levels. I hate to think about
the overhead this creates in function tables :(

Let's get everything sorted out at compile time.

So our containers become widgets, our events become iterators, our
event driver & management system (c.f. Ilog interactors) are the
algorithms. (and the event queue knows about the 'this' pointer).

Want to be able to pick up that button & drag it onto the text box?
No problem.

So why the post to c.s.c++ ? Well I didn't want to start hacking until
at least one other person thinks its a good idea.

Where will I start?
The Athena Widgets of course!

simon

p.s. do a search for 'Linfile' on altavista for my Xlib based GUI
modelled on Windows that needed a c++ widget set - so I gave up :|

p.p.s. Lots of seemingly obvious containers have been left out of the
STL, I've written a hash_map & a 'muti_tree' (my name for a tree with
any number of branches), the muti_tree comes with a stack (sic) of
iterators. Are these too specialised for stl?
---
[ 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              ]