Because that's a simple case. The length argument is not always at the end.
On Fri, Mar 1, 2013 at 7:03 AM, Matteo Settenvini
wrote:
> Il giorno gio, 28/02/2013 alle 01.51 -0800, Simon Feltman ha scritto:
> > On Thu, Feb 28, 2013 at 12:04 AM, Martin Pitt
> > wrote:
> > Nikita Churaev [2
Il giorno gio, 28/02/2013 alle 01.51 -0800, Simon Feltman ha scritto:
> On Thu, Feb 28, 2013 at 12:04 AM, Martin Pitt
> wrote:
> Nikita Churaev [2013-02-27 23:26 +0400]:
> > 3. Gtk.TextBuffer.set_text(text, length) --- length argument
> is useless,
> > since JavaSc
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
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
> 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 collec
On Thu, 2013-02-28 at 15:52 +0400, Nikita Churaev wrote:
> 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
Javier Jardón wrote:
> On 28 February 2013 08:26, Dan Winship 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
On 28 February 2013 08:26, Dan Winship 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 ma
> > 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 w
> 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
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 p
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 an
On Thu, Feb 28, 2013 at 12:04 AM, Martin Pitt wrote:
> 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 odditi
Von: "Martin Pitt" :
>> 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
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)" w
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.
N
On Wed, 2013-02-27 at 23:26 +0400, Nikita Churaev wrote:
> OK, so it seems that GNOME has a serious aim on making GNOME/JavaScript
> the preferred platform for new newbies.
I'd just like to reiterate that the idea isn't that JavaScript is
preferred for new developers or "smaller" applications (wha
On Wed, 2013-02-27 at 23:26 +0400, Nikita Churaev wrote:
> OK, so it seems that GNOME has a serious aim on making GNOME/JavaScript
> the preferred platform for new newbies. However, there are some API
> issues that make Gjs confusing, and bad for PEOPLE.
>
> 1. Some functions return useless "succe
OK, so it seems that GNOME has a serious aim on making GNOME/JavaScript
the preferred platform for new newbies. However, there are some API
issues that make Gjs confusing, and bad for PEOPLE.
1. Some functions return useless "success" boolean: for example
[success, contents, etag_out] = GFile.load
19 matches
Mail list logo
