'Re: Implementing KTextEditor interfaces in KDevelop'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kwrite-devel
Subject:    Re: Implementing KTextEditor interfaces in KDevelop
From:       Joseph Wenninger <jowenn () kde ! org>
Date:       2014-09-15 17:40:19
Message-ID: 52DF1A01-B5A2-4358-AA42-F85B3EAE6AD4 () kde ! org
[Download RAW message or body]

The API was created at a time when reparenting was costly and caused flickering and troubles (KMDI/KDockwidget times)

> Am 15.09.2014 um 18:54 schrieb Milian Wolff <mail@milianw.de>:
> 
>> 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@milianw.de
> http://milianw.de
> _______________________________________________
> KWrite-Devel mailing list
> KWrite-Devel@kde.org
> https://mail.kde.org/mailman/listinfo/kwrite-devel
_______________________________________________
KWrite-Devel mailing list
KWrite-Devel@kde.org
https://mail.kde.org/mailman/listinfo/kwrite-devel
[prev in list] [next in list] [prev in thread] [next in thread] 