SetInitialSize not working properly under Ubuntu 20.04

58 views
Skip to first unread message

utelle

unread,
Jun 23, 2022, 12:15:25 PM6/23/22
to wx-users
I currently develop a wx application under wxGTK 3.1.7, GCC 9.4.0, Ubuntu 20.04. GTK version 3.24.20.

I have a problem with the vertical sizing of my toplevel wxFrame based dialog. The same code delivers correct results under Windows and macOS. Under OpenSuSE 15.3 with almost identical configuration (wxGTK 3.1.7, GCC 9.3.1, Ubuntu 20.04. GTK version 3.24.20) the dialog is also shown correctly. See below screenshots:

Ubuntu:
porttype-ubuntu.jpg

OpenSuSE:
porttype-opensuse.jpg

Obviously the height of the controls is not correctly determined under Ubuntu. If I adjust the height manually in the debugger, the dialog is shown correctly.

I use nested sizers to arrange the controls. Maybe I did something wrong, but it is a bit strange that the code works as is under other platforms (even a Linux variant).

If someone has an idea, what may cause this problem, I'd be grateful for any hints.

Regards,
Ulrich

Vadim Zeitlin

unread,
Jun 24, 2022, 8:55:52 AM6/24/22
to wx-u...@googlegroups.com
On Thu, 23 Jun 2022 09:15:25 -0700 (PDT) utelle wrote:

u> I have a problem with the vertical sizing of my toplevel wxFrame based
u> dialog. The same code delivers correct results under Windows and macOS.
u> Under OpenSuSE 15.3 with almost identical configuration (wxGTK 3.1.7, GCC
u> 9.3.1, Ubuntu 20.04. GTK version 3.24.20) the dialog is also shown
u> correctly.

Do you use the same desktop environment/window manager under both? Also,
do you use X or Wayland under both or does it differ?

u> If someone has an idea, what may cause this problem, I'd be grateful for
u> any hints.

This could be a bug in window decoration size determination, but we need
to understand in which circumstances exactly does it happen and, of course,
having a minimal example reproducing it would be great, as usual.

Regards,
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
http://www.tt-solutions.com/

utelle

unread,
Jun 24, 2022, 10:43:28 AM6/24/22
to wx-users
Vadim Zeitlin schrieb am Freitag, 24. Juni 2022 um 14:55:52 UTC+2:
Do you use the same desktop environment/window manager under both?

Sorry, that I didn't mention that immediately. The systems use different environments.

OpenSuSE: KDE desktop, X11
Ubuntu: Gnome desktop, X11

Also, do you use X or Wayland under both or does it differ?

Both X11 ... at least if I can trust the output of loginctl.
 
This could be a bug in window decoration size determination, but we need
to understand in which circumstances exactly does it happen and, of course,
having a minimal example reproducing it would be great, as usual.

In the meantime I did some debugging.

Before showing the dialog my code calls SetInitialSize. I checked the sizes that are finally used. Actually, the size is determined by GetBestSize, because no min size is set in advance. Then I measured the size of the displayed dialog windows. And here I have a clear difference between both systems:

OpenSuSE: the total height of the displayed dialog window is higher than the height determined by GetBestSize. GetBestSize returns a height value that does not include the height of the title bar of the dialog. Obviously, the total size of the dialog window is increased internally in wx.

Ubuntu: the total height of the displayed dialog window is exactly equal to the height determined by GetBestSize. I suppose that the normal behaviour of GetBestSize is to not take the height of the title bar into account. However, the total height of the dialog window is obviously not increased by the height of title bar.

Then I inspected what GetBestSize returns when I call it directly for the wxStaticBox that gets squeezed if the total height is too low. And here I was a bit confused. The method DoGetBestSize loops through the list of all child windows of the static box. That's fine and expected, but I was really surprised that the offsets of all child windows were (0,0). Thus the reported best size was actually the max width and max height of all child windows. And that's amazing. Since I used sizers to arrange the child windows, I had expected that the relative positions of the child windows would be taken into account. I could observe this behaviour in both systems, OpenSuSE and Ubuntu. Interestingly, the calculated height was nevertheless correct in OpenSuSE.

Regards,
Ulrich

utelle

unread,
Jun 24, 2022, 3:45:21 PM6/24/22
to wx-users
In the meantime I made an additional experiment using SetClientSize instead of SetInitialSize.

