Re: 3.2: gjs/seed
On Thu, Apr 21, 2011 at 23:59, Jasper St. Pierre jstpie...@mecheye.net wrote:
Right now in gjs, you do this:
imports.gi.versions.Gtk = '3.0';
I assume there's nothing stopping Python from using the same technique, and
I know they've talked about it before.
We have basically the same thing:
gi.require_version('Gtk', '3.0')
Regards,
Tomeu
On Thu, Apr 21, 2011 at 5:57 PM, Josselin Mouette j...@debian.org wrote:
Le mercredi 20 avril 2011 à 19:12 -0400, Colin Walters a écrit :
On the other side of the coin though, I think we largely failed to
make JavaScript a compelling way to write apps. The language is only
a part of the question, and it's really not a large one. We need to
focus more on a build/deploy story, and less on /usr/bin/gjs. By
build I mean we really shouldn't be leaving it up to app authors to
figure out how to use Automake with gjs/seed and to do
imports.gi.Gtk. Deploy is another story.
If you are putting this on the table, it might not be too late to
rethink the way modules are imported in JS applications (and this holds
for Python applications, too).
When you use imports.gi.Gtk, you don’t even know whether you’ll be
getting GTK+ 2.x or GTK+ 3.x. This is horribly wrong. Just as wrong as
most modules in Python, the lack of versioning leads to horrible
breakage at runtime when there are API mismatchs. This is a ball and
chain we’ve been pulling since the pygtk 1.x vs. pygtk 2.x times, and it
is still here with GI.
There should be a way to specify the API version required when you
import the module, and it should even be mandatory.
--
.''`. Josselin Mouette
: :' :
`. `' “If you behave this way because you are blackmailed by someone,
`- […] I will see what I can do for you.” -- Jörg Schilling
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.2: gjs/seed
On Fri, Apr 22, 2011 at 00:19, Giovanni Campagna scampa.giova...@gmail.com wrote: Il giorno mer, 20/04/2011 alle 19.12 -0400, Colin Walters ha scritto: Hi, So speaking as someone who was motivated to make writing GNOME apps easier, I'm not very happy with how things turned out with the mix of gjs/seed/python/introspection/gtk3. [...] But let me cut to the chase and say that I think we'd at least consider realigning on seed for 3.2 for gnome-shell (and by extension, mark gjs as deprecated at least in GNOME). [...] Even tougher would be unwinding the Spidermonkey let/const and generator usage inside gnome-shell, but we dug the hole, we can dig it out. I would say Eventually! One working JS engine instead of two piles of bugs!, if it wasn't for this. But removing let/const will be a lot of work, and will surely introduce bugs (as var has different semantics than let). We need to know as soon as possible if such move is needed for 3.2 Also, there are missing parts both in GJS and in Seed, especially wrt GVariant and GDBus. I've made patches for GJS, I'd like know if I need to rewrite them for Seed. Same for array support, which is inconsistent for GJS and appears to be completely missing for Seed. That covers reasons 1,2 and 5. As far as reason 3), they're not as active anymore (probably gjs basically works for them), and for 6) I think we need to change this anyways. This leaves reason 4) which I admit is just a feeling. So - seed/gjs contributors - what do you think? One thing I'm not totally happy with is the organic growth in API in both seed and gjs. seed for example added an os module with e.g. fork which I think is totally wrong; it's just broken to fork() a GNOME app, since it conflicts with threads, etc. If we're going to do some unification, we should also prune a lot of cruft. If there are bits missing from GNOME (like GIO is really missing both Console and Process classes), we need to add them. == Dynamic Languages in GNOME == One thing that's worth addressing though (again) is the question do we need both Python and JavaScript?. The uptake of both seed and gjs has been relatively low; lower than Python at least for scripting GNOME apps. However, I think at least one the core reason for working on JavaScript remains that *we define the platform*. Python comes with a vast API, a lot of it really old and crufty, but even more importantly, large parts of it are *wrong* to use in GNOME. JS also has some native API that is wrong to use in GNOME. Date.toLocaleFormat is one example (it often segfaults GJS). E4X is another big one. Even JSON is bad, if you want to talk to C libraries using JsonGlib. (And let's ignore the subtle differences between RegExp and GRegex). Basically, if you want a language that is fully GObject based, the only choice is Vala. Other languages all have some kind of standard library, that won't interoperate with GLib/GIO. For example, we don't want people to use Python's mostly-POSIX-like wrappers for IO, we want people to use GIO, so it doesn't block the mainloop. We don't want people to use Python's webbrowser module, its multiprocessing module (which totally breaks things like X and DBus since it uses a bare fork()), etc. On the other side of the coin though, I think we largely failed to make JavaScript a compelling way to write apps. The language is only a part of the question, and it's really not a large one. We need to focus more on a build/deploy story, and less on /usr/bin/gjs. By build I mean we really shouldn't be leaving it up to app authors to figure out how to use Automake with gjs/seed and to do imports.gi.Gtk. Deploy is another story. The other reasons: * ecosystem: The industry adoption is reflected in all the work that goes into JIT compilers, as well as people simply learning the language * Better engine internals - the global interpreter lock in cPython really hurts it as far as a future in a multicore world Better implementations != Better engine internals. A PyTypeObject is definitely cleaner than a JSClass, with all its mess of prototype, constructor, parent objects and the like. (Which somehow explains why PyGObject, while being younger than GJS, has complete support for all introspection features). Don't know much about JS internals, but in the case of PyGObject, the reason for broader introspection support is that we had apps to port, so we needed at least the same level of access to GNOME APIs as we had with static bindings. My understanding (please correct me if this is outdated or plainly false) is that for existing usage of GJS such as gnome-shell, it's ok to have to write stuff in C when a limitation is found in GJS's introspection support. Regards, Tomeu ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Orca's external dependencies
On 04/21/2011 03:24 PM, Super Bisquit wrote: Since Orca is for the visually impaired, have you asked a blind person to test out gnome3? We didn't asked specifically to a blind person to test out gnome3, but in general, we asked any person interested in accessibility to test GNOME 3, provide feedback etc. GNOME Accessibility team is working on an accessibility testing distro: https://live.gnome.org/Accessibility/TestingDistro The purpose of this distro is test the accessibility support on GNOME 3, and in the same way, provide updated packages in order to solve the issues that we found on this test. Just a simple yes or no and not an explanation. You can see the explanation that you didn't asked in my previous paragraph. As you wanted a simple yes or no: no. I work with the Vinux project and would like to pass this information to them. Please, if you do that, pass them the link to the testing distro. Any feedback is welcome. On 4/21/11, Frederic Petersfpet...@gnome.org wrote: Hi Joanmarie, Looking at the 2.91 External Dependencies list [1], I see neither Speech Dispatcher nor OpenTTS. OpenTTS got approved for the prior cycle. [2] But they've since re-merged (unforked?) with Speech Dispatcher. So Do I need to propose Speech Dispatcher as an external dependency needed by Orca, or can I assume that because OpenTTS got blessed, Speech Dispatcher inherits that blessing and simply needs to be added to future lists of dependencies? Similarly, Orca has always depended upon BRLTTY [3] for refreshable braille. Thus I was surprised to discover that BRLTTY was not listed as a dependency. Distros seem to know to include it, but should BRLTTY be something officially made an external dependency of GNOME? Finally, if the answer to my question about BRLTTY is Yes, it should be proposed/considered by the Release Team, then I'd like to toss out one more for consideration: Liblouis. [4] Liblouis provides Orca users with the braille translation tables needed for contracted/grade 2 braille. We are moving away of the idea of approving/rejecting individual modules and considering the features we want in GNOME. In that direction we'd say that whatever is needed for Orca to do its work is ok. Of course this calls for some common sense, to keep some coherence in our stack, but in the specific case of Orca we are not adding liblouis to our development platform, it just happens to be a library that is used to provide Orca users an important feature. But we want to have some guidelines, they are still to be discussed, but the current proposal for modules developed outside of GNOME, and with no consideration for our schedule, to require modules to depend on released versions only. Does this answer your question clearly enough? Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- API ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
