Modifying Code::Blocks for students at Cambridge/MIT

[srhb2]

Hi,

I'm working on a project to make a simple IDE for students to use at Cambridge/MIT (a Cambridge-MIT Institute project). I thought Code::Blocks was ideal since it is pretty advanced and uses wx (so students can go home and use it on their windoze machines to develop code they wrote in class on the linux machines), and much of it can be scripted/configured with "soft-coding".

What I'm trying to do is to simplify the interface for use by newbie students while learning C++ basics - the full-blown version is too much to begin with (I guess this is a bit like the BlueJ project in that sense). After a while they can then graduate to the full thing.

I've managed to strip a lot of the non-essential plugins, buttons and menue items, and modified a couple of wizards. Bearing in mind that I'm a non-expert on this (just an environmental fluids researcher hired to do this for the summer), could anyone help me on a few things with soft coding where possible:
-- Can I make the terminal output from running console apps instead appear in a messages window?
-- How do I make wizards start from menu items/buttons directly without going to the New from template window first?
-- What's the proper way to add in different compilers? This is for cross-compiling to a format we're using on an autonamous robot design contest.

Finally, I'm hoping to get Octave working with CB to some extent, so students only have to use one IDE, and we want to get rid of expensive Matlab. Are there any plug-ins already for this? I gues the Matlab lexer is fine for code highlighting.

Thanks in advance for any help.

Regards,
Steven

[MortenMacFly]

Finally, I'm hoping to get Octave working with CB to some extent, so students only have to use one IDE, and we want to get rid of expensive Matlab. Are there any plug-ins already for this? I gues the Matlab lexer is fine for code highlighting.

I don't really understand what you have with Octave (is there an Octave compiler???) in mind, but: I've developed support for the (Free/Matlab) LCC compiler and a Matlab-C-S-Function wizard in addition. This works very well, if you want to get the patch/wizard code please contact me via PM and tell me an Email address to send you all required stuff. Please note: This is in no way illegal stuff, but we have decided not to add support for the LCC compilers at this stage. Allthough I've continued to develop this to a mature state.
With regards, Morten.

[srhb2]

Hi,

The thought of the professor was to use C::B as a Octave front-end a bit like Matlab's (e.g. with a plugin that may have to be developed). I would also be interested in your LCC support wizard/patch, as this could be a useful addition.

Regards,
Steven

[MortenMacFly]

Alright, here it comes. I've attached a ZIP file for you with a content that should be easy to apply to the sources. Included is a patch file that contains the required changes to be applied to files that are already in the sources you've checkout from SVN. In addition several other files (new, not in SVN) are in the archive that you need to put into the folders just as they are in the ZIP archive.
Then compile C::B to have LCC support enabled. Please notice the following: The LCC compiler (if installed correctly) queries the registry under windows to obtain the path to it's libraries. If the registry is not setup correctly the compiler would complain that on the command line and query the path from STD::IN (!). This will *not* work inside C::B (C::B will freeze then) so make sure you have setup LCC correctly. Verify this by compiling a little "hello world" application on the console (not within C::B).
The plugin is compatible to both, the LCC-Win32 compiler and the LCC compiler as it is shipped with Matlab (which is a modified variant of the original one). If you want to run both compilers in parallel I suggest you make a copy of the compiler and adjust the path setup in C::B accordingly.

Inspect the wizard to understand how to setup a C-S-function project using C::B. Please note that this wizard also supports generating S-Functions with the GCC (but you need to convert the libs to GCC compatible ones for this). This works very well for me. If you need further assistance with this feel free to ask.

With regards, Morten.

Ps.: I strongly recommend you remove your email address from the previous post - otherwise this will be spammed sooner or later. That's why I asked you to send me your email address via PM and not within the official thread in the forum.

[attachment deleted by admin]

[thomas]

If I may suggest something regarding this simplification idea:

Don't change anything. This will be an awful lot of work and you'll probably break something. Don't get me wrong, I am not doubting your abilities, but Code::Blocks has become sufficiently complex during the last year so this is not entirely impossible.

Instead, add a plugin that catches events such as for example cbEVT_APP_STARTUP_DONE to display something similar to our "start here" page, but more targeted to someone who has never used an IDE. It could explain what an IDE is about, what you need projects for, and a link "create a project NOW", for example. You could also save the progress in the config for each user, and change that page with time.

You can modify things like the project manager's popup menu or the editor's menu from inside a plugin quite easily (remove or rename some menu items). The same goes for the main menu bar. Settings can be changed, projects and sources be modified.

You might want to look at InfoWindow class and display a few of these at certain key points. Look into sdk_events.h, there are plenty of events being fired at important milestones, you only need to register to them and you can tell the student what to do now (of course you could also launch a wizard or something else instead).

Why am I suggesting this?
1. It is probably a lot easier (just register to some events and do something in reply), and you don't risk to break anything.
2. When your students are sufficiently advanced (or when they think so), they can simply disable this plugin, and Code::Blocks will immediately work in "pro" mode. No recompilation, no need to download a few megabytes again, no problems installing different versions
The plugin might even be configurable to give up different things independently of each other, for example, you could turn off "simplified project menu" but still keep "beginner's start page".
3. This would be a very cool plugin for us to have too If you'd consent with this, we could distribute it with the regular version of Code::Blocks, lowering the complete beginner's entry barrier, but not annoying the advanced user at the same time.

[srhb2]

Hi,

Thank you for these ideas. I think I'm pretty much in agreement.

So far I am trying to do everything only using the .xrc files and wizard scripts, and have been able to do much of what I'd like to do. Just very simple things - getting rid of a lot of the extra menus etc. I don't think I'm the right person to be making detailed changes to C::B anyway, and as you say, I don't want to break it. Also, it needs to be updatable from the SVN insofar as possible.

I'll look at the idea of using a plug-in to catch events, a good way of decoupling any customizations I have to make. (The project PI is of course happy to give away any useful code that might come out of our efforts - it's for educational purposes afterall. There's no point in adding department/course specific stuff though I guess.)

The one problem with the way I've been doing it as compared to your suggestion of having the "easy mode" toggable is that editing the .xrc files etc doesn't neatly toggle on and off like a plugin. Hmm...

Anyway, will get back to you - need to try to figure out plugins and registering event handlers now...

Regards,

Steven

[thomas]

Something like this should be nicely pluggable:

Code

LowEntryBarrierPlugin::OnAppFinishedLoading()
{
    // this is some hefty pseudo-code, but you get the idea  :-)
    for(filename, patchedfilename in all_xrc_files_to_replace)
    {
        wxXmlResource::Get()->UnLoad(_T("memory:") + filename );
        wxXmlResource::Get()->Load(patchedfilename);
    }
}

It first unloads the resouces loaded by the application, and then loads the patched versions instead. Not the most efficient thing to do, but it should work seamlessly.

Please do note that you absolutely need the memory: prefix for unloading, since we do batch loading on the resources for performance reasons (especially over NFS) and let the XRC functions solely read from a memory stream.

[srhb2]

Thanks very much - I'll give this a try.

Regards,

Steven