Notes / Observations while embedding KTextEditor::Plugin(s) into a new host application

[Christoph Cullmann]

Hi,

On 2020-01-16 10:36, Thomas Friedrichsmeier wrote:
> Hi,
> 
> On Wed, 15 Jan 2020 20:54:54 +0100
> Christoph Cullmann <christoph at cullmann.io> wrote:
>> > Hm, not sure that I get you right. For RKWard we're trying quite
>> > hard to support a wide range of our dependent libs, 'cause that's
>> > what our users have been asking for. They want the latest and
>> > greatest in R and RKWard, without touching anything else about
>> > their systems (as much as possible). So from our perspective,
>> > binary compatibility is a very good thing, indeed.
>> 
>> I see that point, but the you are stuck with some things like not
>> being able
>> to e.g. add virtual functions.
> 
> well, I haven't felt that pain, yet, so maybe I'm underestimating it.
> But put bluntly: Without binary stability, I guess we may end up
> copying the plugin, rather than actually using shared plugins. Because
> I have been to the land of "your package just broke on distributions
> a, b, and c, because a dependency had a BIC change, and a rebuild
> will be needed (while the distribution's package maintainer is MiA).
> Distributions d-z will follow over the course of the next two
> years". And *that* wasn't any fun, either...

yes, that is sub-optimal, I can agree with that.

> 
> [...]
> 
>> Perhaps I miss the point, but e.g. Kate would use
>> KTextEditor::MainWindowImpl or?
>> That means it must stay stable BC wise and you don't win a thing with
>> having it separated from
>> the KTextEditor::MainWindow.
>> 
>> You are right that the plugins will have no BC issue, but still the
>> integration
>> will not work as the other side of the interface has BC issues.
>> 
>> But perhaps I misunderstand that.
> 
> You are right, I have been overlooking part of the problem. Since kate
> may have been built against an earlier version of ktexteditor, that
> will mean no new virtuals in existing classes of ktexteditor, and my
> example was wrong in that respect.
> 
> However, there are still some advantages over the current approach:
> 1) *Existing* functions can be offered as virtuals in the "host-facing"
> MainWindowImpl in KF6, allowing for:
> 1a) having default implementations in the base-class, where possible.
> Perhaps e.g. for (read/write)SessionConfig, or findUrl().
> 1b) build-time sanity checks
> 1c) better performance (probably irrelevant)
> 2) This would also give a reasonable place where to provide shareable
> "host-facing" functionality such as (repeat):
>   - loading/unloading a plugin by id, all complete with bookkeeping, 
> and
>     signals
>   - keeping track of views / toolviews / other resources "owned" by a
>     plugin, and emitting the signals for that
> 
> *New* functions could still be added the same way as now: The
> "plugin-facing" MainWindow (tries to) call a slot in its
> "host-facing" parent. No change, here, other than that the parent
> happens to inherit from MainWindowImpl, rather than plain QObject.

I think I would have no issues with such an approach, that we just
have the "initial" stuff in KF6 via virtual functions and just extend
the interface with our "hack" if the need arises.

Greetings
Christoph

-- 
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org