Here are the results of the measurements of the displayed dialog window. All sizes in pixel.

(1) Ubuntu:

GetBestSize returned 458 x 469
SetInitialSize resulted in 458 x 469 (incl titlebar), 458 x 433 (w/o titlebar)
SetClientSize resulted in 458 x 530 (incl titlebar), 458 x 494 (w/o titlebar)

Using SetInitialSize doesn't adjust the height for the title bar, resulting in a too small total dialog height.
Using SetClientSize adds the difference between GetSize and GetClientSize (here (0,25)) to the height, resulting in a too high total dialog height, but at least all elements are visible undistorted.

(2) OpenSuSE:

GetBestSize returned 445 x 460
SetInitialSize resulted in 445 x 490 (incl titlebar), 445 x 460 (w/o titlebar)
SetClientSize resulted in 445 x 515 (incl titlebar), 445 x 485 (w/o titlebar)

Using SetInitialSize sets the total dialog height properly.
Using SetClientSize adds the difference between GetSize and GetClientSize (here (0,25)) to the height, resulting in a too high total dialog height.


That is, unfortunately using SetClientSize does not deliver satisfying results either.

Regards,
Ulrich

utelle

unread,
Jun 26, 2022, 3:01:36 AM6/26/22
to wx-users
> Do you use the same desktop environment/window manager under both?
> Also, do you use X or Wayland under both or does it differ? 

Now I have checked whether using X or Wayland makes a difference. It does not.

I switched on both systems from X to Wayland, but the result was the same as before. Under OpenSuSE (KDE) all is ok, under Ububtu (Gnome) the dialog display is squeezed.

Regards,
Ulrich

Vadim Zeitlin

unread,
Jun 26, 2022, 1:19:05 PM6/26/22
to wx-u...@googlegroups.com
On Sun, 26 Jun 2022 00:01:36 -0700 (PDT) utelle wrote:

u> > Do you use the same desktop environment/window manager under both?
u> > Also, do you use X or Wayland under both or does it differ?
u>
u> Now I have checked whether using X or Wayland makes a difference. It does
u> not.
u>
u> I switched on both systems from X to Wayland, but the result was the same
u> as before. Under OpenSuSE (KDE) all is ok, under Ububtu (Gnome) the dialog
u> display is squeezed.

Sorry, I really have no idea what's going on here and it's very strange
that the behaviour is system- rather Wayland/X11-dependent. Could it be due
to some quirk in determining the best sizes with the Ubuntu theme?

Anyhow, I am just completely out of ideas. Maybe I could find something if
I could debug this, but I'd need a SSCCE for this. And time, of course...

utelle

unread,
Jun 26, 2022, 4:40:50 PM6/26/22
to wx-users
Vadim Zeitlin schrieb am Sonntag, 26. Juni 2022 um 19:19:05 UTC+2:
On Sun, 26 Jun 2022 00:01:36 -0700 (PDT) utelle wrote:

u> > Do you use the same desktop environment/window manager under both?
u> > Also, do you use X or Wayland under both or does it differ?
u>
u> Now I have checked whether using X or Wayland makes a difference. It does
u> not.
u>
u> I switched on both systems from X to Wayland, but the result was the same
u> as before. Under OpenSuSE (KDE) all is ok, under Ububtu (Gnome) the dialog
u> display is squeezed.

Sorry, I really have no idea what's going on here and it's very strange
that the behaviour is system- rather Wayland/X11-dependent.

One idea I had was to use wxPlatformInfo::GetDesktopEnvironment() to determine whether the application is running under KDE or Gnome and simply increase the height manually in case of Gnome as a workaround. However, that doesn't work - it results in an empty string. Is there a way to determine which environment is in use?
 
Could it be due
to some quirk in determining the best sizes with the Ubuntu theme?

I really don't know.

I will try to further debug the problem myself. However, I need a few pointers.

What is method GetBestSize supposed to deliver? The total size of the window including the titlebar? Or only the client size? Or is this system/desktop environment dependent (as it seems to be the case looking at the sizes I see for KDE resp Gnome)?

The comment for method SetClientSize() says: Using this function to size a window tends to be more device-independent than SetSize(), since the application need not worry about what dimensions the border or title bar have when trying to fit the window around panel items, for example.

