Re: Possible to fix glaring Gjs API issues before GNOME 4?
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 (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. The bigger the differences between a new developer's environment and the average core GNOME developer's, the less often core developers will run the same code as new/third-party developers, the less they'll have to run into the same bugs, file and fix them, and thus the less polished our development environment will be for new developers. Maximizing the overlap between "new" and "core" developers is key to making GNOME a great development environment. > However, there are some API issues that make Gjs confusing, and bad > for PEOPLE. New developers are also people :) These issues apply to everyone, and I agree with you, they should be fixed. Have you filed bugs for each of them? That's the safest bet that they will get fixed. Contributing comments and code to those bugs are also great ways to push them forward. And you'll be notified when the bugs change state. ___ 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 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 "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. The GObject > 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? > > 2. The contents of GFile.load_contents itself is a binary data and yet > is returned as a string, it should be returned as a Uint8Array. > > 3. Gtk.TextBuffer.set_text(text, length) --- length argument is useless, > since JavaScript uses UTF-16 and length expects length of UTF-8 string. > > 4. It's impossible to create custom Gtk.TreeIter from JS (no > constructor), so can't implement a completely custom Gtk.TreeModel. > > 6. Gjs adds a prefix "Gjs_" to names of all GObject classes made in Gjs: > "MyMainWindow" becomes "Gjs_MyMainWindow" and it's pretty confusing when > you try to style it with CSS. > > 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. 7. Fixing bug #639908. Not being able to access contact information (among others) from official language (or any other using GIR) is probably suboptimal. 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
Possible to fix glaring Gjs API issues before GNOME 4?
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_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. The GObject 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? 2. The contents of GFile.load_contents itself is a binary data and yet is returned as a string, it should be returned as a Uint8Array. 3. Gtk.TextBuffer.set_text(text, length) --- length argument is useless, since JavaScript uses UTF-16 and length expects length of UTF-8 string. 4. It's impossible to create custom Gtk.TreeIter from JS (no constructor), so can't implement a completely custom Gtk.TreeModel. 6. Gjs adds a prefix "Gjs_" to names of all GObject classes made in Gjs: "MyMainWindow" becomes "Gjs_MyMainWindow" and it's pretty confusing when you try to style it with CSS. 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. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: -Werror considered harmful
On Tue, 2013-02-26 at 15:29 -0500, Behdad Esfahbod wrote: > I'm not questioning that. I think the right question would be: how > many bugs > got fixed in GLib because of the warnings being enabled by default Initally? A lot, some quite bad. We were leaking internal symbols for example. But the nice thing with having the baseline warnings on by default is that we know it's hard for those kinds of bugs to return. > but are you really saying that anyone on Ubuntu ought to > upgrade their mingw32 toolchain before compiling glib? That doesn't make > sense to me. No - they can also use the newly added configure option. But it'd also clearly be good if Ubuntu's mingw32 toolchain was fixed. Probably worth checking whether 12.10 works. I tried briefly but there don't appear to be precompiled packages of the glib depchain (zlib, libffi). ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Release Notes Time!
Hi all, It's that time again! GNOME 3.8 is due for release on 27 March: that means we have about two weeks to get the release notes fully written - that's not much time at all. Enter a trance-like state. Cast your mind back over the last six months. Ask yourself: is there anything I have done that will benefit users, developers or administrators? Come back to the world and write it down on the release notes wiki page [1]. Be happy. The sooner we have this information the better, so please don't delay. Thanks in advance, Allan [1] https://live.gnome.org/ThreePointSeven/ReleaseNotes -- 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
