Re: 3.2: gjs/seed
This is basically what libpeas achieves these days using introspection: the application author chooses which dynamic language he wants to use for extending his app among the few available choices (python, js, seed). I will be writing a full reply to this thread soon, but I have been busy with finishing up my last semester of school and haven't gotten around to it. I thought I would comment on this quickly though so the debate doesn't get in the wrong direction. The whole idea of using multiple dynamic language bindings to GObject in a single application is flawed due to the toggle reference system. Without changes to GObject, or some sort of (and this would have to be very clever...) infrastructure to allow language bindings to share toggle references, we can't really offer the user a choice of multiple languages, at least on the per application basis. ___ 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 04/29/2011 03:41 AM, a...@akbkhome.com wrote: I did think the plan of Introspection was to be able to say to Gnome users, You want to customise application X, pick _your_ favourite language, it's _your_ choice..., rather than getting into a 'this language is better...' story that tends to put people off. More of an Inclusive community concept I guess.. This is basically what libpeas achieves these days using introspection: the application author chooses which dynamic language he wants to use for extending his app among the few available choices (python, js, seed). ___ 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 05/04/2011 04:01 PM, Robert Carr wrote: The whole idea of using multiple dynamic language bindings to GObject in a single application is flawed due to the toggle reference system. Without changes to GObject, or some sort of (and this would have to be very clever...) infrastructure to allow language bindings to share toggle references, we can't really offer the user a choice of multiple languages, at least on the per application basis. Sure, you cannot own more than one toggle reference by object. Hence the singular in my sentence which dynamic language ;-) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.2: gjs/seed
While a little biased, I'd rather there was a plan to keep Javascript in Gnome front and center... I did think the plan of Introspection was to be able to say to Gnome users, You want to customise application X, pick _your_ favourite language, it's _your_ choice..., rather than getting into a 'this language is better...' story that tends to put people off. More of an Inclusive community concept I guess.. Seed on Gtk3 should be usable, Most of the issues I had with maintaining applications written using it are around the changing Gtk API and introspection changes, which I presume python gjs all suffer from now. (It would be nice if introspection had a mailing list rather than IRC to follow and/or follow up discussions...) From a maintenance / development point of view Seed is 'maintained' (eg. bug reports and patches tend to be responded to or applied), however there is little active development (fixing hard problems etc.).. Could have been a good SoC project.. Python is always going to be stronger as it has a longer history in gnome (unfortunately as some people like me really do not enjoy using it), It will also take a long time for JS to gain as much ground, and any sense that the door is closing is not really going to help. I watched my son last night experimenting with Javascript on a web-page with chrome and komodo for his first programming, it was all javascript, as it's accessible on any platform. While some of us grew up with assembler and BBC basic, as that was all that was available, todays generation are more likely to have toyed with javascript first. These are hopefully the type of people that will eventually drive Gnome in the future and I'd be keen to see the barrier of entry kept as low as possible for them.. Anyway my 2c on that. Regards Alan On 04/29/11 07:03, Emmanuele Bassi wrote: hi Colin; On 28 April 2011 23:38, Colin Walterswalt...@verbum.org wrote: On Wed, Apr 20, 2011 at 7:12 PM, Colin Walterswalt...@verbum.org wrote: == 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*. Actually I've been thinking about this more, and I am changing my mind; if we don't have an immediate plan for making JavaScript more compelling, and there's still active people maintaining Python, we should be advertising the latter, and not the former. So here's what I propose (and I'm willing to write patches, but mostly this is just marketing/messaging): * Officially mark both gjs and seed as experimental (this is the reality as it is for 3.0 anyways) * Drop all consumers of seed in GNOME 3.2; rewrite them (this is just gnome-games/lightsoff?) using C/Vala/gtkmm/Python * Remove /usr/bin/gjs * Keep gnome-shell on gjs (but switch to using Spidermonkey 1.8.5, and no - porting to Python would be a pointless waste of time at best) What does this mean about the JavaScript future? My take here is that for 3.2 at least, we could move it more towards being an embedding language, designed from the very start to be used in a split C/JS role. Also, this allows us flexibility to evolve JavaScript and return later with something more interesting. For example, a combined WebKit-with-arbitrary-gnome-JavaScript that I've seen at least two different attempts at. Thoughts? with all due respect, I think this is a knee-jerk reaction, and an oversimplification of the issue. both gjs and seed have been in some way marked as experimental de facto, if not de jure: the fact that only gnome-games and shell have been written using them is in no way a testament to the widespread usage and adoption; quite the contrary. so, marking them both as experimental would achieve nothing, and surely it wouldn't achieve the goal of having a better support of JavaScript as a primary language for Gnome applications. I do agree that the situation is untenable: gjs is barely maintained, with patches bitrotting in bugzilla (e.g. support for array arguments); seed is a hodge-podge of web platform, unixy-platform and gnome-platform, with questionable design choices for the advanced features like sub-classing support, or missing features. setting them both to be experimental bindings would not make them developed any further - actually, it would probably be a surefire way to have them both killed, with nothing to replace them. part of the current situation is due to uncertainty: which one to target when embedding, which one to contribute to, which one to use to write apps. I think it has come time for the Gnome project to do what we are generally afraid to do, and that is: pick one side and stick with it. in your original email you identified Seed as the potential candidate because of the
Re: 3.2: gjs/seed
Hi! Am Donnerstag, den 28.04.2011, 18:38 -0400 schrieb Colin Walters: On Wed, Apr 20, 2011 at 7:12 PM, Colin Walters walt...@verbum.org wrote: == 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*. I think the we define the platform argument is really weak. Our whole platform is written in C and we definitly don't define that platform. You can include a lot of really old Unix API in C and nobody can prevent you doing it. Sting handling is more or less completely broken in C and still GString is only used in a few cases. C++ has it's own implementation of containers and hash-tables which we don't control either. Same for Python, same for more or less any language despite probably Vala where we really control the language in some ways. Still even Vala maps all kind of old-style Unix APIs. Anyway, a responsible programmer will use the correct APIs if we promote them and they are convenient. But many people have a prefered language and will certainly stick to that language if possible. Python seems popular among our community and is really actively promoted by Ubuntu for example, so dropping it isn't an option at all. Still I would agree that we should go for one JavaScript binding because having two makes things unnecessary complex. If we don't have a maintainer for gjs I agree with ebassi that Seed seems a natural choice also giving the confusing that mozilla usually creates with their external API and the fact that the rest of the desktop moved to WebKit. Regards, Johannes signature.asc Description: This is a digitally signed message part ___ 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 Thu, Apr 21, 2011 at 11:49 AM, Colin Walters walt...@verbum.org wrote: Hi, On Thu, Apr 21, 2011 at 3:26 AM, Xan Lopez x...@gnome.org wrote: There's no particular reason for this, we just never got around to untangle them. If there's increased interest in having them as separate libraries we can have it as one of the goals for WebKitGTK+ 1.6, which should be released in time for GNOME 3.2 (of course the actual separation would likely happen a lot earlier in some 1.5.x release). Cool. It'd be nice to have this happen soon so we can evaluate things higher up the stack. I pushed this today to WebKit trunk, so it will be available in the first unstable release of the 1.5.x series in the near future. Cheers, Xan ___ 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 29, 2011 at 3:00 AM, Johannes Schmid j...@jsschmid.de wrote: I think the we define the platform argument is really weak. Our whole platform is written in C and we definitly don't define that platform. You can include a lot of really old Unix API in C and nobody can prevent you doing it. Yes, but GLib is very prominent in the world for code written in C...third party libraries are quite likely to already depend on it. Also, it's not just the API exposed, but the fact that we have control over the implementation if we need it. For a different example, if we wanted to go to town on memory usage optimizations and have a pre-forking zygote process for gtk3+js apps, we could do that. But it would be impossible with Python (at least, not without effectively rewriting it, which would preclude access to all the libraries written in C). ___ 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 29, 2011 at 14:12, Colin Walters walt...@verbum.org wrote: On Fri, Apr 29, 2011 at 3:00 AM, Johannes Schmid j...@jsschmid.de wrote: I think the we define the platform argument is really weak. Our whole platform is written in C and we definitly don't define that platform. You can include a lot of really old Unix API in C and nobody can prevent you doing it. Yes, but GLib is very prominent in the world for code written in C...third party libraries are quite likely to already depend on it. Also, it's not just the API exposed, but the fact that we have control over the implementation if we need it. For a different example, if we wanted to go to town on memory usage optimizations and have a pre-forking zygote process for gtk3+js apps, we could do that. But it would be impossible with Python (at least, not without effectively rewriting it, which would preclude access to all the libraries written in C). Not making an argument for this discussion, but can you explain why it would be more difficult with Python? I did some experiments on this and the issues seemed to be in libraries, not in Python itself. Regards, Tomeu ___ 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, 2011-04-29 at 09:00 +0200, Johannes Schmid wrote: Hi! Am Donnerstag, den 28.04.2011, 18:38 -0400 schrieb Colin Walters: On Wed, Apr 20, 2011 at 7:12 PM, Colin Walters walt...@verbum.org wrote: == 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*. I think the we define the platform argument is really weak. Our whole platform is written in C and we definitly don't define that platform. You can include a lot of really old Unix API in C and nobody can prevent you doing it. Sting handling is more or less completely broken in C and still GString is only used in a few cases. C++ has it's own implementation of containers and hash-tables which we don't control either. Same for Python, same for more or less any language despite probably Vala where we really control the language in some ways. Still even Vala maps all kind of old-style Unix APIs. String handling and containers are sort of limited lowlevel things though. I don't think anyone has a problem with using the language native versions of these. Especially since the gnome platform story on these are quite weak. However, a platform like pyton is much richer. It contains many things that directly conflicts with our platform. Config APIs (gsettings), http support (soup), file handling and streams (gio), ssl support (glib-networking), etc. Isn't there even talk about a native python widget toolkit? The problem is, once you start writing in python it becomes natural to use these modules, and they inherently pull in other modules, until eventually you're not using much of the gnome platform, and get into problems interacting with the gnome side of your code (no giostreams, no gcancellable, etc). This is not insurmountable, if you take care, but in the js side you have none of these issues. Everything will naturally use the gnome platform stack, since there is little else (apart from core language things). That said, I'm not sure we should be writing large apps from scratch in plain JS. I'm personally much more into the app core in C, ui logic in js camp. ___ 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 Thu, 2011-04-28 at 18:38 -0400, Colin Walters wrote: On Wed, Apr 20, 2011 at 7:12 PM, Colin Walters walt...@verbum.org wrote: == 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*. Actually I've been thinking about this more, and I am changing my mind; if we don't have an immediate plan for making JavaScript more compelling, and there's still active people maintaining Python, we should be advertising the latter, and not the former. So here's what I propose (and I'm willing to write patches, but mostly this is just marketing/messaging): * Officially mark both gjs and seed as experimental (this is the reality as it is for 3.0 anyways) * Drop all consumers of seed in GNOME 3.2; rewrite them (this is just gnome-games/lightsoff?) using C/Vala/gtkmm/Python * Remove /usr/bin/gjs * Keep gnome-shell on gjs (but switch to using Spidermonkey 1.8.5, and no - porting to Python would be a pointless waste of time at best) What does this mean about the JavaScript future? My take here is that for 3.2 at least, we could move it more towards being an embedding language, designed from the very start to be used in a split C/JS role. Also, this allows us flexibility to evolve JavaScript and return later with something more interesting. For example, a combined WebKit-with-arbitrary-gnome-JavaScript that I've seen at least two different attempts at. I think that GNOME has the aspiration of being a multilanguage platform since its conception. We should keep in mind that allowing access to C objects from other languages was one of the major design goals. The latest addition of Vala and Javascript to our language toolset is very convenient because it makes easier to develop specifically for our platform. However, we should keep working on making all our API is fully accessible (GObject Introspection is big step in this direction) and help programmers to use it right using other popular languages. That said, I think Javascript and CSS-styling styling is very good move because it gives the impression of adopting web standards in the desktop. Cheers, -- Juanjo Marin ___ 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 Sat, 2011-04-30 at 02:28 +1200, John Stowers wrote: String handling and containers are sort of limited lowlevel things though. I don't think anyone has a problem with using the language native versions of these. Especially since the gnome platform story on these are quite weak. However, a platform like pyton is much richer. It contains many things that directly conflicts with our platform. Config APIs (gsettings), http support (soup), file handling and streams (gio), ssl support (glib-networking), etc. Isn't there even talk about a native python widget toolkit? I don't think that is fair. I'm happy that I was able to do all these things using the python standard library while waiting for the GNOME libraries to catch up. Now that we have gio,gsettings,soup,json etc (and g-i support) I will use them instead. Almost every language lets you shoot yourself in the foot in a myriad of ways but if the argument is that pythons failing - 'you might mistakenly choose to use non/incompatible GNOME libraries' is bad, then I think that is a weak argument. Note here, I'm not saying its a failure of python that they have a great library stack. In fact, that is imho the major feature of python (more important than say syntax or object model). However, that doesn't necessarily mean that python is a great choice to make as the default language for the gnome stack, as that major feature is then sorta in conflict with the goal of gnome (to make its own platform stack). This is even more true in the case where you're doing a C core + JS ui logic kind of app, then you're not really gonna call into *any* library stack stuff, but just into the app classes (and say gtk/clutter), so the availibility of more libraries are not really very useful, even if they were fully compatible with the gnome stack. ___ 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 Wed, Apr 20, 2011 at 7:12 PM, Colin Walters walt...@verbum.org wrote: == 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*. Actually I've been thinking about this more, and I am changing my mind; if we don't have an immediate plan for making JavaScript more compelling, and there's still active people maintaining Python, we should be advertising the latter, and not the former. So here's what I propose (and I'm willing to write patches, but mostly this is just marketing/messaging): * Officially mark both gjs and seed as experimental (this is the reality as it is for 3.0 anyways) * Drop all consumers of seed in GNOME 3.2; rewrite them (this is just gnome-games/lightsoff?) using C/Vala/gtkmm/Python * Remove /usr/bin/gjs * Keep gnome-shell on gjs (but switch to using Spidermonkey 1.8.5, and no - porting to Python would be a pointless waste of time at best) What does this mean about the JavaScript future? My take here is that for 3.2 at least, we could move it more towards being an embedding language, designed from the very start to be used in a split C/JS role. Also, this allows us flexibility to evolve JavaScript and return later with something more interesting. For example, a combined WebKit-with-arbitrary-gnome-JavaScript that I've seen at least two different attempts at. Thoughts? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.2: gjs/seed, QML?
On 04/21/2011 02:12 AM, Colin Walters wrote: == Dynamic Languages in GNOME == One thing that's worth addressing though (again) is the question do we need both Python and JavaScript?. IMHO, no. Which doesn't mean that one of the two must die; but I don't see much benefit in spending energy on two language bindings, when at the end they are pretty much equivalent when it comes to making a programmer's life easier/different. Javascript doesn't bring any greater advantages to an application developer over Python; it's just a different language, with more immature bindings. What would be more beneficial (again IMHO) is to invest our energies on something like QML [0]. A GNOME implementation of QML would be simply rocking. :-) Over the past few months/years I've seen some blog posts from highly skilled and respected developers from the GNOME world who were (skeptically) wondering what's so cool about QML, and comparing it with introspectable Gtk+/Clutter/Clutterscript/Cluttersmith and/or Javascript. Well, if you still think the same, you are off track, by a large distance. Just a quick glance to the wikipedia page for QML [0], or to some of the examples provided with Qt documentation [1] should be enough to give an idea of the differences between QML and imperative programming languages. True, QML uses Javascript, but it's far more than that, it's the concept which is totally different. I believe that a QML-like engine would be extremely beneficial for GNOME; just think of the possibility of creating completely different UIs for desktop and tablets/touchscreens, or 2D and 3D UIs [2] according to the host system hardware capabilities and screen size. And themes could be just different QML skins. I want to make it clear that I don't want to detract from Python (which I love) or Javascript; but you won't change application developers' life much with just a different language that you use in the same way; surely, you can save typing a few characters here and there, but at the end it's still the same old stuff. I personally know some developers who are rather unproductive with traditional languages, but who can build great applications in little time with QML; this is also something to consider, because it could mean widening the GNOME developers community. Just my two cents. Actually, not mine even. :-) Ciao, Alberto [0]: http://en.wikipedia.org/wiki/QML [1]: http://doc.qt.nokia.com/4.7-snapshot/qdeclarativeexamples.html [2]: http://labs.qt.nokia.com/2011/03/22/the-convenient-power-of-qml-scene-graph/ -- http://blog.mardy.it - geek in un lingua international! ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.2: gjs/seed, QML?
hi; On 25 April 2011 12:28, Alberto Mardegan ma...@users.sourceforge.net wrote: On 04/21/2011 02:12 AM, Colin Walters wrote: == Dynamic Languages in GNOME == One thing that's worth addressing though (again) is the question do we need both Python and JavaScript?. IMHO, no. Which doesn't mean that one of the two must die; but I don't see much benefit in spending energy on two language bindings, when at the end they are pretty much equivalent when it comes to making a programmer's life easier/different. Javascript doesn't bring any greater advantages to an application developer over Python; it's just a different language, with more immature bindings. What would be more beneficial (again IMHO) is to invest our energies on something like QML [0]. no, I actually think it would be detrimental to GNOME. QML is the wrong answer to a badly posed question. if we want declarative UIs then we shouldn't look further away than a web rendering engine, HTML5 and JavaScript, and exposing the GNOME platform through ad hoc JS APIs. A GNOME implementation of QML would be simply rocking. :-) I don't believe it would. Over the past few months/years I've seen some blog posts from highly skilled and respected developers from the GNOME world who were (skeptically) wondering what's so cool about QML, and comparing it with introspectable Gtk+/Clutter/Clutterscript/Cluttersmith and/or Javascript. Well, if you still think the same, you are off track, by a large distance. forgive me for being blunt, but: QML is a badly designed JSON-look-alike with JavaScript evaluated on every right-hand-side definition, and it requires dropping into C++ and Qt if you want to have reasonable performance and decent logic abstraction to avoid the write once, throw away immediately after syndrome. the only thing going for it is a half-decent IDE that doesn't make you gouge your eyes out with rusty spork. I tried QML, talked to people using it daily, saw real-world usage of it, and even talked to its creators - and I am constantly amazed how somebody could ever think that conflating UI description and logic into the same ad hoc, barely specified language was a good idea. let's not follow this trainwreck, please. ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.2: gjs/seed, QML?
Hi, On 04/25/2011 04:20 PM, Emmanuele Bassi wrote: [...] if we want declarative UIs then we shouldn't look further away than a web rendering engine, HTML5 and JavaScript, and exposing the GNOME platform through ad hoc JS APIs. This is also a viable way indeed. Though my gut feeling, and some concrete tests [0], hints me that performance-wise the way might be steep for HTML5. [...] QML is a badly designed JSON-look-alike with JavaScript evaluated on every right-hand-side definition, and it requires dropping into C++ and Qt if you want to have reasonable performance and decent logic abstraction to avoid the write once, throw away immediately after syndrome. Indeed, but you'll have to drop into the native code for any declarative UI language. [...] I tried QML, talked to people using it daily, saw real-world usage of it, and even talked to its creators - and I am constantly amazed how somebody could ever think that conflating UI description and logic into the same ad hoc, barely specified language was a good idea. I believe it's part of its strength, instead. I've seen way too many times developers having to change/hack their code to produce a cool effect (or just a layout) that the UI designer wanted so badly, but that the theming engine was unable to deliver. And it's not also about theming; sometimes you want to use a completely different widget, a different animation, a slightly different UI behaviour that cannot be achieved by just changing the application style. At the end, despite having separate theme files (CSS or other), changing a UI in a non trivial way often requires changing the code. And I'm not talking about migrating a desktop UI to a tablet or to a mobile device (even if indeed I believe that the reasoning applies here much more strongly), but at least according to my experience with Nokia UIs (Gtk, Hildon and then MeeGoTouch), the fantasy of UI designers has always surpassed the capabilities of the theming engine. Anyway, be it a QML-like or a HTML5 based language, I believe that GNOME needs a declarative UI engine. Application logic (unless it's really trivial) should still be coded in a native language, with bindings that allow the objects to be used from the UI layer. As I see it, a successful UI language should allow one to: - design the UI, statically - design all the UI interactions - design the animations - allow for easy themability - allow for simple code snippets, which for example could be used for field validation - facilitate code reuse - write the application core in one's favourite language, and provide for different skins (which is more than a theme, as they could contain totally different UI flows) to be used in different contexts: GNOME desktop, KDE, touchscreen device, small screen device, etc. So, not just the theming, but also the fact whether a control should be a switch or a checkbox, and even whether it should be not shown at all, all these are parts I consider to be UI and I'd like them to be modifiable without rewriting my application's code. IMHO QML can do this quite effectively; but then, I'm not claiming it's the only one (it's just the one I'm more familiar with). Ciao, Alberto [0]: http://www.qiliang.net/blog/wp-content/uploads/2010/09/HTML5_QML_Comparison_redist.pdf -- http://blog.mardy.it - geek in un lingua international! ___ 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 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: 3.2: gjs/seed
On Wed, Apr 20, 2011 at 4:12 PM, Colin Walters walt...@verbum.org wrote: There are, however, nontrivial issues. First is that actually in good news on the gjs front, a standalone Spidermonkey release was just made recently, and I have a patch ready to use it in gjs: https://bugzilla.gnome.org/show_bug.cgi?id=646369 In contrast though, /usr/bin/seed appears to actually link to WebKit, which would be a painful dependency to have for gnome-shell, since it'd be insane to try using it inside the compositor process. This may (hopefully) be fixable. There's no particular reason for this, we just never got around to untangle them. If there's increased interest in having them as separate libraries we can have it as one of the goals for WebKitGTK+ 1.6, which should be released in time for GNOME 3.2 (of course the actual separation would likely happen a lot earlier in some 1.5.x release). Cheers, Xan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.2: gjs/seed
Le mercredi 20 avril 2011, à 19:12 -0400, Colin Walters a écrit : One thing that's worth addressing though (again) is the question do we need both Python and JavaScript?. Why do we need to address this? Aren't we happy letting developers choose the language they are the most comfortable with? Vincent -- Les gens heureux ne sont pas pressés. ___ 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 21/04/11 01:12, Colin Walters wrote: There are, however, nontrivial issues. First is that actually in good news on the gjs front, a standalone Spidermonkey release was just made recently, and I have a patch ready to use it in gjs: https://bugzilla.gnome.org/show_bug.cgi?id=646369 In contrast though, /usr/bin/seed appears to actually link to WebKit, which would be a painful dependency to have for gnome-shell, since it'd be insane to try using it inside the compositor process. This may (hopefully) be fixable. It is, we just need to get JSC splitted as a standalone library: https://bugs.webkit.org/show_bug.cgi?id=19428 Cheers, Emilio ___ 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 Wed, 2011-04-20 at 19:12 -0400, Colin Walters wrote: 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. While I see this point when using a scripting language for a component like the shell, for applications this is the opposite: having a rich set of libraries ready to be used makes it possible to quickly come up with interesting plugins and features for applications without having to reinvent the wheel. Ciao Paolo ___ 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 Wed, 2011-04-20 at 19:12 -0400, Colin Walters wrote: and for 6) I think we need to change this anyways. This leaves reason Speaking as user of epiphany on webkit - it is now terribly broken. Certificate handling is broken since 2009 (1.5 years now) which is security bug as it allows to social engineer users easier (not mention the poison DNS attach etc.). Bug 594856. 4) which I admit is just a feeling. How largely should it affect decisions given both are FLOSS? 7) Embedding Mozilla engine stopped being supported. 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. I cannot speak for the gjs/seed as I don't know its inner architecture but not every application Regards signature.asc Description: This is a digitally signed message part ___ 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 Thu, 2011-04-21 at 10:38 +0200, Maciej Piechotka wrote: 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. I cannot speak for the gjs/seed as I don't know its inner architecture but not every application Regards Please ignore last paragraph. Regards signature.asc Description: This is a digitally signed message part ___ 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 Thu, Apr 21, 2011 at 01:12, Colin Walters walt...@verbum.org wrote: == 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. I share the spirit of that argument, but have to say that in my experience (developing and maintaining a GNOME-based desktop written in python for a few years) that won't make that big a difference in the longer run. Specially if application authors have to resort to C so often as in gnome-shell, how can we prevent them from using POSIX stuff that conflicts with glib? All things considered, I think we shouldn't try to do more than advise people to stick with glib as much as they can. And of course, make sure that the glib API is fully accessible to interpreted languages (right now, it's not). Then there's what Paolo said, there are lots of high-level code for python and others that doesn't and won't conflict with any existing GNOME stuff and that allows people to do awesome stuff. Writing a replacement in C/GObject enriches our platform but also limits application authors a lot. Regards, Tomeu ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.2: gjs/seed
7) Embedding Mozilla engine stopped being supported. I do think reason 7 is a big one, although you will need to split webkit into part, separate JSC from the rest. Erick -- El derecho de expresar nuestros pensamientos tiene algún significado tan sólo si somos capaces de tener pensamientos propios. El miedo a la libertad, Erich Fromm ___ 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 04/20/2011 07:12 PM, Colin Walters wrote: 4) While I know some GNOME contributors here don't like Mozilla, in the big picture their mission and culture is *MUCH* more aligned with ours than Apple, at least But: (a) WebKit is probably the least Apple-like thing that Apple does (b) It is heavily driven by Google as well, and while that may not be a whole lot better culture-wise, it means that: (c) WebKit's mission is more or less the *intersection* of Apple's and Google's missions, which often (though not always) ends up being pretty close to Mozilla's mission (the open web). 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. The flip side of this is that if we fall back to stock javascript, we can start using jslint. 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. This is at least in part because of the gjs-vs-seed confusion, and in part because the-GNOME-platform-via-gobject-introspection is still not as full-featured as the various python libraries, although it's getting better (as g-i improves, and as libraries improve their bindability). -- Dan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.2: gjs/seed
Just a small correction here. On Thu, Apr 21, 2011 at 2:08 PM, Maciej Piechotka uzytkown...@gmail.com wrote: 7) Embedding Mozilla engine stopped being supported. https://lwn.net/Articles/436440/ https://lwn.net/Articles/436461/ = mozjs embedding is still supported -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team ___ 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 Thu, 2011-04-21 at 18:31 +0530, Nirbheek Chauhan wrote: Just a small correction here. On Thu, Apr 21, 2011 at 2:08 PM, Maciej Piechotka uzytkown...@gmail.com wrote: 7) Embedding Mozilla engine stopped being supported. https://lwn.net/Articles/436440/ https://lwn.net/Articles/436461/ = mozjs embedding is still supported I meant of course mozembed not spidermonkey. But it itself is somehow worrisome - at least at the level 'we are more culturally aligned with Mozilla then Apple'. Regards signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.2: gjs/seed
Hi, On Thu, Apr 21, 2011 at 3:26 AM, Xan Lopez x...@gnome.org wrote: There's no particular reason for this, we just never got around to untangle them. If there's increased interest in having them as separate libraries we can have it as one of the goals for WebKitGTK+ 1.6, which should be released in time for GNOME 3.2 (of course the actual separation would likely happen a lot earlier in some 1.5.x release). Cool. It'd be nice to have this happen soon so we can evaluate things higher up the stack. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.2: gjs/seed
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 signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.2: gjs/seed
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. 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
Re: 3.2: gjs/seed
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). signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.2: gjs/seed
Hi, On Thu, Apr 21, 2011 at 1:12 AM, Colin Walters walt...@verbum.org wrote: 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. In this mail I just want to focus on the gjs/seed situation. Before 3.0 we chose to use gjs for gnome-shell for a variety of reasons: 1) gjs existed 2) seed didn't 3) Litl contributed a number of engineers to gjs 4) While I know some GNOME contributors here don't like Mozilla, in the big picture their mission and culture is *MUCH* more aligned with ours than Apple, at least 5) The Spidermonkey-specific JavaScript extensions like const and let were useful and cool 6) Many GNOME consumers actually ship Firefox and not Epiphany, and so we were technically aligned on that end (yes, this is the GNOME is a bucket of parts mindset, which I would really like to fix, but that's a separate issue) 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). There are, however, nontrivial issues. First is that actually in good news on the gjs front, a standalone Spidermonkey release was just made recently, and I have a patch ready to use it in gjs: https://bugzilla.gnome.org/show_bug.cgi?id=646369 In contrast though, /usr/bin/seed appears to actually link to WebKit, which would be a painful dependency to have for gnome-shell, since it'd be insane to try using it inside the compositor process. This may (hopefully) be fixable. 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. 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? From my personal (developer using seed) point of view, I think the important point is to have one blessed javascript-gi glue. I am using Seed to add Javascript support to Evince, so it would be good to know that Seed is going to be revamped or deprecated so I can use gjs instead. 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. 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. I understand your point, but I don't think this implies that we don't (at least for me) python. What we really need IMO is good documentation on how to write good Python Gnome Apps, by pointing out the recommendations, like, use GIO instead of python IO, etc. The dev is free to mix code in weird ways, no? 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 (No, unlike what you've read in some parts of the internets, a reason to add JavaScript wasn't to attract web developers explicitly; but they are part of the industry) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org
