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

Thomas Friedrichsmeier thomas.friedrichsmeier at ruhr-uni-bochum.de
Sat Jan 18 20:57:23 GMT 2020


Hi,

On Thu, 16 Jan 2020 20:29:48 +0100
Christoph Cullmann <christoph at cullmann.io> wrote:
> On 2020-01-16 10:36, Thomas Friedrichsmeier wrote:
[...]
> > 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.

... but you don't sound quite convinced, either. To clarify, this
suggestion is not something that will enable me to do anything new in
RKWard. It's an idea to make the interface cleaner. If it doesn't
achieve that - and you have much more expertise in judging that - then
it's no use. So don't be shy to give it a no-go, just because I seem
fond of the idea ;-)

Either way, one thing that I would really like to see, is bringing
(most of) the functionality in KatePluginManager into KTextEditor,
somehow. With my suggestion, I think the obvious place for that would
be KTextEditor::ApplicationImpl (or whatever it would be called).
Without my suggestion, where should it go?

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/20200118/d7a150cc/attachment.sig>


More information about the KWrite-Devel mailing list