🚀 go-pugleaf

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