Re: Possible to fix glaring Gjs API issues before GNOME 4?

[Martin Pitt <martin pitt ubuntu com>]

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)