Have been thinking about it for a bit.
Frank, I believe you are on the right track in considering that G-P
should be for users which brings some implications like reliability,
especially *thou shalt not crash Geany*, and some level of
documentation, and a good set of useful features.
But thinking further about the last, to get a good selection of
plugins G-P needs to support developers as well. It needs to provide
a process that makes it easy for developers to add plugins and support
for making useful documentation and to continue to develop the
plugins.
So how to provide these? The rest of this post is one suggestion for
how to implement it, but there are other possibilities, but whatever
method is used, but should not lose sight of the principles above.
I don't think the current monolithic arrangement is suitable for
providing the way forward.
@b4n has in the past ruled out a download based system for plugins,
but perhaps its time to consider it further. G-P could provide the
infrastructure to fetch the plugins when the user requests them, using
a repository/package list that packagers can set for their distro, or
from git(hub) for those plugins that don't need building (the future
Python etc plugins) and for those with development environments it
could get and build C/C++ plugins.
It is particularly important that the system is suitable to support
no-build languages like Python, Autotools and m4 need not apply :).
Thats the way to make it easier to develop plugins so more effort can
go in the features and quality and less into low level hacking.
Because G-P would use a fixed list *reasonable* security features can
allay some of @b4n's fears. The list should be provided by distros
for the plugins that they package and in G-P git as a fallback
referring to the git repos of the approved plugins.
The big advantage of such a system is that it can allow individual
plugins to remain in their own repository rather than a central site,
and they can have their own issue tracking without developers having
to know about all the other plugins issues. G-P plugins would be
mirrored on the Geany github for fallback purposes and for running
quality control tests supporting translations etc. Having individual
plugins in their own repository makes it much simpler for their
developer to support them and will encourage more to be included so
they become part of distributed G-P (see the list of "external"
plugins on the G-P site).
There are many details to consider here, I don't think its a 1.27
target, but at least the process has started.
Cheers
Lex
On 28 November 2015 at 19:22, Frank Lanitz wrote:
> On 22.11.2015 13:52, Frank Lanitz wrote:
>> The more important question for me is what will it be in future?
>
> Any thought about this anybody?
>
> Cheers,
> Frank
>
>
> ___
> Devel mailing list
> Devel@lists.geany.org
> https://lists.geany.org/cgi-bin/mailman/listinfo/devel
>
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel
