#19134: Using wxNotebook with dev-latest and GTK3 always causes minimum TLW sizing even if setting a larger initial window size with PersistenceManager or explicit SetSize()

21 views
Skip to first unread message

wxTrac

unread,
Apr 9, 2021, 4:32:48 PM4/9/21
to wx-...@googlegroups.com
#19134: Using wxNotebook with dev-latest and GTK3 always causes minimum TLW sizing
even if setting a larger initial window size with PersistenceManager or
explicit SetSize()
------------------------+--------------------
Reporter: jdagresta | Owner:
Type: defect | Status: new
Priority: normal | Milestone:
Component: wxGTK | Version: 3.1.4
Keywords: wxNotebook | Blocked By:
Blocking: | Patch: 0
------------------------+--------------------
Our application has a Dialog window that contains a wxNotebook (with a
number of wxPanel's) as well as a wxTextCtrl (message log window) to the
right of the wxNotebook and button areas above and below the wxNotebook.

Our application uses wxPeristenceManager to save/restore the last Dialog
window size.

When building our application on (Red Hat) Linux with wxWidgets 3.1.4 (or
dev-latest) and built for GTK3, the Dialog window "flashes" at the
appropriate saved window size (from Persistence Manager) but then always
resizes to the "minimum" size of the contained widgets (both horizontally
and vertically).

Also, even if the user then expands quite a bit the window size (both
horizontally and vertically) and then exits the Dialog, the Persistence
Manager is always saving the "minimum" dialog window size. Then we
manually edit the Width=/Height= values in the Persistence Manager save
file back to the much large sizes, but when re-starting the application
the same thing happens again - the dialog window "flashes" at the
specified size and then immediately shrinks down to the "minimum" size.

This problem happens with version 3.1.4 or dev-latest, but only if built
for GTK3 (--with-gtk3, which is the default). If we change to build with
GTK2 (--with-gtk2) this problem does not occur.

If we use wxWidgets version 3.0.5, this problem does not occur whether we
build with GTK2 or GTK3.

I've been able to reproduce the problem by making only a small change to
the notebook sample to effectively add a SetSize(900,600) call in OnInit()
to mimic what wxPersistenceManager is doing in our application.

Use the [[notebook_sample.patch]] attachment to modify the notebook
sample, and build the sample with wxWidgets 3.1.4 or dev-latest and built
for GTK3.

As soon as you run the `notebook` sample, you will see the problem.

In order to easily see this "initial sizing" problem with the modified
notebook sample, use appropriate large Width/Height values in the code
modifications according to the screen resolution being used for testing.

Details of our environment:
Red Hat Enterprise Linux Server release 7.9 (Maipo)
gtk2 version 2.24.31
gtk3 version_3.22.30
dev-latest we tested with was dated:_March 30, 2021
Screen Resolution: 1440 x 900

--
Ticket URL: <https://trac.wxwidgets.org/ticket/19134>

wxTrac

unread,
Apr 9, 2021, 4:33:10 PM4/9/21
to wx-...@googlegroups.com
#19134: Using wxNotebook with dev-latest and GTK3 always causes minimum TLW sizing
even if setting a larger initial window size with PersistenceManager or
explicit SetSize()
------------------------+------------------------
Reporter: jdagresta | Owner:
Type: defect | Status: new
Priority: normal | Milestone:
Component: wxGTK | Version: 3.1.4
Resolution: | Keywords: wxNotebook
Blocked By: | Blocking:
Patch: 0 |
------------------------+------------------------
Changes (by jdagresta):

* Attachment "notebook_sample.patch" added.

wxTrac

unread,
Apr 10, 2021, 8:29:24 AM4/10/21
to wx-...@googlegroups.com
#19134: Using wxNotebook with dev-latest and GTK3 always causes minimum TLW sizing
even if setting a larger initial window size with PersistenceManager or
explicit SetSize()
------------------------+------------------------
Reporter: jdagresta | Owner:
Type: defect | Status: confirmed
Priority: normal | Milestone: 3.1.5
Component: wxGTK | Version: 3.1.4
Resolution: | Keywords: wxNotebook
Blocked By: | Blocking:
Patch: 0 |
------------------------+------------------------
Changes (by vadz):

* status: new => confirmed
* milestone: => 3.1.5


Comment:

Thanks, I can indeed see this.

With the following patch
{{{
#!diff
diff --git a/samples/notebook/notebook.cpp b/samples/notebook/notebook.cpp
index 4bfcbf563e..fe782690aa 100644
--- a/samples/notebook/notebook.cpp
+++ b/samples/notebook/notebook.cpp
@@ -52,6 +52,12 @@ bool MyApp::OnInit()
frame->SetSize(wxDefaultCoord, wxDefaultCoord, width, height);
#endif

+ frame->SetSize(wxSize(900, 600));
+ frame->Bind(wxEVT_SIZE, [](wxSizeEvent& e) {
+ wxPrintf("Frame size: %d*%d\n", e.GetSize().x, e.GetSize().y);
+ e.Skip();
+ });
+
frame->Show();

return true;
}}}
the output is
{{{
Frame size: 900*600
Frame size: 354*330
Frame size: 900*592
Frame size: 354*322
}}}

And the problem seems to come from the bad interaction between
`wxSizer::SetSizeHintsOnShow()` (see
f655a52fba3109570ec7cdf137c2173c7921edd2) and the deferred decoration size
determination in wxTLW. I.e. we somehow need to avoid setting size hints
when the window is shown if its size has been explicitly set/changed in
the meanwhile.

Paul, perhaps you can already see a simple way of doing it? If not, I'll
try to fix it myself, ideally even before 3.1.5 because this does seem
like a rather bad regression.

--
Ticket URL: <https://trac.wxwidgets.org/ticket/19134#comment:1>

wxTrac

unread,
Apr 10, 2021, 9:32:32 AM4/10/21
to wx-...@googlegroups.com
#19134: Using wxNotebook with dev-latest and GTK3 always causes minimum TLW sizing
even if setting a larger initial window size with PersistenceManager or
explicit SetSize()
------------------------+------------------------
Reporter: jdagresta | Owner:
Type: defect | Status: confirmed
Priority: normal | Milestone: 3.1.5
Component: wxGTK | Version: 3.1.4
Resolution: | Keywords: wxNotebook
Blocked By: | Blocking:
Patch: 0 |
------------------------+------------------------

Comment (by vadz):

After thinking more about this, I believe the simplest solution would be
to move GTK workaround from `wxSizer` code to `wxTLW` itself, i.e. call
some new `virtual void wxWindow::UpdateClientSize(wxSize, int flags =
ClientSize_SetMin)` (I hesitate changing `SetClientSize()` itself like
this because this could have unforeseen consequences for its existing
uses) that would just call `SetMinClientSize()` if `ClientSize_SetMin` is
specified in flags and then `SetClientSize()` by default, but would be
overridden in wxGTK wxTLW to remember the size and reset it when the
window is shown.

This would allow to reset this remembered size if `SetSize()` is called in
the meanwhile, fixing this bug, and would also avoid `__WXGTK3__` checks
in common sizer code.

What do you think?

--
Ticket URL: <https://trac.wxwidgets.org/ticket/19134#comment:2>

wxTrac

unread,
Apr 10, 2021, 10:39:50 AM4/10/21
to wx-...@googlegroups.com
#19134: Using wxNotebook with dev-latest and GTK3 always causes minimum TLW sizing
even if setting a larger initial window size with PersistenceManager or
explicit SetSize()
------------------------+------------------------
Reporter: jdagresta | Owner:
Type: defect | Status: confirmed
Priority: normal | Milestone: 3.1.5
Component: wxGTK | Version: 3.1.4
Resolution: | Keywords: wxNotebook
Blocked By: | Blocking:
Patch: 0 |
------------------------+------------------------

Comment (by pcor):

I'll try to look at this later today.

--
Ticket URL: <https://trac.wxwidgets.org/ticket/19134#comment:3>

wxTrac

unread,
Apr 12, 2021, 6:25:29 PM4/12/21
to wx-...@googlegroups.com
#19134: Using wxNotebook with dev-latest and GTK3 always causes minimum TLW sizing
even if setting a larger initial window size with PersistenceManager or
explicit SetSize()
------------------------+-------------------------------------
Reporter: jdagresta | Owner: Vadim Zeitlin <vadim@…>
Type: defect | Status: closed
Priority: normal | Milestone: 3.1.5
Component: wxGTK | Version: 3.1.4
Resolution: fixed | Keywords: wxNotebook
Blocked By: | Blocking:
Patch: 0 |
------------------------+-------------------------------------
Changes (by Vadim Zeitlin <vadim@…>):

* owner: => Vadim Zeitlin <vadim@…>
* status: confirmed => closed
* resolution: => fixed


Comment:

In [changeset:"645e1d2fd0eaaa1db4a3ae4590d303784584aad2/git-wxWidgets"
645e1d2fd/git-wxWidgets]:
{{{
#!CommitTicketReference repository="git-wxWidgets"
revision="645e1d2fd0eaaa1db4a3ae4590d303784584aad2"
Don't overwrite explicitly set size with pending client size

Calls to SetSize() were ignored in wxGTK if they happened after calling
wxSizer::Fit() since the changes of f655a52fba (Allow wxSizer::Fit() to
work properly when called from TLW ctor on GTK3, 2020-04-20) because we
overwrote the explicitly set size with the client size computed earlier
by the sizer.

Don't do this by explicitly forgetting the client size we were going to
set when SetSize() is called.

Closes #19134.
}}}

--
Ticket URL: <https://trac.wxwidgets.org/ticket/19134#comment:4>

wxTrac

unread,
Apr 12, 2021, 6:25:30 PM4/12/21
to wx-...@googlegroups.com
#19134: Using wxNotebook with dev-latest and GTK3 always causes minimum TLW sizing
even if setting a larger initial window size with PersistenceManager or
explicit SetSize()
------------------------+-------------------------------------
Reporter: jdagresta | Owner: Vadim Zeitlin <vadim@…>
Type: defect | Status: closed
Priority: normal | Milestone: 3.1.5
Component: wxGTK | Version: 3.1.4
Resolution: fixed | Keywords: wxNotebook
Blocked By: | Blocking:
Patch: 0 |
------------------------+-------------------------------------

Comment (by Vadim Zeitlin <vadim@…>):

In [changeset:"9c0a8be1dc32063d91ed1901fd5fcd54f4f955a1/git-wxWidgets"
9c0a8be1d/git-wxWidgets]:
{{{
#!CommitTicketReference repository="git-wxWidgets"
revision="9c0a8be1dc32063d91ed1901fd5fcd54f4f955a1"
Merge branch 'gtk-initial-size'

Fix initial size of TLWs in wxGTK when using both sizers and explicit
SetSize() calls.

See https://github.com/wxWidgets/wxWidgets/pull/2322

See #16088, #19134.
}}}

--
Ticket URL: <https://trac.wxwidgets.org/ticket/19134#comment:5>
Reply all
Reply to author
Forward
0 new messages