[Geany-Devel] Spawn module API

[Matthew Brush]

On 2015-06-23 09:04 AM, Dimitar Zhekov wrote:
> On 23.6.2015 г. 02:25, Matthew Brush wrote:
>
>> [...]
>
> One thing I forgot: the plugin API currently exports
> utils_spawn_[a]sync, and a few plugins use utils_spawn_sync. These
> functions were (partially correct) wrappers around the old glib/win32
> spawn, and are now wrappers around spawn_[a]sync. Someday, in the
> distant future, they should be obsoleted...
>

+1

>  > I get what you're saying but I also
>  > feel uneasy about blanket exporting of APIs with no current users of it,
>  > so we don't know exactly what really needs to be exported.
>
> Well, with nothing from spawn exported, we can be pretty sure that all
> plugins _will_ be using utils_spawn and g_spawn instead. :)
>

I think the general policy is to export stuff on demand as plugins need 
it. Seeing as you wrote the API in question, I'm assuming you know best 
the stuff you will need, so I don't personally see much problem 
preemptively exposing that stuff[0].

 From you're previous email you mentioned the stuff checked with [x] below:

[ ] spawn_get_program_name()
[ ] spawn_check_command()
[x] spawn_kill_process()
[ ] spawn_async_with_pipes()
[ ] spawn_async()
[x] spawn_with_callbacks()
[x] spawn_write_data()
[ ] spawn_get_exit_status()
[ ] spawn_sync()

[x] SpawnFlags
[x] SpawnReadFunc
[x] SpawnWriteData

Is that sufficient, or is there other stuff? I will remove the /** from 
anything that is not expected to be needed, if nobody objects.

About the WIF* macros, those (at present) are not "officially" part of 
the plugin API as they have no Doxygen comments, though they will still 
be visible to plugins since they're macros and bypass the linker trick 
we use to hide functions. I think it would be best to add documentation 
to those (and possible define them into the "GEANY_" 'namespace'?), at 
the very least to ensure nobody accidentally moves or hides them. Just 
the other day I tried to move them into spawn.c thinking they were there 
on accident, but then I left them because another .c file uses them so 
they need to be in a (not necessarily public) header.

>  > We should make Colomban decide :)
>
> The leading developers should decide - including you.
>

Well you know my opinion :) I think everyone pretty much agrees we 
shouldn't expose stuff unrelated to the plugin API, and I think we all 
also agree it's stupid for plugins to have to copy&paste code that 
exists already or else use an inferior version. I also think everyone 
agrees that a separate utility library would be a good idea. The problem 
I have is that once this API makes it into the next release, it's 
"forever" stuck inside Geany and we'll have to keep it indefinitely, 
regardless if something possibly better[1] like GProcess comes available 
to us, and we don't even use it internally anymore.

Cheers,
Matthew Brush

[0]: At least until we establish a policy around what belongs in the 
plugin API or not.
[1]: I have no idea if it's better, just an example.