Proposed standard GUI: Update 1

Proposed standard GUI: Update 1

[Nick Roberts]

First, my apologies for not making any noise sooner than this: as ever, time
is not my own!

Second: many thanks to the people who have replied to my original posting,
by e-mail and to this newsgroup. I am happy to say that I have received five
e-mail messages expressing support - for which, very many thanks - and a
further message with suggestions. Thanks also to Tony Lowe (Rockwell
Collins). Anyone else who might wish to help (or who has a comment or
suggestion): please e-mail me!

Various existing systems have been suggested as a base: TeleUSE/TeleWindows
(TeleSoft); UIMS; Screen Machine (OIS); Fresco; Qt (TrollTech); TASH, based
on Tcl/Tk; Java JNI; Java AWT; Chiron; Amulet; Claw (R&R); and OpenGL/GLUT.
Also the DGJPP mailing list has been mentioned, as well as the comp.graphics
newsgroups.

More than one contributor has suggested the benefits of using a proprietary
system (such as Claw, for example). It seems to me, however, that one of the
things a putative standard must be is non-proprietary. Would R&R Systems be
willing to allow the interface (not the implementation) of Claw be used
freely by their competitors? If so, then fair enough; otherwise, no game,
surely (comments invited)?

I haven't been able to check out all of the above ideas, but I have looked
at many of them, and I present my initial ideas here. Note that I am very
much open to criticism and/or expansion in these comments.

*** TeleUSE ***
This is an interface building software suite, for Ada, aimed (primarily at
least) at the OSF/Motif environment. This system is proprietary, but it
could serve as a useful base, should the owners (TeleSoft) be willing.

*** Screen Machine ***
Similar comments apply to this as for TeleUSE. Narrower in scope, I think,
than what we require.

*** Amulet ***
A sponsored university venture to design a GUI specifically for Ada. A
slightly eclectic design, possibly, but Amulet could serve as a good base.
Seems to have run out of funding, now, so it is not in a completely finished
state yet.

*** TASH, Tcl/Tk ***
TASH is a way for Ada programs to call upon the graphics library used by
Tcl/Tk. For systems with Tcl/Tk, this is great; for systems where this is
not practicable (e.g. a turn-key application), it is not helpful. I think
Tcl/Tk could be regarded as one environment for us to support, but only one
of many.

*** Java JNI ***
I think this option has been overtaken by Java AWT (see next).

*** Java AWT ***
This is for Java what we are trying to achieve for Ada. I have taken a
(moderately) close look at AWT. It could certainly serve as a very good
base, but it is not perfect: it is somewhat limited in some respects; it
does not provide for low(er)-level access to graphics devices; it is,
naturally, C++ idiomatic, and would be somewhat awkward if translated
directly to Ada.

I don't think that re-use of AWT libraries (in source or compiled form)
should be a priority consideration for our standard: Ada programs which use
a GUI will span a much broader spectrum of environments than Java AWT, from
embedded process-control systems (e.g. Nuclear power stations!) to
workstations front-ending supercomputers. I think we need to concentrate on
ensuring that our standard has the flexibility to encompass these kinds of
application, otherwise it is not likely to gain the widespread acceptance
that is (I think) our goal.

*** Claw ***
This is a 'thick' binding to the Windows (Win32, I think) API, including the
(large) section of it devoted to the Windows GUI environment. As such, it is
relatively Windows-specific. This needn't be such a great problem, since the
Windows interface is slightly higher-level than most others (e.g. XWS), most
(but not quite all) Windows dingen can be implemented on the others (I think
this is/was essentially the idea behind Motif).

However, Claw, though it may be inexpensive, is a proprietary product.

**~~~**

I shall be investigating (briefly) the other systems as soon as I can.

In the meantime, I hope to be putting up my own skeletal design for this
proposed standard onto a WWW site very soon (the next few days, hopefully).
I can't make any guarantees on the time-scale, though: as ever, time is not
my own! Please bear with me.

All the best,

--
Nick Roberts
ThoughtWing Software, Croydon, UK
ThoughtWing@dial.pipex.com

Re: Proposed standard GUI: Update 1

[Tom Moran]

As developers of Claw, we would be interested in cooperation for the
creation of a standard Ada GUI.  We've looked a bit at the issues
involved, and concluded that an abstraction layer higher than the
current Claw bindings would be required.

Therefore, we don't think that the use of Claw as it is currently
designed would be appropriate for this task.

On the other hand, an interface designed following the same
principles as Claw (see our Tri-Ada '97 paper at www.rrsoftware.com
for details) would be an admirable goal.  We have no objection to
"borrowing" those principles for a new design.  In any case, we
think any such GUI interface should be designed using Ada 95 for
maximum portability, and most of the products on your list were not
designed for Ada 95.  That makes Claw one of the best choices for a
starting point.

We have kept Claw proprietary to this point mainly because we felt
that we needed to keep control over its evolution in order to keep a
common vision for its design.  Once the binding is mature enough
that frequent enhancements are no longer needed, we intend to look
at the possibility of making some or all of it public.

