Implementing KTextEditor plugins

Milian Wolff mail at milianw.de
Sun Jul 26 08:35:58 UTC 2015


On Sunday, July 26, 2015 09:47:32 AM Dominik Haumann wrote:
> Hi Milian / Andreas,
> 
> CC: kwrite-devel, kdevelop-devel
> 
> there are several plugins where it would definitely be nice to share
> them between Kate, Kile, KDevelop: Terminal, Documents (filetree),
> File System Browser, Tab document switcher, maybe Search & Replace.
> 
> However, since the KTextEditor plugins gained more power, they cannot
> be handled on KTextEditor level completely. That means: Applications
> like Kate, Kile, KDevelop need to implement some interfaces and magic
> to load these plugins.
> 
> In short, what we'll have to do is
> 1. create a KTextEditor plugin manager
> Since there is no plugin manager on KTextEditor level anymore, the
> host application needs to implement this. As starting point, you can
> have a look kate/src/katepluginmanager.h/cpp. This class collects all
> the KTextEditor plugins, it can load & unload plugins, and return a
> list of available plugins. Currently, the License is LGPLv2+, but we
> could probably extend this to GPLv2+, if required.

LGPLv2+ is better than GPLv2+, no? The former is compatible to the letter, not 
the other way around.

> 2. Special "relay" classes: KTextEditor::Application,
> KTextEditor::MainWindow KTextEditor::Application gives the KTextEditor
> plugins access to the currently activeMainWindow(), the number of
> mainWindows(), convenience functions like quit(), documents(),
> close/openDocument(), etc, just have a look.
> This class is QObject and takes a QObject in its constructor. For
> instance, KTextEditor::Application::quit() is doing this:
> bool Application::quit()
> {
>     if (!this) {
>         return false;
>     }
> 
>     // dispatch to parent
>     bool success = false;
>     QMetaObject::invokeMethod(parent()
>                               , "quit"
>                               , Qt::DirectConnection
>                               , Q_RETURN_ARG(bool, success));
> 
>     return success;
> }
> So what you have to do is to have a function quit() in *your*
> application (invocable through the QMetaObject system), which the
> KTextEditor::Application functions will try to call through the meta
> system. Think of a "runtime" dependency that is not checked at compile
> time. This is, how application functionality like quit() etc is made
> available in KTextEditor level.
> 
> The same applies to KTextEditor::MainWindow, just have a look at
> ktexteditor/src/include/ktexteditor/mainwindow.h, and for a reference
> implementation in kate/src/kate/katemainwindow.h/cpp.
> 
> In the Kate app, we usually call these relay object m_wrapper.
> 
> 3. Given you have the plugin manager now, and the wrapper classes, you
> the only thing missing is to show the plugins in some list in the
> settings. If you already have a plugin manager list view (KDevelop),
> you'll probably integrate it there somehow. In case of Kile, there is
> no such plugin system yet, so in this case, you can again copy Kate
> code that does this, see kateconfigpluginpage.h/cpp and
> kateconfigdialog.h/cpp.
> 
> That's about it. Would be cool, if we get support for KDevelop and
> Kile this week, and if required, we can extend / change the .desktop
> file spec a bit to fulfill Kile's and KDevelop's needs.

Yes, I'll try to start working on that, probably starting tomorrow. Thanks for 
the input and summary.

Bye
-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20150726/c5e2329f/attachment.sig>


More information about the KDevelop-devel mailing list