I thought the objective of plugins was to keep the underlying program lean and mean and let the user decide which additional features they need. That approach is also more conducive to the creation of alternative plugins with similar functionality. It also means plugin bug fixes and enhancements can be delivered independently of the core - in a matter of hours, rather than waiting for the next release of the core.
How will you decide which will be in the core, if you exclude plugins that reference external resources, that will eliminate one of the docx import plugins (the one that uses Mammoth) - it could be that that's the one most widely used.
Quote:
Originally Posted by KevinH
[ . . . ]
Or is all of this just a waste of time and we simply stick to what we have now?
[ . . . ]
|
That would be my 'philosophical' view. However I would not suggest you take much notice of that.
What would be useful would be the means to get hold of earlier versions of plugins so that one can easily revert when something goes wrong.
And a notification mechanism when Sigil starts that advises of new plugins and new versions of installed plugins. As I understand it, it's when one uses a plugin that one will be informed of a new version. But that is probably not the best time to be considering updating the plugin you were just about to use.
BR