Use glib::translate to handle arrays and lists of strings

[gkoz]

This changes the APIs that take or return lists (of strings for now).

On the input side this allows a reference to anything that can iterate over strings:

    pub fn set_authors<S, I>(&self, authors: I)
    where S: Str, I: IntoIterator<Item = S> {
    ...

        dialog.set_authors(&crew);

The return type is Vec<String> but could if needed work similarly to Iterator::collect() that is generic over the container type.

It's pointless to use a glib::List or SList because you don't put native types in it, so it can't be passed to the libs unmodified, and thus has no benefits compared to the standard collections.

AboutDialog and FileChooser were broken and now they work! :)

[GuillaumeGomez]

Oh nice ! Isn't there other places where replacing arrays of pointers is needed ?

[gkoz]

Those have caught my eye because of deprecation warnings. I'll look to see if string arrays are used in any other places. Collections of pointers to other types will follow afterwards.

[gkoz]

Turns out there weren't many cases of string arrays usage. There're app_info and app_launch_context that are just commented out altogether. And there're two RecentInfo-related structs that need to be put onto the glib::translate rails -- that's what I planned to do next.

[GuillaumeGomez]

Perfect then. I merge when I can. Le 8 mars 2015 19:18, "Gleb Kozyrev" notifications@github.com a écrit :

Turns out there weren't many cases of string arrays usage. There're app_info and app_launch_context that are just commented out altogether. And there're two RecentInfo-related structs that need to be put onto the glib::translate rails -- that's what I planned to do next.

— Reply to this email directly or view it on GitHub https://github.com/jeremyletang/rgtk/pull/228#issuecomment-77765490.