[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comment to 0.19
From: |
Thomas Fitzsimmons |
Subject: |
Re: Comment to 0.19 |
Date: |
Mon, 07 Nov 2005 15:36:47 -0500 |
On Mon, 2005-11-07 at 14:11 +0000, theUser BL wrote:
> > > Additional to bugs, which Sun have, GNU Classpath have its own bugs. I
> >have
> > > seen, that the AWT don't recognice, when the window was moved.
> > > For example the Listing2902 at
> > > http://www.mycore.de/library/go-to-java-2/html/k100181.html
> > > works only right at start. But if you move the window, the program don't
> > > recogniczed it.
> > > Only to mention it. Because without completly functional AWT, a
> >completly
> > > functional Swing isn't possible.
> >
> >Please file this as a bug report if you haven't already.
> >
> >Thanks for your comments. If you feel we should fix the first bug (that
> >would be possible since we are talking about a not-specified area),
> >please also file a bug report.
>
> I haven't done it. And I would be happy, if anybody other doing it.
This is a hard bug -- we need to update the x and y fields of the Window
without causing it to call back into the peers to move the GtkWindowPeer
to a specific location. I've never been able to receive reliable
configure events from the window manager on window-move events. The
symptom of blindly updating a Window's position with setBounds calls
from the peers is a move-set loop that causes windows to either wiggle
back and forth between two positions or to glide across the screen
before hitting an edge (at which point window manager limits kick in).
My previous workaround was ugly but it did work. I had a package
private method in Window called setBoundsCallback that the peers called
and would not in turn attempt to move the window peer (see CVS history).
For now we could revive that patch, though Sven would likely object.
To fix this properly, we need to analyze how window managers produce
configure events and why the ones we receive are not consistent. This
may require a window manager fix, or it may require us to ignore certain
events. However I'd like to avoid heuristics since they didn't work
reliably for me in the past.
I recommend testing on metacity which has great developer support
features (e.g. good debug output logging, simple Xnest setup).
Tom