The Nim bindings up to release 0.8.0 have no real GList support. So in the last days I have fixed that for the case when the GList is a result of a function call – that was not that difficult as we have to copy the data to a Nim seq basically. And call g_list_free() when necessary.
GList argument parameters are still unsolved. I guess they are very rarely used, at least I am not aware of some code which actually uses such parameter types, so I would not be able to actually test it.
The transfer mode of the parameter determines who should free the GList. The GI annotations in the API docs can assume default values - see “Default Annotations” in the GI annotations documentation. Alternatively, the girepository interface can be used to query the transfer mode. Either way, you’ll find that the transfer mode is ‘none’ for the parameter uris of the function g_app_info_launch_uris.
In this case you suspected right but, generally, there’s no need for doubt - it just depends on the transfer mode which determines who ends up owning the GList and, therefore, must free it:
‘none’: the caller still owns the GList;
‘container’: ownership of the GList is transferred to the function.
‘full’: ownership of the GList and the elements is transferred to the function.
Note that in the case of ‘container’ or ‘full’, the function could even transfer ownership back to the caller in another parameter or the return value so that it doesn’t need to free anything.