KTextEditor Plugins

[Dominik Haumann]

On Sunday 22 December 2013 22:34:50 Milian Wolff wrote:
> On Saturday 21 December 2013 22:49:42 Christoph Cullmann wrote:
> > Hi,
> > 
> > during the last 10 years, close to zero usable plugins did show up for
> > KTextEditor. The few existing that are useful, would be better merged into
> > the part, instead of having the whole code around to load plugins, manage
> > them, ...
> > 
> > For KF5, I would remove the KTextEditor plugin interface completely.
> > 
> > It was brought up, that this kills the possibility to have plugins shared
> > between Kate / KDevelop.
> 
> <snip>
> 
> I agree that sharing would be a cool thing to have eventually - but it
> should not be a priority.
> 
> Rather, I'd argue along a different route on why you should keep - and
> improve - the existing API, rather than ditching it.

And again, the KTE::Plugins were basically not use at all.

> A plugin API allows for much faster experimenting with new features, similar
> to what Sven mentioned. I don't need to create a "fork" of Kate in a branch
> to try out a new feature e.g. New functionality can also first be tested
> easily by interested people before then integrating it.

In this thread, we are talking a lot about keeping the KTE::Plugin interfaces.
But we are not talking at all about the use cases. Now we can extend the KTE 
interfaces, but if they are again not used for the next release cycle, it's 
completely wasted time...

Use cases that make sense:
- plugin for collaborative editing
- search & replace in multiple files (but here already is the integration with
  other plugins a problem, e.g. in Kate with the Projects plugin)
- ... ?

It's also unclear to me how to control which plugin shows in which app. We'd 
need to introduce new keys in the .desktop files to make sure a KTE plugin for 
KDevelop and Kate does not appear in Kile, for instance. Having general 
purpose plugins for applications with different focus is simply not the most 
awesome thing to have. 

Also, I don't think merging the Kate interfaces in the KTE interfaces makes 
sense. You don't need a DocumentManager from Kate in KDevelop. Kile also has 
its own implementation - and that's ok.

Or to put it the other way round: If we move all our Kate plugins to KTE 
level, then we basically can the entire Kate app into KDevelop, same for Kile.
But this is not going to happen.

Greetings,
Dominik