From: Godmar Back (gback@cs.utah.edu)
Date: Wed Jan 06 1999 - 19:18:56 EST
>
> On Wed, 06 Jan 1999, Godmar Back wrote:
> >ad (2): External libs (I assume you mean libpng, libjpeg, libgif, etc.) do
> >not depend on X, or do they?
>
> We use C-callbacks for the lib-specfic image decoder in order to build the
> X-image on-the-fly (without any temporary storage). Of course you can do that
So that's an optimization then that can't implemented in a way that's
Xlib independent?
> with a Xproto approach, but what's the point in using Xproto *and* native
> methods?
>
> >In fact, the way it's now is probably wrong;
> >these should go in libraries/awt/png, libraries/awt/jpeg, libraries/awt/gif.
>
> Why that? We don't have libraries/stdlib either, but we use the standard C lib.
> We just use them unmodified.
What I meant is more like that if my claim that these things can be implemented
in an Xlib independent way is true (note the `if'), then they shouldn't
be in awt/X. That's all I'm saying.
>
> >ad (1): I don't see where portability would come in. The way I would
> >envision it, there would simply be an alternative Toolkit singleton where
> >all the methods that are now natively implemented in wnd.c or evt.c would
> >be implemented in Java based on XTC. You either use the Xlib based one,
> >or you use the XTC based one.
>
> That's what I meant with JNI-specific design. Yoo should do things differently
> with a direct Xproto utilization. No need to go through the Toolkit bottleneck
> in this case, no need to pass around all these parameters, no need to shadow
> anything on the native side. Look at all the Graphics state mod, for instance
> (setColor, setClip, etc. - you wouldn't have to immediately pass them to the
> native layer (look at how biss-only collected all these state changes - you
> would do it pretty similiar with Xproto).
>
> The bottom line is: you would end up with a hybrid (Xproto and natives), and
> the current Toolkit interface is suboptimal for that.
>
I don't even pretend to understand all the issues here, but then why do we
need this Toolkit interface anyway?
Is it suboptimal for only Xproto, is it suboptimal for a hybrid, or is it
already suboptimal for the current natives approach?
What would be wrong with subdividing it in different interfaces
corresponding to windowing, event handling, image routines, etc.?
Essentially, what's now subdivided in the different .c files in awt/X?
Should users be able to replace their own toolkit, like you could with
Sun's? I don't think that we must support that ability.
If the toolkit interface is an inconvenient bottleneck without benefits,
why not get rid of it in favor of one or more interfaces that's better suited?
I understand that Sun defines java.awt.Toolkit, but none of these
specific native methods appear in the public interface.
For your GRX port, did you find that the Toolkit interface was appropriate?
- Godmar
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:57:30 EDT