Module proposal: Gjs
I'm having mail delivery from desktop-devel disabled, so please include me in the cc. Purpose: Gjs a language binding for Spidermonkey, the original JavaScript engine. It provides access to GObject based libraries such as Gtk+, Clutter and GStreamer though gobject-introspection and it also contains native bindings for cairo and dbus, Gjs is currently being used by GNOME Shell and that's why it's proposed here. Target: Desktop Release Set Dependencies: spidermonkey: JavaScript engine used by firefox thunderbird. gobject-introspection: Will either be proposed as a desktop release set module or used as an external dependency cairo: already an external dependency dbus: ditto Spidermonkey is a part of the xulrunner platform which is packaged by most distributions shipping GNOME. In the current situation it means that to be able to build Gjs on one of the distributions you would have to install a large part of firefox. This is the main way Mozilla supports Spidermonkey as there are no recent (~12 months) tarballs released, users of Spidermonkey are encouraged to stick by a specific version by forking it. [citation needed] In short-term Spidermonkey will depend on xulrunner, in the future it'll be made to work on top of the occasional standalone tarballs released by Mozilla. Resource usage: tarballs: http://ftp.gnome.org/pub/GNOME/sources/gjs/ source control: git://git.gnome.org/gjs bugzilla: http://bugzilla.gnome.org, gjs product Adoption: Gjs is a dependency of GNOME Shell for which packages exist for most major Linux distributions; since GNOME Shell has not yet had a stable release, no distribution is shipping it by default. GNOME-ness, community: Gjs was originally developed by litl LLC for it's client user interfaces, it has since been picked up by GNOME shell and is slowly being picked up by others. Development of Gjs happens openly and there has been 17 people commiting (8 outside of litl). Other notes: Gjs vs Seed or in extensions Gecko/Xulrunner vs WebKit is not going be a productive discussion. Both seed and gjs has their strengths and merits. Gjs is a mature binding, which is used in production, shipped software (see http://litl.com), a refusal to accept Gjs would force the GNOME Shell team to rewrite its javascript parts to run on top of Seed would not be very productive at this point. I strongly encourage tempted list members to avoid that discussion for reasons mentioned above. -- Johan Dahlin ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
JavaScript engines
We need to have this discussion sooner or later, seems like sooner is now required as Robert proposed to have Seed included in Gnome. First of all, I think most of us agrees that it would be a mistake to depend on two different JavaScript bindings in GNOME, we need to chose one and stick to that one. What we currently have are the following two engines: * Gjs - binding for Spidermonkey, part of Gecko/Mozilla * Seed - binding for JSCore, part of Webkit/Apple Before attempting to list the different reasons for using one over the other we need to decide what are the requirements for an engine using JavaScript. For instance, points such as: - External dependencies - Interpretor implementation language - Memory usage - Speed - APIs (Extending Embedding) - Documentation - License - Feature completeness - API stability (both in JS engine bindings) - JavaScript language extensions Would be useful to help out in this discussion. [Note: I have contributed patches to Gjs] Johan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New Module Proposal: libseed
[Robert and list moderators: I sent a copy from another mail address, please ignore that mail and reply to this] Robert Carr wrote: I was not planning to do this until .28, however a nice Clutter game written in Seed was merged in to gnome-games today, and there is some interest in being able to include this in .26. I would like to propose Seed (http://live.gnome.org/Seed) as a beta -bindings module for .26 For those not following, Seed is a set of bindings between WebKit's JavaScriptCore interpreter, and GObject (through GObject introspection). Seed provides a standalone interpreter, and a library with a clean API for embedding Seed as a scripting language. Through GOBject-introspection Seed automatically provides bindings to dozens of libraries, in a convenient fashion where individual bindings do not have to be maintained (but just the core library). Seed provides no platform of it's own (unlike say Python) and builds instead on the large GNOME platform, in a similar fashion to Vala. In short, Seed provides a way to write GNOME applications in JavaScript, and to easily embed JavaScript as an extension language in your application (similar to Guile, but perhaps more accessible, as JavaScript is often cited as the language with the most programmers). As a maintainer of gobject-introspection I'm strongly objecting inclusion of modules in GNOME using it at this point. gobject-introspection is currently not promising neither ABI or API stability, the best would be for application authors to wait until it's included in the platform, at which point it can be used in GNOME itself. It's just not ready to be included yet in my opinion. The Vala comparision is bogus as the generated .c code can be committed to svn and thus avoids any external dependencies. Depending on a library linking directly to libgirepository is a whole different matter. Johan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: JavaScript engines
Jason D. Clinton wrote: On Tue, Jan 6, 2009 at 9:12 AM, Johan Dahlin jo...@gnome.org wrote: We need to have this discussion sooner or later, seems like sooner is now required as Robert proposed to have Seed included in Gnome. First of all, I think most of us agrees that it would be a mistake to depend on two different JavaScript bindings in GNOME, we need to chose one and stick to that one. Actually, I do disagree. The JavaScript interpreter/JIT wars are just now heating up and its still way to early to call a winner. 2-3 years from now, there could be a distinct winner in the JS VM battle and it would be unfortunate if we picked the wrong horse, so to speak. I think we need to support bindings for both front-runners. After all, both implementations run the same language with the same syntax and they are *both* using the same underlying GObject bindings so the API's will be the same. The language is pretty different, SpiderMonkey supports quite a few /language/ extensions which JSCore doesn't.[1][2][3] I don't see any harm in using both for the short to medium term. What you're saying is essentially the same as saying that we should support more than one toolkit as well. Why don't we go ahead and support Qt next to Gtk in GNOME as well? My point is that you can write an application which supports both but it'll be a lot of extra work to little benefit. Using different JS engines for different applications can also be compared to toolkits. Can certainly be done, but will create similar inconsistencies. Engine 1 supports features A, B, C, but Engine 2 supports features D, E and F. People will just ask; No to mention trying to answer the obvious Which engine should I use in my application? question. Johan [1]: https://developer.mozilla.org/en/New_in_JavaScript_1.6 [2]: https://developer.mozilla.org/en/New_in_JavaScript_1.7 [3]: https://developer.mozilla.org/en/New_in_JavaScript_1.8 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: JavaScript engines
Jason D. Clinton wrote: On Tue, Jan 6, 2009 at 11:14 AM, Johan Dahlin jo...@gnome.org wrote: The language is pretty different, SpiderMonkey supports quite a few /language/ extensions which JSCore doesn't.[1][2][3] s/doesn't./doesn't yet./g I don't think JSCore is going to implement all features present in Spidermonkey since they have a different use case. WebKit/JSCore uses javascript mainly to run scripts found on web pages. Spidermonkey is different as it's in addition to that is used to develop native applications (firefox, thunderbird etc). In other words, JSCore (V8 JScript etc) will reasonably only support what web pages actually uses. So sure, the language extensions present in Spidermonkey might eventually be supported in other engines, but /only/ if web pages actually start to use them. Anyway, what subset of JS that's going to be used in the newest and fanciest web pages seems like a less than ideal criteria to use to select a javascript engine for GNOME. Instead we should compare what's available, which will help developers to write great applications *today*. Johan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: DVCS
Zeeshan Ali Khattak wrote: Hi everyone! I remember that at GUADEC, we were seriously thinking about migrating to git but the decision was postponed on Mark Shuttleworth's request. It's been some months since that and we are still stuck with SVN. AFAIK both git and bazaar have very strong supporters in our community so the only way I see out of this is: 1. Get someone (known and trusted) to volunteer to set-up and maintain the repository. I think Olav likes bazaar so he would volunteer for that? 2. Assuming that we get volunteers for both the repository types, we simply vote amongst the top 50 contributers (i myself most probably don't count :)) +1 Lets not turn this into yet another bazaar vs. git war cause we already had plenty of that and nothing good comes out of that. Right, let's avoid that. No technical discussion in this thread please. Johan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: External Deps: Minimal Python dependency
Sebastian Pölsterl wrote: Vincent Untz schrieb: Le mardi 22 juillet 2008, à 17:56 +0200, Sebastian Pölsterl a écrit : Hi! As mentioned in [1] sqlite is a blessed external dependency now. I want to use sqlite for Deskbar-Applet, too. Because, Python 2.5 has a built-in sqlite module I suggest increasing the minimal version to 2.5 from currently 2.4.3 . Of course, Python 2.5 has more benefits [2]. [1]: http://mail.gnome.org/archives/desktop-devel-list/2008-July/msg00090.html [2]: http://docs.python.org/whatsnew/whatsnew25.html (heh, I should read ddl before replying to mails) So, I took a quick look at the second link. That's all cool, but can we get an overview of what is really useful in there for us? Vincent * Various speed improvements regarding re module, sets, unicode operations (substring, split, en-/decode) and handling exceptions [1]. I don't understand why optimizations is an argument in bumping the minimum required version. Sure, those who want to make their python program can upgrade, but is the intention really to tell users of 2.4 that they can't use it because we think it's too slow? * New ElementTree package for processing XML. It's easy to understand and fast. Available as an external module. * New hashlib package which supports previously unsupported SHA-224, SHA-256, SHA-384, and SHA-512. I bet this is not useful for any GNOME applications. * New ctypes package which lets you load libraries and calling functions in them. Available as an external module. Which leaves us with the 'with statement' as a new feature worthwhile to upgrade for. Is it worth telling users of RHEL5, Debian Etch etc that they can't use the GNOME release because you want to use the with statement in your code? Is it really that difficult to write code without using it? Johan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Using vala in GNOME
Gustavo J. A. M. Carneiro wrote: On Mon, 2008-06-30 at 15:07 +0100, Alberto Ruiz wrote: [..] Plus, CMake is getting more mature and stable and it already supports VisualStudio and XCode project files conversion, lack of proper extensibility being its only downside at the moment. Lack of extensibility, and use of another arcane custom made programming language (if we can call it that) for everything. No, CMake is not an answer. It is not significantly better than autotools to justify a switch to it IMHO. CMake *is* considerably better. Xcode/VisualStudio are killer features which alone would make a switch worth it. Can we please start to organize ourselves and try to move forward with switching to another build system? Proposal: - Decide features we need to do a migrate - Create a table of proposed build systems x features - Check the KDE build system migration and see what we can learn[1] - An obvious option will eventually appear - Start migrate some modules [1]: Tim has some notes on this: http://blogs.gnome.org/timj/2008/06/02/02062008-linuxtag-2008/ Johan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Using vala in GNOME
Jason D. Clinton wrote: On Mon, Jun 30, 2008 at 9:47 AM, Gustavo J. A. M. Carneiro [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: [..] I watched the CMake transition in KDE with interest. It was very painful for them. A search of Planet KDE for the word cmake will return no end of complaints about it. That should not be an argument against CMake as we have the chance to from their experiences before we start doing a migration. IMO, the only hope that we can get away from autofoo is the Quagmire effort. Quagmire would be another option to evaluate. Could you download it and check if it would meet the (still somewhat fuzzy) requirements described on the wiki page Alberto just required? Johan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: build system alternatives (Was: Using vala in GNOME)
Gustavo J. A. M. Carneiro wrote: On Tue, 2008-07-01 at 12:19 -0400, David Malcolm wrote: [..] Also, I find it funny that people that do not actually use either XCode or Visual Studio claim that supporting them is crucial. Again, I don't trust that judgement without proof (statistics). Now, I do know a few developers that use Visual Studio and can't live without it. But among GNOME developers I have serious doubts anyone uses one of those IDEs. Exactly because we don't have Visual Studio/XCode integration. But adding them we would increase the developers that would be able to contribute to GNOME significantly. How do you expect Mac/Windows developers to contribute to GNOME if they can't even build it in their environment? These arguments applies to the part of the stack that are usable outside of Linux/X11 which are not all of them. But we are starting to see more and more applications (Gimp, Evolution etc) that are ported to non-X11 platforms. From my point of view, Gtk+ the stack below dominates the platform. What they will use will eventually be propagated up in the upper part of the platform stack. The contribution barrier for GNOME is way to high as it is today, I'm merely trying to reduce it by allowing developers from other (as in non-unix) backgrounds be able to contribute. Johan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: build system alternatives (Was: Using vala in GNOME)
Colin Walters wrote: On Tue, 2008-07-01 at 16:02 -0300, Johan Dahlin wrote: The contribution barrier for GNOME is way to high as it is today, I'm merely trying to reduce it by allowing developers from other (as in non-unix) backgrounds be able to contribute. Strategically speaking, while I think it makes sense for GNOME to invest in the fundamentals (core GTK+ windowing, DBus) of running on non-freedesktop.org platforms[1], developer time is better spent pushing the free platform as a whole forward. Competing with Qt/Swing/Windows.Forms/XULRunner/AIR (Qt in particular) for this is a big project. Great success for me would be to have people chose GTK/GNOME technologies to develop cross-platform applications. I don't really see that as negative impact on the development of the GNOME platform, rather the opposite by helping it to be even more successful by deploying it on more systems. There are two different strategies of pursuing our agenda. Either using completely free systems or having free programs running on what is non-free systems below. Not completely unlike comparing the Top-down or Bottom-up kind of designs. Let's do both, trying all possible ways of making people use our software. So in this particular case, our target audience for GTK+ on Windows/OS X is experienced developers familiar with the free desktop stack who at least somewhat understand autotools, etc. My interest is mainly the GTK+ part of the stack, which should be considerably easier to support. I'm not talking about taking away developer time from already busy developers. Just widening the developer base and allowing more expertize to contribute to the platform. Johan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: PyGIO?
Matteo Settenvini wrote: Hi everybody, does anyone have any news on some PyGIO bindings? They should complement the PyGtk and PyGObject stack, but googling for it didn't bring up any result. There's the beginning of python bindings for GIO in PyGObject SVN (trunk), but be aware as they arefar from finished Any kind of contribution is greatly appreciated! Johan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moving gnome-vfs to to-be-deprecated part of our platform
Vincent Untz wrote: Hi, Since we now have gio, I guess everybody agrees that we can move gnome-vfs (and gnome-mime-data, which is a dependency for gnome-vfs) to the to-be-deprecated part of our platform. To make it clear, it means we're still shipping gnome-vfs in our platform. It's just a way to tell people: you shouldn't use this in new applications. I'm also wondering about libglade, since we now have GtkBuilder. Should it be moved there too? Maybe. There's no support for saving to the GtkBuilder format in glade-3. While there is a script to convert from what glade-3 outputs, there might be better to wait until glade-3 supports it properly. Johan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moving gnome-vfs to to-be-deprecated part of our platform
Matthias Clasen wrote: On Jan 24, 2008 8:35 AM, Bastien Nocera [EMAIL PROTECTED] wrote: Maybe. There's no support for saving to the GtkBuilder format in glade-3. While there is a script to convert from what glade-3 outputs, there might be better to wait until glade-3 supports it properly. Same here. As an early adopter of GtkBuilder (in Totem), I think this is the single biggest reason to keep on using libglade unfortunately. The second biggest reason is that we don't have support for a11y properties in GtkBuilder yet. We really need to land that in the next GTK+ release, Johan... I will try to finish that tonight. It's mostly done, mainly testing and updating gtk-builder-convert left. Johan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: State of gvfs in Gnome 2.21
Sebastian Pölsterl wrote: Are there any plans for providing python bindings? In progress; http://svn.gnome.org/viewvc/pygobject/trunk/gio/ Unlikely to hit GNOME 2.22 though. Johan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Online Desktop and GNOME 2.22
Rui Tiago Cação Matos wrote: On Ter, 2007-10-30 at 17:10 -0400, Havoc Pennington wrote: (Though, I do think python is questionable for tray icons and daemons, since for whatever reason each python / pygtk process is so huge. Well, last I checked, the cpython implementation *never* releases memory back to the OS. This is why I can't really understand why so many things in gnome are done in python. I mean, check your rhythmbox before and after you load a python plugin. I really like python's philosophy and syntax but this memory use behavior continues to drive me away from it and from apps written in it. Anyway, yea, this is quite a tangent here. This changed in Python 2.5 which is now widely distributed. Johan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gtk_show_help and gtk_show_url
Havoc Pennington wrote: Hi, I had a random thought at the summit; what if we add a new library in the stack (perhaps shipping with GLib or GTK tarball, I don't know). Call it libgapplication. It would contain: - GApplication - GSettings - dbus main loop hooks - ... Session management? It would depend on GObject, dbus, gvfs, dconf but be below GDK, Cairo, and Pango (i.e. no graphics). Do we want to push other parts of what we have in GTK+ today down to that library? I guess this is a direct analog of libgnome, really. Maybe a bad idea; we can cram all this stuff elsewhere, either in GTK or in dbus or in gvfs. Not necessarily a bad idea, at least as long as a CORBA and Bonobo dependency can be avoided, which I hope is not planned. Johan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: MAINTAINERS in svn -- have it or no commit for you
Murray Cumming wrote: Could you please turn this off now? I can't commit to either libsigc++ (I emailed you about that already) or gconfmm. For instance: [EMAIL PROTECTED]:~/svn/gnome220/gconfmm$ more MAINTAINERS Murray Cumming E-mail: [EMAIL PROTECTED] Userid: murrayc It's in the wrong directory, it must be in the /trunk directory of your repository. I guess the administrator scripts are not compatible with the directory layout of gnomemm. Johan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [pygtk] Python 3.0 plans
Fernando San Martín Woerner wrote: El mié, 29-08-2007 a las 23:36 +0200, Andi Albrecht escribió: 2007/8/29, Johan Dahlin [EMAIL PROTECTED]: Hi Johan and all, in general I think it is a very good idea to port PyGTK to Python 3.x as soon as possible. The api must not be stable with the fist alpha release, but it need to be stable at least with one of the first betas. We'll have to port a bunch of things: First of all the bindings, but the examples and maybe the documentations too. On the other hand, please don't forget win32 port, for many developers are very relevant too! PyGTK is already ported and works fine under win32, the missing piece of the puzzle is binary distribution which is something neither GNOME or PyGTK traditionally are willing to do. Interested parties needs to step up and work on a solution. Most developers of PyGTK do not have access to a windows development environment. Johan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Python 3.0 plans
Behdad Esfahbod wrote: On Wed, 2007-08-29 at 12:37 -0300, Johan Dahlin wrote: Greetings Couple thoughts: - Do things more Pythonesque. Looking at Pango bindings, for example replace all to_string() methods with __str__. Same for compare(), equal(), etc. Or should it be in addition? This can already be done as it is, there's no need to break the API, it's just syntactic sugar. eg __str__ can be implemented to as to_string(). Is it actually worth the pain to remove the old names? Perhaps, I'm unsure. - Finish and use gobject-introspection. gobject-introspection isn't quite finished yet, but hopefully it'll be ready before Python 3.0 is finished. Johan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gtk+ API change; who should fix it? (A.k.a. Why isn't GNOME 2.19.4 released yet?)
Joseph Sacco wrote: The currently available version of pygtk is the stable branch. I would expect the development branchof pygtk to adapt. I'm ready to adapt but only if the general consent is that API changes are okay. My personal opinion is that the API shouldn't be allowed to change, once an API is added it should stay stable until the major version is bumped (3.0 in the case of gtk+). Johan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Glade 3.0 stable branched
Tristan Van Berkom wrote: Vincent Untz wrote: Le vendredi 29 septembre 2006, à 22:46, Tristan Van Berkom a écrit : to say do we want glade as part of some gnome module set ? any ideas on that ? Straight question: if we integrate an interface builder in GNOME, how can we choose between glade, gazpacho and stetic? I guess a reply on my behalf is called for here ;-) A few points I guess I'll raise in the favor of Glade; o Support for all widgets in gtk+ including depricated ones Depends on what supported means; GtkTreeView, GtkIconView friends are not really supported by glade. Nor by Gazpacho, Stetic or anything else... Johan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Glade 3.0 stable branched
Vincent Untz wrote: Le vendredi 29 septembre 2006, à 22:46, Tristan Van Berkom a écrit : to say do we want glade as part of some gnome module set ? any ideas on that ? Straight question: if we integrate an interface builder in GNOME, how can we choose between glade, gazpacho and stetic? I'd go for Glade3, since: * Gazpacho is not really developed these days and is until GtkBuilder has landed specific for Python. * Stetic is specific for Mono. Johan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Contribution
Maxim Udushlivy wrote: [..] I want to change GuiLoader license to LGPL and contribute Gideon and GuiLoader to Gnome. There's already a couple of ui designers for gnome, glade-2, glade-3, gazpacho, stetic. The GuiLoader in Gideon is also completely different from libglade and gtkbuilder which is going to be included in gtk+. I'm not sure I see the point of one more ui designer and one more ui loader... Johan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Deprecating Bug-Buddy versions before 2.16.0
Olav Vitters wrote: [ Please keep discussion (if any) in desktop-devel-list; not gnome-hackers that devel-announce-list might point to ] With the release of Bug-Buddy 2.16 I am going to deprecate the email interface used by older Bug-Buddy versions. It will still be supported for at least a year after bug-buddy has been released. After that the official support will be over. In practice this means that I will not add the email interface Bug-Buddy support to the first bugzilla.gnome.org after around Sep 2007. So it could be that the support goes on until 2010. Or that it ends on 10 Sep 2007. Of course, if there is a person really wanting to have the interface stay alive, then I'll gladly make them maintainer of the existing interface when 2.16.0 is out. Note that it has lots of issues (readability of the code being just one of them) and it is only reliable when bug-buddy mails to it. Plus it requires a Bugzilla part that needs changing every time Bugzilla is upgraded. I'd like to see it alive, at least until we can upgrade our bug submission process for Gazpacho. Is there a protocol specifications somewhere of the new interface bug-buddy uses? Johan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Gtk# in the bindings suite
* Should we include Gtk# in the Bindings suite? - short term - it hasn't been proposed for 2.16, but we could grandfather it in - the release management issues have largely been solved, aside from Gtk# not being split between Platform and Desktop (stable and unstable) APIs which is pretty important in terms of ISV/ISD communication and so on - bindings are a very important part of GNOME, and our value proposition - it seems that few people are concerned about Gtk# adopting the release process and other standards, then being included in our Bindings suite - a social/business/non-technical issue may persist regarding GNOME using or endorsing a Microsoft derived technology; some users/vendors may not appreciate that, to the point that they may choose to disassociate from the GNOME project (this shouldn't be dismissed out of hand) Definitely. They're already widely used and they seem to be mature enough to be included in the suite. I cannot se a reason why they shouldn't if they follow the bindings/platform stability rules and are prepared to follow the release schedule. Johan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Time to heat up the new module discussion
Jits on the desktop are usually bad not just because they do take more memory but also because you need the build system of mono installed which means more bloat. Considering that Gtk# applications consume less memory than PyGtk applications am puzzled by this blank statement. I'd be interested to see any numbers backing up that statement, otherwise I'm going to be as puzzled as you by blank statements. And no, I wouldn't actually count a Hello World like program as a very representative application. Johan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: First successful build on jhbuild.bxlug.be
Frederic Peters wrote: [posting to desktop-devel-list@ following Luis advice] Hello, 143 modules, not a single failure. I am quite happy to announce the first ever really complete and successful build published on jhbuild.bxlug.be; http://jhbuild.bxlug.be/builds/2006-05-25-0008/ Woho! Awesome, thanks a lot for making this work. Are there any tools available to get a notification when your module(s) break? And I wonder if we could arrange a policy to have a couple of build sheriffs that could contact maintainers and/or fix trivial breakage across the whole platform? Johan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: First successful build on jhbuild.bxlug.be
Bastien Nocera wrote: On Thu, 2006-05-25 at 12:21 -0300, Johan Dahlin wrote: Frederic Peters wrote: [posting to desktop-devel-list@ following Luis advice] Hello, 143 modules, not a single failure. I am quite happy to announce the first ever really complete and successful build published on jhbuild.bxlug.be; http://jhbuild.bxlug.be/builds/2006-05-25-0008/ Woho! Awesome, thanks a lot for making this work. Are there any tools available to get a notification when your module(s) break? Should be straight forward, especially now that MAINTAINERS files have been added to all the Desktop and Platform modules (or at least should have been added). It's somewhat problematic due to time zone differences. The question is how much we value a green tree. Should reverting code [for whatever reason] be accepted? I'd like to see some checks being run too, such as check or distcheck, which would make it even easier for people to catch errors. Johan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
PyGTK branched
PyGTK is branched for gtk-2.10, so it's open for feature additions again. I've updated jhbuild for gnome 2.12 and gnome 2.14 to use the 2.8 branch (called pygtk-2-8) -- Johan Dahlin [EMAIL PROTECTED] Async Open Source ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: autotools gives autopain
Nickolay V. Shmyrev wrote: В Сбт, 17/12/2005 в 15:03 +0800, Davyd Madeley пишет: On Fri, 2005-12-16 at 22:26 +, Andrew Sobala wrote: Sean D'Epagnier wrote: Isn't it true that scons requires you download and install it as an extra program to use it? Many users may not have scons and may not want to install it, but do want to install gnome (by compiling from source code). This is identical to the situation for autotools. Only to run autogen, not configure. --d You are probably not correct here Davyd, current gnome builds do require pkg-config to be installed. pkg-config is not tied to any specific build systems. If we were to switch to SCons it'll still be required. However, pkg-config provides a few macros to integrate nicely with autotools, these and quite a few other scripts needs to be rewritten for SCons. Johan Dahlin ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Python bindings
Alexander Larsson wrote: I've been convinced that proposing Sabayon for inclusion is the right thing to do. I'm also fully behind splitting it into an admin suite if it gets accepted. So, I hereby propose Sabayon for inclusion into the Gnome 2.14 Desktop. Information about sabayon is available at: http://www.gnome.org/projects/sabayon/ and an example screencast at: http://blogs.gnome.org/view/alexl/2005/11/07/0 Since sabayon required pygtk, gnome-python (gconf) and pyorbit (for the applet) do they need to be proposed for inclusion separately? Johan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
