Implementing KTextEditor plugins
Dominik Haumann
dhaumann at kde.org
Sun Jul 26 07:47:32 UTC 2015
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.
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.
Cheers,
Dominik
More information about the KDevelop-devel
mailing list