Java and Microsoft Windows

[Peter Olcott]

Someone told me that Java always makes all of its graphical user interface
controls from scratch, and never implements its controls as Microsoft Windows
controls, is this always true, even for applets that run inside of Internet
Explorer?

 

[Michael Rauscher]

Someone told me that Java always makes all of its graphical user interface
controls from scratch, and never implements its controls as Microsoft Windows
controls, is this always true, even for applets that run inside of Internet
Explorer?

AWT uses native components, SWT too. Swing uses lightweight controls, so
they're painted by Swing.

Bye
Michael

 

[Peter Olcott]

AWT uses native components, SWT too. Swing uses lightweight controls, so
they're painted by Swing.

Bye
Michael

So does Java most often use Microsoft Windows controls (is this what you mean by
native components) or does it most often build them from scratch itself? (I am
not a Java programmer so I don't know if AWT is the foundation on which Java is
based, or some obscure technology that is rarely used).

 

[Jeffrey Schwab]

Someone told me that Java always makes all of its graphical user interface
controls from scratch, and never implements its controls as Microsoft Windows
controls, is this always true, even for applets that run inside of Internet
Explorer?

You get to pick whether to use native controls (AWT) or light-weight
controls (Swing). Both of these libraries come with J2SE out of the
box. You can alternatively download SWT, which uses a combination of
the two techniques.

Is there a reason you need to know this, or are you just assuming there
will be a significant performance penalty for drawing components "from
scratch?"

 

[Peter Olcott]

You get to pick whether to use native controls (AWT) or light-weight controls
(Swing). Both of these libraries come with J2SE out of the box. You can
alternatively download SWT, which uses a combination of the two techniques.

Is there a reason you need to know this, or are you just assuming there will
be a significant performance penalty for drawing components "from scratch?"

There is a reason that I need to know this. I don't assume anything. There would
be no reason why drawing a component from scratch would be required to be
inherently slower. How popular is Swing and SWT relative to AWT? Which of these
are used for web applets?

 

[Michael Rauscher]

So does Java most often use Microsoft Windows controls (is this what you mean by
native components) or does it most often build them from scratch itself? (I am
not a Java programmer so I don't know if AWT is the foundation on which Java is
based, or some obscure technology that is rarely used).

First of all, Java is a language. Neither AWT nor Swing are part of the
language but of the user interface libraries of the "Java Platform".

AWT was the first windowing toolkit (Abstract Windowing Toolkit - AWT)
included in the Java Platform. Later, Swing was introduced.

AWT provides only a very basic set of native components (components that
are provided by the underlying system, e. g. Microsoft Windows). Most
probably you'll find just a few applications built upon pure AWT.

SWT (Standard Widget Toolkit) is a 3rd party library that is part of the
Eclipse project. It also uses native components but I don't know if one
can use SWT effectively in applets.

Swing is based on AWT but paints all components by itself. This way
different Look & Feels are supported.

But why do you want to know that?

Bye
Michael

 

[Peter Olcott]

First of all, Java is a language. Neither AWT nor Swing are part of the
language but of the user interface libraries of the "Java Platform".

AWT was the first windowing toolkit (Abstract Windowing Toolkit - AWT)
included in the Java Platform. Later, Swing was introduced.

AWT provides only a very basic set of native components (components that are
provided by the underlying system, e. g. Microsoft Windows). Most probably
you'll find just a few applications built upon pure AWT.

SWT (Standard Widget Toolkit) is a 3rd party library that is part of the
Eclipse project. It also uses native components but I don't know if one can
use SWT effectively in applets.

Which of these three technologies is used most often in web applets?

Swing is based on AWT but paints all components by itself. This way different
Look & Feels are supported.

But why do you want to know that?

I am working on an application that must interface with every other application
type.

 

[Andrew Thompson]

Which of these three technologies is used most often in web applets?

If the authors have the mistaken impression that
coding in AWT will provide support for 'all browsers'
(read 'IE + the other one'), they might stick to the
limited number of GUI components available in the
AWT.

