Re: [Java-gnome-developer] Possibility to built SWING on top uf Java-GTK?

[Bill H. <bil...@su...>]

Hi again Helgi:

On Thu, 2003-01-09 at 14:08, Helgi Hrafn Gunnarsson wrote:

> For example, if I change the theme of Gtk+, I would want Swing 
> apps to use the same thing, regardless of what Java feels about it, 
> since that functionality should be in the native widget set itself, 
> in our case, Gtk+. Whether this'll be the case for 1.5 or not, 
> I don't know, I couldn't tell by your words. If this is what they'll do, 
> I'll embrace Java Swing much sooner. Furthermore, if that's the case, 
> a specific Linux project of implementing Gtk+ in Swing (with the 
> relevant and cross-platform Swing API and all that stuff) would be 
> rather pointless. We wouldn't get the project in a runnable state
> before 1.5 anyway.

What 1.5. will do is _emulate_ the gtk+ default engine, including the
engine's themability.   So in 1.5 Swing will match the current gtk+
theme and system font size, etc. provided the theme uses either the
default engine or something similar.

For instance the themes currently in gnome-themes (which will be part of
the GNOME 2.2 release) should all work well with 1.5's Swing (and
reports are that they do).  But if you install a totally different gtk+
engine, your results may vary.  As long as the gtk+ theme in question
continues to use the standard gtk+ RC file format, results should be
pretty good, except for possibly things like bevels versus radius if
widget borders, etc.

So the 1.5 solution is not all-inclusive but it will work for a wide
variety of GNOME/GTK+ themes including the 'standard' GNOME-2.2 ones.

> 
> If you can, please elaborate on what you meant by your words on 1.5. 
> Do you know if they're planning on using the native, underlying Gtk+ 
> set or are they just going to imitate it?
> 
> The underlying code running Swing can be slow as hell for all I care. 
> The greatest slowdown in Swing so far has been drawing the UI itself 
> through whichever technology they've used so far. But like I said, 
> the slowness isn't the point, that can be remedied later. Using the 
> Gtk+ widget set from the underlying OS, however, would be politically 
> a more correct way, since that would dump the performance 
> responsibility to the underlying OS and libraries, where that 
> responsibility belongs rightfully.

There are 'political' and practical concerns either way; if you
introduce a dependency on gtk+, you are (potentially) breaking
the platform-independence of Swing.  Of course if the change is only a
pluggable 'optimization' (as it seems to be in MacOS) then it's win-win.

Certainly if a non-default gtk+ engine becomes popular, Swing's PLAF
mechanism allows you to write a new Swing look to match it.  Perhaps
that would be a better project than re-writing Swing to use native
widgets, in terms of portability and also feasibility.

I don't recall offhand if a PLAF could be used to substitute a whole
native widget set... perhaps it is technically possible but I doubt
anyone has tried it.  That would be worth exploring however, since it's
an officially sanctioned mechanism for changing Swing's UI
implementation, and would work with any compliant VM.

best regards,

Bill

> 
> Peace.
> Helgi Hrafn Gunnarsson
> 

-- 
Bill Haneman <bil...@su...>