[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kwrite-devel
Subject:    Re: KTextEditor Plugins
From:       Sven Brauch <svenbrauch () googlemail ! com>
Date:       2013-12-22 13:08:42
Message-ID: 3534100.2tk8eiuuJV () localhost ! localdomain
[Download RAW message or body]

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.

Greetings!
Sven

_______________________________________________
KWrite-Devel mailing list
KWrite-Devel@kde.org
https://mail.kde.org/mailman/listinfo/kwrite-devel
[prev in list] [next in list] [prev in thread] [next in thread]