What I don't understand is that method SetClientSize() resp wxWindowGTK::DoSetClientSize() applies a correction to the width and height, before passing the values on to method SetSize(). And SetSize() then adds further height for the titlebar.

Finally, when and where the correction for the height of the titlebar is applied?
 
Anyhow, I am just completely out of ideas. Maybe I could find something if
I could debug this, but I'd need a SSCCE for this. And time, of course...

First, I will try to find out what's going on based on the existing application, because creating a SSCCE could take quite some time. However, if I don't find out anything, I will try to create a SSCCE.

Regards,
Ulrich

Vadim Zeitlin

unread,
Jun 26, 2022, 5:24:52 PM6/26/22
to wx-u...@googlegroups.com
On Sun, 26 Jun 2022 13:40:50 -0700 (PDT) utelle wrote:

u> One idea I had was to use wxPlatformInfo::GetDesktopEnvironment() to
u> determine whether the application is running under KDE or Gnome and simply
u> increase the height manually in case of Gnome as a workaround. However,
u> that doesn't work - it results in an empty string. Is there a way to
u> determine which environment is in use?

This is supposed to work, please check that libSM was detected by
configure. And if it was, please check what happens inside GetSM() in
src/gtk/utilsgtk.cpp

But this shouldn't be necessary, of course...

u> What is method GetBestSize supposed to deliver? The total size of the
u> window including the titlebar?

Yes.

u> Or only the client size?

This would be GetBestClientSize().

u> What I don't understand is that method SetClientSize() resp
u> wxWindowGTK::DoSetClientSize() applies a correction to the width and
u> height, before passing the values on to method SetSize().

SetClientSize() doesn't do this for TLWs, why do you think it does it?

u> Finally, when and where the correction for the height of the titlebar is
u> applied?

This is complicated because we can have client-side decorations or not,
Wayland or X11, and with the latter we can't get the decorations size
immediately. There is a lot of code dealing with this in
src/gtk/toplevel.cpp.

utelle

unread,
Jun 26, 2022, 6:53:17 PM6/26/22
to wx-users
Vadim Zeitlin schrieb am Sonntag, 26. Juni 2022 um 23:24:52 UTC+2:
u> Is there a way to determine which environment is in use?

This is supposed to work, please check that libSM was detected by
configure. And if it was, please check what happens inside GetSM() in
src/gtk/utilsgtk.cpp

The symbol wxUSE_DETECT_SM has the value 0. Therefore GetSM is not invoked.
 
But this shouldn't be necessary, of course...

u> What is method GetBestSize supposed to deliver? The total size of the
u> window including the titlebar?

Yes.

AFAICT the method ComputeFittingClientSize works correctly. The height correction I mentioned comes from the menu bar. And this is therefore also correct. The point is that GetBestSize does not take the title bar into account, or it can't determine its height.
 
u> What I don't understand is that method SetClientSize() resp
u> wxWindowGTK::DoSetClientSize() applies a correction to the width and
u> height, before passing the values on to method SetSize().

SetClientSize() doesn't do this for TLWs, why do you think it does it?

Ok, this is related to wxFrame. If it has a menubar, the height is corrected accordingly.

u> Finally, when and where the correction for the height of the titlebar is
u> applied?

This is complicated because we can have client-side decorations or not,
Wayland or X11, and with the latter we can't get the decorations size
immediately. There is a lot of code dealing with this in
src/gtk/toplevel.cpp.

All I can tell up to now is that no height correction for the title bar is applied under Ubuntu/Gnome - for whatever reason. I will check what happens under OpenSuSE/KDE tomorrow.

Regards,
Ulrich

Vadim Zeitlin

unread,
Jun 26, 2022, 7:09:55 PM6/26/22
to wx-u...@googlegroups.com
On Sun, 26 Jun 2022 15:53:17 -0700 (PDT) utelle wrote:

u> The symbol wxUSE_DETECT_SM has the value 0. Therefore GetSM is not invoked.

You should be able to see why libSM wasn't detected in config.log, but the
most likely explanation is that the corresponding -dev package wasn't
installed.

u> AFAICT the method ComputeFittingClientSize works correctly. The height
u> correction I mentioned comes from the menu bar. And this is therefore also
u> correct. The point is that GetBestSize does not take the title bar into
u> account, or it can't determine its height.

Probably, yes, but I don't know why. It's supposed to, and this does work
in at least some circumstances.

utelle

