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.
_______________________________________________
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel
