Re: AWT is dead now

[Per Bothner <per at bothner dot com>]

Cedric Berger <cedric@wireless-networks.com> writes:

> What is the real advantage of Gtk over "pure Java"? Speed?

(Speed is not a major advantage - we always have the option of
replacing critical methods by CNI for a "mostly-Java" solution.)
(1) It may be easier to implement something useful if we build on gtk.
(2) Increased compatibility at the code level between C/C++/Java,
makes it more feasible to mix components in different languages.
(3) Better look+feel compatibility between Java apps and Gnome
apps.  Specifically, Swing L+F should follow gtk themes.

I think (3) is the most important, at least long-term.
At the very least, we need a default Swing look+feel that just
uses the current gtk theme.

> And it is sometimes interresting to be able to modify the "view"
> part of a widget. If I take again my example of syntax coloring;
> I've been able to implement that very easily with Swing because
> I've change the *view* part of the simple (plain) text pane: the
> document remains a list of lines of ascii text (without style info)
> and I've just overriden the drawLine() method of the View. No
> need to insert style info or anything special into the "model"

Yes, but that does not preclude having the default rendering
use the native (gtk) toolkit.  (I don't know what's involved though.)

> I'm not quite sure I understand what you mean: the FOP viewer
> is built on top of Java2D, but kind of GUI widget do you want to
> build with FOP?
> Or do you thing about generating PDFs from Java2D? that would
> be very cool!

I was thinking of using the the abstract "formatting object"
model specified for XSL as the way to organize the Swing View
hierarchies, and possibly using FOP as the basis for such an
implementation.

The idea is we use the XSL spec as a design document for how
to construct View hierarchies.  I.e. wherever XSL has an Area,
we create a sub-class of View with the corresponding semantics.
We have the option of using the FOP implementation (assuming the
licensing is ok), but the design is more important than the code.

This has the obvious advantage of making it easier to write tools
to process XML, but it may have a less obvious advantage in that a
lot of the Swing documentation is under-specified, and trying to
reverse engineer View hierachies is both painful and requires
care with the legalities.  (Though Topley's "Core Swing advanced
programming" gives a fair bit of information.)
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/