[Geany-devel] Ideas on increasing quality of plugins
Matthew Brush
matthewbrush at xxxxx
Wed Feb 23 00:10:56 UTC 2011
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)
More information about the Devel
mailing list