🚀 go-pugleaf

In article <C1zv2w.63L@csisun.uucp>, jburnes@csisun.uucp (Jim Burnes) writes:
|> 
|> I have an idea.  Its probably already been thought of.  Why
|> don't we as developers come up with a POSIX/ISO/IEEE portable
|> class library for GUI's.  
|> Suggest away...
|> 
|> Jim Burnes
|> jburnes@compusci.com

This sounds like an excellent idea for GNU!

Jacob

The model (even if practice doesn't live up to it) for IEEE and other
formal standards is to codify existing practice.  I don't think
there's enough existing practice out there to standardize on yet.
There are some commercial products (e.g. XVT, Galaxy, and Galaxy is
supposed to be the most 00-like) but in the absence of reasonable
experience with existing practice, I believe formal standardization to
be premature.

				dave
p.s.  taking a hint from Henry Spencer, imagine what things would be
like if OS-360 had become the standard operating system...

In article <1993Feb10.083156.5298@latcs1.lat.oz.au> jacob@latcs1.lat.OZ.AU (Jacob L. Cybulski) writes:
>In article <C1zv2w.63L@csisun.uucp>, jburnes@csisun.uucp (Jim Burnes) writes:
>|> 
>|> I have an idea.  Its probably already been thought of.  Why
>|> don't we as developers come up with a POSIX/ISO/IEEE portable
>|> class library for GUI's.  
>|> Suggest away...
>|> 
>|> Jim Burnes
>|> jburnes@compusci.com
>
>This sounds like an excellent idea for GNU!

From what I am given to understand, GNU very much wants to do a GUI, however
they think that if they do, Apple will sue. This is part of the reason for
the FSF boycott of Apple products.

In article <EMERY.93Feb10103958@goldfinger.mitre.org> emery@goldfinger.mitre.org (David Emery) writes:
>The model (even if practice doesn't live up to it) for IEEE and other
>formal standards is to codify existing practice.  I don't think
>there's enough existing practice out there to standardize on yet.
>There are some commercial products (e.g. XVT, Galaxy, and Galaxy is
>supposed to be the most 00-like) but in the absence of reasonable
>experience with existing practice, I believe formal standardization to
>be premature.

There are so many questions to ask before standardizing anything. First and foremost is
what do you want to standardize?

For example XVT provides portability of certain widgets (menus, buttons, lists boxes). 
Galaxy on the other hand defines a wider range of portable functionality: widgets, but also 
drawing (in this case display postscript), a 2.5D object oriented graphics facility, 
run-time and persistent B-Trees, file I/O, exception handling, and on and on.

Do you want to standardize an interface to a certain set of widgets or do you want to
standardize everything that Galaxy covers? And why?
--
Posted for patl@goldfish.mitron.tek.com

In article <1993Feb10.161418.5930@netcom.com> jimlynch@netcom.com (Jim Lynch) writes:
>In article <1993Feb10.083156.5298@latcs1.lat.oz.au> jacob@latcs1.lat.OZ.AU (Jacob L. Cybulski) writes:
>>In article <C1zv2w.63L@csisun.uucp>, jburnes@csisun.uucp (Jim Burnes) writes:
>>|> 
>>|> I have an idea.  Its probably already been thought of.  Why
>>|> don't we as developers come up with a POSIX/ISO/IEEE portable
>>|> class library for GUI's.  
>>|> Suggest away...
>>|> 
>>|> Jim Burnes
>>|> jburnes@compusci.com

C'mon, haven't we already learned from POSIX what a screw standards are
when they standardize things that aren't well thought-out to begin with?
It's not time to standardize GUI interfaces yet (user, programmer, or
otherwise).

>From what I am given to understand, GNU very much wants to do a GUI, however
>they think that if they do, Apple will sue. This is part of the reason for
>the FSF boycott of Apple products.

We can't develop a GUI that looks like Apple's, but we do want to write a
desktop (one which we think will be better than Apple's anyway).  This
project is waiting while the staff complete certain other projects first
(like Emacs 19). 

In article <C1zv2w.63L@csisun.uucp>, jburnes@csisun.uucp (Jim Burnes) writes:
> 
> I have an idea.  Its probably already been thought of.  Why
> don't we as developers come up with a POSIX/ISO/IEEE portable
> class library for GUI's.  

IEEE working group P1295.2 is working on the Open Toolkit Environment,
which is basically a Standard for the OLIT (Open Look Intrinsics Toiolkit)
API.  There is another group (P1295.1?) doing the same for Motif.

You may or may not believe that these toolkits are portable, 
object-oriented, good, elegant, modern, useful, etc.

Bryan Boreham
Alex Technologies Ltd

Noah Friedman writes:

   C'mon, haven't we already learned from POSIX what a screw standards are
   when they standardize things that aren't well thought-out to begin with?

Let me guess: you never had the misfortune of working with/involved in
CCITT [those color-coordinated books that brought you X.400 and X.500]
and/or ISO standards, have you? :-) :-6

oz
---
It is hard to ridicule reality when  | electric: oz@sis.yorku.ca
reality itself is so ridiculous.     | ph: [416] 736 2100 x33976

In article <1993Feb11.132609.21497@alex.com> bryan@alex.com writes:
>IEEE working group P1295.2 is working on the Open Toolkit Environment,
>which is basically a Standard for the OLIT (Open Look Intrinsics Toiolkit)
>API.  There is another group (P1295.1?) doing the same for Motif.

Tcl/Tk, which is free software, is designed to resemble the look and
feel of Motif (though there are, at present, many deviations, it is
getting closer all the time).

In the past I've seen messages from GNUites saying "Don't use Motif".
But you don't need to use Motif, or pay anyone for a Motif license, to
use the good ideas in it, as the OSF is not attempting to assert that they
own the look-and-feel (only the Motif software).



--
Joe Buck	jbuck@ohm.berkeley.edu

>>>>> On Fri, 5 Feb 1993 21:16:08 GMT, jburnes@csisun.uucp (Jim Burnes) said:

> I have an idea.  Its probably already been thought of.  Why
> don't we as developers come up with a POSIX/ISO/IEEE portable
> class library for GUI's.  

Why do you need/want an official standard? Are you aware of
InterViews, originally implemented at Stanford, nowadays sponsored by
SGI as the basis for an X consortium C++ GUI toolkit?

It is freely available, it's here today, and it works. The biggest
problem it has today is a lack of documentation (tutorials etc.).
Another problem is the changes in the library between the releases
(*BIG* changes between IV-2.6 and IV-3.0, smaller but often confusing
changes between IV-3.0 and IV-3.1).

- Steinar

emery@goldfinger.mitre.org (David Emery) writes:

>The model (even if practice doesn't live up to it) for IEEE and other
>formal standards is to codify existing practice.  I don't think
>there's enough existing practice out there to standardize on yet.
>There are some commercial products (e.g. XVT, Galaxy, and Galaxy is
>supposed to be the most 00-like) but in the absence of reasonable
>experience with existing practice, I believe formal standardization to
>be premature.

Beyond that, you must realize that a portable application like XVT compared to
something written in native Motif or MS Windows simply cannot compare. How do
you compensate for its shortcomings?


IMHO you will *never* see a truly portable GUI for the same reasons you will
*never* see a truly portable OS (don't even _thing_ about saying *nix). The
best we'll ever be able to hope for is ONE GUI for each OS (Motif on Unix,
MS Windows on DOS, PM on OS/2, etc).


-- 
+-------------------------------+---------------------------------------------+
| Kevyn B. Ford			| 	 kevyn@kodak.com (main)    	      |
| Eastman Kodak Company		|	 kevyn@world.std.com (secondary)      |
+-------------------------------+---------------------------------------------+

In article <C2B1z0.6w4@world.std.com> kevyn@world.std.com (Kevyn Ford) writes:

|
|   emery@goldfinger.mitre.org (David Emery) writes:
|
|   >The model (even if practice doesn't live up to it) for IEEE and other
|   >formal standards is to codify existing practice.  I don't think
|   >there's enough existing practice out there to standardize on yet.
|   >There are some commercial products (e.g. XVT, Galaxy, and Galaxy is
|   >supposed to be the most 00-like) but in the absence of reasonable
|   >experience with existing practice, I believe formal standardization to
|   >be premature.
|
|   Beyond that, you must realize that a portable application like XVT
|   compared to something written in native Motif or MS Windows simply
|   cannot compare. How do you compensate for its shortcomings?
|
|   IMHO you will *never* see a truly portable GUI for the same reasons you will
|   *never* see a truly portable OS (don't even _thing_ about saying *nix). The
|   best we'll ever be able to hope for is ONE GUI for each OS (Motif on Unix,
|   MS Windows on DOS, PM on OS/2, etc).
---
While opinions are always interesting, it is conventional to provide at
least a little bit of evidence or experience to support them.  What
shortcomings of portable GUI toolkits did you have in mind?  Certainly
there are quite a few people working on building them and there quite a
few major corporations and organizations using them to build portable
applications.  Those applications seem to meet the needs of those
organizations quite nicely, with the tremendous advantage of being
portable across the major platforms.  In fact, I think some people would
argue that those portable applications in some cases obey the GUI style
guides better than some applications built using the native style guides.
This is not surprising, since the look and feel is being regulated by
the toolkit and the application developer is being constrained to
expressing the application in look-and-feel-independent terms.

I have heard people describe things they said could not be done in a
portable GUI toolkit and which they felt were essential to providing a
quality application.  In most cases they were describing things they had
to do *because the native toolkit was broken or inadequate*.  I find
that a weak argument for the superiority of the native toolkits; in many
cases the portable toolkits have avoided those problems or have filled
in gaps in ways that are nicely portable across platforms.

The point of your second paragraph is equally obscure.  Either you meant
to knock the idea of a portable operating system API (like POSIX), which
seems pretty goofy, since there are quite a few implementations of the
POSIX API and there are real, portable programs written to that API to
prove that it does work, or you meant that UNIX is too hard to port to
call it portable.  The latter statement is, of course, un-testable, in
the absence of a definition of portability, so it's not very interesting
even as opinion.  Certainly UNIX is a lot more portable than most other
operating systems have, historically, been.  Certainly future operating
systems will be more portable.

Of course, a more interesting question is "what is an operating system."
Most of the modern standards are being written as APIs or ABIs based on
application execution environments.  Is the operating system the outer
interface, used by binary applications?  It's possible to implement UNIX
as one or more servers and/or libraries on top of a micro-kernel.  The
micro-kernel is much more constrained and helps isolate the
machine-dependencies such that it is, typically, *much* easier to port
to different hardware.  The outer shell of libraries and servers may
then be extremely portable, possibly even as binaries.  Applications, of
course, don't care whether an API turns into a trap, a library routine,
or a message.

My opinion is possibly biased, since I'm chairing an IEEE standards
working group (1201.1) working on producing a specification for a
uniform API for GUI programming.  Contrary to Dave Emery's opinion, I
believe that there is quite a lot of existing practice; what there is
not is a single, common existing practice.  However, most of the
existing products have a lot in common, architecturally; 1201.1 is trying
to take that core practice and express it as a language-independent
specification and a C API instantiating the specification.

scott
--
scott preece
motorola/mcg urbana design center	1101 e. university, urbana, il   61801
uucp:	uunet!uiucuxc!udc!preece,	 arpa:	preece@urbana.mcd.mot.com
phone:	217-384-8589			  fax:	217-384-8550

Jacob L. Cybulski writes:
>In article <C1zv2w.63L@csisun.uucp>, jburnes@csisun.uucp (Jim Burnes) writes:
>|> 
>|> I have an idea.  Its probably already been thought of.  Why
>|> don't we as developers come up with a POSIX/ISO/IEEE portable
>|> class library for GUI's.  
>|> Suggest away...
>|> 
>|> Jim Burnes
>|> jburnes@compusci.com
>
>This sounds like an excellent idea for GNU!
>
>Jacob

The model that Jim Burnes suggests is most like that of the Object
Management Group, a consortium of a few hundred companies, both
clients and vendors. They have an entire object-oriented reference
architecture and are building the standards step-wise. They have
completed their object request broker (CORBA) standard and are
working on v.2 of that, and are working on object model, standard
object services, C++ bindings, etc. as well.

There are many arguments about the success and failure chances of
organizations like the OMG, the quality of what they produce, and
the both the quickness of response and the likelihood of cooperation,
both pro and con. GUI interoperability standards are on their list,
however.

--
Edward Jung, Software Architect     edwardj@microsoft.com
Advanced Systems, Microsoft Corp.