Paul Fisher wrote:
> "Daniel Rall" <[EMAIL PROTECTED]> writes:
>
> > Yeah, same here. I vote for doing away with heavyweight peer
> > components all together and having the AWT simply wrap the
> > lightweight JFC components.
>
> The GTK+ heavyweight peers are almost complete. We're not going to
> just throw them away. They work.
>
> As for the possibility of implementing peers using lightweight
> components, we need free JFC components first.
For a completley free implementation yes but Lightweight peers can be
free.
I have already done all this it's available today.
The project is called shark windows and its currently available via CVS
at
www.gjt.org
CVS dir
java/org/gjt/shark
>
>
> > That way we have a completely portable implementation and never have
> > to worry about writing a single line of native code (as far as the
> > AWT goes).
>
> If you have a completely portable implementation, how do you ever
> display anything to the screen? You have to interface with the
> hardware at some level, and that's going to be non-portable.
>
Actually it turns out you can have several levels of abstractionI have
drivers directly on top of the hardware and yes the driver is
non-portable
I have a AWT driver and on on top of X11. These are more portable.
And since I've been able to create a AWT implementation of my drivers it
can be considered "PURE" java : )
All you need is a graphics library. Soon I'll work with the new frame
buffer device in Linux 2.2 and the
GGI lib. At the level of graphics libraries all platforms have at least
one most several and there so basic
the APIs are pretty much alike. There are only so many way to draw a line
and fill a polygon.
I have been very happy with the portability at this level I can write a
driver in less than a week.
What's nice is a AWT port is a simple matter of hooking into graphics
calls available from any api.
At the lowest level you need to be able to make a few blit calls to a
dumb frame buffer.
It is extremely portable. In fact you should be able to have it running
on a new platform in less than a month.
I have even written some graphics primitives in Java there useful during
the porting stage but you probably want to
replace then with native version later on.
The concept is similar to the X11 sample server.
I see no reason for classpath to repeat this endeavor.
Now as far as the JFC is concerned. Java graphics is so bad that I whant
to develop a generic
windowing api first then layer the JFC on top of that. There is no reason
to use the Java approach to graphics.
This would allow you to write whatever Windowing api you want on top of
the primitive system.
I plan on doing this like Display Postscript. Postscript draws the basic
white window and handles dragging.
Basically it replaces JDesktopPane.
You have new classes BasicWindow and DragRegion.
Next you need to create a GraphicsContext class separate from the drawing
device.
I've done this already.
Anyway what you suggest has already been done. There is no reason for the
Classpath group to waste time on this.
What I would like them to do is write the AWT classes against there
peers. Then I can use them instead of running
against the Sun AWT. I can do this. As long as classpath can provide a
free implementation.
I can adopt it to USe the JFC easily. Later we need to work on a free
JFC. But I do have a lot of experience with it
and trying to implement the JFC on top of the current Java graphics
implementation does not work well.
You need to create a basic no frills windowing system then set the JFC
components on top of that.
This can be done but it will take time. I see no reason to follows Sun's
implementation and try to make JFC work on top of
a poor graphics engine. They have the JFC which runs on all VM we can
make one which is VM specific but much better.
In this case there is know real reason to make JFC run on all platforms
since sun already provides a platform independent JFC.
I'd much rather have a all java JFC written on top of a better graphics
foundation which contains a small amount of native code
but is free.
If you think about it for a bit Sun cliams JFC is "PURE" java becuase
they provide the native implementation for two platforms.
I'd much rather run the windowing System on top of a "ALL" java api
which is native only at the graphics primitive and input level.
Infact thats what I've done : )
This is far more poratable robust and more java than Suns "PURE" java
JFC.
"PURE" java is just Suns way of saying it runs on Solaris and NT.
I do not know why Sun has not made a better graphics layer considering
they wrote the News system.
They should know better.
Mike