unread,
Jun 27, 2022, 3:30:30 AM6/27/22
to wx-users
Vadim Zeitlin schrieb am Montag, 27. Juni 2022 um 01:09:55 UTC+2:
u> The symbol wxUSE_DETECT_SM has the value 0. Therefore GetSM is not invoked.

You should be able to see why libSM wasn't detected in config.log, but the
most likely explanation is that the corresponding -dev package wasn't
installed.

Looking into setup.h for the created wx libraries the symbol has the value 0.

I checked that the package libsm-dev is installed. I'm not sure how to interpret config.log, therefore I attached the file config.log.
 
u> AFAICT the method ComputeFittingClientSize works correctly. The height
u> correction I mentioned comes from the menu bar. And this is therefore also
u> correct. The point is that GetBestSize does not take the title bar into
u> account, or it can't determine its height.

Probably, yes, but I don't know why. It's supposed to, and this does work
in at least some circumstances.

I don't know why the decoration sizes have a value of 0 under my Ubuntu/Gnome system. However, something seems to be wrong on determining the decoration sizes. I will try to provide a minimal sample within the next couple of days.

For the time being I will live with the workaround I found:

1) Retrieve GetBestSize
2) Retrieve GetSize
3) Retrieve GetClientSize
4) Calculate clientSize = GetBestSize - (GetSize - GetClientSize)
5) Use the calculated size for SetClientSize

(instead of using SetInitialSize).

However, in the long run I think it would be nice and better if SetInitialSize would work as expected under all circumstances.

Regards,
Ulrich
config.log

Vadim Zeitlin

unread,
Jun 27, 2022, 11:06:50 AM6/27/22
to wx-u...@googlegroups.com
On Mon, 27 Jun 2022 00:30:30 -0700 (PDT) utelle wrote:

u> Vadim Zeitlin schrieb am Montag, 27. Juni 2022 um 01:09:55 UTC+2:
u>
u> > u> The symbol wxUSE_DETECT_SM has the value 0. Therefore GetSM is not
u> > invoked.
u> >
u> > You should be able to see why libSM wasn't detected in config.log, but the
u> > most likely explanation is that the corresponding -dev package wasn't
u> > installed.
u> >
u>
u> Looking into setup.h for the created wx libraries the symbol has the value
u> 0.
u>
u> I checked that the package libsm-dev is installed. I'm not sure how to
u> interpret config.log, therefore I attached the file config.log.

Something is wrong here as the attached config.log clearly shows that
libSM was successfully detected and contains

#define wxUSE_DETECT_SM 1

so you should have it on in your build.

u> I don't know why the decoration sizes have a value of 0 under my
u> Ubuntu/Gnome system. However, something seems to be wrong on determining
u> the decoration sizes. I will try to provide a minimal sample within the
u> next couple of days.

Thanks, I hope we can find what goes wrong then...

u> For the time being I will live with the workaround I found:
u>
u> 1) Retrieve GetBestSize
u> 2) Retrieve GetSize
u> 3) Retrieve GetClientSize
u> 4) Calculate clientSize = GetBestSize - (GetSize - GetClientSize)
u> 5) Use the calculated size for SetClientSize
u>
u> (instead of using SetInitialSize).

I don't understand what is the advantage of doing this instead of just
using SetClientSize(GetBestClientSize()) directly?

u> However, in the long run I think it would be nice and better if
u> SetInitialSize would work as expected under all circumstances.

Yes, of course.

utelle

unread,
Jun 27, 2022, 12:57:49 PM6/27/22
to wx-users
Vadim Zeitlin schrieb am Montag, 27. Juni 2022 um 17:06:50 UTC+2:
u> Looking into setup.h for the created wx libraries the symbol has the value
u> 0.
u>
u> I checked that the package libsm-dev is installed. I'm not sure how to
u> interpret config.log, therefore I attached the file config.log.

Something is wrong here as the attached config.log clearly shows that
libSM was successfully detected and contains

#define wxUSE_DETECT_SM 1

so you should have it on in your build.

I checked again. And you are right. The symbol is defined as you say. Sorry for the confusion. I'm sure where I looked and got it wrong.

Nevertheless, the desktop environment is not detected and wxPlatFormInfo::Get().GetDesktopEnvironment() returns an empty string. I debugged the code and found out that GetSM() returns the value "gnome-session", but that value is compared with "GnomeSM". Not equal, therefore an empty string is returned.
 
