From: peter@transvirtual.com
Date: Wed Jan 06 1999 - 18:46:24 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
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.
>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.
-- Peter
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:57:30 EDT