[kaffe] Classpath AWT progress.
S. Meslin-Weber
twiun@adorphuye.com
Tue Dec 9 05:49:02 2003
Hi Sascha, James,
> to the toolkit. All Classpath toolkits would be mandated to subclass
> gnu.java.awt.ClasspathToolkit. The intention is to keep the platform
> dependencies limited to as few places as possible. There was some debat=
e
> about whether GraphicsEnvironment or Toolkit would be the appropriate
> place for this, and the apparent conclusion, at the time, was that
> Toolkit would be preferable.
I fear that this will limit the usefulness of non-Classpath toolkits as=20
the majority of them are intended for use in a cross-JVM way and have a=20
Toolkit implementation that derives directly from java.awt.Toolkit.
These external toolkits/peers would either have to replace Classpath's=20
java.awt.Toolkit in the bootclasspath or use some other class gymnastics=20
to avoid using Classpath-specific interfaces.
I'll explain:
I'm concerned with the Classpath-specific interface aspect because this=20
brings in the dreaded 'linking' clause of the GPL (as understood by=20
debian-legal). Such linkage implies the requirement for the external=20
toolkit to be GPL'd too. This would limit the appeal for companies to mak=
e=20
the effort to be Classpath-compatible. QtAWT from Trolltech for instance=20
is not going to be GPL'd anytime soon.
It's been suggested that external toolkit implementors provide an empty=20
ClasspathToolkit and this would work; but requires additional work from=20
toolkit implementors. Most Open Source toolkit implementors would probabl=
y=20
be prepared to do this - commercial ones are unlikely to.
Just in case people are wondering, other toolkits include:
- PJA at http://www.eteks.com/pja/en/
- Charva at http://www.pitman.co.za/projects/charva/
- fbAWT at=20
http://adorphuye.com/zaurus/java/faq.jsp?section=3DJava+Extensions&subsec=
tion=3DfbAWT
- QtAWT from http://www.trolltech.com (unfortunately not publicly=20
available _yet_)
- ... and few others
I understand that certain awt classes that have platform dependencies can=
=20
be constructed directly by user applications and as such need custom=20
handling directly in the java.awt.* class. But so far, only java.awt.Font=
=20
seems to require this as both Toolkit and GraphicsEnvironment on Sun's SD=
K=20
use the system properties to set platform dependent ones:
java.awt.graphicsenv=3D
awt.Toolkit=3D
These can be inferred from a dump of the System properties, an example of=
=20
which can be found at:
http://bbs.rhaon.co.kr/mywiki/moin.cgi/ProgrammingTips_2fSystemProperties
For me, the GPL issue is not that important, but if we want companies wit=
h=20
their own Toolkits to use GNU Classpath we need to offer them a way of=20
doing this without resorting to GPL-ing their code (as that is something=20
they may not be allowed to do).
Thanks,
Steph Meslin-Weber