Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

event sequence question?

<< < (6/6)

killerbot:
displayevents is in plugins (so not in contrib) which is ok, but I think it better acts as the other plugins then, meaning it does not have its own cbp files, but integrates directly in the CodeBlocks_wx<...>.cbp

What do you think ?

Miguel Gimenez:
You know better the build system than me. The only constraint is the plugin should not be in the nightly/release, because plugins activate automatically and this would waste time without any benefit for users.

Miguel Gimenez:
I read somewhere that this plugin should be treated like the headerguard, i.e. a core plugin not added to the main project. I think this is the better solution, this way you can install it if needed but it will never go in the nightly/release.

AndrewCot:
I was looking at the header guard and the other plugins by same author last night and they were not included because they can cause bad side affects if not used/configured correctly. As such these are probably not the best to use as a template.

Headerguard info:    URL info: https://wiki.codeblocks.org/index.php/Header_Guard_plugin    Problem:  The Header Guard plugin is included in Code::Blocks' source code (src/plugins/headerguard/), however, it is not built by default to prevent unexpected behavior.
It would probably be better to do one f the following:1) Create the cbplugin via the project file and leave it up toe the dev to manually install it2) Create the plugin in the devel directory but mod the profess so it does not copy the files to the output directory so it does not get released, but can be used when running he C::B as a debugee.3) Do both options 1 and 2
I am inclined to think option 3 would benefit the developers the most.

MortenMacFly:
Just keep in mind that some plugins are for pros and spoeciual needs., These are:
* header guard
* debuggergdbmi
* DisplayEvents
* EventsDisplay
* loghacker
* modpoller
* tidy cmt
(Some of them form different sources.)

These I would consider as "special plugins" meaning its partially more a tech-demo or debugging tool and the average user won't use these. In fact, as written above they may cause unexpected side-effects. So any use should be done with care.
I would also think about whether or not to add these at all to a release. From my point of view they should probably all be in a separate workspace/project.
For an installer I would expect these on a separate page with a clear warning message and not to be installed by default.

Navigation

[0] Message Index

[*] Previous page