Jason Osgood wrote:
> Michael Emmel-
>
> Thank you for your reply and offer!
>
> Michael Emmel wrote:
>
> > The Swing would be a kickass toolkit if they threw the Awt crap out
> > the window.
>
> Would it be possible to reimplement Swing without AWT?
Yes I have already. I followed for the most part the current
graphicsclass. Mainly for compatibility.
I think the best deign is
Low level / Hardware code blit operation and some line drawing mostly.
On top of this you provide a software library which does clipping
algorithms
Algorithm determination etc. It would be the basic drawing engine
underlying your font sever
and windowing system. This could be compared to SuperVga Lib.
On top of this is the core windowing system which handles buffered panting
and dragging
rectangles across the screen. ITs nice to keep drag fairly low so all
component can take
adnvantage of it. They simply register a drag region. This is how
Nextstep worked.
The "Windowing " System now becomes what is drawn in those rectangles.
This split the X11 sever into 3 distinct servers each capable of running
without the higher level one.
I see three level of remote api's being possible also.
>
>
> I (obviously) don't have a good understanding of any of the issues
> involved. How I wish I could get a brain dump from you. (Most of my
> GUI experience is with use interface design for CAD and illustration
> programs.)
>
> How this originally came up was a concern I was parroting about
> threading/concurrency issues in Sun's JDK/JRE. I don't know enough to
> ask intelligent questions, but I wanted to learn if this was a design or
> an implementation issue, as well as whether or not the issue poses a
> risk to GNU's Classpath.
Nope as of now there based on Sun's Swing. And any way it's complimentary
to class pathClasspath is "traditional" while my approach is to develop
java with no concern for
today's legacy systems. Linux provides the ideal system for such work and
with GGI I think
with GGI it becomes quit feasible.
It really has nothing to do with Classpath or current Java implementations.
I can and will integrate with classpath. The need to do what there doing
today to support java
on Linux. My stuff is is for tommorow : )
I pretty much sidestep allot the hooks used to tie people to a particular
vendor
GTK and KDE included.
For example my AWT based driver runs any where. Some one run the whole thin
on NT
I've never even tried since I don't personally own a NT box.
The goal is to creat a entire desktop enviroment wich runs on any OS using
various simple
drivers. Then if it has tools and apps why use a native platform. And I get
acces to any
Java apps so I don't have to convince people that my particular windowng
system is the best.
Nor do I fight the OS wars. I siply provide a portatable virtual NC.
I don't care how you run it.
Linux happnes to be the best pltform to run on but that more becuase its
open source.
Not any inherent advatage in the Linux kernel besides it being a very good
OS.
OS/2 would probably be a good and BE but no source ....
If this takes off then you can laye it on ne OS desings with little
trouble. I think the embedded guys
should be intrested since it fits there stuff well. The Swing can be
slimmed down a lot for embedded devices.
>
>
> Another issue is the effort of supporting AWT on top of numerous native
> GUIs. Idle speculation suggests that "lightweight" widgets may reduce
> effort and perhaps even improve robustness and consistency.
You should be able to port my AWT to a raw hardware platform in less than a
week.
There are speed issues today but if Sun opens up hotspot just a little
I have a few Ideas.
Based on a concept called a Signature Compiler.
Basically you extend the compiler to handle all the devices that make up a
computer
instead of just concentrating on the CPU. The code will optimize itself
not only for a
a particular CPU but also your graphics card SCSI etc etc.
The concept of hotspot work's for any device not just a CPU.
>
>
>
> The distinction between peerless and lightweight is important (and
> confusing for novices like me). Let me see if I get this right:
> Peerless means there's no matching underlying window handle/context;
Peerless components contain the full component implementation the Swing
forexample is peerless. The light heavy weight stuff comes simply
because the current AWT uses native peers.
> lightweight means the widget is drawn in Java, not by the underlying
> native GUI. So it's possible to have lightweight widgets with peers,
> which is how you described Kaffe's current AWT implementation.
Kaffe is lightwieght upt to the part I want lightweight : (The native
stuff is "peerless".
>
>
> ---
>
> Blue Sky for a moment: What would be the ideal design and implementation
> solution of AWT and Swing/JFC? (Talk slow, because some of us are still
> kind of dense. <grin>)
See my generic design above it's basically the way Mac OS X works today.
Except for there lack of network support in the current design it's quit
good.
I believe that the graphics hardware should be accessed at 4 levels of
abstraction
each could support a remote interface. There is some overlap between
hardware acceleration and software routines.
1.) Basic hardware driver in its most primitive form the dumb frame buffer
2.) Graphics lib Svga Lib and numerous others.
3.) Basic buffered windowing system resolution independent overlapping
rectangles. Drag should be here
using a registered drag region. These run on top of a single background
window like Swings desktop.
4.) The Widget set which is drawn in the "Windows" Each window forwards
event into its widgets.
This really has little to do with Java. The display would be useful mainly
in mode 2 and 4.
1.) is basically TV mode and has its uses.
3.) I plan to use to implement the X11 server. this is good for emulation
of other windowing systems.
The fact that Java is probably the best implementation language is another
issue.
I might had that I have successfully written a basic Video Driver almost
entirely in java.
I did that first as proof of concept. It was good enough to convince me to
continue.
I have one on top of Eugene XTC toolkit wich replaces xlib.
I've been maily using my AWT one to get the higer level stuff working and
make sure the perfomace is
okay up there. Soon I hope to start working back at the lowere lvels
getting these driver back up.
First order is a GGI driver then start on X11 server. I hope others are
intrested in the X11 but
I need to do enough to really understand the design. There is a lot of good
stuff in X11 it's just old.
Plus I feel that there are a lot of littel mistkaes in X11 that add up to
a overall problem.
Probably the biggest is the did not go far enough and get a good windowing
syste on top of X11.
Another for me is its probalby the most complex C code on the planet.
Building it is a challenge itself.
My core code will be up on the web soon. I manages to expose a bad bug as I
was cleaning it up.
Two wrongs made a right : (
It's a bit ugly but hey I didn't have much to go on.
On that note I see no reason to support anything but True Color and up and
Liner frame buffers.
And 2-4 megs of Vram prefer 4.
I can by such a card at a second hand store for about 30 dollars.
You do need a few asm routines and a fast memcopy. Plus memmap to map the
cards memory.
90% of the driver is initialization code that run's once So speed is not
and issue.
A few core routines need to be blazingly fast. My stuff is basically Java
and Assembler wit C is the glue.
The are about 500 lines of C/Asm and the rest is java
drwxr-xr-x 6 mike program 1024 Dec 14 05:45 ..
-rw-r--r-- 1 mike program 2632 Dec 14 05:44 BusMouse.java
-rw-r--r-- 1 mike program 191 Dec 13 20:04 CLASSPATH
-rw-r--r-- 1 mike program 11618 Dec 14 05:44 Cirrus5430.java
-rw-r--r-- 1 mike program 261 Dec 13 20:04 DEBUG
-rw-r--r-- 1 mike program 1392 Dec 14 05:44 Device.java
-rw-r--r-- 1 mike program 1325 Dec 14 05:44 DeviceLoader.java
-rw-r--r-- 1 mike program 14849 Dec 14 05:44 LinuxKeyboard.java
-rw-r--r-- 1 mike program 6017 Dec 14 05:44 Memory.java
-rw-r--r-- 1 mike program 11990 Dec 13 20:04 NativeLibrary.c
-rw-r--r-- 1 mike program 2431 Dec 14 05:44 NativeLibrary.java
-rw-r--r-- 1 mike program 44296 Dec 13 20:04 NativeLibrary.o
-rwxr-xr-x 1 mike program 46414 Dec 13 20:04 NativeLibrary.so
-rw-r--r-- 1 mike program 46414 Dec 13 20:04 NativeLibrary_g.so
-rw-r--r-- 1 mike program 11278 Dec 14 05:44 PciBus.java
-rw-r--r-- 1 mike program 4663 Dec 14 05:44 PciDevice.java
-rw-r--r-- 1 mike program 1153 Dec 14 05:44 Port.java
-rw-r--r-- 1 mike program 2327 Dec 14 05:44 QGraphicsDevice.java
-rw-r--r-- 1 mike program 289 Dec 14 05:44 Range.java
-rw-r--r-- 1 mike program 14619 Dec 14 05:44 SvgaDevice.java
-rw-r--r-- 1 mike program 144 Dec 14 05:44
SvgaDeviceGraphics.java
-rw-r--r-- 1 mike program 699 Dec 14 05:44 Test.java
-rw-r--r-- 1 mike program 18461 Dec 14 05:44 Vga.java
-rw-r--r-- 1 mike program 6453 Dec 13 20:04
gnu_device_NativeLibrary.h
-rwxr-xr-x 1 mike program 490 Dec 13 20:04 mk
Attached is the C code.
bash% wc -l NativeLibrary.c
502 NativeLibrary.c
Theres a bit of cruft in it too.
I was pleased with even my dumb frame buffer's performance. Unfortunaltey
I've had to get the rest of the stuff going.
Java device drivers are not much use without something on top of them : )
I know I never want to write peers agian.
NativeLibrary.c