It is difficult to hide the underlying OS API and at the same time
create programs which appear to users to have the 'style' of a
particular OS.  For some users, this doesn't matter.  But for anyone
whose applications are to be used by ordinary end-users as opposed
to the developers themselves, this is a requirement.  We've been
made even more aware of this with the Claw GUI builder program,
where some of the most common complaints from early testers were
about missing Windows-specific features.  Claw was designed with an
emphasis on creating programs with a 'Windows style'.

It would certainly be desirable from a programmers viewpoint to have
a GUI as OS-independent as possible.  Even if conflicting goals make
perfection impossible, work in that direction could produce good,
useful products for the short term, and valuable conceptual
understandings for the long term.  We think it's reasonable to
strive toward such a goal.

Randy Brukardt
Tom Moran

Re: Proposed standard GUI: Update 1

[Chip Richards]

I suppose I should chime in on this thread, as I am working on a related
project.

In article <6jhras$pbm$3@plug.news.pipex.net>,
	"Nick Roberts" <Nick.Roberts@dial.pipex.com> writes:

> First, my apologies for not making any noise sooner than this: as ever, time
> is not my own!

A common affliction.  I suffer from it myself. <grin>

> Various existing systems have been suggested as a base: TeleUSE/TeleWindows
> (TeleSoft); UIMS; Screen Machine (OIS); Fresco; Qt (TrollTech); TASH, based
> on Tcl/Tk; Java JNI; Java AWT; Chiron; Amulet; Claw (R&R); and OpenGL/GLUT.
> Also the DGJPP mailing list has been mentioned, as well as the comp.graphics
> newsgroups.

I think it's a positive step to survey the existing offerings.  I doubt that
any of them will prove fully suitable, but knowing what the field offers is
essential.  We might someday hope to see a high-level abstraction that uses a
variety of existing toolkits as its "back-end", in the manner of WxWindows.
But the first cut (and possibly the only cut) should probably be stand-alone.

> In the meantime, I hope to be putting up my own skeletal design for this
> proposed standard onto a WWW site very soon (the next few days, hopefully).
> I can't make any guarantees on the time-scale, though: as ever, time is not
> my own! Please bear with me.

I look forward to seeing the announcement.

The reason I'm writing is that I'm working on a bit of an Ada GUI toolkit
myself.  It's an Ada translation of Steve Baker's "PUI", which is a more
advanced follow-up to SGI's "MUI", a widget set based on OpenGL and GLUT.

The advantage of the PUI design is that it is based on OpenGL, which is highly
portable--OpenGL (and GLUT) implementations exist for most Unix platforms, as
well as Microsoft OS's and (to some extent, at least) OS/2, Mac, and others.

The disadvantage of PUI is that it is based on OpenGL, which is a bit of
overkill if you are not doing 3D graphics, or are doing them without using
OpenGL.  It's also quite basic, not nearly as full-featured as most of the
others you've mentioned above.

My conversion is coming along quite nicely, although I'm having some
difficulty figuring out how to structure the packages due to inexperience with
OO under Ada.  I've gotten some good help from David Hoos, and will probably
need more before I'm through.

The code (both the original C++ PUI and the Ada conversion) is public domain,
so it's available for all to do with as they wish.  For reference, Steve's
original PUI web page is "http://web2.airmail.net/sjbaker1/pui/".  My Ada PUI
development page is "http://www.niestu.com/languages/oglada/apui/apui-dev.html". 

I don't see PUI serving as a general-purpose widget set, but it's small,
cheap, and will be ready to use shortly.  I plan to follow your project
closely, to see how much cross-pollination is possible.

-- 
Chip

Re: Proposed standard GUI: Update 1

[Matthew Heaney]

In article <6jhras$pbm$3@plug.news.pipex.net>, "Nick Roberts"
<Nick.Roberts@dial.pipex.com> wrote:

>Various existing systems have been suggested as a base: TeleUSE/TeleWindows
>(TeleSoft); UIMS; Screen Machine (OIS); Fresco; Qt (TrollTech); TASH, based
>on Tcl/Tk; Java JNI; Java AWT; Chiron; Amulet; Claw (R&R); and OpenGL/GLUT.
>Also the DGJPP mailing list has been mentioned, as well as the comp.graphics
>newsgroups.

You may also want to look at Yet Another C++ Library (YACL).  I think he
incorporated stuff to do platform independent GUI programming.

<http://www.cs.sc.edu/~sridhar/yacl/>

Maybe you could borrow some of the ideas.

Matt

Re: Proposed standard GUI: Update 1

[Michael Erdmann]

I am missing the C-2 (or Chiron 2) approach of building GUI. Within this
approach a component method is used which is worthwhile analyzing it.
Making up a clear component and application concept is one of the
key factors for success of this idea, because it will assure reuseability
and extendebility in longer terms.

M.Erdmann