Hi all,
Codebase significantly updated.
A little while after 1.0RC2 was released, me and Thomas started working on a separate branch to implement some radical new features (keep reading - we 'll get to them shortly ;)). This was done so that C::B developers wouldn't be disturbed by the every-so-often update of base C::B classes and be forced to rebuild everything so often.
Finally, we managed to pull this off. Here are the major changes:
ConfigManager - completely rewritten from scratch by Thomas.
Configurations are now saved in xml format. There is one config file per personality, so logically separate information is physically separated, too. You can create copies of these files to create new personalities.
wxMSW users: This means you can now delete the registry key used for C::B configuration.
Unfortunately, there is no code to convert your old settings to the new format...
The mere fact that configuration is saved in xml format is not to be understood as an invitation for deliberate editing your configurations by hand. You can of course try, but it is entirely possible that you get unexpected results!
Apart from the actual configuration, the configuration manager offers functions to retrieve "standard paths" such as the installation directory or the data directory. There is a function to locate a Code::Blocks related file in a consistent way, too. For compatibility reasons, you should always use these functions rather than hard-code a path like "share/codeblocks/plugins".
Code::Blocks will load the personality given on the commandline, or the default personality if either none is specified or the specified personality cannot be found or is invalid. If a file named default.conf is found in the same directory as the main executable, this file will be used rather than the one from the config directory. This enables custom installations on read-only media.
You can specify a http:// URL as personality. In this case, Code::Blocks will download the specified URL and parse it as a configuration file. If this fails, the default config file is used (see above). Saving configurations over http:// is not supported.
It is no longer possible to get a pointer to the ConfigManager singleton via ConfigManager::Get(). In fact, ConfigManager no longer is a singleton. Instances of ConfigManager are constructed by a builder class according to the provided namespace.
The correct way to get an instance of ConfigManager is:
Manager::Get()->GetConfigmanager(name_space)
where name_space is a string constant that identifies the namespace which you want to use. Here's an example:
// old way
ConfigManager::Get()->Read("/editor/tab_size", 4);
ConfigManager::Get()->Write("/editor/tab_size", 4);
// new way
Manager::Get()->GetConfigmanager("editor")->ReadInt("/tab_size", 4);
Manager::Get()->GetConfigmanager("editor")->Write("/tab_size", 4);
You are free to do whatever you want within your namespace, all other namespaces will be unaffected by your actions. If your namespace starts with "volatile:" then you get a ConfigManager instance that supports everything as usual but will not save any data to disk. A volatile namespace can be seen pretty much like a static global variable (or a collection of these), except that the data is accessible using the ConfigManager API.
In most cases, it is NOT NECESSARY to have constructs like
wxString oldPath = cm->GetPath();
cm->SetPath("somewhere");
cm->Read("something");
cm->SetPath(oldPath);
any more, as every namespace has its own proper state. Given the general concept of namespaces, a lot less path mangling needs to be done in most cases, too.
In addition to writing standard primitive types such as int, double, and bool as well as wxString and wxColour, you can implement simple flags using Set(), UnSet(), and Exists() in much the same way as lock files or #defines are typically used.
Complex objects (wxArrayStrings, string maps and sets, serializable objects and maps of serializable objects) can be written to and read from configuration conveniently with one API call.
There are no functions to iterate through subkeys any more, instead you can enumerate all subpaths or subkeys using one convenient function now (if you really need).
Scripting support
The AngelScript script library was added for scripting C::B.
The scripts are written in a C-style syntax so it should be really easy to pick up and start writing scripts :)
Many script bindings have already been added in the SDK with more to come. It's not clear right now what exact parts of C::B will be exposed to scripting, so the scripting API will be changing until a relevant discussion reaches a conclusion.
Current bindings include wxString and wxArrayString from wxWidgets useful types. C::B's exposed types include ProjectManager, ConfigManager, cbProject, ProjectFile, ProjectBuildTarget, cbEditor and EditorManager.
But, as already said, it has not yet been decided which of those stay, which go and which others will be added...
The first step has been taken though ;)
Debugger plugin
This plugin has been redesigned, almost completely. Prepare yourself for what you 're gonna read in the next paragraphs :)
Added "Attach to process" and "Detach" debugger commands.
The format (dec, hex, etc) used for each debugger watched variable can now be specified.
Improved watches support with dialogs to add/edit watches.
Dialogs were also added to edit breakpoints.
On the subject of breakpoints, if you set a breakpoint and right-click on its red-dot in the editor's margin, you can click "Edit breakpoint". What you can set there is:
- Enable/disable that breakpoint :).
- Set the ignore-count. This tells the debugger that it should be ignored for X passes before breaking (useful in loops) :).
- Make it conditional by setting a condition, e.g. x>8 (this would make the breakpoint hit only if x was greater than 8 ) :).
But these wouldn't be possible without the present redesign.
A base DebuggerDriver (debuggerdriver.h) class has been created and GDB_driver derives from it. A base DebuggerCommand (debugger_defs.h) class has also been added, which just sends the passed command to the driver and (optionally) displays its output in the debug log. Every debugger input/output goes to the debugger debug-log.
Already implemented GDB commands can be found in gdb_commands.h. Each command is a small class deriving from DebuggerCommand and, by convenience, their names start with GdbCmd_ (for GDB_driver).
Now for the most important part (for many users): I have already implemented (rudimentary) support for cdb.exe/ntsd.exe. This means C::B can now debug MSVC generated programs :D.
As far as I know, C::B is the very first open source IDE with this very feature ;)
What I mean by "rudimentary support" is it can start the debugging process, set/unset breakpoints, break on set breakpoints and stop the debugging process. It still lacks support for watches, backtrace, disassembly and tooltip evaluation. But all that is needed is to write the relevant commands (driver in cdb_driver.h and commands in cdb_commands.h) :).
But don't try debugging MSVC programs just now. I haven't yet added a way to recognize which debugger to use ;).
After such a rewrite, testing is badly needed. It works fine even for debugging C::B itself but certainly some bugs have creeped in. Those should be identified and fixed. With the new design, it should be easier for people to understand what's going on and help with those bugs. But things are already looking good :)
As a last note, GDB breakpoints are now explicitely pending meaning that you can set a breakpoint on a DLL and it will be set when that DLL is loaded. Also means you can just put breakpoints anywhere in C::B source code and press "Debug->Start" (yes, I renamed it). No more wizard skills are needed to debug C::B :)
Finally, debugging is now much more responsive (aka faster).
Updated tinyXML to version 2.4.2
Better unicode handling and faster string parsing.
wxKeyBinder added in the project
You can find its configuration in "Settings->Keyboard shortcuts". Looks like it's working OK, although I have identified a couple of bugs with it. Its configuration uses the file <config folder>/keys.conf, so if something goes wrong you can always delete the file ;)
By the way, if anyone has a list of menu shortcuts for MSVisualC++ please share them so we can add a second keybinding profile for people migrating over to C::B ;)
Minor yet useful changes
- Added context menu when right-clicking on editor tabs, ala Firefox (wxMSW only).
- Close page under mouse when middle-clicking on the tab, ala Firefox (wxMSW only).
- Control-rightclick in editor, pops-up context menu with web-search options (Google, MSDN) for the keyword under the mouse.
- Editor's context menu un-cluttered (close/save/etc - exist in tab's context menu)
- Multifile search is aware of hits in the same line now.
- Improved time needed for big projects (like C::B) from pressing "Build" to actually start building.
- Fixed "no handler for wxToolBarAddOn" xrc-loading problem with wx2.6.2/unicode.
- Moved some functions scattered around in globals.cpp.
- Fixed loading/saving wxDockit layout in unicode mode.
- Fixed "auto-complete" text box in editor options to be highlighted always using C/C++
- Memory-block allocator is used for parser's Token and project's ProjectFile classes (allocates large blocks of memory to avoid memory fragmentation).
- ~25% speed-up of project loading
- Show message if trying to open a project file from history which doesn't exist anymore.
- Fixed bug in cbProject when a template was trying to add a file in a different target.
- Added attribute in templates to ignore the default compiler (for templates that provide different settings for each compiler)
- Added projectPath and projectName fields in the new project dialog.
- Added fix for DigitalMars (wrong static lib linker and added stlport include path). Patch by Lieven de Cock.
- Don't show "Rename workspace" when right clicking the workspace, if no workspace is open.
- Fixed automatic filename conversion when changing target type in project options.
- Added support for Intel compiler (patch by yop).
- Added global cbSaveToFile() which uses a temporary file before overwriting the target file.
- Added a few base functions in EditorBase to handle common markers (bookmarks, breakpoints, etc).
- Added EditorBase::GotoLine(). Moves to specified line and tries to center it vertically on-screen.
- Added separate history for recent projects.
- Added network proxy support.
- Created separate context menu for editor when right-clicking on the margin.
And many other minor changes (quite a few bugs have been fixed).
All the changes were merged just a little while ago to HEAD. So, now you know why you haven't seen any cvs activity by me the last few weeks :)
OMG! Holly S**t! :o
Those are major changes for sure, I'm amazed!
Here are my first impressions:
ConfigManager
Amazing! But I'm not sure if I like breaking interface compatibility with wxConfig.
It is necesary to write
Manager::Get()->GetConfigmanager("editor")->ReadInt("/tab_size", 4);
instead of this?
Manager::Get()->GetConfigManager("editor")->Read("/tab_size", 4);
On where to store the configuration files and data, following the standard rules (like Mozilla apps) is a good idea:
* On Windows XP/2000
%AppData%\CodeBlocks\
* On Windows 9x/Me (if password protection is disabled)
C:\WINDOWS\Application Data\CodeBlocks\
* On Windows 9x/Me (if password protection is enabled)
C:\WINDOWS\Profiles\%USER%\Application Data\CodeBlocks\
* On Windows NT 4.x
C:\WINNT\Profiles\%USER%\Application Data\CodeBlocks\
* On Linux
~/.codeblocks/
* On Mac OS X
~/Library/CodeBlocks/
~/Library/Application Support/CodeBlocks/
%AppData% is a environmental variable which normally points to
C:\Documents and Settings\%USER%\Application Data on Windows 2000/XP.
About the XML file itself, following a based standard on the tags of the file, like the ones used in GConf (http://en.wikipedia.org/wiki/GConf) would be better.
IMHO Gnome's GConf XML format is one of the best, you can assign schemas to the configuration files, with descriptions on each element, different languages, etc.
A posibility, like GConf does, is to put each major setting (like Editor, Compiler, To-Do, etc) in a separate physical XML file. That way, if you go to another installation of C::B and only wants to import a specific setting (ie. Editor settings) you'll only have to copy that file!
All of that is pretty standard now within the GNOME apps, and is working great :)
Scripting support
Amazing!!
Perhaps you'll want to include wxScript (http://wxcode.sourceforge.net/components/wxscript/) support as well:
It's a set of abstract classes to add a script-interpreter support to your wxWidgets applications/libraries. The implementation of these interfaces for the Lua, Python, UnderC and CINT interpreters (these two are C/C++ intepreters) are provided.
Debugger plugin
:o!!
wxKeyBinder added in the project
One of my major feature requests was this! :D
I thought some ideas on how to improve even more here (http://forums.codeblocks.org/index.php/topic,1377.0.html). PLEASE, give me your thoughts on that.
Minor yet useful changes
* Added context menu when right-clicking on editor tabs, ala Firefox (wxMSW only).
:)
* Close page under mouse when middle-clicking on the tab, ala Firefox (wxMSW only).
:)
* Editor's context menu un-cluttered (close/save/etc - exist in tab's context menu)
:oops: Great! Now it's un-cluttered, but I'd still would like to see the Cut/Copy/Paste right there instead of a sub-menu.
* ~25% speed-up of project loading
:)
* Added separate history for recent projects.
My suggestion is to put at the bottom of the lists the "Clear history".
* Added network proxy support.
I'd suggest moving the dialog to Settings->Environment.
* Created separate context menu for editor when right-clicking on the margin.
:)
I'm amazed with all the changes being made!
I'm pretty sure Code::Blocks together with wxSmith are the best -and most promising- IDE/RADs out there!
Thanks to all devs, keep the good job! :D
Hello therion,
first of all i would like to thank you and the CB team for their work!
Second, the CVS Build you provided unfortunately doesn't work on Windows 98 because of a missing export:
Codeblocks DLL is linked with a missing export to SHELL32.DLL:SHGetFolderPathA
Here is a code snippet from MS to make it work on W98: // SHGetFolderPath can work everywhere SHFOLDER is installed.
HMODULE hModSHFolder = LoadLibrary("shfolder.dll");
if ( hModSHFolder != NULL )
{
(*(FARPROC*)&g_pfnSHGetFolderPath = GetProcAddress(hModSHFolder, "SHGetFolderPathA"));
}
else
g_pfnSHGetFolderPath = NULL;
}
if (g_pfnSHGetFolderPath != NULL )
g_pfnSHGetFolderPath(NULL, CSIDL_SYSTEM, NULL, NULL, szSystem32);
else
szSystem32[0] = '\0';
OpenFileName.lpstrInitialDir = szSystem32;
But i guess a dev needs to update the cvs for the fix.
Thx very much
Revy ---- waiting for a working cvs build for w98 :)
PS
I think one of its major strength of CB is, that it also works on W98, especially because everyone can use VC++ Express on W2k and above for free.
Ive just uploaded the files. They were update from head_merged_to_yt tag, but everything looks fine, should be some kind of temp tag, dont know :-)
BTW The KeyBinder is great! Really a great feature!
Ill test the new debug plugin and send a new build from HEAD revision (the real one) tomorrow (quite late here in Brazil, hehehe)
Enjoy the new build. http://paginas.terra.com.br/informatica/mauricio/codeblocks/