KTextEditor Plugins

[Christoph Cullmann]

> Hi!
> 
> I still find the concept of KTextEditor plugins very elegant, and that they
> have not been used is not true in my eyes. For example I have written this
> collaborative stuff recently, and another person has written a D code
> completion plugin -- just in the last few months.
> 
> Let's take the collaborative editing stuff as an example of why KTE plugins
> are great for it: It is a feature which is potentially useful for all
> applications using katepart, including kate, kile, kwrite and kdev. You
> might say it could be in katepart, but that's only correct on paper:
> Although the feature is working okay, it is not woking as well as the rest
> of katepart. I would in its current state not want to merge it into
> katepart. Thus, without KTE plugins, it would exist only in a fork of kate
> and slowly rot unless I maintain the fork all the time (merge from kate
> master etc). Like this, though, it's in an extra repo and only interfaces
> with an API which has been the same for 7 years, distros package it, and
> people who want it can use it without the others suffering from the bugs it
> still has.
> Of course it would be cool to have it in katepart, but it's a project which
> can't start in there. It's much easier to develop it outside of the kate
> tree for a year, and later merge it eventually.
> Apart from the staibility issues, the plugin currently depends on lots of
> things katepart should not depend on. It would take quite some work to
> change that. Same goes for e.g. the D plugin: If you have it as a separate
> plugin, you don't have to worry about run-time dependency handling. You
> don't want kate to depend on a D compiler.
> 
> We should discuss that again at the sprint though, it'll be much easier in
> person.
> 
> Then again, under the condition that we manage to design a plugin interface
> which all relevant apps implement which also allows document and toolview
> management, I would be okay with moving to that and dropping the KTE one.
> But then we should really do that and make it work (I'd help with
> implementing it) and only then make the final decision to drop KTE plugins.
Yeah, we can discuss that at the sprint.

e.g. the current Kate application interfaces would make a good starting point, guess
needs to be just shrinked down.

Btw., does KDevelop support multiple main windows or is this then again a new process?

I was about thinking to go for Kate to the "each main window is an own process" scheme, too.
This would make the interfaces A LOT less complex, as each plugin would have only one view,
even the plugin/view split could be removed.

Greetings
Christoph

-- 
----------------------------- Dr.-Ing. Christoph Cullmann ---------
AbsInt Angewandte Informatik GmbH      Email: cullmann at AbsInt.com
Science Park 1                         Tel:   +49-681-38360-22
66123 Saarbrücken                      Fax:   +49-681-38360-20
GERMANY                                WWW:   http://www.AbsInt.com
--------------------------------------------------------------------
Geschäftsführung: Dr.-Ing. Christian Ferdinand
Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234