Implementing KTextEditor interfaces in KDevelop

[Milian Wolff]

On Monday 15 September 2014 18:25:06 Dominik Haumann wrote:
> 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".

OK, the only thing that I find odd then is this:

QWidget* toolview = mw->createToolView(...);
// now I want to add custom widgets here, what should I do?

currently, you create new widgets and pass in the toolview as parent. I've 
also seen the very ugly 

toolView->layout()->addItem(layout);

(see kateprojectpluginview.cpp)

This will always mean that the host app must create a dummy widget with a 
dummy layout and pass that to the plugin. Generally, I think "createToolView" 
is misnamed. It should be addToolView and take a QWidget that a plugin wants 
to show in a toolview as a paramter.

> > 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.

Ah, right. The apidox even say that. Sorry for the confusion here.

> > c) Too bad we notice this now, after Akademy...
> 
> I don't see an issue so far ;)

Let's hope it stays this way :)
-- 
Milian Wolff
mail at milianw.de
http://milianw.de