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

Lex Trotman elextr at xxxxx
Mon Nov 22 22:20:35 UTC 2010


On 22 November 2010 23:55, Nick Treleaven <nick.treleaven at btinternet.com> wrote:
> On Mon, 22 Nov 2010 08:24:13 +1100
> Lex Trotman <elextr at gmail.com> wrote:
>
>> , but I don't really think we should add accessors for
>> >> all fields.
>>
>> @Nick,
>>
>> Well you have in the past commented negatively about making structures
>> visible.  As you sagely said either you constrain your implementation
>> or yuo have to spend the effort "faking" the structure for plugin
>> purposes.
>
> 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.

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

>
> Fields in the API generally should not be set. There is a stronger
> argument for adding setter functions than getter functions, if plugins
> need to set something.

Agree

Cheers
Lex

>
>> I'm not saying any of this needs to happen yesterday, but if we don't
>> start thinking about it nothing will ever happen.  And as more plugins
>> are being made, adding significant capability to Geany  the problems
>> of updating them in sync will get worse.
>
> Nick
> _______________________________________________
> Geany-devel mailing list
> Geany-devel at uvena.de
> http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
>



More information about the Devel mailing list