Code::Blocks Forums

User forums => Using Code::Blocks => Topic started by: gd_on on June 06, 2022, 07:39:47 pm

Title: wxWidgets 3.1.7 is available
Post by: gd_on on June 06, 2022, 07:39:47 pm
It's here : https://github.com/wxWidgets/wxWidgets/releases/tag/v3.1.7
Title: Re: wxWidgets 3.1.7 is available
Post by: killerbot on June 06, 2022, 07:54:08 pm
I didn't actively follow the discussion on the 3.1.6, but I think that one was not usable for CB, or were all problems fixed in the mean time ?

If possible, we could try to step up to 3.1.7 and as such catch up again ? What do you think ?
Title: Re: wxWidgets 3.1.7 is available
Post by: gd_on on June 06, 2022, 09:29:13 pm
I have compiled and used C::B (I follow the svn versions) with wxWidgets 3.1.6 for a long time and had no problems. I'm on Windows 10 (see my signature)
Here, I have compiled C::B (svn 12831) with wxWidgets 3.1.7. It starts correctly. Of course, I had no time to test deeply, it's too fresh.
I had also tested some of my own programs with wxWidgets 3.1.7 for a few months, while wxWidgets 3.1.7 was still on development, without any problems.

For C::B, may be it should be more prudent to wait the 3.2.0 version (due date 7 july ...)

gd_on
Title: Re: wxWidgets 3.1.7 is available
Post by: AndrewCot on June 07, 2022, 12:16:11 am
I think the devs should test it with C::B as the news has the following paragraph:

Quote
This is also the last release before the upcoming 3.2.0 release that will be the start of a new API and ABI-stable wxWidgets version, so please test your existing applications with this version and let us know about any problems and, especially, regressions, so that they could still be fixed before 3.2.0.
Been building with wx3.1.6 since it come out and have not spotted any issues on Windows or MacOS. Will be updating to 3.1.7 today. The default Linux build process uses the installed wxWidgets and as such I build with 3.0.5.
I would love to see the nightly move to 3.1.7 as there are no C::B code changes required, but as expected new wxWidget DLL's would be need to be packaged into a 7z file.


Title: Re: wxWidgets 3.1.7 is available
Post by: AndrewCot on June 07, 2022, 05:35:04 am
Looks like there is an issue with wxWidget 3.1.7 compared to 3.1.6 in that BlueHazzard's cbSystemView plugin (https://forums.codeblocks.org/index.php?topic=22207.0 for info) failes to build with the error below on 3.1.7, but is okay with 3.1.6:
Code
D:\Andrew_Development\Work_Installers\CodeBLocks_Private_Experimental\src\plugins\contrib-wip\cbSystemView\src\cbSVWindow.cpp: In constructor 'cbSVWindow::cbSVWindow(wxWindow*)':
D:\Andrew_Development\Work_Installers\CodeBLocks_Private_Experimental\src\plugins\contrib-wip\cbSystemView\src\cbSVWindow.cpp:194:36: error: 'void wxPropertyGridPageState::SetColumnCount(int)' is protected within this context
  194 |     m_pg_first_page->SetColumnCount(4);
      |     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~
In file included from D:\Andrew_Development\Libraries\wxWidgets-3.1.7_win64\include/wx/propgrid/propgridiface.h:19,
                 from D:\Andrew_Development\Libraries\wxWidgets-3.1.7_win64\include/wx/propgrid/propgrid.h:23,
                 from D:\Andrew_Development\Libraries\wxWidgets-3.1.7_win64\include/wx/propgrid/manager.h:18,
                 from .\include/cbSVWindow.h:32,
                 from D:\Andrew_Development\Work_Installers\CodeBLocks_Private_Experimental\src\plugins\contrib-wip\cbSystemView\src\cbSVWindow.cpp:19:
D:\Andrew_Development\Libraries\wxWidgets-3.1.7_win64\include/wx/propgrid/propgridpagestate.h:586:10: note: declared protected here
  586 |     void SetColumnCount(int colCount);
      |          ^~~~~~~~~~~~~~
Process terminated with status 1 (0 minute(s), 3 second(s))
I have not looked into the error above.

The following is the list of plugin's I build and they all loaded without any errors on C::B startup:
Title: Re: wxWidgets 3.1.7 is available
Post by: AndrewCot on June 07, 2022, 05:46:49 am
The wxWidget 3.1.7 changes to the wxPropertyGridPageState class has caused the cbSystemView build to now fail.
The changed file is include\wx\propgrid\propgridpagestate.h and is caused by the following changes as per the following changes.txt file entry:

Code
3.1.7: (released 2022-06-06) ---------------------------- INCOMPATIBLE CHANGES SINCE 3.1.6: - wxPropertyGridPageState funtions intended for internal use are no longer public. Corresponding functions in wxPropertyGridInterface, wxPropertyGrid, wxPropertyGridPage, and wxPropertyGridManager should be used instead.
Title: Re: wxWidgets 3.1.7 is available
Post by: Miguel Gimenez on June 07, 2022, 06:19:33 pm
I didn't actively follow the discussion on the 3.1.6, but I think that one was not usable for CB, or were all problems fixed in the mean time ?

If possible, we could try to step up to 3.1.7 and as such catch up again ? What do you think ?

wx3.1.6 was perfectly usable, and I expect wx3.1.7 to be usable too without changes,

The only gotcha may be the change to the PCRE2 regular expression library in wx3.1.6, but many regexes were adapted before wx3.1.6 release and some of us have been using wx3.1.6 without problems so far.
Title: Re: wxWidgets 3.1.7 is available
Post by: AndrewCot on June 29, 2022, 05:39:40 am
On MacOS using wxWidgets 3.1.7 the C::B build fails with an ambiguous error for the src\sdk\editormanager.cpp on line 545 with the AddPage.

