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

[Thomas Friedrichsmeier]

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...

[...]

> 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.

Regards
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://mail.kde.org/pipermail/kwrite-devel/attachments/20200116/701d0976/attachment.sig>