[Geany-devel] GProject - the second attempt

[Lex Trotman]

>> Totally agree, Geany doesn't (yet) support plugins integrating
>> themselves fully into Geany, but its something that needs thinking
>> about as a general capability to allow a more seamless user
>> experience, maybe we can look at how tools like Firefox do it.
>>
>> The problem with the current approach is that each time someone comes
>> along with a good idea they have to request access to parts of Geany
>> from the primary developers and then there is a discussion of what is
>> right to make available or add to the core.  All of which wastes the
>> core developers time and reduces what else they can do.  A more
>> general plugin system would save them having to do that.
>
> On the other hand, we could easily overdo it with plugin API
> generality. Geany should definitely not become Eclipse written in C.

Definitely not

> In my opinion the current approach of introducing API functions on
> demand is alright. The amount of things the plugins can already do is
> satisfactory for most of the plugins I guess.

Yes you and I are pushing the edges with project and build plugins
because we are not adding new functionality but improving something
that already exists so need to integrate with it.

My plugin is a bit
> exceptional in being the first plugin that extends the project
> management of geany and therefore needs some extra functions and
> signals for that (not so many though, most of the patches are just
> general geany improvements). And talking about every single additional
> API function with geany developers is good in the sense that the given
> function is considered from more viewpoints and sufficient brain time
> is spent before introducing a possibly nonsense function into the API.

Yes, but it tends to be a specific function for a specific plugin, not
general capability, there seems to be some resistance to thinking
about them as general capabilities.

> Also introducing API functions in advance can cause that these
> functions are poorly tested because there's nothing that uses them.

Yes, I agree, I was more thinking about providing general capabilities
rather than a wide API.  It may mean some re factoring of Geany
because at the moment many of the restrictions are hard coded in low
level functions.

 I
> also like that the API is restrictive a bit - plugins shouldn't be
> able to modify geany completely so it becomes a different editor -
> they should just extend it in a certain way.

Well, really why not?  I someone wants to make it work differently
because they like it that way, why can't they.  If you don't like what
a particular plugin does, just don't use it. :-)

Cheers
Lex

>
> But I don't have anything against looking at how others do it - there
> are surely good (and bad) lessons we can learn. If I should say a
> single thing I dislike about how plugins are implemented in geany (and
> there's actually only this single complaint), it is the fact that by
> including geanyplugin.h I also include lots of function prototypes
> that don't belong to the API. It happened to me several times that I
> copied some code from geany into my plugin, compiled it without any
> problem, but then the plugin didn't load because the function I used
> was not a part of the API. Some macros or whatever should be used to
> prevent non-API functions and data structures from being included by
> the plugins.
>
> Cheers,
>
> Jiri
>
>>
>>
>>> One more thing that might be needed by plugins (but which isn't needed
>>> by gproject so I haven't added the API methods) is the ability to add
>>> their own validators of the dialog entries the given plugins added.
>>> There could be something like register_validator() and
>>> unregister_validator() whose argument would be a pointer to the
>>> validator function. Geany would keep a list of these pointers and run
>>> all the functions to see if everything is valid before it sends the
>>> above signal. The functions could also return some error string used
>>> by a pop up error dialog. As I said, I don't need it but could be
>>> added when some plugin requires such a functionality.
>>
>> This is a good idea that needs to be addressed as part of an overall
>> discussion of how plugins integrate with Geany.  I guess when everyone
>> gets some time :-(.
>>
>>>
>>
>> Cheers
>> Lex
>> _______________________________________________
>> Geany-devel mailing list
>> Geany-devel at uvena.de
>> http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
>>
> _______________________________________________
> Geany-devel mailing list
> Geany-devel at uvena.de
> http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
>