u> For the time being I will live with the workaround I found:
u>
u> 1) Retrieve GetBestSize
u> 2) Retrieve GetSize
u> 3) Retrieve GetClientSize
u> 4) Calculate clientSize = GetBestSize - (GetSize - GetClientSize)
u> 5) Use the calculated size for SetClientSize
u>
u> (instead of using SetInitialSize).

I don't understand what is the advantage of doing this instead of just
using SetClientSize(GetBestClientSize()) directly?

Sorry, there exists no method GetBestClientSize(). I only found the protected method DoGetBestClientSize(). Usually methods with the "Do" prefix should not be called directly in application code, but maybe this isn't true in this use case.
 
Regards,
Ulrich

Vadim Zeitlin

unread,
Jun 27, 2022, 1:07:59 PM6/27/22
to wx-u...@googlegroups.com
On Mon, 27 Jun 2022 09:57:49 -0700 (PDT) utelle wrote:

u> Nevertheless, the desktop environment is not detected and
u> wxPlatFormInfo::Get().GetDesktopEnvironment() returns an empty string. I
u> debugged the code and found out that GetSM() returns the value
u> "gnome-session", but that value is compared with "GnomeSM". Not equal,
u> therefore an empty string is returned.

Wow, it looks like "GnomeSM" was used with Gnome 2.0 (but I'm not even
sure about it), so we should definitely recognize "gnome-session" here
nowadays. I'll make a PR...

u> Sorry, there exists no method GetBestClientSize().

Oops, yes, you're right, sorry. But for a dialog you would typically use
wxSizer::ComputeFittingClientSize() with its top level size. And this is
also what wxSizer::Fit() does.

utelle

unread,
Jun 27, 2022, 4:30:54 PM6/27/22
to wx-users
Vadim Zeitlin schrieb am Montag, 27. Juni 2022 um 19:07:59 UTC+2:
u> I debugged the code and found out that GetSM() returns the value
u> "gnome-session", but that value is compared with "GnomeSM". Not equal,
u> therefore an empty string is returned.

Wow, it looks like "GnomeSM" was used with Gnome 2.0 (but I'm not even
sure about it), so we should definitely recognize "gnome-session" here
nowadays. I'll make a PR...

Maybe just checking whether the returned string starts with (or contains) the substring "gnome", would be better than checking for a specific string.
 
u> Sorry, there exists no method GetBestClientSize().

Oops, yes, you're right, sorry. But for a dialog you would typically use
wxSizer::ComputeFittingClientSize() with its top level size. And this is
also what wxSizer::Fit() does.

I call SetSizerAndFit() for the main wxPanel that is added as the content area to a wxFrame. And as far as I can remember this method calls ComputeFittingClientSize() internally. However, I have to call SetInitialSize or SetClientSize, before the window is displayed. Otherwise the wxFrame is not displayed with correct sizes.

Regards,
Ulrich

Vadim Zeitlin

unread,
Jun 27, 2022, 8:03:42 PM6/27/22
to wx-u...@googlegroups.com
On Mon, 27 Jun 2022 13:30:54 -0700 (PDT) utelle wrote:

u> Vadim Zeitlin schrieb am Montag, 27. Juni 2022 um 19:07:59 UTC+2:
u>
u> > u> I debugged the code and found out that GetSM() returns the value
u> > u> "gnome-session", but that value is compared with "GnomeSM". Not equal,
u> > u> therefore an empty string is returned.
u> >
u> > Wow, it looks like "GnomeSM" was used with Gnome 2.0 (but I'm not even
u> > sure about it), so we should definitely recognize "gnome-session" here
u> > nowadays. I'll make a PR...
u> >
u>
u> Maybe just checking whether the returned string starts with (or contains)
u> the substring "gnome", would be better than checking for a specific string.

Good idea, thanks, please check https://github.com/wxWidgets/wxWidgets/pull/22575

u> I call SetSizerAndFit() for the main wxPanel that is added as the content
u> area to a wxFrame. And as far as I can remember this method calls
u> ComputeFittingClientSize() internally. However, I have to call
u> SetInitialSize or SetClientSize, before the window is displayed. Otherwise
u> the wxFrame is not displayed with correct sizes.

This is very strange because SetSizerAndFit() really should result in
setting the client size to the correct value... Again, sorry for lack of
help but I just don't understand at all what's going on in your case.

