G_app_info_launch_uris ()

[StefanSalewski]

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.

One example of such a function is

https://developer.gnome.org/gio/stable/GAppInfo.html#g-app-info-launch-uris

First question: How would ordinary C code to construct such a GList parameter look?

And who will free that GList? The called function, or do I have to free the GList after the function call? With functions like g_list_free() ?

From the API docs we have [nullable][element-type utf8] which is not much.

[EDIT]

Well creation of the list should be easy with g_list_prepend() or g_list_append() from

https://developer.gnome.org/glib/stable/glib-Doubly-Linked-Lists.html

And I strongly guess I have to free the list myself after the function call.

[pclayton (Phil Clayton)]

@StefanSalewski

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.

One example of such a function is

Gio – 2.0

And who will free that GList? The called function, or do I have to free the GList after the function call? With functions like g_list_free() ?

From the API docs we have [nullable][element-type utf8] which is not much.

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.

And I strongly guess I have to free the list myself after the function call.

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.