[Geany-devel] Ideas on increasing quality of plugins

[Matthew Brush]

Hi all,

For first thing, maybe we could enforce use/passing of those tools 
mentioned and these before adding to release, examples:
http://www.splint.org/
http://valgrind.org/info/tools.html
(suppression for GTK - http://people.gnome.org/~johan/gtk.suppression)
http://www.gnu.org/software/indent/ (just for making coding styles more 
consistent between plugins)
http://check.sourceforge.net/ or http://cutest.sourceforge.net/ or 
http://cunit.sourceforge.net/
Perhaps some or all of these could be automated.

Another thing could be to make mandatory that documentation is existent 
and current, up to some standard.  I mean for README, manual, and also 
doc-comments in code (ex. each function/global must have a comment or 
something).  Some other items where documentation could be enforced; new 
keybindings, preferences, menu/toolbar items, tabs.

In reference to using additional languages for plugins, I think this 
should be #1 priority for improving quality.  Think about it like this; 
who writes plugins?  Geany users/hackers.  What languages do they 
use/know?  Probably not C in a lot of cases (more likely Python, PHP, 
etc - of course I'm just guessing on this).  To make a PHP programmer 
write a plugin in C is asking for trouble (unless they know C also).  If 
you could use a scripting language like Python, it would basically 
totally eliminate crashing Geany.  I can't think of anything you could 
do in plain Python that would crash the interpreter all-together 
(thought it might be possible).

Of course this brings back the problem of the plugin API not being 
well-suited to use in other languages (no shared library to link to, no 
way to auto-generate the large bindings required, having to maintain 
backwards compatibility, etc).  I was the one working on GeanyPy to try 
to add Python bindings but I all but gave up due to the above issues.

I think a big step forward would be to add the Geany Vala bindings into 
the official code distribution (adding to autotools/waf to put the VAPI 
into the right system location).  Of course the Vala binding needs 
testing, but I can verify that it's very usable, having written some 
plugins with it.  It won't get much testing unless it's part of Geany 
and mentioned in the Plugin documentation so people know it exists.

In the sense of VCS, I think using a more "social" site than SourceForge 
for the plugins could be helpful (I'm thinking GitHub, Gitorious, etc).  
There could be a geany-plugins repository that is the official one 
containing releasable code.  There could be additional repositories each 
plugin author maintains against the official repository, where they make 
all their in-between release changes, and at release time, a pull 
request for each plugin could need to be sent to the official repository 
to bring in the releasable version.  The benefit of this is also that 
you could hack on a plugin by forking it and then send a pull request to 
the person who maintains the plugin's repository for them to review, 
without messing with their code directly.  (More info: 
http://help.github.com/pull-requests/)  I know at least for GitHub, 
there is provided very pretty graphs and user interface which shows all 
issues, fork queue, pull requests, and other work being performed on the 
same code across repositories.  This might be personal preference for 
workflow, because I'm not adept at using Subversion and I don't have 
access to make changes to the project at SourceForge, but it does seem 
to be the way the "cool kids are doing it" (ex. 
https://github.com/mirrors/linux-2.6).

Another slightly off topic thing that could be done is to make the 
plugins installable from within Geany where a releasable plugin hosted 
officially could be downloaded/updated by itself (kinda like Eclipse) 
without requiring all the stress of making a massive multi-plugin 
release for each Geany release.  This would also make less work for 
whoever has to keep the build-systems up to date with the plugins.  If 
the specific plugin author doesn't ensure their plugin builds properly, 
then people just won't be able to use that plugin.  Also plugins could 
be fixed without waiting for release time.

Ok, I have typed too long now, so I will stop here :)

Cheers,
Matthew Brush (codebrainz)