Godmar Back wrote:

> >
> > I've already written a lightweight awt.
> > It's on top of the Swing now. But it could run on other lightweight  toolkits.
> > BTW free  kaffe is peerless not lightweight.
> >
>
> I'm not an expert in GUI terminology, but I know that the developers of
> the kaffe awt call it lightweight because it does not rely on widgets
> provided by an underlying library, such as Xaw or Xt.  Instead, things
> such as buttons are programmed in Java.
>
> On the other hand, they've decided to put peers back in, although
> a limited form thereof which is basically faked.  This is apparently
> necessary to satify applications such as the Swing libraries, which
> make use of some peers directly.
>
> So maybe what you meant is: "kaffe is lightweight but not peerless"?
>
>         - Godmar

  I just looked agian its been a while.  My big probelm was there was no lighweight
windows
or  buffer drawing machinery as is used in Swing and IFC.
The Scroll bars etc  are lightwight. Your correct. Unfortunaly the part I need thve
pretty much bolted
onto the Native WIndowing system. Marimba just open source there code and it has a
lightweight windows.

Look a GWT for another set of lightweight peers. There are actually many such
toolkits.

This not the big  issue for me its tying in to the native windowing system so tight
that  I did not like.
I do not care much for the toolkit/Window part of kaffe.  So far the only "OK" one
is the Swing.
And I don't like it very much.

I do not use the native windowing system at all. I actually worked up for the
device driver.
I do have a driver built on top of the AWT but its more for testing and demos.
I run full screen. I could integrate into a native windowng system but why ?
I'd rather write a X11 server on top of Java and chunk my X window managers.
Thats on the todo list.
As soon as I get a chance I really want to do a GGI driver.
I could use the Kaffe widget set as peers fairly easily. But right now I'm tied to
the
Swing for the  JInternalFrame that I use for Window peers. So I did not see much
sense in mixing.
Given a widget set and the work I've done moving of the Swing for widgets is easy.

--------If there is a free toolkit which has lightweight frames let me know.
------------

I really don't care much for the Swing any more its guts are pretty ugly.
I keep tracing bugs back into the Swing.

First they corrupted there graphics Stack now I find that  the let covered windows
draw through  the
top component.  It's almost funny how bad there graphics stuff is.  And they don't
let you draw to
there buffers. I'm not sure who set the access levels for Swing but not having
SwingGraphics public
is stupid.  Plus talking to Sun about how botched there stuff is useless.

The Swing  would be a kickass toolkit if they threw the Awt crap out the window.
And redid the graphics layer like a real graphics engine.  Awt graphics model
pretty much kills it.
Of course I used to do DPS on Nexstep  sniff sniff.
Having a stack to push graphics ops on is great.
Plus not being able to mainitain a graphics context outside of a device bites.
I  use a GraphicsContext object inside my stuff it has the clip rect translation
current color etc.
You just pass it into a device the device binds it then performs the graphics op.


I found it fairly easy to  fake a video card and graphics lib on top of a windowing
system : )

My next plans are GGI driver/ X11 server. They have a X11 server for GGI so
I should be able to get it going as I write my GGI driver.

Mike



Reply via email to