[prev in list] [next in list] [prev in thread] [next in thread]
List: kwrite-devel
Subject: Re: I don't like "Python plugins"
From: J._Pablo_Martín_Cobos <goinnn () gmail ! com>
Date: 2013-05-09 6:53:19
Message-ID: CALNyWLExWDsHci+hwQHhPi5YMAFDeC2Ox_cVJDQ7S_KPodR6fQ () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
2013/5/8 Shaheed Haque <srhaque@theiet.org>
> Pablo, thanks for starting this thread!
>
>
You are welcome Shaheed.
Before to send the email, I thought in a solution like Philipp, Joseph or
Dominik said... but I thought in this was a lot of work. A solution without
tree, and without any difference. Shaheed sometimes if you lose some
features the end-user win in usability. And I think that this is the case.
I only wanted open a discussion, because I don't like the current
solution. I thought a lot about this. And I thought that would be better a
little proposal, and after to read your answers
I understand that pate is a plugin, in fact I think that this is a
brainwave, a plugin to do plugins... This is very nice. I undersand it
because this was a project outside kate project, but now pate is integrated
with kate project. Now should only be "Plugins", nothing of Pate, nothing
of Python Plugin, etc etc
If you need help, python help xD, tell me.
> 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
>>
>
>
> _______________________________________________
> KWrite-Devel mailing list
> KWrite-Devel@kde.org
> https://mail.kde.org/mailman/listinfo/kwrite-devel
>
>
[Attachment #5 (text/html)]
<div dir="ltr">2013/5/8 Shaheed Haque <span dir="ltr"><<a \
href="mailto:srhaque@theiet.org" \
target="_blank">srhaque@theiet.org</a>></span><br><div class="gmail_extra"><div \
class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div>Pablo, thanks for starting this \
thread!</div><div><br></div></div></blockquote><div><br></div><div style>You are \
welcome Shaheed. </div><div style><br></div><div style>Before to send the email, I \
thought in a solution like <span \
style="font-family:arial,sans-serif;font-size:13px">Philipp, Joseph or Dominik \
said... but I </span>thought in this was a lot of work. A solution without tree, and \
without any difference. Shaheed sometimes if you lose some features the end-user win \
in usability. And I think that this is the case.</div> <div style><br></div><div \
style>I only wanted open a discussion, because I don't like the current solution. \
I thought a lot about this. And I thought that would be better a little proposal, and \
after to read your answers</div> <div style><br></div><div style>I understand that \
pate is a plugin, in fact I think that this is a brainwave, a plugin to do plugins... \
This is very nice. I undersand it because this was a project outside kate project, \
but now pate is integrated with kate project. Now should only be "Plugins", \
nothing of Pate, nothing of Python Plugin, etc etc</div> <div style><br></div><div \
style>If you need help, python help xD, tell me.<br><table cellpadding="0" class="" \
style="font-size:13px;font-family:arial,sans-serif"><tbody><tr class=""><td class="" \
style="width:578px"><table cellpadding="0" class="" style="width:578px"> \
<tbody><tr><td><div class=""><br></div></td></tr></tbody></table></td></tr></tbody></table></div><div> \
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div></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=""><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:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style: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><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></blockquote></div><br></div></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