[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-10 21:21:07
Message-ID: CAHAc2jc7fop41-EzGpsxDx05g+7jvg3Rw78f6puEBGE8apy38Q () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Hah, on the KTrader question, I found the docs on techbase at
http://techbase.kde.org/Development/Tutorials/Services/Traders#The_KTrader_Query_Language.
Thoughts on the main question still welcome...
On 10 May 2013 21:14, Shaheed Haque <srhaque@theiet.org> wrote:
> Here is an idea that we could consider now (for 4.11) that might
> facilitate the kind of changes suggested in this thread at a later date.
> The search paths that Pate uses to find its plugins resolve on my system to:
>
> /home/$USER/.kde/share/apps/kate/pate <<< my in-development plugin versions
> /usr/local/share/apps/kate/pate <<< my locally installed
> plugins
> /usr/share/kde4/apps/kate/pate
>
> This corresponds to the search path used, i.e.
> KGlobal::dirs()->findDirs("appdata", "pate"), whereas native plugins (such
> as Pate itself) live in KStandardDirs::locate("appdata", "plugins"). Since
> the name "pate" is likely to be meaningless to users who might be
> interested in hacking on their own scripts, it might make more sense to
> either move all the plugins to either ("appdata", "plugins"), or
> possibly ("appdata", "plugins/python"). Thoughts?
>
> Also, I do we know how KTrader deals with search paths? If foo.desktop
> exists in each of the three paths listed above, I assume that the one
> nearest the user would override the others, is that right? And if it does,
> is there any way to enumerate the overridden ones? Or put another way, I've
> wondered for over 10 years if the query and constraint grammars for KTrader
> are documented somewhere other than the code...
>
>
> On 9 May 2013 07:53, J. Pablo Martín Cobos <goinnn@gmail.com> wrote:
>
>> 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
>>>
>>>
>>
>> _______________________________________________
>> KWrite-Devel mailing list
>> KWrite-Devel@kde.org
>> https://mail.kde.org/mailman/listinfo/kwrite-devel
>>
>>
>
[Attachment #5 (text/html)]
<div dir="ltr">Hah, on the KTrader question, I found the docs on techbase at <a \
href="http://techbase.kde.org/Development/Tutorials/Services/Traders#The_KTrader_Query \
_Language">http://techbase.kde.org/Development/Tutorials/Services/Traders#The_KTrader_Query_Language</a>. \
Thoughts on the main question still welcome...</div> <div \
class="gmail_extra"><br><br><div class="gmail_quote">On 10 May 2013 21:14, 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">Here is an idea that we could consider now \
(for 4.11) that might facilitate the kind of changes suggested in this thread at a \
later date. The search paths that Pate uses to find its plugins resolve on my system \
to:<div>
<br></div><div>/home/$USER/.kde/share/apps/kate/pate <<< my in-development \
plugin versions</div><div>/usr/local/share/apps/kate/pate \
<<< my locally installed plugins</div><div>
/usr/share/kde4/apps/kate/pate<br></div><div><br></div><div>This corresponds to the \
search path used, i.e. KGlobal::dirs()->findDirs("appdata", \
"pate"), whereas native plugins (such as Pate itself) live in \
KStandardDirs::locate("appdata", "plugins"). Since the name \
"pate" is likely to be meaningless to users who might be interested in \
hacking on their own scripts, it might make more sense to either move all the plugins \
to either ("appdata", "plugins"), or possibly \
("appdata", "plugins/python"). Thoughts?</div>
<div><br></div><div>Also, I do we know how KTrader deals with search paths? If \
foo.desktop exists in each of the three paths listed above, I assume that the one \
nearest the user would override the others, is that right? And if it does, is there \
any way to enumerate the overridden ones? Or put another way, I've wondered for \
over 10 years if the query and constraint grammars for KTrader are documented \
somewhere other than the code...</div>
</div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div \
class="gmail_quote">On 9 May 2013 07:53, J. Pablo Martín Cobos <span \
dir="ltr"><<a href="mailto:goinnn@gmail.com" \
target="_blank">goinnn@gmail.com</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">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"><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>Pablo, thanks for starting this \
thread!</div><div><br></div></div></blockquote><div><br></div></div><div>You are \
welcome Shaheed. </div><div><br></div><div>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><br></div><div>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><br></div><div>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><br></div><div>If you need help, python help xD, tell me.<br><table \
cellpadding="0" style="font-size:13px;font-family:arial,sans-serif"><tbody><tr><td \
style="width:578px"><table cellpadding="0" style="width:578px"> \
<tbody><tr><td><div><br></div></td></tr></tbody></table></td></tr></tbody></table></div><div><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><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: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" \
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></blockquote></div></div></div><br></div></div> \
<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></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