2.8.5 rc2, wxGTK top level positioning

[Arne Steinarson]

> actual size just doesn't match. The window comes out positioned in
> a slightly wrong place, and the size can be off with 10..30 pixels.

This is a known and annoying problem, but a cleaner approach
to solving it would be highly appreciated. Unless I'm entirely
mistaken, this function

Yes, I've gone over the issue in quite some detail now. The solution
(my patch) addresses the full problem. I understand the background and
how GTK does the positioning/moving of windows.

It all boils down to wxWidgets handling window sizes _including_ frame
decorations and GTK API calls handling sizes _without_ decoration sizes.

So, this difference has to be accounted for in all calls to GTK that
involve TLW sizes. The patch does this AFAIK.


mistaken, this function

http://library.gnome.org/devel/gdk/unstable/gdk-Windows.html#gdk-window-get=
-frame-extents

can be used to get the size of the frame with decorations and
it should be able to calculate the missing values from it.
Would you have time to have a look at this? I don't really

Yes, I use gdk_window_get_frame_extents already. That's how the difference
between wxWindow size and GTK window size is calculated.

In order to account for the difference, I created a cache of decoration
sizes (what the window manager adds around a TWL). The first time a TLW
of a particular GDK style (m_gdkDecor) is shown (in Create), one cannot
know this value, but an decent guess can be made.

The next time around however, one will know the size of decorations, and
the window can be positioned exactly as requested by the user.

In reality, an app is likely to use only one or two GDK decor styles, so
it would be very difficult to notice the effect of the 1st time estimate.
(The 1st dialog will come out OK, since it usually have the same decoration
as the main window).


When it comes to the patch, the improvement I can see would be in terms
of naming of a couple of functions and variables, otherwise, I feel it's
quite OK.


Regards
// Arne Steinarson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wxwidgets.org/pipermail/wx-dev/attachments/20070823/31636=
7c9/attachment.htm