🚀 go-pugleaf

I love these sorts of discussions - take this not as an official policy
statement from Symantec, but rather "Will's ramblings..."

In article <Dq0rq5.9sz@unify.com>, lee@Unify.com (Lee Crocker) wrote:

> Sun's current attitude about AWT offers little hope.  They seem to
> think that they can achieve portability by making AWT a subset of the
> functionality of existing GUIs; but that attitude is backwards.  To be
> truly portable, it must be a superset of existing GUIs, emulating those
> functions specific to each on the others in a portable way, and letting
> developers query the system for its capabilities in a portable way.

Well, I completely disagree.  ;)

There was a certain project some time ago which attempted to pull off
exactly what you're describing.  It was called Bedrock, and more money
than you can possibly imagine was blown on it (this was before my time -
it has since metamorphed into ODF).  The scope of what you're talking
about is *massive*.  

Consider for a moment that the Mac has QuickDraw GX, drag & drop between
applications, QuickDraw3D, QuickTime, Open Transport (AppleTalk & TCP/IP),
Apple Guide, AppleScript/AppleEvents, OpenDoc, etc, etc, etc.  To do a Mac
app "right" and retain full crossplatform compatibility, you'd have to
implement all of these technologies on Windows.  You'd never ship such a
framework.

There is no reason that a developer couldn't build an application with
Java which checked at runtime what kind of machine it ran on and did
conditional branching depending on the results.  The Java application (you
probably wouldn't want to do this with an applet) could load native
libraries and make native system calls.

> There is never any excuse to sacrifice functionality for portability.
> Ever.  Users demand--and rightly so--that they be able to take full
> advantage of every dollar they've spent on their hardware and software,
> and if they hear "well, we could do that but it wouldn't be portable"
> from a vendor, they'll go to a vendor that will do it non-portably.

You're thinking in terms of commercial shrinkwrapped software.  The
current implementation of the AWT is quite adequate for Web page applets
(the primary attraction) and inhouse custom application development (most
likely deployed as client apps via the web).  I'll gloss over
nontraditional boxes such as the Pippin or Newton.

As a reallife example of this, I wrote a small application for internal
use to generate UserIDs and passwords for our secure server.  It's just a
small console app.  I used to build two versions, a Mac version and a PC
version.  From the high level language perspective, there's absolutely no
reason for having to build two versions - this app doesn't do *anything*
that really requires multiple builds beyond the simple incompatibility of
the x86 and the 680x0.  With Java, I just build it once and can post it to
a web server behind the firewall.

As an aside, before Java, this would be a classic argument against having
Macs (or Windows boxes or Unix boxes, depending on where you stand) in
your group - too much work to support muliple platforms.  With Java, I can
use my Mac, you can use your Windows box, and the guy down the hall can
use his Linux box.

> The only way to ensure portability, therefore, is the ensure that a
> portable program is capable of doing everything the software needs 
> to do, and AWT doesn't even come close.  The glaring omissions for
> me are things like right-button popup menus, native video support
> (for example, being able to query the system for its color capabilities
> and things like monitor gamma, and then optimizing my diplay for it),
> portable virtual keys for things like arrow and cut/paste, better
> font metrics, and about 1000 more system properties.

Actually, you can check for right mouse button clicks (see snippet below).

The other "glaring omission" is exactly what I was referring to earlier. 
I would hazard that less than one in a hundred developers are going to
care about the monitor gamma for display optimization.  Is this something
that is really *vital* to be in a crossplatform framework?  In a word,
NO.  If your application requires this sort of detail, develop a native
interface and hook into that.

The next year will be defined not just by which OS is superior, but which
has the best implementation of Java.  I wouldn't be suprised to see future
OS reviews include Java benchmarks.  The nirvana we are shooting for is to
let each user select the OS they prefer (for OS specific features and
applications), but to not be hampered by a lack of the mundane apps they
are required to use.

My 2 cents.

-Will


from D'Arcy Smith, one of our Java engineers...

/*** Begin snippet ***/
//    the following was "stolen" off of DejaNews... (sorry don't know who to 
//     give credit to):
     
//      This is how I distinguish mouse button clicks:
     
      public boolean handleEvent(Event evt) {
     
        switch(evt.id) {
     
      case Event.MOUSE_DOWN:
       if (evt.modifiers == evt.CTRL_MASK) {
        System.out.println("Right button pressed");
       } else {
        if (evt.modifiers == evt.ALT_MASK) {
         System.out.println("Middle btn pressed");
        } else {
         System.out.println("Left button pressed");
        }
       }
       return true;
      }
         }
          return super.handleEvent(evt);
     }
/*** End snippet ***/

---
Will Iverson,  Symantec Corporation
Macintosh Developer Relations - wiverson@bedford.symantec.com
As Will Rogers would have said, "There is no such thing as a free variable"