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
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
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
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
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
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
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
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
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
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
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
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
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
13 matches
Mail list logo
