Plugin skeleton generator

[nxtum]

Plugin skeleton generator 1.0:

• plugin name
• jsonrpc functionality
• comrpc / jsonrpc interfaces
• out of process or in process

[MFransen69]

Hi Tym,

Great start!!

Some small remarks:

• Perhaps for consistency (and certainly if people will call them without a path in front in case that was added to a system path) should we also call the main Python files ThunderDevTools and PluginSkeletonGenerator?
• perhaps make the console interface for the devtools a bit nicer / easier to read :

== Thunder Development Tools ==

Choose one of the following tools: (To quit, type q)

1. Plugin Skeleton Generator

You have picked:

• It now does not (yet :) ) create the .json file
• Add a .template to the template files to prevent making people think they can just copy and paste them to their own location and not use the tool?
• just as an idea: perhaps for a next version (so not needed to this this now) make the templates files a little smarter and into smaller snippets that combined deliver a complete cpp/header/cmake file? (now there is quite some overlap in for example the files for in and out of process)
• I'll try to add the remarks on the generated code in the template files themselves, that is easier. Guess there is no code in the python files?

[VeithMetro]

Looks like a great tool indeed, well done! I added some remarks, and if something is not clear, feel free to reach out. Small side note: I reviewed the python code, and the generated code in examples, since it was easier than reviewing templates.

Also, it would be great if you could simply react to or comment each of my remarks after you take them into consideration, way easier to track what's changed 😄

[MFransen69]

• set execution bits for py files
• remove examples in the end
• start from ThunderDevTTools:
  Error running the script: python3: can't open file '/home/mfransen/src/ThunderWIP/PluginSkeletonGenerator/ThunderTools/PluginSkeletonGenerator/PluginSkeletonGeneratror.py':
• make adding config conditional (see below as well)
• in plugin c'tor also call PluginHost::IPlugin, JSONRPC etc. constructors (like we now do for the other interfaces, classes)
• config, also call constructor for member(s) in initializer list
• for a lot of the methods there is only a declaation, not a definition
• let's indent the entries in the interface map as wel always do
• eh think the Jsonrpc without comrpc do not make much sense, or am I missing something
• out of process should have a mode setting in the conf.in file

•   explicit ConnectionNotification(OutProcess* parent)
            : _parent(*parent)
        {
  

  propose to do (OutProcess& parent) (no assert needed and clear it must be a valid pointer) and make member then also a &
• out of process -> the Deactivated notification handlinging in the parent is missing
• OOP without interface is hardly valid use case. If we want to support it the interface in root should be IPlugin I guess)
• OOP implementatiion is missing the move deletes
• plugin.josn status": "production", -> make this development (ask Sebastian for possible options)
• OOP missing init for the interface members in ctor and queryinterfacing them and asserts and assigning etc for multiple interfaces e.g.g always refered to as _implementation in cpp file)
• OOP implementation no Exchange:: namespce before interfaces
• OOP configure needs more attention. I propose to indeed ask support and when OOP ask for in or out of process configuration (and use IConfiguration for the latter)
• OOP Deinitialize: if (_service != nullptr) { -> sorry somebody added that almiost in every plugin, that should not have hapenend :) It should be an assert I think: ASSERT(_service == service);
• Think it should be okay now but if you change for the above comments taken into account Deinitaize will be called ahen Initialize is failed so should to correct cleanup for every failure in Initialize
• Also for OOP does not make sense to have jsonrpc without comrpc interface, also now realize how do you connect them together. Sorry only realize this now we should not ask for the jsonrpc inteface we can deduct from the comrpc. Hmm only problem could be that they are in one header file (like IDisplayInfo) but we can't cater for all situations, they have to change that manualy
  if we parse the interfaces we can just check the @JSON tag
• move the J interfaces to the cpp file?