Alternatives to AWT
James Arendt
I really disliked the AWT that came with the JDK 1.02. I do like the 1.1
version of the AWT better, but I still feel it still is not want I'm
looking for. I don't think my expectations are too high...
Anyway, does anyone recommend other interfaces such as Netscape's IFC
classes, Marimba's, etc. Here's what I hope to get:
- easy to customize and extend
- drag and drop + clip board features
- efficient and intuitive event handling
- either takes on native look or provides consistent look
over most (if not all) supported platforms
- poised to take good advantage of features provided in the
new JDK 1.1
I appreciate all advice, criticisms, flames, etc.
James
are...@uiuc.edu
Brian Carter
I'd suggest that you take a look at the IFC. The components are very
easy to extend. Drag and drop is supported and a number of the JDK 1.1
features are being added, such as printing and clipboard support. The
look and feel is the same across all platforms. You don't get a native
look and feel but it is consistent and fairly attractive.
Brian Carter
BLaCKSMITH, Inc.
Sam Brannen
Brian Carter wrote:
>
> James Arendt wrote:
> >
> > I really disliked the AWT that came with the JDK 1.02. I do like the 1.1
> > version of the AWT better, but I still feel it still is not want I'm
> > looking for. I don't think my expectations are too high...
> >
<snip>
> I'd suggest that you take a look at the IFC. The components are very
> easy to extend. Drag and drop is supported and a number of the JDK 1.1
> features are being added, such as printing and clipboard support. The
> look and feel is the same across all platforms. You don't get a native
> look and feel but it is consistent and fairly attractive.
>
> Brian Carter
> BLaCKSMITH, Inc.
Another package you could take a look at is sub_arctic. Here's
the URL for that one:
http://www.cc.gatech.edu/gvu/ui/sub_arctic/
- Sam
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ Sam Brannen ~
~ ~
~ e-mail -> mailto:gt5...@prism.gatech.edu ~
~ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Robert McWhorter
James Arendt wrote:
>
...
> Anyway, does anyone recommend other interfaces such as Netscape's IFC
> classes, Marimba's, etc.
Try Rogue Wave Software http://www.roguewave.com
James Arendt
Brian Carter wrote:
> I'd suggest that you take a look at the IFC. The components are very
> easy to extend. Drag and drop is supported and a number of the JDK 1.1
> features are being added, such as printing and clipboard support. The
> look and feel is the same across all platforms. You don't get a native
> look and feel but it is consistent and fairly attractive.
>
> Brian Carter
> BLaCKSMITH, Inc.
With my limited knowledge... a couple of questions. How large is the IFC
or does it just depend on what packages and classes you use? Further
more, since it has consistent feel across platforms, I'm assuming it's
pure Java (meaning no DLLs, etc. to worry about)?
Also, how easy is to extend the components in the IFC? Implement your
own?
James Arendt
are...@uiuc.edu
Mitch Gart
James Arendt (are...@uiuc.edu) wrote:
: I really disliked the AWT that came with the JDK 1.02. I do like the 1.1
: version of the AWT better, but I still feel it still is not want I'm
: looking for. I don't think my expectations are too high...
I think a lot depends on whether you are writing an applet or an
application. If you're writing an applet you want to be careful
about using a lot of classes that aren't guaranteed to be already
on the user's machine. You might write a little bit of code but
it might load megabytes of class framework code. That would be
slow over the Internet. On the other hand, if you're writing an
application and you will be shipping all the .class files, go ahead
and pick the best class framework from anywhere. Hope that helps,
- Mitch
- m...@inmet.com
Douglas Finnigan
Hello,
I'm a bit puzzled here ... I thought the idea behind Java applets was that
the classes needed to run the applet were downloaded to the client machine?
Why do you need to have classes already on the client? Sure, the VM is
necessary, but why can't even the UI (AWT) classes be downloaded
dynamically? Is this a size issue, ie to cut down the amount of traffic?
Once ot twice I've tried an applet on a site only to get an error message
saying that it can't find class such-and-such ...
???
Thanks,
Douglas
Mitch Gart <m...@harp.camb.inmet.com> wrote in article
<E2KAD7....@inmet.camb.inmet.com>...
Mitch Gart
Douglas Finnigan (dou...@tp.ac.sg) wrote:
: Hello,
: I'm a bit puzzled here ... I thought the idea behind Java applets was that
: the classes needed to run the applet were downloaded to the client machine?
: Why do you need to have classes already on the client? Sure, the VM is
: necessary, but why can't even the UI (AWT) classes be downloaded
: dynamically? Is this a size issue, ie to cut down the amount of traffic?
Yes it's a size issue. If you write a 100-line applet that makes
calls to AWT and other predefined classes, the code for those
classes is already installed on the user's machine as part of
Netscape or IE and doesn't have to be downloaded over the net.
If a similar applet called classes that were not predefined, all
the code for those classes would also have to be downloaded and
that could take a long time.
- Mitch
Surendra Singh
m...@harp.camb.inmet.com (Mitch Gart) wrote:
>- Mitch
So it sounds like if you don't have the right set of pre-defined
classes installed, you can't run certain Java applets. I foound this
yo be the case when I tried to run applets that were created with IFC.
They would not work until I installed IFC.
Seems like things are going to get fragmented. Applets/applications
won't work if you don't have the right classes installed, assuming
they are available for you desired platform.
Surendra Singh
Marijn Ros
On Thu, 19 Dec 1996, Surendra Singh wrote:
> So it sounds like if you don't have the right set of pre-defined
> classes installed, you can't run certain Java applets. I foound this
> yo be the case when I tried to run applets that were created with IFC.
> They would not work until I installed IFC.
>
> Seems like things are going to get fragmented. Applets/applications
> won't work if you don't have the right classes installed, assuming
> they are available for you desired platform.
(theoretical mode on, legal mode off)
The IFC is written purely in java. It should thus be possible to download
them when needed. The problem might be that the applet provider doesn't
have a copy of the IFC in the same directory as the applet.
(theoretical mode off, legal mode on)
I have no idea if Netscape allows the distribution of their classes in
this way.
Bye,
Marijn
-------------------------------------------------------------
ros et vies dot rue dot enel
-------------------------------------------------------------
Commercial and/or unsolicited email and/or spam will be
processed for a DFL100 handling fee. Unsolicited sending
constitutes acceptance.
-------------------------------------------------------------
Indu Adige
TITLE: Netscape/Java/JDBC AppletSecurityException
Please somebody HELP!
Everything I talk about here works fine in my Microsoft J++
development environment, but bombs when implemented in a client
server
environment (trying to utilize Openlink's JDBC drivers). When the
Java
classes on the unix server dont do any JDBC/Oracle processing,
everything works fine on the client's Netscape browser, and there
are
no apparent security violations.
But when lostFocus(....) ORACLE database-validation methods
are introduced into certain TextField objects in the Java applet,
the
following exceptions are raised in the Netscape Java Console, even
though the input text IS database-valid...
.
.
.
# Security Exception: properties
netscape.applet.AppletSecurityException:
security.properties
at netscape.applet.AppletSecurity.checkPropertiesAccess(Compiled
Code)
at java.lang.SecurityManager.checksPropertiesAccess(Compiled Code)
at java.lang.System.getProperties(Compiled Code)
at usr_ods.USR_InvoiceField.validate_invoice
(C:\Windows\Java\Classes\pack age\USR_InvoiceField.java:51)
at usr_ods.USR_InvoiceField.lostFocus(Compiled Code)
at java.awt.Component.handleEvent(Compiled Code)
at java.awt.Component.postEvent(Compiled Code)
at sun.awt.windows.WComponentPeer.handleLostFocus(Compiled Code)
at sun.awt.windows.WToolkit.run(WToolkit.java:95)
at
Invalid INVOICE NUMBER entered.
.
.
.
PLEASE NOTE:
1. I am aware that 'java.sql' at the server end raises security
problems at the client Netscape end. So, I have recompiled
java.sql classes and the java.lang BigNum class into my own
package, and the applet objects refer to this new package.
2. Unix preferences on all files are correct.
3. Using Apache Web Server 1.1
Wondering if anybody has implemented a similar scenario
successfully,
or would otherwise just have any suggestions... ALSO, has anyone
experienced problems with Apache Web Server 1.1 not recognizing the
CLASSPATH
variable. As of now, I'm getting around this by keeping all class
folders beneath where the applets lie (and making sure codebase in
the
applet tag is correct), but this ghastly solution cannot last!
Thanks in advance,
Vik Adige.
Indu Adige
Stan Kaufman
Indu Adige wrote:
>
> TITLE: Netscape/Java/JDBC AppletSecurityException
>
> Please somebody HELP!
>
> netscape.applet.AppletSecurityException:
> security.properties
>
> successfully,
> or would otherwise just have any suggestions...
>
> Vik Adige.
I've encountered the same exception using Symantec's dbANYWHERE (PR2 and
PR3). In my applets, which use sample code from Symantec, the offending
line is:
driver = (symjava.sql.Driver)Class.forName( driverName ).newInstance();
The impact of this raised exception varies from one browser's VM to
another. MSIE3.0 sails right through; NN3.0 raises the exception but
makes the database connection OK on Win95 and Digital unix boxes, but
NN3.0 on an SGI box barfs.
Hope there's an answer for this one...
Stan
/**
* Stan Kaufman, MD
* Human Interface Technology Lab, U. of Washington, Seattle, WA
* http://weber.u.washington.edu/~tinman/ email:
tin...@u.washington.edu
*/
Mitch Gart
Marijn Ros (r...@fys.ruu.nl) wrote:
: The IFC is written purely in java. It should thus be possible to download
: them when needed. The problem might be that the applet provider doesn't
: have a copy of the IFC in the same directory as the applet.
Yes that's right but there are 2 problems:
- logistics: the person providing the applet must put all the right
classes on their web site so they will be found at execution time.
This is doable but takes a bit of work, the new JDK 1.1 JAR
files are supposed to help with this but I haven't tried them
yet.
- efficiency: if your 100-line applet has to download a megabyte
of third-party .class files, the applet is going to take a long
time to start up.
Mitch
m...@inmet.com
Matt Kennel
Marijn Ros (r...@fys.ruu.nl) wrote:
: On Thu, 19 Dec 1996, Surendra Singh wrote:
: > So it sounds like if you don't have the right set of pre-defined
: > classes installed, you can't run certain Java applets. I foound this
: > yo be the case when I tried to run applets that were created with IFC.
: > They would not work until I installed IFC.
: >
: > Seems like things are going to get fragmented. Applets/applications
: > won't work if you don't have the right classes installed, assuming
: > they are available for you desired platform.
: (theoretical mode on, legal mode off)
: The IFC is written purely in java. It should thus be possible to download
: them when needed. The problem might be that the applet provider doesn't
: have a copy of the IFC in the same directory as the applet.
What is the caching policy for libraries?
In *principle*, if a new applet uses the same "official" framework as
someone else, then the runtime should not need to download new parts.
This requires smart versioning, and perhaps signatures.
Shouldn't Netscape Navigator be split up into two parts?
1) the UI applications
2) the caching-downloading-verifying server process (i.e. Super Marimba)
--
Matthew B. Kennel/m...@caffeine.engr.utk.edu/I do not speak for ORNL, DOE or UT
Oak Ridge National Laboratory/University of Tennessee, Knoxville, TN USA/
dIon Gillard
Mitch Gart wrote:
> - logistics: the person providing the applet must put all the right
> classes on their web site so they will be found at execution time.
> This is doable but takes a bit of work, the new JDK 1.1 JAR
> files are supposed to help with this but I haven't tried them
> yet.
NetRexx...and use CODEBASE from other pages.
> - efficiency: if your 100-line applet has to download a megabyte
> of third-party .class files, the applet is going to take a long
> time to start up.
Yep....but they will only be downloaded as used....and this turns
out to be okay for some instances.
--
dIon <Multitask Consulting - Bringing OS/2 to U>
NetRexx FAQ: http://www.multitask.com.au/netrexxfaq.htm
NetRexx FAC: http://www.multitask.com.au/netrexx/fac
NetRexx API: http://www.multitask.com.au/netrexx/api
dIon Gillard
Surendra Singh wrote:
> Seems like things are going to get fragmented. Applets/applications
> won't work if you don't have the right classes installed, assuming
> they are available for you desired platform.