New projects for wxWidgets 3.2

[Miguel Gimenez]

I have just commited the projects, workspaces and batch files for wxWidgets 3.2 in 32 and 64 bits.

I have asked Darmar to add the same files to the Fortran project. Meanwhile, you can use the attached files or just ignore the warning when loading the workspace.

[ollydbg]

Nice contribution! Thanks.

[Miguel Gimenez]

Darmar has just commited the wx32 Fortran projects.

[SpaceCadet]

I have just commited the projects, workspaces and batch files for wxWidgets 3.2 in 32 and 64 bits.

I have asked Darmar to add the same files to the Fortran project. Meanwhile, you can use the attached files or just ignore the warning when loading the workspace.

If you are saying you have created C::B projects for wxWidgets, great job!  And if the samples are included awesome!  Not sure where to find these committed projects, are they on svn somewhere?  Thanks!

[Miguel Gimenez]

I have created the projects needed to compile C::B with wxWidgets 3.2. You can create your own projects for wxWidgets 3.2 using the wizard, it was updated some months ago.

[ollydbg]

Hi, when loading the workspace file: CodeBlocks_wx32_64.workspace

I got an error, see below:

Code

ProjectsImporter: loaded
RegExTestbed: loaded
ReopenEditor: loaded
rndgen: loaded
ScriptedWizard: loaded
SmartIndentCpp: loaded
SmartIndentFortran: loaded
SmartIndentHDL: loaded
SmartIndentLua: loaded
SmartIndentPascal: loaded
SmartIndentPython: loaded
SmartIndentXML: loaded
SpellChecker: loaded
SymTab: loaded
ThreadSearch: loaded
tidycmt: loaded
ToDoList: loaded
ToolsPlus: loaded
The plugin name "wxSmithMime" does not match the name in the "wxSmith" file.
wxSmith: loaded
wxSmithMime: loaded
wxSmithAui: loaded
wxSmithContribItems: loaded
WindowsXPLookNFeel: loaded
Abbreviations plugin activated

The line is:

The plugin name "wxSmithMime" does not match the name in the "wxSmith" file.

Is this the expected message?

Thanks.

[Miguel Gimenez]

The wxSmith.dll is special, because it contains two plugins: wxSmith and wxSmithMime. Obviously, one of them will fail the check (DLL name == plugin name). This is an extract of the manifest.xml file:

Code

    <Plugin name="wxSmith">
    ...
    </Plugin>
    <Plugin name="wxSmithMime">
    ...
    </Plugin>

[ollydbg]

Thanks for the explanation.
Note sure why this has such special xml file, I just built the whole workspace against the wx 3.2.1, and the result cb works fine here.

[AndrewCot]

Do we still need the wx 3.1 workspace/project files as wx 3.2.1 is released?

[Miguel Gimenez]

Do we still need the wx 3.1 workspace/project files as wx 3.2.1 is released?

IMHO we must keep them for a couple of 3.2.1 nightlies, just in case we find major problems and must go back to wx3.1.5.

[vimer]

Hi,
I am just wonder now C::B can support wxWidgets 3.2?
Because I come from Debian, this is RC bug from there：
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1019830
If we want keep C::B in Debian(bookworm) need to fix the bug.
thanks.

[Miguel Gimenez]

Just adding this

Code

#include <wx/filename.h>

after the last include should fix the issue. See line #20 here

The warning is unavoidable if you want to keep scripting compatibility with old wxWidgets.

Line numbering in the bug report suggests you are using the 20.03 source code; Recent changes in wxRegEx will make 20.03 fail when parsing some texts, and the new wxBitmapBundle automatic zooming will distort the UI when using screen scale factors > 1.0.

I suggest you to pick the current trunk code (r13000), it is not a release but it is more stable than 20.03. I do not know when Bookworm will be promoted to stable, but may be we have a new release before that.

[vimer]

hmm, thanks. I have added the #include <wx/filename.h> into the file, but it fails still 
yes, the C::B is 20.03 in Debian: https://tracker.debian.org/pkg/codeblocks
Ok, now I know the r13000 is in a good state, but Debian's policy, it is worth waiting here C::B releases a new stable version.

PS: Could you also add support for riscv64 build?
The patch below I have tested it on riscv64 boards, please let me know if there is any issues.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1011502

[Miguel Gimenez]

When should the release be ready to be included in bookworm?

----------------------

The first error origin is a change in wxFileName::Normalize(), now the first parameter is not optional.

To fix this you must add

Code

    SQInteger wxFileName_Normalize(HSQUIRRELVM v)
    {
        StackHandler sa(v);
        wxFileName& self = *SqPlus::GetInstance<wxFileName,false>(v, 1);
        return sa.Return((SQInteger)self.Normalize(wxPATH_NORM_ALL));
    }

after wxFileName_OpToString() and change

Code

                func(&wxFileName::Normalize, "Normalize").

to

Code

                staticFunc(&wxFileName_Normalize, "Normalize");

but you will find more errors later. Those related to wxBitmapBundle can be fixed replacing

Code

bitmap.GetHeight()

with

Code

bitmap.GetDefaultSize().GetHeight()

Same for width.
Add this to failed attempts to use the bitmap in notebookstyles.cpp

Code

.GetBitmap(wxDefaultSize);

In watchesdlg.cpp:106 use

Code

        wxPGWindowList const list(nullptr, nullptr);

In main.cpp:2682 remove

Code

        wxPaintEvent e;
        ProcessEvent(e);

[vimer]

> When should the release be ready to be included in bookworm?

From https://release.debian.org/testing/freeze_policy.html#transition, it is should be ok to release a new stable version before 2023-01.
If the maintainer of C::B package on Debian has no time to upgrade the package, I can do NMU(Non maintainer upload) upload to reflect on the new version.

Thanks for more hints to fix build issue, I will try it

[off topic]
Need I open another topic to discuss with adding riscv build?
When I first time to submit the patch to support riscv64 build, I am looking at it here(forward patch) but the login scared me