Mention of the career editor in the QA thread reminded me of a chat I was having with Peter last night (and on other occasions in the past) about just what is a plugin, and what role and responsibilities should it have.

 

We came up with the idea that a plugin should be completely optional; the core program and other plugins should be able to work perfectly well without the plugin installed.   Within this definition, Peter's Body Mesh Tool is a plugin, while the PJSE string editor is not, and apparently the BHAV wrapper is not, if it is used when importing semiglobals at package level.

 

This perhaps means the string editor needs to be arranged so that the string editor core is a dll that becomes part of SimPe core, which SimPE and other plugins may call to if they need to (or they can of course use their own specific code and not use that dll at all)

 

Once this next public release is out, perhaps we could discuss the optimum way to have Peter (and other plugin makers) and Quaxi's work interrelate.   That could pave the way to make it easier to incorporate new plugins.

Technically the core-plugins are nevertheless plugins , but the idea described by Inge is a good one.

Maybe the plugins could be grouped into two classes in the future:

Core Plugins, that provide basic functions and are neccessary for SimPE to work

and

Extension Plugins that extend the Features of SimPE in a way

Those could be grouped according to this classification in the Preferences Window, Basic Plugs just shown (maybe with version number, for bug-research reasons), but the users are not able to manipulate them and the Extension Plugins with checkboxes to activate or deactivate  (or rearrange) them by users discretion.

The string Wrapper is an integral part of SimPe, it is used in many places. So that definetly is not a plugin, not even a core plugin.

BHAVs are another story. SimPE itself does not need to know BHAVs, BCONs or stuff like this. So from SimPe's point of view, BHAVs are a real Plugin.
If you look at the world fom the Carrer Editors point of view, the BHAVs become a manditory feature, as the Plugin needs to manipulate BHAV content. So what is it now, a core Plugin. For the career editor it certainly is one, for SimPE itself and most other plugins it is not.

A nice way to solve this would be the definition of interfaces for important types. So SimPe would define an Interface for the BHAV-Wrapper, one for the BCON-Wrapper and so on.
Plugin developers could then use these interfaces to work with BHAVs without binding to a certain plugin (like PJSE), they just expect an object reference to a class that implement sthe BHAV interface. If no such class is known to SimPE, the Plugin won't install itself, or show a warning when executed.

The big problem with this approach is, that we would need such an interface for each resource wrapper, that is not an original part of SimPE.

The other way would be, to implement all wrappers in SimPE itself (at least base versions), and then extend the gui's for those base wrappers in the Plugins. But those would be weak plugins at bestm because they would all use the stuff implemented in SimPE, which (as recently with the TTAB) simply results in more work.

Actually Quaxi, I *like* that idea of the shell!  If the wrappers were the equivalent of a shell, then there would be a whole separate class for plugins that were mainly user interfaces.  People could choose the ones they happened to like working in - some could be simple, some more complex to suit the type of user and their task.   People who simply want to rename their object in the CTSS do not need the entire weight of the PJSE string editor interface - or maybe they need something extra, like a wizard that asks "will you want to edit this for the other languages?" and if not it will get rid of them.

I don't necessarily see that as a problem.  I think the idea of using interfaces to define what a BHAV or BCON, etc, "is" is a good one.  These would be interfaces in addition to the current AbstractWrapper (and my own ExtendedWrapper) classes that purely define the filetype-specific methods required by other users of that filetype.  Methods would need to be added to the interface in a controlled manner, of course, so that all implementers of the interface could upgrade.

From my limited experience, it doesn't sound logical that the data wrapper should be the provider for its UI.

When I needed to use the Str wrapper on the hair binning tool (a true 3rd party plugin), I only wanted to get a string from the resource, so I was a bit confused by the existence of two Str wrappers in SimPe.

In that stance, I would agree to keep the un/serialization functions in the core of SimPe, while providing a mechanism to attach a certain UI handler to a particular wrapper instance (or the other way round?), in the form of a "UI registry".

The base data handler could be overriden by simply keeping the current Plugin-Wrapper management.

Ok, what I mean is to have a table linking the file descriptor type to the data wrapper type, and another linking a wrapper type to the possible ui handler types.
By changing the priority of a particular ui handler, one could choose the UI for the Cpf, Ttab, etc.
Better yet, it could be done similar to windows explorer's "Open with.." verb. :D

From the resource loader perspective, it would have to instantiate the data wrapper and the ui handler separately. The wrapper instance (or instances) would be passed to the ui handler, for example by exposing a "WrapperList" property ;)

Does this make any sense, or is it too complicated/crazy to implement?

I am not experienced in dll type programming, does this mean that you can make a Sims tool that uses SimPe's wrappers without opening SimPE to run the tool?

I think the Lot Expander already uses SimPe's dlls to manipulate the lot packages. Of course the included dll's also have the ui code that it's not even necessary.

When I mentioned the Str wrapper, it was used in a "Tool plugin", which needs SimPe main window to run though.

Yes, the reading and the GUI stuff is not seperated very well, but this would be possible even with the current Interfaces. The base Wrappers would simply not register with the WrapperRegistry, and return a null reference in the Control. Plugins could then simply extend those base classes and override the Control Property to attach a UI to the Wrapper AND register that extended class with the WrapperRegistry.

I think the reason why Peter choose to have his own Str-Wrapper was, that the original SimPE one is a mess to use, and not the fact that simply wanted a different UI :D

The complete SimPE core was never designed to support a larger amount of plugins. It all grew from a very simple architecture, that was supposed to be a extremley simple package reader/writer.
So the architecture would basically need a major upgrade :)

 

Is that a rueful smile because you really don't want to do that much extra work, or an eager smile because you welcome the challenge?  :P