Plasma Plugin Loading

[Aaron J. Seigo]

On Tuesday, September 2, 2014 14.00:58 Sebastian Kügler wrote:
> On Tuesday, September 02, 2014 12:45:37 Aaron J. Seigo wrote:
> > Whatever path is taken, Plasma::PluginLoader is currently internally
> > inconsistent. Picking a path and then making all plugins load via the same
> > pattern would be fantastic for 3rd party developers wanting to work with
> > the  system. Complicating things is that libplasma was already released in
> > its current state, including shipping plugin macros that don't work.
> 
> Which? What are the problems?

See below about macros, which results in a source compatibility issue. 

It's also quite bizarre to have different methods of writing binary plugins 
for different components, but as a developer "inconvenience" it's not as 
critical as the macros situation.

> > The
> > more time that elapses with it in its current state the harder it will be
> > to fix as people write plugins using currently supported / advertised
> > methods.
> 
> You mean that we currently require to ship a .desktop file, which could in
> the future be a json file? Anything else?

Plugins use the plugin macros provided in the header, e.g. 
K_EXPORT_PLASMA_APPLET

If these all move to json based plugins, then a new macro is going to be 
wanted, as already done for DataEngine and PackageStructure .. which now have 
both the old and new macros in their headers which currently can lead to 
plugins that build but which aren't loadable by libplasma anymore. Currently 
this is not much of an issue as there really isn't much in the way of third 
party add-ons for Plasma 5 out there, but as users eventually migrate to it 
and 3rd party developers start working with it, plugins will appear and 
transitioning to json will be a lot harder without annoying users and 
developers.

For anyone who might wish to build an actual product around Plasma, breaking 
plugins between releases is likely to be a deal breaker.

Of course, support for the old macros can be kept by making PluginLoader use 
both mechanisms when looking for a plugin. That is not what loadDataEngine is 
doing, nor is it what loadPackage is doing as that was modeled on how 
loadDataEngine was written. Adding a fallback means more code, use of more 
classes from KF5 and (marginally) worse performance when failing to find a 
plugin. 

An alternative is to just rip out those old macros all at once and hope nobody 
notices. I don't think they will since there aren't the third party add-ons 
out there just yet.

If the macros are kept, which would be keeping with the letter of the law for 
stable releases, then the fallback paths ought to be there so they actually 
work.

These are things that need figuring out and fixing ...

> Note that these tasks are not currently on my TODO stack. If someone else
> wants to work on it, that's totally cool, it's not a priority for me in this
> cycle.

I'm sorry to hear that. Leaving that sort of work half-done is unfortunate and 
frankly not what one would expect from a KF5 component. It's certainly not as 
"fun" as hacking on klipper's UI, but it is the kind of thing that makes 
Plasma a less viable solution for those who might wish to pick it up. These 
are really basic things that need to work and work consistently.

(That isn't hypothetical: The work I did last week was paid work done in hopes 
of salvaging Plasma for use in a product. There is still a long list of items, 
unfortunately, this among them.)

> By the way, the json file does include i18n'ed Comment and Name keys. What
> else are you missing?

Ah, I see there is a new version in kdecore-addons by Alex Richardson which is 
much better; the old version in the kservice repo was still there when I 
started last week's work... btw, there are still tests and man pages in 
kservices for desktoptojson that probably should also be removed.

Anyways, I'm back to other things again with the work project, so I take my 
leave again at this point.

-- 
Aaron J. Seigo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20140902/a844f459/attachment.sig>