[Geany-devel] geany-plugins depends on GIO - plugin API

Nick Treleaven nick.treleaven at xxxxx
Wed Nov 24 12:35:50 UTC 2010

On Wed, 24 Nov 2010 09:09:57 +1100
Lex Trotman <elextr at gmail.com> wrote:

> >> > It depends on what fields we're talking about. For a getter function
> >> > for a pref, there's not much you can do if the behaviour of the pref
> >> > changes or the pref is removed, the function will be no better than
> >> > the field.
> >>
> >> Yes semantic changes breaks the item, but ATM all you can do is break
> >> the whole ABI.
> >>
> >> If a field is removed from a structure the getter function may still
> >> be able to compute it or get it from the new location instead of
> >> another structure needing to be exposed.
> >
> > True, but we have a lot of fields in the API,
> But you only need getter and setters for ones that are used, the
> sooner its started the less plugins there will be, the less fields
> used and the less effort involved to change things.  Leave it too late
> and it will be logistically impossible :-(
>  it seems a bit ugly to
> > have tons of getter functions.
> True but they can be logically grouped with one function handling
> multiple fields of the same type.  Or where several fields are
> logically used together, one function may return multiple fields at
> once.  In other words the API can be tailored for the users, not
> reflect the current internal implementation.
> Also getters can return copies of data so that accidental (or
> deliberate) sets are not possible.

This is basically what editor_get_indent_prefs() does.

> This is of course in line with the
> direction of GTK.

GTK has to be more robust. The plugin API was designed for easy

> >> > Getting groups of prefs is different. One solution for overridden prefs
> >> > is editor_get_indent_prefs():
> >> > http://www.geany.org/manual/reference/editor_8h.html#db89e1ea679531fb35ba13efa2c93eda
> >> >
> >> > Perhaps this would be a good approach for other pref groups.
> >>
> >> Yes, as time and inclination permits.
> >
> > I have been meaning to add editor_get_prefs() as a future-proofing
> > function. It would be much tidier than core functions like
> > editor_get_long_line_*() which are specialized and just check whether
> > to use project or global prefs.
> Agree.

I've added an implementation to the core. It doesn't have all the
per-document overrides yet so I haven't exposed it to the API.


More information about the Devel mailing list