If the authors are realistic and need split panes,
trees, table support.., they will use either Swing
or SWT - which both have a richer GUI
component set than AWT.

Swing & AWT both come 'packaged with Java' and
therefore you can get a Swing/AWT based applet
that is <10Kb.

If using SWT in an applet, OTOH, the SWT jar needs
to be downloaded as a separate archive (transparently
to the user - but taking longer). I have neve seen an
actual SWT based applet.

For that reason I would say - the majority (ever increasing)
are Swing, a shrinking number are AWT, & theoretically,
you might find one or two that use SWT.

I am working on an application that must interface with every other application
type.

What about Swing/SWT/AWT *applications*?

Andrew T.

 

[Peter Olcott]

If the authors have the mistaken impression that
coding in AWT will provide support for 'all browsers'
(read 'IE + the other one'), they might stick to the
limited number of GUI components available in the
AWT.

If the authors are realistic and need split panes,
trees, table support.., they will use either Swing
or SWT - which both have a richer GUI
component set than AWT.

Swing & AWT both come 'packaged with Java' and
therefore you can get a Swing/AWT based applet
that is <10Kb.

If using SWT in an applet, OTOH, the SWT jar needs
to be downloaded as a separate archive (transparently
to the user - but taking longer). I have neve seen an
actual SWT based applet.

For that reason I would say - the majority (ever increasing)
are Swing, a shrinking number are AWT, & theoretically,
you might find one or two that use SWT.

The current majority of web applets use Swing technology?

What about Swing/SWT/AWT *applications*?

Yes, and even YeOlde MSDOS Command Line applications. I must be able to
interface to anything.

 

[Jeffrey Schwab]

There is a reason that I need to know this.

Great, but could you be more specific?

I don't assume anything. There would
be no reason why drawing a component from scratch would be required to be
inherently slower. How popular is Swing and SWT relative to AWT? Which of these
are used for web applets?

Swing is probably the most popular. Applets can be either AWT or Swing.

You seem to have some confusion about what a GUI toolkit actually is.
It's not a protocol that you use to interface one program to another;
it's a way of interfacing with the user. If you're going to try to make
your GUI look like somebody else's GUI, you should definitely choose
Swing, which gives you the most control.

 

[Peter Olcott]

Great, but could you be more specific?


Swing is probably the most popular. Applets can be either AWT or Swing.

You seem to have some confusion about what a GUI toolkit actually is. It's not
a protocol that you use to interface one program to another; it's a way of
interfacing with the user. If you're going to try to make your GUI look like
somebody else's GUI, you should definitely choose Swing, which gives you the
most control.

I have invented a way for one application to interface with any other
application. I wanted to see how difficult it would be for competing products to
duplicate the functional benefits of my technology. Thanks to Java Swing
technology it looks like alternatives to my technology would be too difficult to
implement, thus providing my technology with truly unique functional benefits.

 

[Michael Rauscher]

The current majority of web applets use Swing technology?

With respect to applets that use components that goes beyond simple
drawing/animation, I'd say yes.

Perhaps you could explain to me what you mean with the following
statement you wrote in response to Jeffrey Schwab:

> I have invented a way for one application to interface with any other
> application.

Remote controlling, embedding, ... ?

Bye
Michael

 

[Peter Olcott]

With respect to applets that use components that goes beyond simple
drawing/animation, I'd say yes.

What about ordinary business applications and applets?

Perhaps you could explain to me what you mean with the following statement you
wrote in response to Jeffrey Schwab:


Remote controlling, embedding, ... ?

Universal GUI Scripting Language that can "see" anything on the screen by
processing the screen pixels in real time using a deterministic finite
automaton.

 

[Jeffrey Schwab]

Universal GUI Scripting Language that can "see" anything on the screen by
processing the screen pixels in real time using a deterministic finite
automaton.

Er... Like java.awt.Robot?

http://java.sun.com/j2se/1.5.0/docs/api/java/awt/Robot.html

 

