Re: I wish to help

[Mark Wielaard]

Hi,

On Thu, 2002-10-31 at 14:32, Andy Walter wrote:
> On Thursday 31 October 2002 12:15, Mark Wielaard wrote:
> > Has someone actually tried Rudolph with GNU Classpath?
> 
> Yes, it is running quite well here. But we replaced many native methods (all 
> but 5) by Java code. Since Rudolph uses a proprietary interface, this 
> replacement might be interesting for classpath. On the downside, our 
> implementation diverged from Rudolph.

Nice. Do you use any of the non-rudolph java.awt.* packages/classes?
We will probably have to merge a lot between the GNU Classpath
implementations and the Rudolph implementations anyhow when we decide to
import it. So that might be the ideal time to work away the diverged
classes.

> > Also take into account that Wonka contains only the java.awt,
> > java.awt.event and java.awt.image packages. We have that and
> > java.awt.color, java.awt.datatransfer, java.awt.dnd, java.awt.dnd.peer,
> > java.awt.font, java.awt.geom, java.awt.im, java.awt.im.spi,
> > java.awt.image.renderable, java.awt.peer and java.awt.print. The
> > important advantage that Rudolph has is of course that the code that
> > they have actually works!
> 
> Not only that but it also doesn't depend on GTK.

I don't know if I would count that as an important advantage :)
Having AWT classes based on GTK peers seems like a very good idea for
any GNU/Linux based system since it will give a more common look when
used on the desktop.

> I think it would be great to 
> separate the top level graphics stuff from the low level peer classes by a 
> common, well-defined interface. That way had three sets of peer classes 
> (GTK-based, acunia framebuffer, jni framebuffer), but only one common set of 
> top level classes, which are probably much more (I have to admit that 
> personally, I don't have to do much with graphics).
> 
> I expect that the sooner we agree on such a common layer, the fewer redundant 
> work there is on the top level.

Yes, that would be a great plan. I am glad that Jeffrey stepped in just
at this time so that we now have someone with GTK+ experience that help
define the correct interface. What do you think about the current
java.awt.peer classes that we have. Are they general/flexible enough?

> > And please make sure that all arrangements between Acunia and the FSF
> > are made clear and public. The last deal that was done with respect to
> > the AWT code (with Transvirtual) was never communicated clearly and that
> > produced some tensions. (I am perfectly happy to let RMS try to get a
> > deal that is in the best interest of all free software users as long as
> > it is clear in the end what has been decided.)
> 
> RMS for sure is the right person to do this. I had expected all agreements of 
> the FSF to be made public and am surprised to read this wasn't the case with 
> Transvirtual.

It was actually meant to be public knowledge. But at the time not
everybody was informed clearly of why and what decision was made. I
don't think that was very deliberate. Although the fact that not
everybody agreed with the decision was probably part of the reason that
it was not clearly communicated. (Read the archives if you are
interested in the details. At the time it felt important, but it is not
really relevant anymore. And I changed my opinion a bit since that
time.)

Cheers,

Mark