wxPanel Size not obeyed on some window managers (GNOME, XFCE) ?

[GillesDuvert]

First of all thanks for your efforts. Having a portable GUI library between all the different OSes is more than useful.

I want to report a strange behaviour appearing on (at least, Debian 10, Debian 11 and derivatives) with XFCE and GNOME.
I create a colored Panel inside a Frame, and I explicitely fix the size of this panel to be 500x500 pixels. And moreover force the Frame to honor it.
The source code is just a copy of your 'hello world' example, with suitable modifications, below. Say the executable is called 'hello':
The image below shows the result, side-by-side, of 'hello' on my Mageia8+KDE (wxWidgets 3.1, gtk 3) (left) and on a VM running Debian11 on my laptop (right) on which I run the same 'hello' command, using a ssh -X on my laptop . So, same code, libraries etc.

The size of the GNOME/Debian 11 Panel is reduced in height by the size of the window titlebar. This is IMHO a bug as the behaviour in size should be insured on all platforms. I realize this is difficult since (I tested with events) the GNOME desktop does not create the same serie of size events as the KDE desktop at creation of a Frame.

At the very least there should be some documentation to explain how to avoid this unfortunate behaviour (through #ifdef perhaps?) or, some internal check at the creation of the wxApp could, e.g., add the height of the titlebar to the frame height on this platform? Well, anything that could make our life easier by hiding platform specifics, which is after all the purpose of the game?

code:

#include <wx/wxprec.h>
 
#ifndef WX_PRECOMP
    #include <wx/wx.h>
#endif

class MyApp : public wxApp
{
public:
    virtual bool OnInit();
};
 
class MyFrame : public wxFrame
{
public:
    MyFrame();
 
private:
    void OnExit(wxCommandEvent& event);
    void OnAbout(wxCommandEvent& event);
};
 
wxIMPLEMENT_APP(MyApp);

bool MyApp::OnInit()
{
    MyFrame *frame = new MyFrame();
    frame->Show(true);
    return true;
}
MyFrame::MyFrame()
    : wxFrame(nullptr, wxID_ANY, "Hello World")
{
    wxMenu *menuFile = new wxMenu;

    menuFile->Append(wxID_EXIT);
 
    wxMenu *menuHelp = new wxMenu;
    menuHelp->Append(wxID_ABOUT);
 
    wxMenuBar *menuBar = new wxMenuBar;
    menuBar->Append(menuFile, "&File");
    menuBar->Append(menuHelp, "&Help");
 
    SetMenuBar( menuBar );
 
    CreateStatusBar();
    SetStatusText("Welcome to wxWidgets!");
 
    Bind(wxEVT_MENU, &MyFrame::OnAbout, this, wxID_ABOUT);
    Bind(wxEVT_MENU, &MyFrame::OnExit, this, wxID_EXIT);

        wxBoxSizer* sizer = new wxBoxSizer(wxVERTICAL);
       this->SetSizer(sizer);


       wxPanel* p=new wxPanel(this,  wxID_ANY, wxDefaultPosition, wxSize(500,500));
        sizer->Add(p, 0, wxALL, 0);
        p->SetBackgroundColour(wxColour(0xE1, 0x8A, 0x61));
 
        //        p->SetMinSize(wxSize(500,500));
        this->Fit();


}
void MyFrame::OnExit(wxCommandEvent& event)
{
    Close(true);
}
 
void MyFrame::OnAbout(wxCommandEvent& event)
{
    wxMessageBox("This is a wxWidgets showing the Panel size is not the same on different Display Managers.",
                 "About Hello World", wxOK | wxICON_INFORMATION);
}

[vadz]

This seems to be the same as #23041 and the discussion there explains why it's not that simple to fix it, unfortunately. But it is relatively simple to work around it in your code, by working in client size terms rather than full size, so maybe this can be sufficient.

[GillesDuvert]

@vadz thanks for the prompt reply.
Thanks,
Interestingly, the solution seems to be, before realization of the wxFrame, to write this redundant code: this->SetClientSize(this->GetClientSize());
At least it works with my example, adding this line after this->Fit();
So it could be something done always by wxWidgets for any wxFrame as it seems safe...

[vadz]

This actually might not be the same problem as the other issue as I don't see it here (while I do see the other one). I now also realize that you've written that you used wx 3.1, which covers a very wide range of versions considering the 10 year lifetime of this release. Could you please retest with 3.2 or the latest master and check if you actually still see this problem?

[GillesDuvert]

hm, perhaps... The use of wxWidgets in our case is rather special as this is a programming language, not an App. Meaning I cannot fathom what the user will ask for a size, etc..
OK I will test on a Debian11 (new VM). My recurring problem is that the package to which I contribute is installed on various platforms and with any level of installed libraries such as wxWidgets, GTK etc. I guess that's the same for many pople :smile , but I'm very much frowned upon if the GDL language does not work on old distros...

[GillesDuvert]

@vadz I tested the above code on a Debian 11 with all updates made. The wx-config --version-full gives 3.0.5.0 . The 'y size' problem is not present. However, if (via an ssh) I run the same code, from my laptop, where wx-config --version-full gives 3.1.7.0 (yes, more recent than Debian11) the the problem is present.

As all things equal wrt. the display manager, it would appear that some change between 3.0.5 and 3.1.7 (!) are at the origin of the problem?

[vadz]

Sorry, it really makes no sense to try to do anything about a possible problem in 3.1.7, please test 3.2.1 or master (as you must have compiled 3.1.7 yourself, it shouldn't be a problem to compile the latest version instead).

[GillesDuvert]

oh, my bad.

[GillesDuvert]

@vadz I did not have the time to test on 3.1.7 but instead found several places in the GDL code related to wxWidgets where I put safeguards and apparently our problem is solved.

[vadz]

Ideally there would be no need for the workarounds, so please check if you still need them once you upgrade to the version including the changes of 08301b1 (Ensure that TLW size is updated when decoration size changes on Wayland, 2023-01-17).