[prev in list] [next in list] [prev in thread] [next in thread]
List: kwrite-devel
Subject: Re: I don't like "Python plugins"
From: Shaheed Haque <srhaque () theiet ! org>
Date: 2013-05-08 20:43:29
Message-ID: CAHAc2jf9cnqtxiF=nngCC3j3t9-VFOJnKSSHmJcfubwNVHSHTA () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
..and I forgot to say, if we are not already in string freeze, or after we
come out, I'm happy with both of Pablo's original suggestions.
On 8 May 2013 21:27, Shaheed Haque <srhaque@theiet.org> wrote:
> Pablo, thanks for starting this thread!
>
> First, I think I to agree with the notion that there should be one list
> *except* that we may wish to preserve some distinction between interpreted
> plugins that are - at least in principle - hackable/extensible in the field
> by the user and compiled C++. This is reflected in the Pate case by showing
> two branches in its tree (as per Philipp's mockup). I presume JS can or
> could follow a similar model.
>
> I also like the idea of demand-loading the host: if we moved the "list
> available plugins and choose them" logic into Kate as Domink suggests, I
> think we'd end up close to the separation Phillipp proposed of the Pate
> plugin ("Python developer support plugin") from the host functions.
>
> On Dominik's questions...
>
> 1. Whatever is exposed by the Kate sip file. Plus or minus the thread
> elsewhere looking into how the sip support is updated, the answer therefore
> tends to 100%. The one exception that I am aware of if per-session
> figuration save/load, which has been discussed recently (I have an idea how
> to implement it, but not had time yet. If anybody is interested in having a
> go, I am happy to discuss the idea I have with them).
>
> 2. I cannot recall doing anything weird. The main host functions are
> in addons/kate/pate/src/kate:
>
> __init__.py: Kate-centric helpers. For example, providing so-called
> "decorators" to simplify adding a config page, or KDE generic (like hooking
> up a menu action, or saving/loading non-session config), get singalled ona
> change of current document etc.
>
> gui.py: A few random-ish GUI helpers to do things like setup the
> "toolview" and a few similar things Ihave not even played with.
>
> In other words, the answer tends to 0.
>
> 3. I'll let others chip in. When a similar question was asked a while
> ago, I gave a vague answer about wanting some kind of coupling between the
> cursor (mouse and/or document cursor), the plugin and a sort of custom
> tooltip. The idea being that the plugin should have real-time access to the
> current word/text region and be able to display something near the cursor
> in response. The specific use case I had in mind was to float over a
> variable name, and have a debugger plugin display the value in a tooltip.
>
> And finally, if much of this depends on me, it will indeed take a little
> time...
>
>
> On 8 May 2013 21:17, totte <totte@tott.es> wrote:
>
>> On Wednesday 08 May 2013 21:28:07 Dominik Haumann wrote:
>> > On Wednesday, 8. May 2013 16:17:06 Joseph Wenninger wrote:
>> > > But why a tree, wouldn't it better to just merge the lists of the
>> > > providers? Why does a user care, if the plugin is written in C++,
>> Python,
>> > > JavaScript, ....?
>> >
>> > Right. It should just be an item in the list, no tree, please. It would
>> > expose information most of the users will never understand, for nothing.
>> >
>> > > I think, it would be even better if the list could show the python
>> > > plugins,
>> > > even if PATE is not loaded and load pate on demand. python plugins +
>> > > desktopfiles and automatic dependency resolution
>> >
>> > Yes, the correct solution is that all python plugins provide a .desktop
>> > file. The contents then would basically look like:
>> >
>> > [Desktop Entry]
>> > Type=Service
>> > ServiceTypes=Kate/PythonPlugin
>> > X-KDE-Library=python-plugin-folder or so...
>> > X-Kate-Version=3.0
>> > Name=Plugin name
>> > Comment=Plugin description
>> >
>> > The Kate plugin manager would then query for both, "Kate/Plugin"
>> > ServiceTypes and "Kate/PythonPlugin". As soon as such a plugin is
>> loaded,
>> > Kate
>> > automatically loads the Pate-host, and then forwards the call to the
>> Python-
>> > Plugin to load the correspronding plugin.
>> >
>> >
>> > For this to happen and accept in Kate, I'd like to have a rather tight
>> > review of what the PythonPlugin with respect to the following items:
>> >
>> > 1. Which API does the PythonPlugin provide? All of interfaces/kate/* ?
>> > My requirement would be: 100% of this interfaces should be
>> implemented.
>> >
>> > 2. What additional features does the PythonPlugin give in addition to
>> the
>> > interfaces in interfaces/kate/* ?
>> > My requirement: Keep it as low as possible, preferrably close to 0
>> > addons. Why? Because IF you need addons, these are most likely also
>> usable
>> > for C++ plugins. And in that case, it should be properly exposed and
>> > implemented in interfaces/kate/*
>> >
>> > 3. What is missing or nice to have in interfaces/kate/?
>> > Any interfaces you need and miss?
>> >
>> > Finally a remark: Currently, all Python plugin are completely hidden
>> behind
>> > the Pate-host plugin. And that is a tremendous advantage, since it
>> keeps all
>> > the rest of Kate untouched. This also means you are flexible to change
>> API,
>> > for instance. Once Python support gets more pulled into Kate itself,
>> > chaning this will be much harder in the long run.
>> >
>> > I'd prefer to have all the python plugins listed along with all the
>> other
>> > plugins. However, I'd rather prefer not to rush this, and if needed
>> only put
>> > this very late into KDE 4.11 (e.g. 4.11.8), or even KDE 5.
>> >
>> > Greetings,
>> >
>> > Dominik
>> >
>> > > Am 08.05.2013 um 15:30 schrieb "Philipp A." <flying-sheep@web.de>:
>> > > > i have a more radical idea: get rid of the separate Paté plugin
>> list.
>> > > >
>> > > > for the end user (as you said) it's not clear that Paté just enables
>> > > > another list of plugins, which makes those plugins unnecessarily
>> hidden.
>> > > > also i as end user wouldn't care where the plugins i enable come
>> from.
>> > > >
>> > > > ————
>> > > >
>> > > > i think we should
>> > > > 1. if it's not already done, make the plugin list extensible by
>> allowing
>> > > > adding more plugin providers>
>> > > >
>> > > > make the plugin list into a treeview (like the Paté plugin list
>> is)
>> > > > with each provider being a node, and it's plugins being a tree
>> below
>> > > > that.>
>> > > >
>> > > > 2. split Paté into such a plugin provider and a plugin that provides
>> > > > Paté's remaining functionality (the documentation tab and the
>> "reload
>> > > > modules" button for Paté plugin developers)
>> > > >
>> > > > ————
>> > > >
>> > > > mockup: http://i.imgur.com/amkeQS6.png
>> > > >
>> > > >
>> > > > 2013/5/8 J. Pablo Martín Cobos <goinnn@gmail.com>
>> > > > Hi all,
>> > > >
>> > > > I don't like the name of the "Python plugins"... With this name I
>> would
>> > > > think that these are plugins for Python, plugins with features to
>> > > > python.... but this is not true. There are features to python, js,
>> c++,
>> > > > xml, etc
>> > > >
>> > > > I think that we should change this name and the description, "Pâté
>> host
>> > > > for Python Plugins".
>> > > >
>> > > > I think that the name could be: "Python plugin engine", and the
>> > > > description, "If you enable this plugin you will have another list
>> of
>> > > > the
>> > > > plugins write in python".
>> > > >
>> > > > do you think about this??
>> > > >
>> > > > Best regards,
>> >
>> > _______________________________________________
>> > KWrite-Devel mailing list
>> > KWrite-Devel@kde.org
>> > https://mail.kde.org/mailman/listinfo/kwrite-devel
>>
>> I still wish for a more official (or so to speak) Python API for Kate, as
>> already somewhat indirectly stated in this bug report:
>> https://bugs.kde.org/show_bug.cgi?id=312169. It's really a mess of an
>> interface for a normal user who has little to no understanding of Kate's
>> internals.
>> _______________________________________________
>> KWrite-Devel mailing list
>> KWrite-Devel@kde.org
>> https://mail.kde.org/mailman/listinfo/kwrite-devel
>>
>
>
[Attachment #5 (text/html)]
<div dir="ltr">..and I forgot to say, if we are not already in string freeze, or \
after we come out, I'm happy with both of Pablo's original \
suggestions.</div><div class="gmail_extra"><br><br><div class="gmail_quote"> On 8 May \
2013 21:27, Shaheed Haque <span dir="ltr"><<a href="mailto:srhaque@theiet.org" \
target="_blank">srhaque@theiet.org</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> <div dir="ltr"><div>Pablo, thanks for starting this \
thread!</div><div><br></div>First, I think I to agree with the notion that there \
should be one list *except* that we may wish to preserve some distinction between \
interpreted plugins that are - at least in principle - hackable/extensible in the \
field by the user and compiled C++. This is reflected in the Pate case by showing two \
branches in its tree (as per Philipp's mockup). I presume JS can or could follow \
a similar model.<div>
<div><br></div><div>I also like the idea of demand-loading the host: if we moved the \
"list available plugins and choose them" logic into Kate as Domink \
suggests, I think we'd end up close to the separation Phillipp proposed of the \
Pate plugin ("Python developer support plugin") from the host \
functions.</div>
<div><br></div><div>On Dominik's questions...</div><div><br></div><div>1. \
Whatever is exposed by the Kate sip file. Plus or minus the thread elsewhere looking \
into how the sip support is updated, the answer therefore tends to 100%. The one \
exception that I am aware of if per-session figuration save/load, which has been \
discussed recently (I have an idea how to implement it, but not had time yet. If \
anybody is interested in having a go, I am happy to discuss the idea I have with \
them).</div>
<div><br></div><div>2. I cannot recall doing anything weird. The main host functions \
are in addons/kate/pate/src/kate:</div><div><br></div><div>__init__.py: Kate-centric \
helpers. For example, providing so-called "decorators" to simplify adding a \
config page, or KDE generic (like hooking up a menu action, or saving/loading \
non-session config), get singalled ona change of current document etc.</div>
<div><br></div><div>gui.py: A few random-ish GUI helpers to do things like setup the \
"toolview" and a few similar things Ihave not even played \
with.</div><div><br></div><div>In other words, the answer tends to 0.</div>
<div><br></div><div>3. I'll let others chip in. When a similar question was \
asked a while ago, I gave a vague answer about wanting some kind of coupling between \
the cursor (mouse and/or document cursor), the plugin and a sort of custom tooltip. \
The idea being that the plugin should have real-time access to the current word/text \
region and be able to display something near the cursor in response. The specific use \
case I had in mind was to float over a variable name, and have a debugger plugin \
display the value in a tooltip.</div>
</div><div><br></div><div>And finally, if much of this depends on me, it will indeed \
take a little time...</div></div><div class="HOEnZb"><div class="h5"><div \
class="gmail_extra"><br><br><div class="gmail_quote">On 8 May 2013 21:17, totte <span \
dir="ltr"><<a href="mailto:totte@tott.es" \
target="_blank">totte@tott.es</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div><div>On Wednesday 08 May 2013 21:28:07 Dominik Haumann \
wrote:<br> > On Wednesday, 8. May 2013 16:17:06 Joseph Wenninger wrote:<br>
> > But why a tree, wouldn't it better to just merge the lists of the<br>
> > providers? Why does a user care, if the plugin is written in C++, \
Python,<br> > > JavaScript, ....?<br>
><br>
> Right. It should just be an item in the list, no tree, please. It would<br>
> expose information most of the users will never understand, for nothing.<br>
><br>
> > I think, it would be even better if the list could show the python<br>
> > plugins,<br>
> > even if PATE is not loaded and load pate on demand. python plugins +<br>
> > desktopfiles and automatic dependency resolution<br>
><br>
> Yes, the correct solution is that all python plugins provide a .desktop<br>
> file. The contents then would basically look like:<br>
><br>
> [Desktop Entry]<br>
> Type=Service<br>
> ServiceTypes=Kate/PythonPlugin<br>
> X-KDE-Library=python-plugin-folder or so...<br>
> X-Kate-Version=3.0<br>
> Name=Plugin name<br>
> Comment=Plugin description<br>
><br>
> The Kate plugin manager would then query for both, "Kate/Plugin"<br>
> ServiceTypes and "Kate/PythonPlugin". As soon as such a plugin is \
loaded,<br> > Kate<br>
> automatically loads the Pate-host, and then forwards the call to the Python-<br>
> Plugin to load the correspronding plugin.<br>
><br>
><br>
> For this to happen and accept in Kate, I'd like to have a rather tight<br>
> review of what the PythonPlugin with respect to the following items:<br>
><br>
> 1. Which API does the PythonPlugin provide? All of interfaces/kate/* ?<br>
> My requirement would be: 100% of this interfaces should be implemented.<br>
><br>
> 2. What additional features does the PythonPlugin give in addition to the<br>
> interfaces in interfaces/kate/* ?<br>
> My requirement: Keep it as low as possible, preferrably close to 0<br>
> addons. Why? Because IF you need addons, these are most likely also usable<br>
> for C++ plugins. And in that case, it should be properly exposed and<br>
> implemented in interfaces/kate/*<br>
><br>
> 3. What is missing or nice to have in interfaces/kate/?<br>
> Any interfaces you need and miss?<br>
><br>
> Finally a remark: Currently, all Python plugin are completely hidden behind<br>
> the Pate-host plugin. And that is a tremendous advantage, since it keeps all<br>
> the rest of Kate untouched. This also means you are flexible to change API,<br>
> for instance. Once Python support gets more pulled into Kate itself,<br>
> chaning this will be much harder in the long run.<br>
><br>
> I'd prefer to have all the python plugins listed along with all the \
other<br> > plugins. However, I'd rather prefer not to rush this, and if \
needed only put<br> > this very late into KDE 4.11 (e.g. 4.11.8), or even KDE \
5.<br> ><br>
> Greetings,<br>
><br>
> Dominik<br>
><br>
> > Am 08.05.2013 um 15:30 schrieb "Philipp A." <<a \
href="mailto:flying-sheep@web.de" target="_blank">flying-sheep@web.de</a>>:<br> \
> > > i have a more radical idea: get rid of the separate Paté plugin \
list.<br> > > ><br>
> > > for the end user (as you said) it's not clear that Paté just \
enables<br> > > > another list of plugins, which makes those plugins \
unnecessarily hidden.<br> > > > also i as end user wouldn't care where the \
plugins i enable come from.<br> > > ><br>
> > > ————<br>
> > ><br>
> > > i think we should<br>
> > > 1. if it's not already done, make the plugin list extensible by \
allowing<br> > > > adding more plugin providers><br>
> > ><br>
> > > make the plugin list into a treeview (like the Paté plugin list \
is)<br> > > > with each provider being a node, and it's plugins being a \
tree below<br> > > > that.><br>
> > ><br>
> > > 2. split Paté into such a plugin provider and a plugin that \
provides<br> > > > Paté's remaining functionality (the documentation tab \
and the "reload<br> > > > modules" button for Paté plugin developers)<br>
> > ><br>
> > > ————<br>
> > ><br>
> > > mockup: <a href="http://i.imgur.com/amkeQS6.png" \
target="_blank">http://i.imgur.com/amkeQS6.png</a><br> > > ><br>
> > ><br>
> > > 2013/5/8 J. Pablo Martín Cobos <<a href="mailto:goinnn@gmail.com" \
target="_blank">goinnn@gmail.com</a>><br> > > > Hi all,<br>
> > ><br>
> > > I don't like the name of the "Python plugins"... With \
this name I would<br> > > > think that these are plugins for Python, plugins \
with features to<br> > > > python.... but this is not true. There are \
features to python, js, c++,<br> > > > xml, etc<br>
> > ><br>
> > > I think that we should change this name and the description, \
"Pâté host<br> > > > for Python Plugins".<br>
> > ><br>
> > > I think that the name could be: "Python plugin engine", and \
the<br> > > > description, "If you enable this plugin you will have \
another list of<br> > > > the<br>
> > > plugins write in python".<br>
> > ><br>
> > > do you think about this??<br>
> > ><br>
> > > Best regards,<br>
><br>
> _______________________________________________<br>
> KWrite-Devel mailing list<br>
> <a href="mailto:KWrite-Devel@kde.org" \
target="_blank">KWrite-Devel@kde.org</a><br> > <a \
href="https://mail.kde.org/mailman/listinfo/kwrite-devel" \
target="_blank">https://mail.kde.org/mailman/listinfo/kwrite-devel</a><br> <br>
</div></div>I still wish for a more official (or so to speak) Python API for Kate, \
as<br> already somewhat indirectly stated in this bug report:<br>
<a href="https://bugs.kde.org/show_bug.cgi?id=312169" \
target="_blank">https://bugs.kde.org/show_bug.cgi?id=312169</a>. It's really a \
mess of an<br> interface for a normal user who has little to no understanding of \
Kate's<br> internals.<br>
<div><div>_______________________________________________<br>
KWrite-Devel mailing list<br>
<a href="mailto:KWrite-Devel@kde.org" target="_blank">KWrite-Devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/kwrite-devel" \
target="_blank">https://mail.kde.org/mailman/listinfo/kwrite-devel</a><br> \
</div></div></blockquote></div><br></div> </div></div></blockquote></div><br></div>
_______________________________________________
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]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic