2.8.5 rc2, wxGTK top level positioning

[Arne Steinarson]

Some time delay in responding, I haven't found a good way to use the archiv=
ed
news-groups yet.

> 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,
Why?

Maybe one could, but wxSystemSettings don't give those values, it means one
would have to query WM through GTK. I have no experience there.

The solution I did gets these sizes by reading back frame extents from
existing
windows and the next time one with the same decoration size is created, it
knows the offsets.

> 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 estimat=
e.
>
> I don't fully understand that, but doesn't this mean that (of all
> wxTLWs) the main wxFrame will be positioned wrongly? I'd say any
> wxDialog can be moved a few pixels here and there, but the main
> wxFrame should be where the user wants it to be.
>
>
That's an argument.

The problems I had was with small dialogs (say 150x100 pixels). Then a
mismatch of 30 pixels is easy to see. Particularly when centering such a
dialog over a child window of the app.

For a larger window a difference of 30 pixels (specially when it is not
centered
over any other window) it is not easy to see.  And the caching algorithm
makes
sure the first time guess would never be that much off.

The alternative would be to start querying the GTK & WM about decoration
sizes. However, using the patch for my needs, it does the job.

Regards
// ATS
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wxwidgets.org/pipermail/wx-dev/attachments/20070827/8eaf5=
47d/attachment.htm