X11 with GTK3: Main window height is increased by 37 pixels on app start (Issue #25348)
Valentyn Shtronda
valiko-ua created an issue (wxWidgets/wxWidgets#25348)Bug description:
When using X11 with GTK3, the main window height is increased by 37 pixels after successful wxFrame::SetSize() in wxApp::OnInit().
I tried several wxWidgets versions, all have the same problem: 2.9.5, 3.2.8, 3.3.0.
Expected vs observed behavior:
On app start, I restore main window dimensions by calling wxFrame::SetSize() in wxApp::OnInit().
GetSize called just after SetSize returns values that I specified.
But after exit from OnInit the window height is increased by 37 pixels.
The problem is only reproduced with X11 (choose "Ubuntu on Xorg" during logon).
With Wayland the window size is restored correctly (Wayland has other by-design "problem": it does not support setting window position but that's a different story).
Patch or snippet allowing to reproduce the problem:
repro-for-my-bug.patch
To Reproduce:
- Modify
minimalsample with the attached patch. I made it against the latest commit 9495129. I added two menu commands:Get(F2) andSet(F3) to get and set window placement and print info to console. - Build.
- Launch it from terminal to see debug printing.
- Press F2 in the app to print window placement.
- Observe in terminal that the height is correctly set to
400inOnInitand later increased by 37:
LoadWindowPlacement: x = 1000, y = 200, w = 800, h = 400, m = 0
Set: x = 1000, y = 200, w = 800, h = 400, m = 0
Get: x = 1000, y = 200, w = 800, h = 400, m = 0
Get: x = 1000, y = 200, w = 800, h = 437, m = 0
On Wayland it works as expected:
LoadWindowPlacement: x = 1000, y = 200, w = 800, h = 400, m = 0
Set: x = 1000, y = 200, w = 800, h = 400, m = 0
Get: x = 1000, y = 200, w = 800, h = 400, m = 0
Get: x = 26, y = 23, w = 800, h = 400, m = 0
Platform and version information
- wxWidgets version: 3.2.8, 2.9.5, 3.3.0 (commit 9495129)
- OS: Ubuntu 24.10
- GTK version: 3.24.43 (there is also 4.16.3 installed but I suppose GTK3 is used)
- GDK backend: X11 (I chose "Ubuntu on Xorg" during logon)
- Desktop environment: Gnome
- Current theme: Yaru
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Valentyn Shtronda
valiko-ua left a comment (wxWidgets/wxWidgets#25348)Attachment does not work. Here is the patch:
diff --git a/samples/minimal/minimal.cpp b/samples/minimal/minimal.cpp
index 5f32257c6b..a12e5eea83 100644
--- a/samples/minimal/minimal.cpp
+++ b/samples/minimal/minimal.cpp
@@ -63,10 +63,18 @@ public:
// event handlers (these functions should _not_ be virtual)
void OnQuit(wxCommandEvent& event);
void OnAbout(wxCommandEvent& event);
+ void OnGet(wxCommandEvent& event);
+ void OnSet(wxCommandEvent& event);
+
+ void LoadWindowPlacement();
+ void GetCurDims();
+ void SetCurDims();
private:
// any class wishing to process wxWidgets events must use this macro
wxDECLARE_EVENT_TABLE();
+
+ int _x = 1000, _y = 200, _w = 800, _h = 400, _m = 0;
};
// ----------------------------------------------------------------------------
@@ -76,6 +84,9 @@ private:
// IDs for the controls and the menu commands
enum
{
+ Minimal_Get = 1,
+ Minimal_Set,
+
// menu items
Minimal_Quit = wxID_EXIT,
@@ -95,6 +106,8 @@ enum
wxBEGIN_EVENT_TABLE(MyFrame, wxFrame)
EVT_MENU(Minimal_Quit, MyFrame::OnQuit)
EVT_MENU(Minimal_About, MyFrame::OnAbout)
+ EVT_MENU(Minimal_Get, MyFrame::OnGet)
+ EVT_MENU(Minimal_Set, MyFrame::OnSet)
wxEND_EVENT_TABLE()
// Create a new application object: this macro will allow wxWidgets to create
@@ -123,6 +136,8 @@ bool MyApp::OnInit()
// create the main application window
MyFrame *frame = new MyFrame("Minimal wxWidgets App");
+ frame->LoadWindowPlacement();
+
// and show it (the frames, unlike simple controls, are not shown when
// created initially)
frame->Show(true);
@@ -152,6 +167,8 @@ MyFrame::MyFrame(const wxString& title)
wxMenu *helpMenu = new wxMenu;
helpMenu->Append(Minimal_About, "&About\tF1", "Show about dialog");
+ fileMenu->Append(Minimal_Get, "Get\tF2", "Gets window dimensions");
+ fileMenu->Append(Minimal_Set, "Set\tF3", "Sets window dimensions");
fileMenu->Append(Minimal_Quit, "E&xit\tAlt-X", "Quit this program");
// now append the freshly created menu to the menu bar...
@@ -201,3 +218,33 @@ void MyFrame::OnAbout(wxCommandEvent& WXUNUSED(event))
wxOK | wxICON_INFORMATION,
this);
}
+
+void MyFrame::GetCurDims()
+{
+ auto pos = GetPosition();
+ auto sz = GetSize();
+ std::printf("Get: x = %4i, y = %4i, w = %4i, h = %4i, m = %i\n", pos.x, pos.y, sz.GetWidth(), sz.GetHeight(), (int)IsMaximized());
+}
+
+void MyFrame::SetCurDims()
+{
+ std::printf("Set: x = %4i, y = %4i, w = %4i, h = %4i, m = %i\n", _x, _y, _w, _h, _m);
+ SetSize(_x, _y, _w, _h);
+ GetCurDims();
+}
+
+void MyFrame::OnGet(wxCommandEvent& WXUNUSED(event))
+{
+ GetCurDims();
+}
+
+void MyFrame::OnSet(wxCommandEvent& WXUNUSED(event))
+{
+ SetCurDims();
+}
+
+void MyFrame::LoadWindowPlacement()
+{
+ std::printf("LoadWindowPlacement: x = %4i, y = %4i, w = %4i, h = %4i, m = %i\n", _x, _y, _w, _h, _m);
+ SetCurDims();
+}
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#25348)As a workaround, saving and restoring client size may work.
For the reference, which Gnome version is this?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Ian McInerney
imciner2 left a comment (wxWidgets/wxWidgets#25348)This sounds like the window decorations are being added to the height returned after the frame is being realized.
We have hit this before in KiCad in various configurations, described here https://gitlab.com/kicad/code/kicad/-/issues/4278. Then we added code to try working around it, and we ended up actually shrinking the window instead: https://gitlab.com/kicad/code/kicad/-/issues/8889.
We have code to restore window size here https://gitlab.com/kicad/code/kicad/-/blob/master/common/eda_base_frame.cpp?ref_type=heads#L756, and save it here https://gitlab.com/kicad/code/kicad/-/blob/master/common/eda_base_frame.cpp?ref_type=heads#L916, and it seems to be working so far.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Valentyn Shtronda
valiko-ua left a comment (wxWidgets/wxWidgets#25348)@vadz Gnome version 47.
@imciner2 Yes, during my debugging attempts, I've seen that decoration size was added twice (+37, +37), the second one was excessive. Let me process information you provided.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Valentyn Shtronda
valiko-ua left a comment (wxWidgets/wxWidgets#25348)Indeed, saving/restoring client area size works. It doesn't even look like a workaround:
bug-fix.patchdiff --git a/samples/minimal/minimal.cpp b/samples/minimal/minimal.cpp
index 5f32257c6b..05a244215e 100644
--- a/samples/minimal/minimal.cpp
+++ b/samples/minimal/minimal.cpp
@@ -63,10 +63,18 @@ public:
// event handlers (these functions should _not_ be virtual)
void OnQuit(wxCommandEvent& event);
void OnAbout(wxCommandEvent& event);
+ void OnGet(wxCommandEvent& event);
+ void OnSet(wxCommandEvent& event);
+
+ void LoadWindowPlacement();
+ void GetCurDims();
+ void SetCurDims();
private:
// any class wishing to process wxWidgets events must use this macro
wxDECLARE_EVENT_TABLE();
+
+ int _x = 1000, _y = 200, _w = 800, _h = 400, _m = 0;
};
// ----------------------------------------------------------------------------
@@ -76,6 +84,9 @@ private:
// IDs for the controls and the menu commands
enum
{
+ Minimal_Get = 1,
+ Minimal_Set,
+
// menu items
Minimal_Quit = wxID_EXIT,
@@ -95,6 +106,8 @@ enum
wxBEGIN_EVENT_TABLE(MyFrame, wxFrame)
EVT_MENU(Minimal_Quit, MyFrame::OnQuit)
EVT_MENU(Minimal_About, MyFrame::OnAbout)
+ EVT_MENU(Minimal_Get, MyFrame::OnGet)
+ EVT_MENU(Minimal_Set, MyFrame::OnSet)
wxEND_EVENT_TABLE()
// Create a new application object: this macro will allow wxWidgets to create
@@ -123,6 +136,8 @@ bool MyApp::OnInit()
// create the main application window
MyFrame *frame = new MyFrame("Minimal wxWidgets App");
+ frame->LoadWindowPlacement();
+
// and show it (the frames, unlike simple controls, are not shown when
// created initially)
frame->Show(true);
@@ -152,6 +167,8 @@ MyFrame::MyFrame(const wxString& title)
wxMenu *helpMenu = new wxMenu;
helpMenu->Append(Minimal_About, "&About\tF1", "Show about dialog");
+ fileMenu->Append(Minimal_Get, "Get\tF2", "Gets window dimensions");
+ fileMenu->Append(Minimal_Set, "Set\tF3", "Sets window dimensions");
fileMenu->Append(Minimal_Quit, "E&xit\tAlt-X", "Quit this program");
// now append the freshly created menu to the menu bar...
@@ -201,3 +218,34 @@ void MyFrame::OnAbout(wxCommandEvent& WXUNUSED(event))
wxOK | wxICON_INFORMATION,
this);
}
+
+void MyFrame::GetCurDims()
+{
+ auto pos = GetPosition();
+ auto sz = GetClientSize();
+ std::printf("Get: x = %4i, y = %4i, w = %4i, h = %4i, m = %i\n", pos.x, pos.y, sz.GetWidth(), sz.GetHeight(), (int)IsMaximized());
+}
+
+void MyFrame::SetCurDims()
+{
+ std::printf("Set: x = %4i, y = %4i, w = %4i, h = %4i, m = %i\n", _x, _y, _w, _h, _m);
+ SetPosition(wxPoint(_x, _y));
+ SetClientSize(_w, _h);
+ GetCurDims();
+}
+
+void MyFrame::OnGet(wxCommandEvent& WXUNUSED(event))
+{
+ GetCurDims();
+}
+
+void MyFrame::OnSet(wxCommandEvent& WXUNUSED(event))
+{
+ SetCurDims();
+}
+
+void MyFrame::LoadWindowPlacement()
+{
+ std::printf("LoadWindowPlacement: x = %4i, y = %4i, w = %4i, h = %4i, m = %i\n", _x, _y, _w, _h, _m);
+ SetCurDims();
+}
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#25348)Just to be clear, there is no doubt that this bug is related to windows decorations, the trouble is that we already have a lot of code trying to deal with exactly this problem, i.e. find their correct size and yet somehow this still doesn't work in all cases. It looks like you've removed your patch reproducing the problem which is a pity because I was going to try to debug it when I have time...
BTW, I recommend using wxPersistentRegisterAndRestore() to save and restore window geometry automatically instead of rolling out your own implementation. This is both simpler and can provide more functionality, e.g. under GTK this is supposed to work correctly even if the decorations sizes have changed between runs and under MSW it has some special workarounds for "snapped" windows.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
paulcor
paulcor left a comment (wxWidgets/wxWidgets#25348)I think this is a symptom of a WM which returns incorrect values for _NET_REQUEST_FRAME_EXTENTS. It's difficult to get things right when the WM is lying to us.
Frame extents problems can be avoided by saving/restoring the client size.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#25348)I agree with both points (that it's difficult and that working with client size is better), but I wonder how do we still manage to get the apparently correct decorations size (37) if it's really lying.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
paulcor
paulcor left a comment (wxWidgets/wxWidgets#25348)We are able to determine the actual frame extents ourselves, but by then it's too late to do any corrections.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Valentyn Shtronda
valiko-ua left a comment (wxWidgets/wxWidgets#25348)@vadz I've moved repro patch to my first post under collapsible block, please find it there (bug-repro.patch).
The fixed version of this patch (with client size) is in my previous post (bug-fix.patch).
Thank you again for quick reply and help.
I'll look at wxPersistentRegisterAndRestore as you suggest.
It looks like decorations size is calculated correctly (37 pixels) but added twice instead of once.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Valentyn Shtronda
valiko-ua left a comment (wxWidgets/wxWidgets#25348)@vadz I tried wxPersistentRegisterAndRestore. It works fine if the window is not maximized during close.
But I see two issues if the window is maximized:
- on restoration, its size becomes as big as maximized window but its state is not maximized;
- restored (unmaximized) size is not persisted.
Should I file a new bug/suggestion for this, or these issues are known limitations?
(Although I don't see info about these limitations on https://docs.wxwidgets.org/latest/overview_persistence.html).
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#25348)I think it would indeed be best to open a separate issue for the issues with maximized windows, TIA.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#25348)FWIW I can reproduce the problem with GNOME 48 (running in nested mode under Sway, but I don't think it matters), I'll try to have a look at it, although I'm not sure if I am going to be able to do anything.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#25348)OK, I may be very confused here, but the current code seems wrong to me. IMO we should not be subtracting the decoration size from (i.e. call GTKDoGetSize()) before passing the size to gtk_window_resize() or gtk_widget_set_size_request(), at least when using X11, because they don't add the decorations size to the size passed to them. At least when they're called with 800x400 size, xwininfo shows the window as having 800x400 size, and when we call SetSize() later, once the decorations are known, with 800x363 size, this is the size that the window gets too.
Paul, am I missing something here? If not, I should be able to fix this...
But there is still another problem: if SetClientSize() is called when the decorations size is not known yet, we can't set the size correctly and we'll end up with a (much, in case of Wayland, when the decoration sizes are 26,60,26,29 for mutter) smaller size than requested. I don't know what to do about this one.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#25348)BTW, here is a more convenient (IMHO) patch which can be used for testing:
diff --git a/samples/minimal/minimal.cpp b/samples/minimal/minimal.cpp index 5f32257c6b..6b1d94a06e 100644 --- a/samples/minimal/minimal.cpp +++ b/samples/minimal/minimal.cpp @@ -141,6 +141,30 @@ bool MyApp::OnInit() MyFrame::MyFrame(const wxString& title) : wxFrame(nullptr, wxID_ANY, title) { + auto w = new wxWindow(this, wxID_ANY); + w->SetBackgroundColour(*wxWHITE); + w->Bind(wxEVT_PAINT, [this, w](wxPaintEvent&) { + wxPaintDC dc(w); + dc.SetTextForeground(*wxBLACK); + const auto sz = GetSize(); + const auto cs = GetClientSize(); + wxASSERT( cs == w->GetSize() ); + dc.DrawText(wxString::Format("%d*%d (%d*%d)", sz.x, sz.y, cs.x, cs.y), + sz.x/3, sz.y/3); + }); + w->Bind(wxEVT_SIZE, [w](wxSizeEvent& event) { + w->Refresh(); + event.Skip(); + }); + w->Bind(wxEVT_LEFT_DCLICK, [this](wxMouseEvent&) { + SetSize(wxSize(800, 400)); + }); + w->Bind(wxEVT_RIGHT_DCLICK, [this](wxMouseEvent&) { + SetClientSize(wxSize(800, 400)); + }); + SetSize(wxSize(800, 400)); + return; + // set the frame icon SetIcon(wxICON(sample));
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#25348)OK, next stupid question: why do we change the internal size in "not defer show" case instead of actually resizing the window, as we do in all the other ones? IOW why not apply
diff --git a/src/gtk/toplevel.cpp b/src/gtk/toplevel.cpp index 45c92ae2c7..ff9a02d68a 100644 --- a/src/gtk/toplevel.cpp +++ b/src/gtk/toplevel.cpp @@ -1574,12 +1574,22 @@ void wxTopLevelWindowGTK::GTKUpdateDecorSize(const DecorSize& decorSize) if (!resized) { // adjust overall size to match change in frame extents - m_width += diff.x; - m_height += diff.y; - if (m_width < 1) m_width = 1; - if (m_height < 1) m_height = 1; - m_clientWidth = 0; - gtk_widget_queue_resize(m_wxwindow); + int w = m_width; + int h = m_height; + if (gtk_window_get_resizable(GTK_WINDOW(m_widget))) + { + GTKDoGetSize(&w, &h); + gtk_window_resize(GTK_WINDOW(m_widget), w, h); + } + else + { + if (!HasClientDecor(m_widget)) + GTKDoGetSize(&w, &h); + gtk_widget_set_size_request(GTK_WIDGET(m_widget), w, h); + } + + wxLogTrace(TRACE_TLWSIZE, "Resized %s to (%d, %d) to take decorations into account", + wxDumpWindow(this), w, h); } } if (m_deferShow)
?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
paulcor
paulcor left a comment (wxWidgets/wxWidgets#25348)Because in that case the window is already the right size, why would we need to change it? Your suggested change does not work for me with XFCE, client size is not preserved when using SetClientSize().
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#25348)With mutter the window is not of the right size: when we ask for a window of (total) height 400 initially, we get a window of height 437. I.e. contrary to what I wrote before, GTK does adjust the window size to account for SSD.
I have no idea why does the behaviour differ between mutter and XFCE :-( I also don't understand why do we get zeroes for _NET_REQUEST_FRAME_EXTENTS initially and only get the correct values later — is it because the window needs to be realized to get the correct values?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#25348)Just in case it can be helpful, I've created a (draft, for now) #25349 which, in particular, contains more log messages, allowing to better see what is going on if you run the sample with WXTRACE=tlwsize.
In particular, it wasn't obvious to me that wxTopLevelWindowGTK::GTKUpdateDecorSize() is called recursively: at least with mutter, it is called when we get 0 values for _NET_FRAME_EXTENTS first and then it is called with correct values from inside gtk_widget_show() called from it.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
paulcor
paulcor left a comment (wxWidgets/wxWidgets#25348)OK, I think I remember seeing this behavior before, where the WM initially reports frame extents as zero, then later corrects them. It's taking me a while to set up an environment where I can test this, but I have an idea for a fix.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#25348)The key difference is whether SetSize() or SetClientSize() is called initially: when using the former, we set m_deferShowAllowed to true and so we get 0 frame extents first, then show the window and then get the correct ones. When using the latter, we show the window immediately and get the correct extents right away.
I also have an idea for how to fix this, but I don't have XFCE to test with... If you could test my fix with it, it would be great.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#25348)After trying a couple of more complicated things, I've finally made the smallest possible change, see 58f0049 which I've pushed to #25349, which basically just replaces the test for m_deferShow with a test for m_deferShowAllowed.
If this doesn't work under XFCE (or somewhere else), could you please run the patched sample with WXTRACE=tlwsize and paste the output here to try to understand what's going on?
Note that I've updated the patch to the sample above to also allow testing SetClientSize() by setting WX_SET_CLIENT env var to anything on the command line.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
paulcor
paulcor left a comment (wxWidgets/wxWidgets#25348)it wasn't obvious to me that
wxTopLevelWindowGTK::GTKUpdateDecorSize()is called recursively
Just for the record, it's not called recursively. A "property-notify-event" for _NET_FRAME_EXTENTS will occur as a result of gtk_widget_show() with Mutter, but it is generated later, from the event loop.
The fix from #25349 works for me.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#25348)@imciner2 I'm going to merge this and backport the actual fix to 3.2 too, meaning that you should be able to get rid of the workarounds in KiCad code now (at least when using wx >= 3.2.9). Please let me know if you still have any problems with just using SetSize() (although, again, using persistent windows support in wx itself remains the preferred approach).
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
Closed #25348 as completed via 9537141.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Valentyn Shtronda
valiko-ua left a comment (wxWidgets/wxWidgets#25348)Confirm, bug is fixed.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Ian McInerney
imciner2 left a comment (wxWidgets/wxWidgets#25348)@imciner2 I'm going to merge this and backport the actual fix to 3.2 too, meaning that you should be able to get rid of the workarounds in KiCad code now (at least when using wx >= 3.2.9). Please let me know if you still have any problems with just using SetSize() (although, again, using persistent windows support in wx itself remains the preferred approach).
Circling back to this (since I was just trying a build against 3.3.0 and saw the build error because GTKDoGetSize is private now), after this set of changes, GTK will report the correct value from GetSize to pass into a future SetSize call?
(although, again, using persistent windows support in wx itself remains the preferred approach).
We can certainly look into it eventually. It would probably fit nicely with a workpackage also implementing the AUI panel persistence in our code.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#25348)Circling back to this (since I was just trying a build against 3.3.0 and saw the build error because
GTKDoGetSizeis private now),
Yes, please don't use GTKFoo() (and also MSWBar(), OSXQuux() etc), they're intended to be internal, even if they are not always private for different reasons.
after this set of changes, GTK will report the correct value from
GetSizeto pass into a futureSetSizecall?
I certainly hope so! Of course, please don't hesitate to dash my expectations if it still doesn't (wouldn't be the first time for this particular problem...).
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
dsa-t
dsa-t left a comment (wxWidgets/wxWidgets#25348)I still see issues when doing GetSize/SetSize in KiCad on Linux Mint 21.1 XFCE/X11.
Looks like wxTopLevelWindowGTK::GTKUpdateDecorSize is called after our window size save/load and it increases the frame size by title bar size after each restart.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#25348)Damn, I really hoped (not for the first time, unfortunately) that this was really fixed now...
@paulcor Will you look into this or should I try to?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
paulcor
paulcor left a comment (wxWidgets/wxWidgets#25348)Log with
tlwsize:
Is that the whole log? I would expect to see something about _NET_REQUEST_FRAME_EXTENTS in there. Is m_deferShowAllowed somehow false? Might also have something to do with SetSizeHints().
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
dsa-t
dsa-t left a comment (wxWidgets/wxWidgets#25348)Is that the whole log?
Yes.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
dsa-t
dsa-t left a comment (wxWidgets/wxWidgets#25348)—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.