RE: Possible awt patches

["Boehm, Hans" <hans_boehm at hp dot com>]

Here is a bigger version of the patch.  It fixes enough bugs to almost make CRCalc usable.  (CRCalc works if you use purely the mouse and not the keyboard.)  I have a bit more confidence in this version as a result.

I'm still not positive about the guesses for getPreferredSize.  If I take those out, I get NullPointerExceptions on the result, but those seem to be caught somewhere.  I'd be inclined to put in the guess, simply because it makes debugging easier.

The setFont part of the patch is also a bit dubious.  I don't think it's quite doing the right thing.  (The basic problem is that an AWT setFont request should presumably be propagated down the widget tree.  I don't think that true for GTK.  Furthermore some of the GTK widgets that might be affected are not directly visible at the Component level, so it seems that the subclasses have to be involved.  Hence the partially replicated code.)  I do believe that it moves us closer to correct code.  Hence I would like to check it in, at least in the absence of a better patch by a GTK expert.

OK for trunk?  What about 3.3?

Hans

> -----Original Message-----
> From: Tom Tromey [mailto:tromey@redhat.com]
> Sent: Monday, February 10, 2003 4:06 PM
> To: Boehm, Hans
> Cc: 'java@gcc.gnu.org'
> Subject: Re: Possible awt patches
> 
> 
> >>>>> "Hans" == Boehm, Hans <hans_boehm@hp.com> writes:
> 
> Hans> I've been trying to get the GUI version of my constructive reals
> Hans> calculator to work with gcj.
> 
> Excellent.
> 
> Hans> If someone can verify that I'm not just covering up other
> Hans> problems, I'll be happy to add ChangeLog entries and check them
> Hans> in:
> 
> They all look reasonable to me.
> Note that AWT (the base code and the Gtk peers) is 100% merged, so all
> patches have to go in to Classpath as well.  I can take care of this
> though.
> 
> Hans> 1) setVisible calls didn't seem to invoke the right overridden
> Hans> show calls.  The comments seemed to imply that the current code
> Hans> was incorrect.
> 
> I think I made this change (but failed to remove the comment, bleah)
> on the theory that we shouldn't use deprecated methods in our
> implementation.  Compatibility is more important.
> 
> Hans> 4) Both TextField.getPreferredSize and TextArea.getPreferredSize
> Hans> are apparently easily called before peers exist, and they
> Hans> basically give up in that case.  I added code to guess instead,
> Hans> which gets me further, but is clearly wrong.  Suggestions for a
> Hans> real fix would be appreciated.
> 
> One thing to try would be to see what the JDK does.
> 
> Making a guess doesn't seem so bad to me.  It seems like layout ought
> to be recomputed once peers are made.
> 
> Tom
>

Attachment: 0214awtdiff
Description: Binary data