[Peter Olcott]

Er... Like java.awt.Robot?

http://java.sun.com/j2se/1.5.0/docs/api/java/awt/Robot.html

Can it win live action video games on MS Windows and Apple OS?
Can it control MS DOS 3.1 applications?
Can it always fully automate any application on any platform?

Since you referred to it as java.awt.Robot, I would estimate that it would have
a hard time with Swing technology, thus it would not even be universal on its
own platform, much less every platform.

 

[Jeffrey Schwab]

Can it win live action video games on MS Windows and Apple OS?

Not on its own, of course. You'd have to write some code specific to
the game you want to play. If you've written a class that woke up one
day and decided to get its own avatar in Second Life, I want a copy.

Can it control MS DOS 3.1 applications?

Not sure what you mean... Are you talking about Windows 3.1, or Apple
DOS 3.1? If you're talking about your program sharing a 286 with actual
DOS, my hat's off to you. I wouldn't want to squeeze the J2SE into low
RAM.

Can it always fully automate any application on any platform?

That's a pretty bold claim, but if we're talking about automating GUI
functions, I would guess Robot is the most portable engine you're likely
to find.

Since you referred to it as java.awt.Robot, I would estimate that it would have
a hard time with Swing technology, thus it would not even be universal on its
own platform, much less every platform.

java.awt is just the package where it lives, which makes sense because
it needs tight integration with the host environment. Sorry, I guess I
wasn't clear enough... Why not read the documentation for yourself?

 

[Stefan Schmiedl]

Since you referred to it as java.awt.Robot, I would estimate that it
would have a hard time with Swing technology, thus it would not even be
universal on its own platform, much less every platform.

Don't confuse the methods used to implement its functions with
the scope of those functions.

How does your solution interact with a native RetroForth system running
without multi-MB OS on the bare metal?

s.

 

[Peter Olcott]

Not on its own, of course. You'd have to write some code specific to the game
you want to play. If you've written a class that woke up one day and decided
to get its own avatar in Second Life, I want a copy.

Unless it implements a deterministic finite automaton there is no possible way
that it can recognize the arbitrary sets of pixels that video games produce in
real time. If it does implement a deterministic finite automaton, to recognize
arbitrary sets of pixels in real time for the purpose of controlling another
application, then my patent would probably be invalidated by this prior art.

Not sure what you mean... Are you talking about Windows 3.1, or Apple DOS
3.1? If you're talking about your program sharing a 286 with actual DOS, my
hat's off to you. I wouldn't want to squeeze the J2SE into low RAM.

1981 Microsoft DOS applications still run under the current versions of MS
Windows XP.

That's a pretty bold claim, but if we're talking about automating GUI
functions, I would guess Robot is the most portable engine you're likely to
find.

Can it see the exact location and current state of every graphical user
interface control element on MS Windows (from 3.1 to XP), and Java Swing?

java.awt is just the package where it lives, which makes sense because it
needs tight integration with the host environment. Sorry, I guess I wasn't
clear enough... Why not read the documentation for yourself?

So then it can see the current state and exact location of every Swing control
element?

 

[Peter Olcott]

Don't confuse the methods used to implement its functions with
the scope of those functions.

How does your solution interact with a native RetroForth system running
without multi-MB OS on the bare metal?

s.

When the slave application is running as a segregated part of this
multi-megabyte OS it can interface perfectly.

 

[Jeffrey Schwab]

Unless it implements a deterministic finite automaton there is no possible way
that it can recognize the arbitrary sets of pixels that video games produce in
real time. If it does implement a deterministic finite automaton, to recognize
arbitrary sets of pixels in real time for the purpose of controlling another
application, then my patent would probably be invalidated by this prior art.

1981 Microsoft DOS applications still run under the current versions of MS
Windows XP.


Can it see the exact location and current state of every graphical user
interface control element on MS Windows (from 3.1 to XP), and Java Swing?


So then it can see the current state and exact location of every Swing control
element?

I hope you won't be offended, but may I ask how old you are?