On 02/27/2013 08:26 PM, Nikita Churaev wrote: > Introspection developers have already introduced "(skip)" mark for such > return values, but they won't add it to existing API to avoid backwards > incompatibility. What about adding "(skip2)" mark that only Gjs will use > and replace it to "(skip)" when GNOME 4 comes?
AFAIK, there is no plan/timeline for GNOME 4, or for a GLib ABI break. But it seems like it would be a good idea to start explicitly noting planned future ABI breaks in some way, somewhere, so nothing gets forgotten when it does come, and so people can see the big picture more easily. > 4. It's impossible to create custom Gtk.TreeIter from JS (no > constructor), so can't implement a completely custom Gtk.TreeModel. I don't know the details of this particular issue, but if it's not possible to do at all now, then any change to make it more bindable could not possibly break any existing code, so it could happen at any time. > 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. Well, there's that shell thing. Would probably be good to not break that. One possibility would be to figure out all the ABI breaks we wanted, and then deprecate "imports.gi" and replace it with "imports.new-and-improved-gi" (except with a non-stupid name), where the modules imported from new-and-improved-gi would pick up all the latest-and-greatest annotations, and would not include any functions that had already been deprecated before its first release, while those in imports.gi would just preserve the current API forever (ie, the current versions of their gir files would get checked into git and we'd never generate new ones). (Renaming "imports.gi" is not a totally awful idea anyway, since "gi" is a completely opaque name unless you know details about the platform that new developers shouldn't be expected to have to know. "imports.gnome"?) -- Dan _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list