The function with the AddPage in it that fails is:

Code
void EditorManager::AddEditorBase(EditorBase* eb)
{
    int page = FindPageFromEditor(eb);
    if (page == -1)
    {
        // use fullname as default, so tabs stay as small as possible
        wxFileName fn(eb->GetTitle());
        m_pNotebook->AddPage(eb, fn.GetFullName(), true);
    }
}

the build log for the error is:

editormanager.cpp:545:22: error: call to member function 'AddPage' is ambiguous
        m_pNotebook->AddPage(eb, fn.GetFullName(), true);
        ~~~~~~~~~~~~~^~~~~~~
/usr/local/include/wx-3.1/wx/aui/auibook.h:279:10: note: candidate function
    bool AddPage(wxWindow* page,
         ^
../../src/include/cbauibook.h:125:14: note: candidate function
        bool AddPage(wxWindow* page,
             ^

Using wxWidget 3.1.5 the C:B build does not fail.
Using wxWidget 3.2.0 rc1 also fails to build.
Title: Re: wxWidgets 3.1.7 is available
Post by: AndrewCot on June 29, 2022, 07:35:38 am
In the attached zip are the updated files to get C::B building on the Mac with wxWidget 3.1.7 (3.2.0 rc1 has not been tested yet).
Title: Re: wxWidgets 3.1.7 is available
Post by: blauzahn on June 29, 2022, 07:42:33 am
On Arch Linux and Ubuntu-20.04, both x86_64 with current trunk of wxwidgets (3.2.0) cb trunk (svn12840)  does compile via configure and make. I do not observe that ambiguity error calling AddPage. Over the last weeks I compiled current wxwidgets and cb nearly daily without ever seing that compile error.

Right now, I lack the time to have a peek into the zip just postet by @AndrewCot.
Title: Re: wxWidgets 3.1.7 is available
Post by: AndrewCot on June 29, 2022, 08:30:59 am
GNU GCC does not give the error on Windows using MSYS2 Mingw64 using GCC 12.1 or GCC 11.1 on Xbuntu, but Mac CLang does. It looks like at the moment Clang is more compliant with the C++ specs as there is an issue and it's just a mater of when GCC detects the problem.
Title: Re: wxWidgets 3.1.7 is available
Post by: Miguel Gimenez on June 29, 2022, 02:35:01 pm
Modified patch applied in r12841, thank you.
Title: Re: wxWidgets 3.1.7 is available
Post by: Miguel Gimenez on June 29, 2022, 05:45:26 pm
wxWidgets 3.2.0-rc1 is available, it is intended for last-minute checks before the definitive release next week.

I am testing it on MSW (32 bits) and so far it looks good.
Title: Re: wxWidgets 3.1.7 is available
Post by: AndrewCot on June 30, 2022, 02:34:39 am
The r12841 patch does not include the InsertPage(...) function definition changes like AddPage(). The InsertPage() function definition change is required once you get past the AddPage() issue.

I am working on getting the DAP debugger I have been working on building on the Mac and then Linux. As such it will be a few days before I start tom play with wxWidgets 3.2.0 rc1.
Title: Re: wxWidgets 3.1.7 is available
Post by: Miguel Gimenez on June 30, 2022, 11:37:42 am
Quote
The r12841 patch does not include the InsertPage(...) function definition changes

Completed in r12842.
Title: Re: wxWidgets 3.1.7 is available
Post by: AndrewCot on June 30, 2022, 12:18:28 pm
Thanks.
Title: Re: wxWidgets 3.1.7 is available
Post by: BlueHazzard on June 30, 2022, 04:11:42 pm
wxUSE_GRAPHICS_DIRECT2D and msys2 is still not working? Or at least i have to override the setup.h
Title: Re: wxWidgets 3.1.7 is available
Post by: gd_on on June 30, 2022, 04:34:39 pm
You still have to patch setup.h in \lib\gcc_dll\mswu\wx, line 1659 by :
Code
#define wxUSE_GRAPHICS_DIRECT2D 1   // Modif GD for CB >= 11701
Title: Re: wxWidgets 3.1.7 is available
Post by: AndrewCot on July 01, 2022, 07:50:55 am
FYI: Updated wxWidgets on Mac using brew to 3.1.7 and successfully built and run C::B.
Title: Re: wxWidgets 3.1.7 is available
Post by: Miguel Gimenez on July 01, 2022, 12:00:46 pm
There are some tickets related to Mac, can you reproduce any of them?
Title: Re: wxWidgets 3.1.7 is available
Post by: AndrewCot on July 01, 2022, 03:00:40 pm
Mac still has no debugging that is easy to do (or in my case get working), so first step to fix or investigate any Mac bugs is to get it so you get debug the code without resorting back to the god old printf days. So before I look at any Mac bugs I need to get debugging working first. IMHO and also Eran's Codelite changes for MAC is to add DAP debugger support. Eran has been working on the DAP library and integrating the changes into Codelite over the last few weeks. Some of the DAP library issues I have stumbled across have been fixed in DAP updates and some have been me or my config type issues.

Unfortunately based on past experience most of my large patches are not going to be accepted as they have or will be hijacked IMHO by someone who does not want to think or take the time to try to figure out why the patch is needed in the first place by the average user (not C::B devs) and as such I do not want to waste time on tickets and patches that go no where anymore. AS soon as I get the  "Please explain the reason for this patch..." I now give up as it's a waste of time responding as it goes no where.

Once I get DAP debugging working then I will supply info on the GIT repo and leave it for someone else to run with.