Re: AWT

[Nathan Meyers <nmeyers@teleport.com>]

Tom Tromey wrote:
> I don't understand how this applies to what we might or might not do.
> My own feeling is that, on Unix, it is cooler to leverage Gtk+ even if
> it isn't the absolutely ideal approach -- and as far as I know there's
> no evidence that it is not.

Good point. Using Gtk+ for AWT is a great idea, and about as close to
absolutely ideal as I could imagine. As mentioned below, there's a
heavyweight approach to Windows toolkits that's being missed, but it's
an issue for the toolkits, not for libgcj.



> Nathan> So I guess I get to reveal some pitiful ignorance of Windows
> Nathan> programming here. I'm under the impression that it's possible
> Nathan> in Windows to create a completely plain subwindow...
> 
> Yes, you can.
> You can do this with X too.
> 
> Nathan> With this capability, you could design almost any heavyweight
> Nathan> GUI you want (restricted to opaque rectangular windows, which
> Nathan> isn't fatal) without using native GUI components. Is my
> Nathan> impression incorrect -- is this not possible?
> 
> As I understand it this sort of approach is referred to as
> "lightweight", since the components require no system overhead, just
> the presumably ordinary overhead of your implementation.

Heavy- vs light-weight is determined by who's keeping track of the
window hierarchy, not by who's drawing into the windows. An approach in
which simple windows are allocated from MSWindows but completely drawn
in (borders and contents) by the application exactly mirrors what's done
by Motif, Xt, Gtk+, and Qt under X: it's heavyweight. The term (dare I
say misnomer) "lightweight" applies when the application allocates a
single native window from the underlying system and manages all
descendent windows completely on the application side.

That said, this distinction is obviously harder to draw with MSWindows
than with X. The definition of "lightweight" is very mushy, as my
earlier conversation with Per amply illustrated. What does it mean for a
component to be "associated with its own native screen resource" (Sun's
definition of heavyweight)? If you allocate the sort of window I
described in my paragraph, you're using a native resource; if you
allocate a real GUI component (button, spinbox, whatever...) you're
using a bigger native resource. Unlike X, MSWindows gives you multiple
ways to do heavyweight GUIs. (Maybe the approach I described should be
called "middleweight".)


> Tk's experience is that it is easier to get native look and feel --
> and, on Windows, better performance, using a "heavyweight"
> implementation.

I would love to see the results of a "middleweight" implementation,
which they apparently didn't try. Of course, there may be a good reason;
a private correspondent watching this conversation pointed out to me:
"IMO, the *real* problem is the different native event handling models
of the different platforms. I have worked some years with a GUI library
which has tried this approach, but it failed at last. So I am very happy
with the current solution in SWING."

Nathan