Create Task
Maniphest T6869

Create ktexteditor-addons repo
Closed, WontfixPublic
Actions

Description

Picking up the ml thread "Moving KTextEditor plugins out of kate.git?" from Aug 25, 2015 and the additional interest with the new preview plugin from this August 2017:

Seems people commenting so far agree collecting plugins for ktexteditor in a separate repo makes sense.

Open questions:

  • name of repo?
  • release group of repo?
  • content of repo?
  • layout of repo?

Name: "ktexteditor-addons" has been proposed, would follow naming pattern (e.g. "kdeplasma-addons", "kdepim-addons").

Release group: "KDE Frameworks" does not match, this is about plugins. Being part of "KDE Applications" would mean semi-automatic release & packaging handling. Own release schedule possible, but needs someone to care.

Content: At most this could be all plugins which implement KTextEditor::Plugin. Many existing plugins though are specific to Kate's idea of UI/UX options, like the tabswitcher or filemanager and just happen to reuse the plugin API for simplified code, but are not specific to text documents.
And goal of this repositpry so far has been to help with packaging. Like to enforce/guide distributions to create a separate package with only those plugins which are also interesting for none-Kate apps, to avoid deps on the fiull Kate package. And to ease binary bundle creation e.g. of KDevelop appimages/windows installer/macOS installers, which no longer would need to build all of Kate or maintain patches to just build interesting stuff. Or when building manually with kdesrc-build a non-Kate ktexteditor-based application.
The two plugins mentioned for use outside Kate are: snippets and preview. So the repo could start with these two and get other plugins added if there is demand/interest?

Layout: Right now in the kate repo all plugins are straight below "/addons", with own subdir per plugin. Could perhaps be "/src" or "/plugins" in the new repo, and again own subdir per plugin.

Please everyone give a comment with your replies to each open question.

cullmann added a subscriber: cullmann.Aug 26 2017, 9:14 AM

I would have no problem to move out "all" plugins to some ktexteditor-addons repo.

But we must then ensure that Kate build hard depends on that to be installed that you not end up with a Kate with close to all functionality missing by default ;=)

kossebau added a comment.Aug 28 2017, 2:01 PM

Thanks for reply @cullmann :)

In T6869#107926, @cullmann wrote:

I would have no problem to move out "all" plugins to some ktexteditor-addons repo.

What would be your motivation for this? In other words, what use-cases would that solve for you?

Use-cases which I need to see covered:

  • as none-Kate developer working on KTE plugins shared between Kate, KDevelop and others I would prefer to not have to deal with complete Kate repo
  • distribution packagers fail to split out shared plugin(s) (well, the snippets one right now) into separate package from kate build, resulting in dep of KDevelop on complete kate package and its deps again.
  • binary bundle building of kdevelop needs to build all of Kate to get snippets plugin (or would need to maintain a patch to limit build to just the snippets plugin subfolder)

And putting all of KTE plugins into a separate repo does not really improve things for those use-cases,

But we must then ensure that Kate build hard depends on that to be installed that you not end up with a Kate with close to all functionality missing by default ;=)

Yes, things must be properly communicated to packagers/bundle creators in any case, so they do not screw up.

cullmann added a comment.Aug 28 2017, 2:08 PM

What would be your motivation for this? In other words, what use-cases would that solve for you?

I actually are not sure how to group them, e.g. if you want a text document switcher, you might want to use the plugin for your simple app.
KDevelop for sure not wants it.

Same for e.g. find in files. Most apps don't want that I assume, if the embed just a KTextEditor document/view.

Therefore I don't see really a nice distinction to rule: which plugin in kate git and which in ktexteditor-addons git beside "just all".

But yes, that will not really shrink the deps, as the most deps stem from the plugins.

dhaumann added a subscriber: dhaumann.EditedAug 29 2017, 6:58 AM

I am an in favor of an all-or-nothing approach.

Possible layout:

plugin1/src/*.h,cpp
plugin1/data/*
plugin1/autotest/*
plugin2/src/*.h,cpp
plugin2/data/*
plugin2/autotest/*

This way, each plugin would be self-contained. Of course, this is not a typical Frameworks layout.

And yes: Kate and KDevelop both need a hard dependency on ktexteditor-addons.
We can add it to the applications release for now, and move it to a framework later (if the layout is OK).

Other suggestions?

PS: The tab-switcher plugin is one of the examples that *is* definitely interesting for KDevelop and Kile, since its source code originates from KDevelop's tab-switcher... So sharing more is certainly an objective here, but we never came around so far to implement this such that KDevelop can use this as well (it has more views that just KTextEditor::Views).

brauch added a subscriber: brauch.Sep 5 2017, 7:36 PM

Releasing with applications makes sense to me, I feel like it should be released in sync with kate.
If there is a hard dependency anyways then I agree with Dominik that we should move all plugins over. All of them are possibly useful for an embedding application, and with moving just some I see us moving plugins back and forth all the time for no real reason.

Having each plugin in a self-contained folder, as suggested, neverthereless seems sensible to me to ease future maintenance.

Thanks a lot for caring!

cullmann closed this task as Wontfix.Sep 10 2019, 12:57 PM
cullmann claimed this task.

Given the big KDevelop & Kate share plugins stuff never took off, I think we shall keep them just in kate.git, this will allow to do even more "experimental" stuff in the future like having some extra interfaces for Kate specific stuff that doesn't need to keep BC.