[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:27:28
Message-ID: CAHAc2jf8rnPB-D0mBe=tLALT=rrkpcjsCFHB6LOV_xr0hCTS1w () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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"><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="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 class="HOEnZb"><div class="h5">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">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">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">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 class="HOEnZb"><div \
class="h5">_______________________________________________<br> KWrite-Devel mailing \
list<br> <a href="mailto:KWrite-Devel@kde.org">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>
_______________________________________________
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