61
Nightly builds / Re: The 25 October 2025 build (13754) is out.
« Last post by blauzahn on November 03, 2025, 08:30:03 pm »Thank you, Lieven.
News:
Accounts with zero posts and zero activity during the last months will be deleted periodically to fight SPAM!
Recent Posts
62
Development / Re: AI may help us to create plugins
« Last post by blauzahn on November 03, 2025, 08:27:13 pm »I'd also vote against, regardless of how tempting it might sound.
Using AI as inspiration or as lightning quick "seems to work" hack is fine as long as you resist the huge temptation to cut-copy-paste any single line of code you do not fully understand. Remember: As soon as you change/add anything, the responsability and maintenance becomes essentially yours, not the AI's.
Before adding yet more cruft, I'd favour fixing bugs in cb.
Finding potential memory leaks in cb can be done on Linux with e.g. cppcheck, scan-build, heaptrack or valgrind --- or just look for raw new in the editor and you'll quickly find a few good candidates.
Use a more modern programming style and you put in hardly any leak in the first place. Granted, legacy frameworks may limit its scope.
Using AI as inspiration or as lightning quick "seems to work" hack is fine as long as you resist the huge temptation to cut-copy-paste any single line of code you do not fully understand. Remember: As soon as you change/add anything, the responsability and maintenance becomes essentially yours, not the AI's.
Before adding yet more cruft, I'd favour fixing bugs in cb.
Finding potential memory leaks in cb can be done on Linux with e.g. cppcheck, scan-build, heaptrack or valgrind --- or just look for raw new in the editor and you'll quickly find a few good candidates.
Use a more modern programming style and you put in hardly any leak in the first place. Granted, legacy frameworks may limit its scope.
63
Help / Re: Different handling of placeholders
« Last post by blauzahn on November 03, 2025, 07:55:50 pm »Maybe because macro expansion is better used reluctantly? Like minimizing the usage of the c-preprocessor. Currently, I do not use default-code but I would be fine with how it is as you described.
I briefly searched cb-source for default-code. The function that expands placeholders is in trunk/src/sdk/editormanager.cpp:495
see the lines:
Apart from that snippet, at first glance, I did not find in the source code any further rationale for the decision you asked for.
The code entered into the settings dialog can be found in ~/.config/codeblocks/default.con. Please search for default_code within that file.
Why do you want the creation date of a source file in the first place? I'd rather look up in version control when it was added. With that username, do you do that for legal reasons?
I briefly searched cb-source for default-code. The function that expands placeholders is in trunk/src/sdk/editormanager.cpp:495
Code
cbEditor* EditorManager::New(const wxString& newFileName)
{
// wxString old_title = Manager::Get()->GetAppWindow()->GetTitle(); // Fix for Bug #1389450
// create a dummy file
if (!newFileName.IsEmpty() && !wxFileExists(newFileName) && wxDirExists(wxPathOnly(newFileName)))
{
wxFile f(newFileName, wxFile::write);
if (!f.IsOpened())
return nullptr;
}
cbEditor* ed = new cbEditor(m_pNotebook, newFileName, m_Theme);
// if ((newFileName.IsEmpty() && !ed->SaveAs()) || !ed->Save())
// {
// //DeletePage(ed->GetPageIndex());
// ed->Destroy();
// Manager::Get()->GetAppWindow()->SetTitle(old_title); // Though I can't reproduce the bug, this does no harm
// return 0;
// }
// add default text
wxString key;
key.Printf(_T("/default_code/set%d"), (int)FileTypeOf(ed->GetFilename()));
wxString code = Manager::Get()->GetConfigManager(_T("editor"))->Read(key, wxEmptyString);
// Allow usage of macros
// TODO (Morten#5#): Is it worth making this configurable?!
Manager::Get()->GetMacrosManager()->ReplaceMacros(code);
ed->GetControl()->SetText(code);
ed->SetColourSet(m_Theme);
AddEditorBase(ed);
ed->Show(true);
SetActiveEditor(ed);
CodeBlocksEvent evt(cbEVT_EDITOR_OPEN, -1, nullptr, ed);
Manager::Get()->GetPluginManager()->NotifyPlugins(evt);
return ed;
}
see the lines:
Code
// Allow usage of macros
// TODO (Morten#5#): Is it worth making this configurable?!
Manager::Get()->GetMacrosManager()->ReplaceMacros(code);
Apart from that snippet, at first glance, I did not find in the source code any further rationale for the decision you asked for.
The code entered into the settings dialog can be found in ~/.config/codeblocks/default.con. Please search for default_code within that file.
Why do you want the creation date of a source file in the first place? I'd rather look up in version control when it was added. With that username, do you do that for legal reasons?
64
Development / Re: AI may help us to create plugins
« Last post by Михаил Агарков on November 03, 2025, 06:18:31 pm »Well no kidding?! Who would've thunk?!
You know what could help us create plugins? Or create anything at all? Capable programmers.
This isn't helping. What's even the point of bringing up that crap? Seriously.
Look at the state of this project. How many people have been contributing? How many stable releases in the past eight years?
Last thing we need is incompetent scum "contributing" computer-generated garbage to any part of Code::Blocks.
Well, if you guys want to kill it, then go ahead, suggest AI usage -- nay, even better, make AI plugins, an assistant on the IDE itself. A COPILOT integrated to it! Imagine that! Wouldn't that be great?
And not long ago we didn't even have a functional Symbols Browser. To be removed completely on a newer release. What a joke.
And people wonder why some things are as they are.
Listen to yourself, look around you, look at the project, look around it, then listen to yourself again, and think.
And you just threw Code::Blocks' source code into some garbage bin? Really, projects must have some sort of protection against this kind of stupidity, these days.
Then again, I don't know what's the goal exactly, but, if you guys are planning to turn this into a huge pile of crap, then disregard what I'm saying.
Thanks.
Despite the slightly agressive response, I fully agree that AI is ruining a lot of things, e.g. localhost being broken in Windows 11 and worse.
The reason I love Code::Blocks is that it doesn't use overbloated JS frameworks with Electron, it uses native GUI controls and has a very nice feature set, like wxSmith and so much more.
I also don't want Code::Blocks to fallback on using AI to generate code, because it would very likely break things, god forbid it from using web technologies and take up hundreds of megabytes of RAM being idle just to have Copilot. I love this IDE because it just works, has an amazing feature set and can even work on Windows XP and ReactOS with no lag on old hardware.
If it were to introduce AI, I would very likely create a hard fork just for myself and anyone else interested.
65
Help / Different handling of placeholders
« Last post by rechtsanwaltsteyer on November 03, 2025, 11:07:18 am »Hello everyone,
her my until now unresponded question again:
Since version 20.03 and also in the current version 25.03, I have an unsolvable problem:
1. If I enter a placeholder under Settings/Editor/Code Specification, such as "$(NOW_L)", the current date and time is displayed in the subsequently generated single file (*.cpp/*.h).
2. However, if I enter the same placeholders in /usr/share/codeblocks/templates/wizard/console/cpp/main.cpp, when generating a new project, "$(NOW_L)" is displayed in main.cpp instead of the current date and time.
My question: Why this different treatment of "$(NOW_L)?"
Thank you in advance!
Michael
her my until now unresponded question again:
Since version 20.03 and also in the current version 25.03, I have an unsolvable problem:
1. If I enter a placeholder under Settings/Editor/Code Specification, such as "$(NOW_L)", the current date and time is displayed in the subsequently generated single file (*.cpp/*.h).
2. However, if I enter the same placeholders in /usr/share/codeblocks/templates/wizard/console/cpp/main.cpp, when generating a new project, "$(NOW_L)" is displayed in main.cpp instead of the current date and time.
My question: Why this different treatment of "$(NOW_L)?"
Thank you in advance!
Michael
66
General (but related to Code::Blocks) / Re: forums.codeblocks.org Cert has expired
« Last post by sodev on November 02, 2025, 04:52:39 pm »So you are saying that cert's should be okay after the expiry? I disagree and my second post was a reminder that the admin needs to keep any eye on the 3 monthly lets encrypt expiry.
No i don't, expired certificates do not work. Usually the certificates are managed by Certbot, it schedules a cron job (or whatever system the OS uses) to check the certificates daily and acquire and install new ones automatically when the current ones are about to expire.
67
Development / Re: C::B 25.03 Multiple Debuggers selection old bug still there.
« Last post by Pecan on November 02, 2025, 02:10:31 am »But then, the ability to choose Debugger in a "Compiler Settings" makes no sense.
As I remember, in earlier versions, the current debugger was selected by selecting the "Build target" to build, and in a "Build Options" the compiler is selected, and in a "Compiler setting" is a debugger defined for that particular compiler.
It is a bit misleading to have separate Build target selection and Debugger selection, along with the ability to set debugger in a "Compiler settings", that has no effect then.
Yeah, there's been some fiddling around in that area of the code. But that fiddler is no longer around.
Could you just copy some of this thread and make a ticket of it.
I'm working on debugger_DAP and if/when I get into that area and fix it, I'll make a backport also.
Thanks
68
Development / Re: C::B 25.03 Multiple Debuggers selection old bug still there.
« Last post by MasterAlexei on November 02, 2025, 01:54:20 am »But then, the ability to choose Debugger in a "Compiler Settings" makes no sense.
As I remember, in earlier versions, the current debugger was selected by selecting the "Build target" to build, and in a "Build Options" the compiler is selected, and in a "Compiler setting" is a debugger defined for that particular compiler.
It is a bit misleading to have separate Build target selection and Debugger selection, along with the ability to set debugger in a "Compiler settings", that has no effect then.
As I remember, in earlier versions, the current debugger was selected by selecting the "Build target" to build, and in a "Build Options" the compiler is selected, and in a "Compiler setting" is a debugger defined for that particular compiler.
It is a bit misleading to have separate Build target selection and Debugger selection, along with the ability to set debugger in a "Compiler settings", that has no effect then.
69
Development / Re: C::B 25.03 Multiple Debuggers selection old bug still there.
« Last post by MasterAlexei on November 02, 2025, 12:02:02 am »Oh man, that is a bit hidden under menus. I do start debug sessions via shortcut F8 or a tool button with mouse. This menu "Debug" is a seldom place to visit...
Thanks. Now I learned some thing more.
Thanks. Now I learned some thing more.
70
Development / Re: C::B 25.03 Multiple Debuggers selection old bug still there.
« Last post by Pecan on November 01, 2025, 11:40:33 pm »MainMenu>debug>active debugger>selectDebug config