User forums > General (but related to Code::Blocks)
Hi
vongodric:
Hi everyone,
First wanna say that code::blocks is really great -I'm switching all my dev'ing over 8) Really good work guys!
Now I had also a small question ( wasn't sure into wich topic this belongs ) -I'm developing an IDE as well, but it's for FreeBASIC compiler and is very different from code::blocks ( using c++ and wxWidgets ) and I was playing with the idea of implementing plugin support for my next major release. I'v been looking into the subject a bit ( and also browsing code::blocks source code ), but could someone be so kind and shortly describe what is the best approach to take and reasonable way to implement plugins? Mostly I'd add plugins for helper tools( like code auto formatting/indenting or exporting into html/rtf/..., maybe RAD tool? and the likes )
Thanks.
ps! my "IDE's" website: http://www.fbide.freebasic.net/
thomas:
There are several ways to provide plugins.
The most portable is to embed a scripting engine (of any kind) and write all plugins in that scripting language. Firefox works like this, for example.
Another solution is to build plugins as dynamically linked library with a defined interface. Code::Blocks uses that approach. The intimidating word "interface" means nothing but some known symbol (usually a function with a well-known signature) which is exported by the library (so the application can import it).
There are several ways to design the interface, the easiest way is to export a few C functions, but you can as well define the interface via a C++ class (Code::Blocks does that).
Whatever you choose, you have to ensure that
a) the interface does not change once it is released (or else all plugins will break)
b) plugin developers comply with what you define as the interface
The easiest (least painful) way to guarantee that plugin developers comply with the interface is to make a C++ class from which they derive their plugin.
vongodric:
This is something I had in mind ( pretty much the code::blocks approach ).
To have a base class that provides base set of methods and from what actual plugin is derived. The rest is upto for a plugin developer.
My drafts and a sort of working test that I have so far.
http://cvs.sourceforge.net/viewcvs.py/fbide/FBIde/fbipe/
But I just want some background information before really starting designing potential system of my own. External scripting is I think a way limited and slow. Though no doubt is easy for plugin writer and developer. Doesn't code::block support some scripting capablities? ( I was under impression it provided angel scripting? ).
thomas:
--- Quote ---This is something I had in mind ( pretty much the code::blocks approach ).
[...]
My drafts and a sort of working test that I have so far.
--- End quote ---
You should add something like a "C" GetPlugin() global function which is exported and which returns new YourPlugin. There are of course a hundred other ways to do it, this is just what I would do...
Also, I recommend that you build in some versioning and sanity checking functionality. This can be as easy as exporting a constant, or a function like GetVersion() or something. Anything will do, but you should have a way of telling whether the plugin will send your application straight to hell - in that case, the application should refuse to load it.
Personally, I would also keep the header file near the source, but that is a matter of taste. In any case, think clearly about the filesystem layout now and make any changes that you might make some day now, because the less files you have, the less trouble you have.
--- Quote ---External scripting is I think a way limited and slow. Though no doubt is easy for plugin writer and developer.
--- End quote ---
It really depends on what you want and what you need, and on who is your audience. If you expect your plugins being written by users who don't necessarily know a lot about programming, then Python may very well be a consideration (although I personally hate Python, it still has advantages you can't deny). On the other hand, if you expect your plugins to be written by professionals, then I'd recommend C++.
Inkscape effects are all Python or Perl scripts, Blender supports a large part of its functionality only through Python (almost all file import/exports are done that way, and many, many effects), Firefox extensions do everything using JavaScript... there are more examples that could be used as proof of concept that it works and that it is fast enough on today's hardware.
But generally, you are right. Scripting is of course at least 10-15 times slower than native code.
--- Quote ---Doesn't code::block support some scripting capablities?
--- End quote ---
Yes, Code::Blocks supports AngelScript. But we still write plugins in C++. It is faster, and a plugin has more power (in fact, a plugin has the same capability as the main program).
vongodric:
--- Quote ---You should add something like a "C" GetPlugin() global function which is exported and which returns new YourPlugin.
--- End quote ---
This is eactly what I did with my test app :wink:
--- Quote ---I recommend that you build in some versioning and sanity checking functionality
--- End quote ---
Yes I thought of it as well. I think there should be version checking where plugin checks host system's version and vise versa. Where main program checks SDK version or smth? Maybe some security number or and string. becouse it is possible that some random dll happens to have same global functions. Unlikely thoo :)
--- Quote ---It really depends on what you want and what you need, and on who is your audience
--- End quote ---
Mostly I want ( from my part ) to provide tools for my ide so I won't have to hardcode them into an editor. In most cases these are helper tools and the like. Maybe some wizard like things that guides user through some steps and generates starting code? But few people already have said that they'd be interested in adding rad and cvs plugins -of course this remains to be seen. So I think C++ based are really the best choice for me.
Navigation
[0] Message Index
[#] Next page
Go to full version