[Geany-devel] Ideas on increasing quality of plugins

[Lex Trotman]

On 12 March 2011 11:35, Matthew Brush <matthewbrush at gmail.com> wrote:
> On 03/11/11 15:24, Frank Lanitz wrote:
>>
>> On Wed, 23 Feb 2011 15:28:05 +0300
>> Alexander Petukhov<Alexander.Petukhov at mail.ru>  wrote:
>>
>>> 5. Other language bindings - don't really think it can increase
>>> plugins quality dramatically, there can be problems in any language
>>> that you have to solve in order to make your code work correctly.
>>
>> I agree. It will might also split up resources on core side to support
>> maybe 5 API as even you do use some kind of automatically binding it
>> will not working out of the box in every case.
>>
> If the core API were more binding friendly, for example using standard
> GObject conventions, a HUGE portion of the work doing bindings would be
> completely automated for quite a number of languages, without any need to
> customize the core for them.  The things that don't work out of the box
> would be fixed in the binding itself as is common with other bindings of
> things.  This is the whole purpose of things like GObject introspection (to
> make GObject bindings automatic and natural to that language).
>
> As an example, the Vala bindings are being hacked to death to make them more
> like Vala-ish (make that GObject-ish), when this would be a basically fully
> automated process if the API was already GObject-ish.  Same with Genie,
> Python, and probably others with GObject support like Perl, Ruby, Scheme,
> C++, and so on.
>
> Even if it didn't lead to improved plugin quality, which it would at least
> for languages using VMs/interpreters, it would create a lot of new
> functionality for Geany by having much more participation from a wider range
> of programmers.  Just hanging around on the ML and IRC I've heard many times
> Geany users saying they would like to make a plugin but they don't know C,
> they are experts on some other language.  One of the big benefits of a
> plugin system is making it easy for users to extend the program, and IMO
> making the users learn and code properly in C does not (necessarily)
> accomplish that goal.
>
> The barrier to entry to writing Geany plugins currently is such that a very
> small portion of the users (programmers) are able to extend the software at
> all, and those that fake it in C will end up with nasty mess of buggy code
> (like me :).
>
> My 0.02$ CAD
>
> Matthew Brush (codebrainz)

Hi Matthew,

I wasn't party to the original design of the Geany plugin API/ABI so I
don't have any investment in it.

I can see why it was done the way it is, it has several potential
advantages in terms of reducing plugin re-compilation requirements,
although it loses some of that by being very conservative (but safe)
in terms of its run time acceptance of older plugins.  But as you
point out it isn't easy to bind to.

As we have discussed before, replacing the interface isn't acceptable,
but that doesn't mean that a second interface that is automatically
GObjectable, SWIGable introspectable etc.can't be added.

Over time existing plugins can then be migrated and the old interface removed.

But someone has to do it (tm) and of course patches are welcome (c)...

Cheers
Lex

$0.02AUD worth about the same :-)

> _______________________________________________
> Geany-devel mailing list
> Geany-devel at uvena.de
> http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
>