Implementing KTextEditor interfaces in KDevelop

[Dominik Haumann]

On Monday 15 September 2014 18:14:52 Milian Wolff wrote:
> On Monday 15 September 2014 18:02:28 Sven Brauch wrote:
> > Hi!
> > 
> > I'm experimenting with implementing the KTextEditor interfaces in
> > KDevelop so we can load all the plugins. I have a proof of concept
> > which can load the snippets plugin and execute snippets in a view [1],
> > [2].
> > 
> > One thing which does not work very well is the toolview interface. The
> > KTE interface is designed so that the plugin can say "make me a
> > toolview and give me the widget so I can put my stuff in it". In
> > KDevelop (or rather, sublime), you can only register a toolview
> > factory (= factory for the widget) and sublime will instantiate the
> > widget when required. It's not clear how to connect those two
> > interfaces, since when creating a view, a KTE plugin immediately wants
> > a widget to populate, but sublime doesn't give you that.
> > 
> > In my proof of concept solution, I use a factory which has one fixed
> > widget for each toolview, but that feels very bad.
> 
> Some more input from my side. I think we are misunderstanding the API a bit,
> or maybe there are some issues.
> 
> a) I find it wrong that a plugin queries the mainwindow for a widget and
> embeds itself into it. Rather, I'd think it should work the other way
> around. The mainwindow asks the plugin for a widget and embeds that window
> as appropriate. I assumed this is actually how Plugin::createView should be
> used, but Sven said that this in turn calls MainWindow::createToolView.
> Indeed, e.g. KateSQLPlugin::createView looks harmless, but in the
> KateSQLView ctor it creates toolviews at hardcoded positions. What if the
> user moves the toolviews? See below...
> 
> Apparently a single plugin has multiple views in KTextEditor? The "main"
> view that is returned by Plugin::createView and "secondary" views created
> by KTE::MW::createToolView?

The KTextEditor plugins still support multiple MainWindows. 
Plugin::createView() should be called for each MainWindow exactly once.
Since in KDevelop you only have one main window, you call it only once.
No problem here.

Think of createView() as "hey loaded plugin, if you want to hook into the 
mainwindow (xml gui client, tool views), do this now".

> b) A plugin may have the notion of where to put itself by default, but it
> should not do so itself. This is how I understood the current API to work
> (very rough quick glance only). The user may move the toolview to a
> different position, and when the host app is restarted, it will recreate
> the gui and put the plugin into the right place. With the KTE interface,
> every plugin will need to do that themselves, no? Otherwise they will
> always create the toolview in the same place?

No, KDevelop needs to put the toolviews at a location depending on the 
identifier. Note, that
KTE::MainWindow::createToolView(KTextEditor::Plugin *plugin,
                                const QString &identifier,
                                KTextEditor::MainWindow::ToolViewPosition pos,
                                const QIcon &icon,
                                const QString &text)

takes a unique identifier as 2nd parameter. So when the plugin asks for 'pos', 
you look in KDevelop whether you already have a location for 'identifier', and 
if so, you ignore 'pos'. This way, you get session save&restore without 
flickering. So no, a plugin does not maintain itself where it is located, it 
just tells the host application a preference location.

> c) Too bad we notice this now, after Akademy...

I don't see an issue so far ;)

Greetings,
Dominik