[prev in list] [next in list] [prev in thread] [next in thread]
List: kwrite-devel
Subject: Re: I don't like "Python plugins"
From: Aleix Pol <aleixpol () kde ! org>
Date: 2013-06-13 1:33:40
Message-ID: CACcA1RpkC2n+h3hx733xSrXYXBN6hUk8__FzpYeVN81AJVdctA () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Wed, Jun 12, 2013 at 8:40 PM, Dominik Haumann <dhaumann@kde.org> wrote:
> On Tuesday, 11. June 2013 20:59:44 Shaheed Haque wrote:
> > Arrgggllll: Of course I meant 4.12, not 4.11
>
> Strictly speaking, there is no KDE 4.12:
>
> http://aseigo.blogspot.de/2013/05/plasma-workspaces-411-long-term-release.html
>
> It's not yet clear what this means for Kate Part. Maybe it's simply taken
> from
> the 4.11 branch in the kate git repository for the next years (once it's
> tagged).
>
> For the Kate application this might not be that influencing, since the
> freeze
> mostly holds for the desktop + libraries. So I can think of a new
> applications
> release, but it's still going to be KDE SC 4.11.
>
> I think this will also be discussed in Bilbao at the KDE conference next
> months. Still, for now we even have quite a tough freeze until 4.11 is
> branched in git.
>
> So the future development cycle is a bit unclear.
>
> Greetings,
> Dominik
>
> > On 11 June 2013 20:51, Shaheed Haque <srhaque@theiet.org> wrote:
> > > A bunch of interesting things have been brought up on this thread, but
> it
> > > seems to me that one key issue is the plugin name/description
> translation
> > > problem as that is currently just plain broken. I suggest we start
> there
> > > as
> > > follows:
> > >
> > > 1. Adopt the idea of using a .desktop file to facilitate the
> translation.
> > > So each Pate plugin get's a .desktop file.
> > >
> > > 2. We cannot use KTrader to find the plugins because it simply does not
> > > support the functionality I think we agree is needed (
> > > http://lists.kde.org/?l=kwrite-devel&m=136986686616467&w=2). However,
> by
> > > using KService in combination with the current "search path" logic, I
> > > think
> > > we can get what we need from the .desktop file.
> > >
> > > I would like to get this "in" for 4.11. Now, this won't address the
> ideas
> > > about how the plugins are presented in the UI or demand loading Pate
> > > itself; and I'm not sure I have a definite proposal in mind for either
> of
> > > those yet. Comments?
> > >
> > > On 16 May 2013 11:41, Philipp A. <flying-sheep@web.de> wrote:
> > >> 2013/5/8 Dominik Haumann <dhaumann@kde.org>
> > >>
> > >>> 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.
> > >>
> > >> There is one important information for me as plugin developer, i.e.
> where
> > >> the plugins come from.
> > >>
> > >> Paté plugins can load from multiple directories and i'd like to see
> where
> > >> from.
> > >>
> > >> But i think it's sufficient to make that an optional column in the
> list
> > >> view (source directory, default: off)
> > >>
> > >> 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.
> > >>
> > >> i'm very much in favor of this, too. maybe even a complete rework of
> the
> > >> libkatepate hierarchy (i don't have specific problems, but ATM it
> seems
> > >> to
> > >> grow rather organically ;))
> > >>
> > >> _______________________________________________
> > >> 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
>
I think that there can be a KDE 4.12 with releases in applications but
without the workspaces.
It's definitely something to be discussed!
Aleix
[Attachment #5 (text/html)]
<div dir="ltr">On Wed, Jun 12, 2013 at 8:40 PM, Dominik Haumann <span \
dir="ltr"><<a href="mailto:dhaumann@kde.org" \
target="_blank">dhaumann@kde.org</a>></span> wrote:<br><div \
class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div class="im">On Tuesday, 11. June 2013 20:59:44 Shaheed \
Haque wrote:<br> > Arrgggllll: Of course I meant 4.12, not 4.11<br>
<br>
</div>Strictly speaking, there is no KDE 4.12:<br>
<a href="http://aseigo.blogspot.de/2013/05/plasma-workspaces-411-long-term-release.html" \
target="_blank">http://aseigo.blogspot.de/2013/05/plasma-workspaces-411-long-term-release.html</a><br>
<br>
It's not yet clear what this means for Kate Part. Maybe it's simply taken \
from<br> the 4.11 branch in the kate git repository for the next years (once \
it's<br> tagged).<br>
<br>
For the Kate application this might not be that influencing, since the freeze<br>
mostly holds for the desktop + libraries. So I can think of a new applications<br>
release, but it's still going to be KDE SC 4.11.<br>
<br>
I think this will also be discussed in Bilbao at the KDE conference next<br>
months. Still, for now we even have quite a tough freeze until 4.11 is<br>
branched in git.<br>
<br>
So the future development cycle is a bit unclear.<br>
<br>
Greetings,<br>
Dominik<br>
<div class="HOEnZb"><div class="h5"><br>
> On 11 June 2013 20:51, Shaheed Haque <<a \
href="mailto:srhaque@theiet.org">srhaque@theiet.org</a>> wrote:<br> > > A \
bunch of interesting things have been brought up on this thread, but it<br> > > \
seems to me that one key issue is the plugin name/description translation<br> > \
> problem as that is currently just plain broken. I suggest we start there<br> \
> > as<br> > > follows:<br>
> ><br>
> > 1. Adopt the idea of using a .desktop file to facilitate the \
translation.<br> > > So each Pate plugin get's a .desktop file.<br>
> ><br>
> > 2. We cannot use KTrader to find the plugins because it simply does not<br>
> > support the functionality I think we agree is needed (<br>
> > <a href="http://lists.kde.org/?l=kwrite-devel&m=136986686616467&w=2" \
target="_blank">http://lists.kde.org/?l=kwrite-devel&m=136986686616467&w=2</a>). \
However, by<br> > > using KService in combination with the current "search \
path" logic, I<br> > > think<br>
> > we can get what we need from the .desktop file.<br>
> ><br>
> > I would like to get this "in" for 4.11. Now, this won't \
address the ideas<br> > > about how the plugins are presented in the UI or \
demand loading Pate<br> > > itself; and I'm not sure I have a definite \
proposal in mind for either of<br> > > those yet. Comments?<br>
> ><br>
> > On 16 May 2013 11:41, Philipp A. <<a \
href="mailto:flying-sheep@web.de">flying-sheep@web.de</a>> wrote:<br> > \
>> 2013/5/8 Dominik Haumann <<a \
href="mailto:dhaumann@kde.org">dhaumann@kde.org</a>><br> > >><br>
> >>> Right. It should just be an item in the list, no tree, please. It \
would<br> > >>> expose<br>
> >>> information most of the users will never understand, for \
nothing.<br> > >><br>
> >> There is one important information for me as plugin developer, i.e. \
where<br> > >> the plugins come from.<br>
> >><br>
> >> Paté plugins can load from multiple directories and i'd like to see \
where<br> > >> from.<br>
> >><br>
> >> But i think it's sufficient to make that an optional column in the \
list<br> > >> view (source directory, default: off)<br>
> >><br>
> >> Finally a remark: Currently, all Python plugin are completely \
hidden<br> > >><br>
> >>> behind<br>
> >>> the Pate-host plugin. And that is a tremendous advantage, since it \
keeps<br> > >>> all<br>
> >>> the rest of Kate untouched. This also means you are flexible to \
change<br> > >>> API,<br>
> >>> for instance. Once Python support gets more pulled into Kate \
itself,<br> > >>> chaning<br>
> >>> 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<br> > >>> other<br>
> >>> plugins. However, I'd rather prefer not to rush this, and if \
needed only<br> > >>> put<br>
> >>> this very late into KDE 4.11 (e.g. 4.11.8), or even KDE 5.<br>
> >><br>
> >> i'm very much in favor of this, too. maybe even a complete rework of \
the<br> > >> libkatepate hierarchy (i don't have specific problems, but ATM \
it seems<br> > >> to<br>
> >> grow rather organically ;))<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> 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></div></div></blockquote><div><br></div><div \
style>I think that there can be a KDE 4.12 with releases in applications but without \
the workspaces.</div>
<div style><br></div><div style>It's definitely something to be \
discussed!</div><div style><br></div><div style>Aleix </div></div></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