User forums > General (but related to Code::Blocks)

Hi

<< < (2/2)

thomas:

--- Quote ---This is eactly what I did with my test app  :wink:
--- End quote ---
Ah, I only looked at the PluginClass header, and saw no such thing there. I'd put everything that belongs to the plugin SDK into one file.
Exporting this access function and the version info can conveniently be done via a macro that you define in the plugin SDK header. I am normally very strictly against macros, no matter for what purpose. But in this case, a macro really makes your life easier. Look how Code::Blocks does it.


--- 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.
--- End quote ---
Either way works if everybody is persistent in doing it. The easiest way is to have a compile-time constant in the header, so every plugin has a version number (which can be accessed directly as symbol or via an accessor function). When the application is updated, you update the number in the header, too. The application can then decide not to load plugins with a too low version number.
Alternatively, you can provide something like GetMinVersion() and GetMaxVersion() as virtual (or pure virtual) functions, or you can really put the responsibility of checking the version into the plugin developer's hands. In that case, you must export symbols from the application, though (or provide some other way of determining the version). You can even put the version information into a different file (it could be stored inside the archive holding the resources, for example).
Again, it is your choice how strict you want to handle everything, and how easy or complicated it should be.

vongodric:
I think plugin identification is just a matter of design and there are many ways to do it. I think the easier it is to write plugins the better, it wouldn't do to have to write some 50+ lines for just to initalise.

More important to me at the moment is to settle down the interface how plugin interacts with the main program. I guess I have whole wx api and provide way to get references to wxApp and wxFrame that are used by the main program. But also probably create an internal IDE interface that is exposed to the plugin. Like access to documentManager, configManager, compilerManager, uiManager( menus, toolbars... ) and etc. This is where the complexity kicks in and where I want things clearified for myself.


* How to handle events? - I guess on request to connect to main app event handlers. also internal interface can be used to send / receave events.
* Should plugins be able to interact with eachother? -I don't know if code::block allows that. In some cases it could be even usuable. ( for example code formating plugin interacts with code indenter plugin. to produce output. But in this case they can be the same of course, but it's just an example ). If they do interact then this adds a layer of dependency to the whole system.
Does code::block has any security/protection mechanisms against malicious plugins?

thomas:

--- Quote ---More important to me at the moment is to settle down the interface how plugin interacts with the main program.
--- End quote ---
Providing plugin functionality can (again) be done in a hundred ways. One possible way is to call a function like PluginAction() whenever a specific action is wanted from a plugin. Another solution is to use events. You can either send out dedicated events to a plugin, or you can propagate user events (like key strokes and menu events) to the plugins (or a subset) and let them decide... everything is possible.
Both ways are OK, everything works just as well (events are somewhat more expensive, but more flexible).
You derived your plugin from wxEvtHandler. This suggests that you intended to use events.


--- Quote ---But also probably create an internal IDE interface that is exposed to the plugin. Like access to documentManager, configManager, compilerManager, uiManager( menus, toolbars... ) and etc.
--- End quote ---
A manager is usually a singleton class and thus you need no special interface to access it from the plugin.


--- Quote ---How to handle events? - I guess on request to connect to main app event handlers.
--- End quote ---
An event table is the easiest way, since you know what events the plugin will be wanting in advance.


--- Quote ---Should plugins be able to interact with eachother?
--- End quote ---
This is your decision. To me, it makes little sense, as such dependencies bring a *lot* of troubles, but it is very easy to provide that functionality (just offer a function that enumerates all plugins with pointers to their Get() function).


--- Quote ---Does code::block has any security/protection mechanisms against malicious plugins?
--- End quote ---
Yes, we look at the sources :)
Other than that, you cannot protect yourself from malicious plugins.

vongodric:
Thanks Thomas you'v been a great help  :)

Navigation

[0] Message Index

[*] Previous page