utelle

unread,
Jun 28, 2022, 5:32:35 AM6/28/22
to wx-users
Vadim Zeitlin schrieb am Dienstag, 28. Juni 2022 um 02:03:42 UTC+2:
u> Maybe just checking whether the returned string starts with (or contains)
u> the substring "gnome", would be better than checking for a specific string.

Good idea, thanks, please check https://github.com/wxWidgets/wxWidgets/pull/22575

Yes, that makes the detection of the window manager operational again.

It doesn't solve the initial sizing issue, though. The longer I think about it the more I believe that the explanation is not the window manager in use. The code that determines the decoration sizes does not check for a specific window manager. It also doesn´t seem to be related to differences between X11 and Wayland, because both test systems use X11. BTW, I tested Wayland, too, by switching to Wayland on both systems - no real change in behaviour.
 
u> However, I have to call
u> SetInitialSize or SetClientSize, before the window is displayed. Otherwise
u> the wxFrame is not displayed with correct sizes.

This is very strange because SetSizerAndFit() really should result in
setting the client size to the correct value... Again, sorry for lack of
help but I just don't understand at all what's going on in your case.

As I mentioned in my previous post I have a wxFrame to which I added a wxPanel as the content area. I did a few more experiments.

Experiment 1:
I added the following code line:
mainFrame->SetClientSize(mainPanel->GetBestSize());
That solved the issue.

Experiment 2:
Instead of adding the main panel directly to the main frame, I introduced an additional sizer to which I then added the main panel. Then I finally called
topSizer->Add(mainPanel, wxSizerFlags().Expand());
mainFrame->SetSizerAndFit(topSizer);
That solved the issue, too.

According to the wxFrame documentation adding a panel directly to a wxFrame is perfectly legal. And since I had called mainPanel->SetSizerAndFit() I was actually surprised that it worked on some systems, but not on all.

Now, that I found solutions that work without resorting to manual size calculations, I'm not sure how to continue from here. Is this still something worth to further investigate? If yes, I can provide a minimal sample, of course.

Regards,
Ulrich

Vadim Zeitlin

unread,
Jun 28, 2022, 8:00:14 AM6/28/22
to wx-u...@googlegroups.com
On Tue, 28 Jun 2022 02:32:35 -0700 (PDT) utelle wrote:

u> Vadim Zeitlin schrieb am Dienstag, 28. Juni 2022 um 02:03:42 UTC+2:
u>
u> > u> Maybe just checking whether the returned string starts with (or
u> > contains)
u> > u> the substring "gnome", would be better than checking for a specific
u> > string.
u> >
u> > Good idea, thanks, please check
u> > https://github.com/wxWidgets/wxWidgets/pull/22575
u>
u> Yes, that makes the detection of the window manager operational again.

Thanks for testing, merged now.

u> As I mentioned in my previous post I have a wxFrame to which I added a
u> wxPanel as the content area. I did a few more experiments.
u>
u> Experiment 1:
u> I added the following code line:
u> mainFrame->SetClientSize(mainPanel->GetBestSize());
u> That solved the issue.
u>
u> Experiment 2:
u> Instead of adding the main panel directly to the main frame, I introduced
u> an additional sizer to which I then added the main panel. Then I finally
u> called
u> topSizer->Add(mainPanel, wxSizerFlags().Expand());
u> mainFrame->SetSizerAndFit(topSizer);
u> That solved the issue, too.
u>
u> According to the wxFrame documentation adding a panel directly to a wxFrame
u> is perfectly legal. And since I had called mainPanel->SetSizerAndFit() I
u> was actually surprised that it worked on some systems, but not on all.
u>
u> Now, that I found solutions that work without resorting to manual size
u> calculations, I'm not sure how to continue from here. Is this still
u> something worth to further investigate? If yes, I can provide a minimal
u> sample, of course.

I'd still like to have a sample please because I still don't understand
what's going on here. This must be somehow related to wxGTK-specific hack
with WXSetInitialFittingClientSize() (see src/gtk/toplevel.cpp for the gory
details), but I don't see how yet. Hopefully comparing the working and not
working versions behaviours side by side would help understanding this, so
if you could please open a new issue with the simplest possible example or
patch allowing to reproduce the problem, it would be great.

TIA!
Reply all
Reply to author
Forward
0 new messages