[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kwrite-devel
Subject:    Re: I don't like "Python plugins"
From:       Dominik Haumann <dhaumann () kde ! org>
Date:       2013-06-12 18:58:42
Message-ID: 8522070.ohahgP3PZF () eriador
[Download RAW message or body]

Hi

On Tuesday, 11. June 2013 20:51:58 Shaheed Haque 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.

In my opinion, this is still the way to go: It's standardized across desktop
environments and therefore future proof, and extensible enough for us.

> 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.

Does maybe KStandardDirs help here to find these folders?
http://api.kde.org/4.10-api/kdelibs-apidocs/kdecore/html/classKStandardDirs.html

It says in this thread:
> $HOME/.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         <<< distro default installation

> then Pate will (a) load the user's version but also (b) show the user than
> the other two versions exist, but have been overridden. The idea being that
> user's get the notion that s/he can simply copy a system plugin to a
> directory under $HOME and hack it.

Interestingly, this is also how it works in KDE. Kate uses KStandardDirs to
for instance locate javascript files. The .js files are searched in the home
folder .kde4/share/apps/katepart/scripts/ as well as in the global folder
/usr/share/kde4/apps/katepart/syntax/
For KDE 5, the first one in the home folder may even be changed in favor of
$HOME/.local/...

That said, Kate here also uses the user's script (e.g. indenter) over the
system wide one. So far, this was not a problem.

I'm still not 100% convinced that having the detailed information about the
place of the plugin does much good to the user. I may be wrong, though - and
who codes decides after all. So you can implement it as you wish and we'll
try this.

> I would like to get this "in" for 4.12. 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?

Christoph usually has simple and effective solutions here. You just need to
get him think about it. This might be the hard part :^)

Greetings,
Dominik

> 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

[prev in list] [next in list] [prev in thread] [next in thread]