Hi Oleg,
You're right. This is indeed should have been done. Here it follows:
The intention is to support all modern window managers well (Metacity,
KWin, Compiz), and try our best supporting other WMs.
One could think that this is an unimportant problem at all: just show a
frame, and whatever decorations it gets from the window manager - that
are the insets we need. However a Java program might previously set some
desired parameters to the frame, notably:
a) location,
b) size,
c) client area size (via pack()).
Some details regarding the last case: the pack() method may be called
before showing the frame - at this point the peer can report incorrect
insets - we only get real values for the insets after the window has
been shown. Which means that the preferred size set by the Window.pack()
method may be calculated with the incorrect insets, and therefore we
need to resize the frame upon showing it so that the size of the client
area (that actually has been "packed") be preserved.
Upon showing the frame we would like to preserve the desired settings
making the frame appear on the screen as close as possible to what the
user application wants.
On the other hand, window managers may "dance" with their decorations
differently: some preserve the location of the frame, but, or course,
enlarge the size of the window when decorating it. Others may preserve
the size, but change the location of the frame, because the decorations
add some exterior space to the window bounds. Third may keep the
location and the size of the frame, however the client area size will
obviously shrink. Et cetera.
Hence the main responsibility of the insets-related code is to identify
the moment when the window manager has finished its "dancing", then
figure out what exact parameters we want to preserve, and finally
readjust the bounds of the frame accordingly. And of course it would
also be extremely nice to report some actual values to the user space
via the Frame.getInsets() method. :)
The code is centered around one window property and two event handlers
mostly:
1. The frame extents property (in most cases the XA_NET_FRAME_EXTENTS):
modern window managers may be requested to provide the current frame
extents (== insets in Java terminology) as values in this property. Some
can also automatically update the values when the extents change (like
when the theme changes). So we listen to the PropertyNotify event and
update the locally cached value of the extents (named "native insets" in
the terms of the current fix). Sometimes the code resets the native
insets to null (because we think they may have been changed). In these
cases we request the window manager to update the property and then read
its value (see the XDecoratedPeer.retrieveNativeInsets() method).
2. The ReparentNotify event: most window managers reparent user windows
in order to decorate them. Some do that event twice - by reparenting the
already parented frame - creating two levels of parenting from the
user's window to the root window. Mostly the event is used to reset the
locally cached native insets because we usually don't need to get the
insets immediately after reparenting, and we also need to indicate that
we need to get them later. We'll have a better chance upon receiving
subsequent ConfigureNotify events. Besides there even exist
non-reparenting window managers (like Compiz), so we better postpone the
task.
3. The ConfigureNotify event: that is when we actually do our dirty job.
In a nutshell: we skip some ConfigureNotify events since they do not
carry any useful information for us. Then we calculate the current
bounds of the frame based on the values in the XEvent structure and pass
the info to the XDecoratedPeer.setWindowDimensions() method. The method
checks if the bounds of the frame need to be adjusted (i.e. if we just
got shown, and we need to preserve the location and/or size of the
frame). If we need to do that, we just call the reshape() methods with
the desired location/size (see the adjustBounds() method), and stop
processing the request. If the bounds have already been adjusted (which
happens only once per each showing of the frame), the method updates the
dimensions, sends Java events, and does other house keeping stuff.
Basically that is what the code does. A lot more details can be found in
the comment sections inline.
On 06/16/2009 11:44 PM, Oleg Sukhodolsky wrote:
perhaps I'm a lazy guy, but I think that some short description of
main ideas you use
and decisions you've made would help to review the changes.
I hope the description above is short enough for you to get started. :)
Please feel free to ask any further questions.
--
best regards,
Anthony
Oleg.
On Tue, Jun 16, 2009 at 7:06 PM, Anthony Petrov<[email protected]> wrote:
Hello.
The insets-related code in the XToolkit has been a nightmare to maintain for
quite a long time. This fix is a try to rewrite the code making it more
understandable and maintainable.
Testing: all more-or-less related automatic regression tests have been run.
Categories include but not limited to: top-level tests, layouts tests,
embedded frame tests, mouse events tests, focus tests, menu/popup menu
tests, and some other. Nearly 60 tests were found failing with a clean
build, so I filed the corresponding CRs. The rest pass with this fix on:
linux-i586: Gnome/Metacity 2.24, Gnome/Compiz 2.24/0.7.8, KDE/KWin 4.1.3/3.0
solaris-sparc: Gnome/Metacity 2.8, CDE/DTWM Solaris 10
Please review the code at:
http://cr.openjdk.java.net/~anthony/7-16-insets-6689983.0/
Suggestions are welcome. Thanks!
--
best regards,
Anthony
