Re: Possible to fix glaring Gjs API issues before GNOME 4?
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 desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Possible to fix glaring Gjs API issues before GNOME 4?
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
Re: Possible to fix glaring Gjs API issues before GNOME 4?
Von: Martin Pitt martin.p...@ubuntu.com: 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 We use a similar approach in the Perl bindings: http://git.gnome.org/browse/perl-Glib-Object-Introspection/tree/lib/Glib/Object/Introspection.pm#n48, http://git.gnome.org/browse/perl-Gtk3/tree/lib/Gtk3.pm#n49. When functions with a success boolean and out arguments don't throw an exception, you can still get rid of the boolean if your language supports a variable number of return values. You simply return nothing then in the case the boolean is false. But note that you cannot use a heuristic like has boolean return value and out arguments to decide whether to apply this approach: gtk_tree_selection_get_selected is a counter example, http://developer.gnome.org/gtk3/3.2/GtkTreeSelection.html#gtk-tree-selection-get-selected. I also think an annotation for boolean return values that states this is a sentinel for whether the out args have been set would be useful. It would make it possible for bindings to share this information. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Possible to fix glaring Gjs API issues before GNOME 4?
On Thu, Feb 28, 2013 at 12:04 AM, Martin Pitt martin.p...@ubuntu.comwrote: Nikita Churaev [2013-02-27 23:26 +0400]: 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. I don't think skipping the length arg in this case could work even if API breakage was acceptable. I assume a skip implies a value of zero is used and in this case that would not work. A better alternative would be default value support. This way the oddity can be avoided in client code without breaking API and in general would be a very nice feature. However, new code using this would need to specify it only works with advanced versions of GLib or the libraries providing defaults. https://bugzilla.gnome.org/show_bug.cgi?id=558620 -Simon ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Possible to fix glaring Gjs API issues before GNOME 4?
On Thu, 2013-02-28 at 09:26 +0100, Dan Winship wrote: 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. IIRC the GtkTreeIter is assumed to not allocate memory. The API and ABI would need to be altered in order to incorporate it as: - 3rd party needs to free GtkTreeIter if it uses one from arbitrary model (possibly not so important) - i.e. there is API change and ABI. - All elements of class struct are already occupied so the size of struct would need to be change - thus changing the the ABI. I looked at the issue around Gtk+ 3.2 when someone asked for non-memory allocating iterators for libgee (I cannot find the request right now but making it bindable would solve this issue as well). Best regards signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Possible to fix glaring Gjs API issues before GNOME 4?
On Thu, 2013-02-28 at 10:08 +, Maciej Piechotka wrote:
On Thu, 2013-02-28 at 09:26 +0100, Dan Winship wrote:
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.
IIRC the GtkTreeIter is assumed to not allocate memory. The API and ABI
would need to be altered in order to incorporate it as:
- 3rd party needs to free GtkTreeIter if it uses one from arbitrary
model (possibly not so important) - i.e. there is API change and ABI.
- All elements of class struct are already occupied so the size of
struct would need to be change - thus changing the the ABI.
I looked at the issue around Gtk+ 3.2 when someone asked for non-memory
allocating iterators for libgee (I cannot find the request right now but
making it bindable would solve this issue as well).
Best regards
struct GtkTreeIter {
gint stamp;
gpointer user_data;
gpointer user_data2;
gpointer user_data3;
};
There's a stamp member that models can put unique IDs in. We could allow
Gjs to create iterators with just stamps and leave user_data alone.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Possible to fix glaring Gjs API issues before GNOME 4?
I'd just like to reiterate that the idea isn't that JavaScript is preferred for new developers or smaller applications (what would be the cut-off?). We're going to encourage JavaScript for all new applications (regardless of who's writing them), both for core GNOME and third-party. Can Gjs handle complex applications (eg. multimedia editors like photo and video editors, medium games, complex data analysis) without eating up all the CPU and memory? If it can, then go for it! However, there are some API issues that make Gjs confusing, and bad for PEOPLE. New developers are also people :) Yes, they are all people, but they are also PEOPLE. I admit, GNOME/JavaScript platform will only attract imperfect PEOPLE who still have their inner hacker (in a good way) not completely beaten out of them, as it's literally impossible for perfect PEOPLE to program in any other platform other than a good safe platform that's prescribed, that is, HTML5 on Windows 8+. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Possible to fix glaring Gjs API issues before GNOME 4?
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? Maybe add version system to Gjs, so that if you call gjs xx.js it'll use old API and if you call gjs2 xx.js it'll use the new API. GNOME Shell could just use the old API. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Possible to fix glaring Gjs API issues before GNOME 4?
On 28 February 2013 08:26, Dan Winship d...@gnome.org wrote: 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. In GTK+ this is done by marking bugs with 4.0 as target milestore [1] [1] https://bugzilla.gnome.org/buglist.cgi?product=gtk%2Bbug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDtarget_milestone=4.0 -- Javier Jardón Cabezas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Possible to fix glaring Gjs API issues before GNOME 4?
Javier Jardón jjar...@gnome.org wrote: On 28 February 2013 08:26, Dan Winship d...@gnome.org wrote: 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. In GTK+ this is done by marking bugs with 4.0 as target milestore [1] We should also be tracking and targeting any gjs binding issues. We really need the new applications to be clearing the way for those who want to follow, rather than working around deficiencies in the platform. One issue I know of is the lack of introspection support in libcanberra [1]. I bet there are others... Allan [1] https://bugs.freedesktop.org/show_bug.cgi?id=32587 -- IRC: aday on irc.gnome.org Blog: http://afaikblog.wordpress.com/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Possible to fix glaring Gjs API issues before GNOME 4?
That's not an issue - you can put even a pointer but the problem is that
you need to pin object. You don't know (automatically without user
intervention) when you can free the resource. At any point GTK might
keep GtkTreeIter alive so data you put inside cannot be freed (or
garbage collected or however you'll call it) and it need's to be always
considered 'alive'. I guess it is possible to workaround the issue by
reverse engineering the Gtk internals but solution would be very
unstable and not remotely elegant.
The problem with GtkTreeIter is that you can't make any function to be
called when iter goes out of scope. Example:
int
foo(void)
{
GtkTreeIter iter;
get_iter_of_something (iter);
do_something_with_iter (iter);
/* iter is no longer needed, C frees its memory
automatically, but we can't make it call a
custom function, as C doesn't have C++'s
destructors, that's why we can't put references
to JavaScript objects into them */
}
However, luckily for us, GtkTreeIter has an integer stamp field that
could be used instead of a direct reference. JavaScript custom tree
models will be slower as they would need to look up items by their
stamps. Example:
_init: function() {
this.parent(...);
this._items = [];
},
getTreeIterOfItem: function(itemStamp)
{
if (this._items[itemStamp] === undefined)
return undefined;
return new Gtk.TreeIter(itemStamp);
},
getItemByTreeIter: function(iter)
{
return this._items[iter.stamp];
}
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Possible to fix glaring Gjs API issues before GNOME 4?
On Fri, 2013-03-01 at 02:44 +0400, Nikita Churaev wrote:
That's not an issue - you can put even a pointer but the problem is that
you need to pin object. You don't know (automatically without user
intervention) when you can free the resource. At any point GTK might
keep GtkTreeIter alive so data you put inside cannot be freed (or
garbage collected or however you'll call it) and it need's to be always
considered 'alive'. I guess it is possible to workaround the issue by
reverse engineering the Gtk internals but solution would be very
unstable and not remotely elegant.
The problem with GtkTreeIter is that you can't make any function to be
called when iter goes out of scope. Example:
int
foo(void)
{
GtkTreeIter iter;
get_iter_of_something (iter);
do_something_with_iter (iter);
/* iter is no longer needed, C frees its memory
automatically, but we can't make it call a
custom function, as C doesn't have C++'s
destructors, that's why we can't put references
to JavaScript objects into them */
}
However, luckily for us, GtkTreeIter has an integer stamp field that
could be used instead of a direct reference. JavaScript custom tree
models will be slower as they would need to look up items by their
stamps. Example:
_init: function() {
this.parent(...);
this._items = [];
},
getTreeIterOfItem: function(itemStamp)
{
if (this._items[itemStamp] === undefined)
return undefined;
return new Gtk.TreeIter(itemStamp);
},
getItemByTreeIter: function(iter)
{
return this._items[iter.stamp];
}
Yes. That is the problem I've wrote about.
I didn't parsed the sentence models guarantee that an
iterator is valid for as long as the node it refers to is valid (...)
correctly. Arguably this allows to even point to node in one of the
field speeding things a little:
I assume that we don't use list as probably GtkListModel is better in
such case. Sorry if code is incorrect (I don't use JS):
function MyNode() {
this._init();
}
MyNode.prototype = {
_init: function() {
},
next: function() {
}
parent: function() {
}
};
function MyModel() {
this._init();
}
MyModel.prototype = {
_init: function() {
...
},
getTreeIterFromTreePath: function(iter, path) {
var node = doMagic(path);
iter._user_data1 = marshal_as_unowned(node); // Don't pin
}
getNodeFromTreeIter: function(iter) {
return iter._user_data1;
}
root: new MyNode();
};
I'm not sure if marshal_as_unowned exists in GJS now though.
Best regards
signature.asc
Description: This is a digitally signed message part
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Possible to fix glaring Gjs API issues before GNOME 4?
On Thu, 2013-02-28 at 23:09 +, Maciej Piechotka wrote:
On Fri, 2013-03-01 at 02:44 +0400, Nikita Churaev wrote:
That's not an issue - you can put even a pointer but the problem is that
you need to pin object. You don't know (automatically without user
intervention) when you can free the resource. At any point GTK might
keep GtkTreeIter alive so data you put inside cannot be freed (or
garbage collected or however you'll call it) and it need's to be always
considered 'alive'. I guess it is possible to workaround the issue by
reverse engineering the Gtk internals but solution would be very
unstable and not remotely elegant.
The problem with GtkTreeIter is that you can't make any function to be
called when iter goes out of scope. Example:
int
foo(void)
{
GtkTreeIter iter;
get_iter_of_something (iter);
do_something_with_iter (iter);
/* iter is no longer needed, C frees its memory
automatically, but we can't make it call a
custom function, as C doesn't have C++'s
destructors, that's why we can't put references
to JavaScript objects into them */
}
However, luckily for us, GtkTreeIter has an integer stamp field that
could be used instead of a direct reference. JavaScript custom tree
models will be slower as they would need to look up items by their
stamps. Example:
_init: function() {
this.parent(...);
this._items = [];
},
getTreeIterOfItem: function(itemStamp)
{
if (this._items[itemStamp] === undefined)
return undefined;
return new Gtk.TreeIter(itemStamp);
},
getItemByTreeIter: function(iter)
{
return this._items[iter.stamp];
}
Yes. That is the problem I've wrote about.
I didn't parsed the sentence models guarantee that an
iterator is valid for as long as the node it refers to is valid (...)
correctly. Arguably this allows to even point to node in one of the
field speeding things a little:
I assume that we don't use list as probably GtkListModel is better in
such case. Sorry if code is incorrect (I don't use JS):
function MyNode() {
this._init();
}
MyNode.prototype = {
_init: function() {
},
next: function() {
}
parent: function() {
}
};
function MyModel() {
this._init();
}
MyModel.prototype = {
_init: function() {
...
},
getTreeIterFromTreePath: function(iter, path) {
var node = doMagic(path);
iter._user_data1 = marshal_as_unowned(node); // Don't pin
}
getNodeFromTreeIter: function(iter) {
return iter._user_data1;
}
root: new MyNode();
};
I'm not sure if marshal_as_unowned exists in GJS now though.
Best regards
IDK, there's no guarantee that SpiderMonkey won't start moving objects
in memory in next versions.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
