Nikita Churaev [2013-02-27 23:26 +0400]: > 1. Some functions return useless "success" boolean: for example > [success, contents, etag_out] = GFile.load_contents(). When C > g_file_load_contents returns false, it also sets GError, so in Gjs it's > either true or the function has thrown exception.
Note that many other functions with that style don't throw a GError. In PyGObject we have overrides for many of them to filter out the bool and only return the (out) arguments if the return value is True. Look for "strip_boolean_result" in http://git.gnome.org/browse/pygobject/tree/gi/overrides/Gtk.py Perhaps gjs could do something similar. But as you already said, doing this anywhere (in annotations or overrides) always means an API break, so at this point it might actually be better to just use what we have and live with it. The existing ones in PyGObject were mostly done for compatibility to the old PyGTK API, but we will not introduce any new ones. In particular not as a global heuristics for all functions (https://bugzilla.gnome.org/show_bug.cgi?id=620912) > 3. Gtk.TextBuffer.set_text(text, length) --- length argument is useless, > since JavaScript uses UTF-16 and length expects length of UTF-8 string. I'm afraid we have to live with little oddities like this. I think it's better to stay compatible with the C API and its documentation, and all currently existing JavaScript program which use the API than breaking API and continuously chasing after weird cases like that. > 4. It's impossible to create custom Gtk.TreeIter from JS (no > constructor), so can't implement a completely custom Gtk.TreeModel. Aren't these just vfuncs? Doesn't gjs support defining/overwriting them? > Is it possible to fix these issues at least in Gjs ASAP without having > to wait for GNOME 4, as there are still very few Gjs applications, so we > don't have to worry as much about backwards compatibility as in eg. > Python. That's a fair point. I guess the primary affected module would be gnome-shell, plus all the existing plugins? Martin -- Martin Pitt | http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) _______________________________________________ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
