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 frank@frank.uvena.de 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