[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Event class?
From: |
Shane Nay |
Subject: |
Re: Event class? |
Date: |
Fri, 11 May 2001 02:17:38 -0700 |
> I don't know what you mean. On interpreter-enabled platforms using
> libgcj should be just like using Sun's java interpreter. Unless of
> course you are trying to use the JNI invocation API, which we still
> haven't implemented. The interpreter works on x86, PPC, IA-64, and
> alpha.
I don't see any reference within the libgcj site about an interprettor driven
enviro that can utilize libgcj? Does such a thing exist? (Or is it simply
possible?) See, my background, and primary interest is in embedded stuff (I
used to work for AgendaComputing BTW), these types of enviroments would
benefit greatly from an interpretter driven setup. So you don't *need* the
cross compiler, this confuses lots of would be developers. They would also
be greatly benefitted by native code with efficient link ups between the
interpretted code and the native code (i.e. native calling conventions, pass
args through registers, etc.) But having a compiler such as gcj on board is
a no go because of the space and resource limitations inherent in cost
effective embedded devices. So, what I would really like is to either have a
fully interpretted enviro such as GNUClasspath and some VM, or some
conglomeration of libgcj that allowed a VM.
> Shane> Also gcj's AWT is based around much lower level code than what
> Shane> I'd like..., looks like Xlib calls, but I need to make it all
> Shane> widget level stuff with Peers and the like.
>
> This sounds like confusion on your part. libgcj's AWT, such as it is,
> is based on a standard peer approach. There are partial
> implementations of two different sets of peers: the raw xlib peers and
> the Gtk peers (based on the Classpath peers).
Right, but the xlib is much more developed. And re-implementing the Xlib
peer architecture for a widget based architecture is substantially more
complex than implementing a new widget based architecture based on a prior
widget based implementation. (For instance, I re-wrote all the java calls in
gnu.java.awt.gtk in a matter of 10 hours or so for pgui, re-aligning the
inheritances where it made since in the other enviroment. If I were to do
this for a more low level drawing peer driven architecture like Xlib it would
have to be basically re-designed in order for it to be coherent)
> Shane> What's everyones vibe on Classpath's AWT? Would you like to
> Shane> see it fixed?, would a fixed AWT be accepted into the core of
> Shane> GNUClasspath?
>
> I'm sure the answers to both are "yes".
Maybe :). There is some argument with respect to whether it should "inherit"
the license from GNUClasspath, or gtk itself. I could really care less,
LGPL, or GPL with exception is fine for me either way.
Thanks,
Shane Nay.
- Re: Event class?, (continued)
- Re: Event class?, Tom Tromey, 2001/05/10
- Re: Event class?, John Keiser, 2001/05/10
- Re: Event class?, Tom Tromey, 2001/05/10
- Re: Event class?, Shane Nay, 2001/05/10
- Re: Event class?, Paul Fisher, 2001/05/10
- Re: Event class?, Tom Tromey, 2001/05/10
- Re: Event class?, Paul Fisher, 2001/05/10
- Re: Event class?, Bryce McKinlay, 2001/05/11
- AWT work [WAS Re: Event class? ], Brian Jones, 2001/05/11
- Re: Event class?, Tom Tromey, 2001/05/10
- Re: Event class?,
Shane Nay <=
- Re: Event class?, Shane Nay, 2001/05/11
- Re: Event class?, Aaron M. Renn, 2001/05/10
- Re: Event class?, Tom Tromey, 2001/05/11
- RE: Event class?, John Keiser, 2001/05/12
- Re: Event class?, Tom Tromey, 2001/05/12
- Licenses (was Event class?), John Leuner, 2001/05/13
- Re: Event class?, John Leuner, 2001/05/11
- Re: Event class?, Aaron M. Renn, 2001/05/12
- Re: Event class?, John Leuner, 2001/05/13
- Re: Event class?, Shane Nay, 2001/05/13