files types are handled automatically (more or less - at present, there's no programmatic way to add new file types for the project tree). you can create project wizards without creating a plugin.

a plugin would be suitable for adding testing or debugging facilities. I put together a "proof-of-concept" python debugger a couple of years back, which simply parses the output of the command line debugger (pdb) in order to offer familiar gui interaction. what do you have in mind for testing?

I asked because it makes a difference. CB's project infrastructure was designed for compiled languages. Interpreted languages don't need all of that complexity. So what sort of project support do you need: just a container to say these files belong to this project?

Quote

But the plugin must add new project types and new file types.

you could deploy a project wizard along with your plugin. It wouldn't be all that difficult to tweak the CB SDK to add the ability to add file types programmatically (file a patch if you want)

Quote

For testing, it should create a console that interpretates commands and return the possible results....By the way, is there a way to incorporate the console on "Log & others"?

You could use existing logs to send output (for example, commands that you set up on the tools menu can be redirected to the log)

Alternatively, you could create your own frame or window that handles process I/O. I've written a plugin called ShellExtensions that does just that for arbitrary commands. (you can find links to these plugins at the project page in my sig. I'm in the process of getting some of this code ready to move into C::B proper)

one way to proceed would be for your projects to offer two targets (or two sets of targets): one for the actual program, and one for its tests. users could then select which target they want to run. the problem with this is that C::B targets can't at this time be set up to pass their output to a plugin for further processing. the other problem is that if you use the project system in this way, C::B will expect you to choose a compiler for the project (or use an existing compiler) and present a bunch of unwanted and confusing compiler options to your users.

But the tutorial is incomplete. Is there an updated (and completed) version of the tutorial?

unfortunately plugin development documentation is in a sorry state (lots of incomplete stuff). The best way to learn is just to download code::blocks source and inspect some of the plugins.

We can help you, but you need to give us a better idea of what you want to do. I suggest writing up a short description that more precisely lays out a minimal sample project and the features that you want to support.

was written by the project leader to educate me on how to write a plugin. If you are interested in that specific example, it actually became the basis for the "ShellExtensions" plugin (which does a lot more than just launch external programs: it has a file manager, supports custom commands and redirection of command output to a dockable window). I'm working on getting that plugin ready for the main cb repository. Right now, you can find it by following the link to the project page in my sig.

Just for now, I need to make a plugin that: - when plugged to Code::Blocks, it will add a new project type and new file extensions - when unplugged to Code::Blocks, the new project type and new file extensions will disappear