[Geany-devel] Ideas on increasing quality of plugins

[Frank Lanitz]

On Sat, 12 Mar 2011 12:04:31 +1100
Lex Trotman <elextr at gmail.com> wrote:

> 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)...

Yes. I'm sure we can discuss to set up a branch on geany-svn where
Matthew and maybe some other can start to build up a GObject based
interface by keeping the old. That's being said: I guess the core team
itself will currently not have the capacities to do it. But this should
be another thread as its off topic here. 

Cheers, 
Frank 
-- 
http://frank.uvena.de/en/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.geany.org/pipermail/devel/attachments/20110312/22dcc715/attachment.pgp>