Re: Time to heat up the new module discussion
Replying from off-list, pardon the break. At the encouragement of various important parties on #gnome-hackers, I am posting a copy of this from my blog in an effort to help focus the Pro/Con-Mono argument. I am not taking any side. This is only a summary. So, I spent two hours reading every email sent in April, May and July about including Mono as an official part of the GNOME platform and Tomboy as an official application of the Desktop. You might be thinking, Two hours is a lot of time to waste on this, but this argument is really, I think, one battle in the much larger war over whether JIT languages can be general use languages. Further, there are a lot of side issues which are complicating this. Now, first, let me summarize - as objectively as I can - the two sides of the Mono argument. I have some experience in both camps. As the gnome-games maintainer, I oversee the maintenance of lots of C applications (and one Scheme); some of them very hard to maintain. On the other hand, I have written several commercial GUI apps. in GTK# using both Glade# and Stetic. * Pro-Mono people are arguing: * Lots of cool applications and innovations are happening in the Mono camp. There's apps. like F-Spot, Tomboy, Beagle, and Banshee being written way faster than they could be in C. Anti-Mono folks generally agree but think that high level languages should only be used for prototyping (the benefits of RAD don't outweigh the cons). * ISV's and corporate environments will benefit from the Monodevelop tool and the general availability of more RAD tools on the GNOME platform. Anti-Mono folks generally agree but argue that being able to install these separately isn't a barrier to their use for this purpose. * Mono needs the GNOME endorsement of official inclusion to heal the community divisions over it. If we don't include Mono, the community will split further. Anti-Mono folks argue that - even if Mono is included - distributors like Mameo and RHEL are going to pick-and-choose the parts of GNOME that fit their requirements (official inclusion really doesn't mean much in the way of platform endorsement). * Python is there, so why not Mono? Anti-Mono folks argue that - in some ways (Deskbar) - including Python was a mistake. * Anti-Mono people are arguing: * Mono applications will use, generally, at least twice as much memory as an equivalent C application. In some cases more because of the overhead of the VM. If such an application were part of the panel, for instance, that would be a huge drain on memory and start-up times. Pro-Mono folks agree about the memory figure but argue that the pros outweigh the cons. Pro-Mono folks disagree about start-up times and also argue that users will have to choose to enable those panel applets. Also, deep in the thread Miguel pointed out that Mono apps. can be compiled AOT which would allow them to share the overhead in the same sense that shared libraries work in C. (I should also note that some Anti-Mono folks seems to have had bad experiences with Beagle running away with their RAM - especially on older systems.) * C#/Mono is a Microsoft invention and therefore it might be used as a weapon against GNOME. Pro-Mono folks point out that this has already been argued against many years ago and that the argument is closed. * Mono is just like Java and, despite Java existing for a decade, no compelling desktop applications exist that run on Java. This shows that JIT platforms are generally too slow. Pro-Mono folks point out that the freeness of Java has been a factor but, despite this, GCJ/Classpath is progressing and some counter examples are Eclipse and Azureus. * There is a general effort to decrease GNOME's footprint and including Mono would continue to undermine that effort. Pro-Mono folks argue that optimizations are good all around and that, again, the pros of rapid development outweigh the costs. Also, Pro-Mono folks point to Evolution as an example of a C program that is clearly a memory hog. SO, what is my opinion? Well, probably no one cares and I have to say that I don't know which
Re: Mono/GTK#/Tomboy
On Mon, 2006-07-17 at 10:12 -0400, JP Rosevear wrote: This is really just a packaging issue, on opensuse/SLED they are all individual packages (glib-sharp, gtk-sharp, etc). Not taking a side but I would like to point out that they are also separately packaged on Ubuntu and Debian-based distros. 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: Time to heat up the new module discussion
On Mon, 2006-07-17 at 13:48 +, Hubert Figuiere wrote: For those who don't believe me, have a look at your friends of KDE. They produce a huge amount of application written in C++ with Qt and sometime it looks like Gnome is really lagging behind. Too bad for us, we have a very good C++ framework called Gtkmm (Thanks Murray and al. for this), even if it is not even Just an observation: I have spent a great deal of time in the last 4 years hanging out on both GNOME and KDE's IRC channels and reading both Planets (once they existed). C++ is no silver bullet. In fact, KDE developers frequently complain about issues in C++ implementations (g++ stability) and design problems (templates come to mind). I think C and C++ both fall in to the same GCC-supported languages bucket (as a matter of classification for the purposes of this argument). 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: Time to heat up the new module discussion
On Mon, 2006-07-17 at 10:33 +0200, Andy Wingo wrote: On Sun, 2006-07-16 at 23:33 -0500, Jason D. Clinton wrote: Anti-Mono folks generally [...] think that high level languages should only be used for prototyping (the benefits of RAD don't outweigh the cons). Some people have said this, but I don't think all people uncomfortable with mono would agree. I should have replaced every occurrence of Pro-Mono folks with some people whom at some time in April, May or June argued for including Mono in GNOME in some way and Anti-Mono folks with some people whom at some point in April, May or June argued against including Mono in GNOME in someway ... but then it would have been impossible to read. I would like to remind them that gnome-games, long included by default on every Linux distribution, depends on Scheme (the guile bindings). AFAIU it only depends on guile, not the guile bindings to the gnome stack. Yes, you are correct. 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: Time to heat up the new module discussion
On Mon, 2006-07-17 at 08:23 +0200, Murray Cumming wrote: [snip] So, I spent two hours reading every email sent in April, May and July about including Mono as an official part of the GNOME platform That hasn't been proposed, as far as I know. It's been proposed for the Platform Bindings. Yea... I think that Jeff's upcoming email will attempt to define terms in the argument which should address your concerns. I admit that I can't keep them separate even after having read the entire thread history ... 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: Time to heat up the new module discussion
On Mon, 2006-07-17 at 07:55 +0200, David Nielsen wrote: søn, 16 07 2006 kl. 23:33 -0500, skrev Jason D. Clinton: While you provided a fine run down of arguments, I believe you forgot a vital one, Mono can be optimized, we can cut down ressource consumption, we can indeed do better - we cannot however make C development as fast development in C#, nor as fun. Twice the memory consumption is as I understand it not the lowest common denominator but rather the worst case under the new garbage collector - but nobody has provided hard numbers for the highly contested ressource use yet. This IS an interesting argument but this is the first time I have seen it. But, perhaps I missed it in my review; if I did, I appologize. It wasn't out of malice for Mono. 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: Time to heat up the new module discussion
On Mon, 2006-07-17 at 16:32 +0200, Murray Cumming wrote: I don't have concerns about this that need addressing. Gtk# has simply not been proposed for the Developer Platform during GNOME 2.15/2.16. So, I am seeking clarification, not trying to start something ... Are you saying that Tomboy cannot be considered for inclusion in 2.16 because the necessary step of proposing GTK# for official GNOME platform bindings inclusion has not taken place? Again, I am not trying to put words in your mouth. I just want to understand what's being said ... 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: focus! (was Re: Focusing on innovation re: mono, python et al)
On Tue, 2006-07-18 at 08:33 -0700, Rich Burridge wrote: Christian Fredrik Kalager Schaller wrote: I am not saying we shouldn't take good ideas etc., from Apple, but lets try to remember that Apple is basically a failure in the desktop market. What were you smoking when you wrote this? I don't think that your comment is very constructive or insightful. 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: Putting the 'Mono debate' back on the rails
On Sat, 2006-07-22 at 00:03 +1000, Jeff Waugh wrote: * Should applications built with anything in the Bindings suite be accepted into the Desktop suite? - short to medium term - do we want the central components of our software to potentially be written in five to ten different languages and/or runtimes/platforms? - this leads very neatly into the next question * Is it time to redefine the suites and/or 'franchise' the release process? - medium term - this is not just about new suites, it's about redefining the current Desktop suite by its integration interfaces and central components; we need to make current suites serve us better before kicking off new stuff - http://perkypants.org/blog/2005/05/19/1116533413/ (last few paras) - start slow: don't even create new suites to begin with, just make sure the small number of apps that want to adopt our process and standards right now can do so - new/further governance of suites can come later Regarding just the above two issues: What if there is a bilateral subdivision of the desktop suite which helps *distributors* distinguish between applications that support being compiled AOT (C, C++, Mono AOT, Java GCJ, D?) and applications that run JIT'd/VM'd (Mono JIT, Java JRE, Python, Ruby, Perl). It seems to me that, at least conceptually if not technically, the division between the two camps above is one of AOT/native compilation versus JIT/VM'd/interpreted compilation. Notice that both Java and Mono could be in either camp depending on how the project's Makefiles are written ... in both the Mono AOT and Java GCJ cases, libraries in use are shared between processes. Execution performance is also (generally) higher. It would be interesting to get Miguel's take on whether or not Mono AOT usage should be encouraged. In the Java GCJ case, it is encouraged for use by its authors. 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: bug-buddy support
On Fri, 2006-07-21 at 12:35 -0400, Matthias Clasen wrote: I noticed that bug-buddy refuses to file bugs against a number of core desktop applications (I just found yelp and evince). I think we should make an effort to ensure that all core desktop apps have the necessary information in their .desktop files by 2.16. I just noticed this as well. See bug #347679. Pardon my ignorance as I have just become the maintainer but, when did this change and what needs to be done? 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: Putting the 'Mono debate' back on the rails
On Fri, 2006-07-21 at 13:39 -0400, Ben Maurer wrote: I don't think this is an item worth dividing on. For languages like Mono (and Java with GCJ), the compile or JIT (for Mono) or interp (for GCJ) is purely a case-by-case performance decision. ... The statement that performance is generally higher isn't quite correct. However, it's completely besides the point for this discussion. ... Again, completely besides the point. The decision to AOT would be based on measurements. It doesn't address any of the issues in Jeff's email. Well I respectfully disagree and I find your statements that my statements don't address any issues raised by Jeff very puzzling as they were specifically influenced by the framing Jeff did in the issue directly above the two I quoted. Quoth Jeff: * Should Gtk#/Mono applications be accepted into the Desktop suite? ... - performance (memory and cpu) is a red herring here; we all *know* that ... - can we resolve the dissonance between delivering a coherent Desktop (a goal of the Desktop suite) and suggesting that vendors deliver multiple vm/language/binding/runtime platforms to satisfy it, and demand that users stomach it too? (this has also been raised as a performance issue) You are, of course, welcome to disagree with my suggestion. I have no idea if it's a good one or not but I thought it was worth bringing up. I think that inventivizing projects to push toward an AOT approach could be one way to help allay the people pounding their fists over the perceived performance of the desktop OOTB. 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: Putting the 'Mono debate' back on the rails
On Fri, 2006-07-21 at 14:20 -0400, Ben Maurer wrote: AOT is *not* always faster. There are lots of variables. For example, at JIT time, the compiler can make some assumptions that AOT can not (for example, if you have a static readonly field [static final in java], JITs can inline the constant value because it will never change. AOT can't do this because the value is computed in the static constructor). We're goin' way off topic. Let me point you back to me first email: the project's Makefiles are written ... in both the Mono AOT and Java GCJ cases, libraries in use are shared between processes. Execution The benefit of AOT that I am emphasizing here is shared libraries and the amount of memory which would be saved - especially in the Java case. Any gains (or not) in execution speed would just be a nice side effect. 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: Bug buddy maintainer? (Was Re: bug-buddy support)
On Fri, 2006-07-21 at 21:06 +0200, Fernando Herrera wrote: Anyway, I did my best to get new bug-buddy interface and internal ready for 2.16, after the great work from Olav in bugzilla.gnome.org and lot of help from Brent. I am sorry about breaking the command line interface that yelp and other applications were using (it's a developer release!) and will try to fix it ASAP. Of course, any help with bug-buddy (as with any other module in GNOME) is very welcome. Besides the command line changes, what else must be done? 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: Bug buddy maintainer? (Was Re: bug-buddy support)
On Fri, 2006-07-21 at 15:20 -0400, Matthias Clasen wrote: You need to add something to the .desktop file to convince bug-buddy to consider your app. Check out a desktop file of an app that bug-buddy does recognize for the details. I do appreciate your help but I was hoping for something a little more definitive. What is it? Which parts are mandatory? Optional? How long has it been there? Is it going to change again? Does it need to be translated? 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
[Fwd: Re: Bug buddy maintainer? (Was Re: bug-buddy support)]
Here is the information everyone needs. Apparently mistakenly sent only to me. ---BeginMessage--- Hi, On 7/21/06, Jason D. Clinton [EMAIL PROTECTED] wrote: I do appreciate your help but I was hoping for something a little more definitive. What is it? Metainformation about the application used to report bugs on out BTS Which parts are mandatory? Optional? X-GNOME-Bugzilla-Bugzilla=GNOME -- Mandatory X-GNOME-Bugzilla-Product=XXX --Mandatory X-GNOME-Bugzilla-Component=YYY -- Mandatory X-GNOME-Bugzilla-OtherBinaries=ZZZ -- Optional, only if you application has several binaries X-GNOME-Bugzilla-Version=X.Y.Z -- Optional, and should need expansion from configure script, so if you want this you need a application.desktop.in.in to expand here @VERSION@ (application.desktop.in is used by intltool for translations). How long has it been there? circa 2002 Is it going to change again? No and yes. If you refer at the field names, they haven't changed since 2002 (X-GNOME-Bugzilla-Version was added on 2003). If you mean the values, bugzilla product/component could be changed if the maintainer ask the bugmaster to do it and should update the info in the desktop file after the change. As I mentioned on a previous email, afer this product/component renaming would break any old instalation of the application for submiting bugs, but we are working on a server side fallback to solve it. Does it need to be translated? Hope this helps. Salu2 ---End Message--- 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: dbus building pains
On Mon, 2006-07-24 at 16:07 -0400, John (J5) Palmieri wrote: The system bus (=0.90) needs to be running and accessible by the build. We need to remove this dependency in the future. The quick fix is to build outside of jhbuild and copy the dbus-bus-introspect.xml into the tools directory in D-Bus's jhbuild build root. I have placed the needed .xml file at http://jasonclinton.com/ - hopefully that will help others whom are stuck. 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: Deskbar Applet, NewStuffManager, 2.16, Installing New Plug-Ins, AutoUpdate, etc.
On Mon, 2006-07-31 at 01:06 +1000, Nigel Tao wrote: thingy people have implemented, aiming for the 2.16 release timeframe. So are you asking for official inclusion of this for 2.16? 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: Deskbar Applet, NewStuffManager, 2.16, Installing New Plug-Ins, AutoUpdate, etc.
On Wed, 2006-08-02 at 18:31 +0100, Mike Hearn wrote: Is it really that hard to check a digital signature? I'd have thought there'd be APIs in Python/C/Mono that make this trivial by now. And that's all you have to do to protect against the files are changed by evil people case. gpg has well documented exit codes which can be suitably used for this. It's not high performance to invoke lots of sub-processes if you have a lot of files you are verifying, but it get's the job done. 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: Common knowledge in jhbuild for funny modules
On Tue, 2006-08-08 at 18:55 -0600, Elijah Newren wrote: /me starts cheerleading federico on I don't know the answers, but the building-gnome nightmare is long overdue for discussion. ... Magnus Therning spent a similar amount of time recently, with the gory details archives on the gnome-love list. I totally agree with you. Most of the build issues are due to the fact that we allow dependencies on cvs versions of freedesktop.org modules. I'd like to propose that we move away from that, and just pick certain tarball versions to depend on at the beginning of a release; and require specific proposals to allow dependencies on newer tarball versions if issues come up. Thoughts? Comments? I would be very interesting in hearing the opinions of people like Josselin Mouette [EMAIL PROTECTED] who build new releases of GNOME for their respective distributions regularly. How do they keep up? What tricks are they using? Can we steal some of their ideas? 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
In search opinions on GNOME Games module games
The GNOME Games maintainers, Andreas and I, are planning to deprecate one GNOME Games game which is unpopular and difficult to maintain during the 2.18 release cycle and replace it with a more popular game with better, more maintainable code. To this end, we are seeking input from our users to decide which game to remove and also opinions on which game to include. This is also a PR opportunity - a way to directly involve end users in driving a very visible change to their desktops' features. So, we would like to get this message out as widely as possible. Feel free to post this on any forum or mailing list which has a majority of GNOME users on it. Users interested in participating in driving this decision can do so at: http://live.gnome.org/GnomeGames/NewGamesPlan 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: Getting a list of 2.18 new features
On Wednesday 08 November 2006 14:11, Andre Klapper wrote: okay, two weeks later, and which changes do i see?: info about the plans for pango (thanks behdad), control-center (thanks rodrigo), and gdm (thanks brian). now, where are the main applications? where are evolution, nautilus, epiphany, gtk+, totem? dear maintainers, you're part of the marketing. please deal with it, it will only take you 5 minutes and will help a lot. It seems to me that being able to easily build GNOME would go a long way towards people knowing where we stand as a community during our development cycles. How is the work on that coming along? -- Jason D. Clinton Something clever goes on this line. pgpHNEvZVcPBs.pgp Description: PGP signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: Empathy for GNOME 2.22
-1 Needless duplication of work covered by Pidgin and Ekiga (and, so far, done better). This is a reimplementation of the wheel. If the last two Gnome releases are any indication, we are strapped for resources - taking on new modules that add absolutely nothing features-wise but DO add additional maintenance work doesn't seem like a good idea ... for now ... Maybe in 2.24. On 9/23/07, Xavier Claessens [EMAIL PROTECTED] wrote: Hi, * Proposal: Include Empathy in GNOME 2.22 desktop. * Purpose: Empathy [1] consists of a rich set of reusable instant messaging widgets, and a GNOME client using those widgets. It uses Telepathy and Nokia's Mission Control, and reuses Gossip's UI. The main goal is to permit desktop integration by providing libempathy and libempathy-gtk libraries. libempathy-gtk is a set of powerful widgets that can be embeded into any GNOME application. * Dependencies: glib-2.0 = 2.14.0 gconf-2.0 = 1.2.0 libxml-2.0 gnome-vfs-2.0 libtelepathy = 0.0.57 libmissioncontrol = 4.33 gtk+-2.0 = 2.12.0 libglade-2.0 = 2.0.0 libgnomeui-2.0 libebook-1.2 libpanelapplet-2.0 = 2.10.0 * Resource usage: Already using GNOME FTP, GNOME SVN and GNOME bugzilla. * Adoption: It is packaged at least for debian, ubuntu, mandriva, gentoo and fedora. It is used by Intel for the moblin [2] platform. There is patches for Totem and nautilus-send-to [3] to make use of libempathy(-gtk). Someone was working on integration in gtetrinet but I don't know the status of that work. There is also an epiphany plugin [4]. Work was being done for GSoC to integrate Empathy into Jockosher [5]. Empathy is also used by Soylent [6]. * GNOME-ness: The community reports bugs in GNOME bugzilla and attach patches, I review and commit in GNOME's SVN. Some i18n teams already started to commit translations. I take care of usability thanks to loads of usability bugs opened by Vincent Untz. User documentation is not started yet, I guess we can pick gossip's doc and adapt it for Empathy since the UI is almost the same. * Miscellaneous: - There is patches to support File Transfer, Voice and Video. I think it will be ready before GNOME 2.22 feature freeze. - Empathy is still a young project with some bugs but I'm pretty sure we can fix them in time for GNOME 2.22. - At some point we'll have same features than Ekiga which is already in GNOME desktop. The big advantage of Empathy is it uses Telepathy framework which make easy for desktop integration and means we'll have VoIP for all protocols (SIP, MSN, Jabber, etc). Empathy supports all IM features (private chat, chatroom, presence, avatar, alias, etc), not only Voice and Video. Ekiga don't have those advantages. Thanks, Xavier Claessens. [1] http://live.gnome.org/Empathy [2] http://www.moblin.org/projects_chat.html [3] http://www.barisione.org/blog.html/p=100 [4] http://blog.senko.net/2007/07/19/emphatic-epiphany [5] http://blog.mikeasoft.com/2007/05/07/jokosher-soc [6] http://live.gnome.org/Soylent ___ 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: Module proposal: Empathy for GNOME 2.22
On 9/23/07, Ross Burton [EMAIL PROTECTED] wrote: On Sun, 2007-09-23 at 16:00 -0500, Jason D. Clinton wrote: Needless duplication of work covered by Pidgin and Ekiga (and, so far, done better). This is a reimplementation of the wheel. Empathy is a UI around an IM platform which totally replaces the single-application model of pidgin, ekiga, gossip and every other IM client. With Empathy I can go online when I login and using the same Jabber connection chat in Empathy, see presence in Evolution, and transfer files in nautilus. I'll be logged into the Jabber server once, and the connection is shared between them. Do these features exist yet or are we considering what Empathy could be at some theoretical point in the future? You talk as though we should evaluate Empathy's potential to replace Ekiga... how do the Ekiga developers feel about this? And can it actually deliver on this claim right now? My only issues with Empathy are stability and features, but I'm +100 for including Empathy in a future GNOME release. Oh, and Pidgen isn't part of GNOME. It's Pidgin and it's non-inclusion in Gnome is irrelevant. Every single distro ships it as the pre-installed IM client for a desktop install. For better or worse, it's the application filling the IM space at the moment and I don't mind saying that it does a damn good job at this. Why are we trying to compete with them? So what are we going to gain by including Empathy, other than more maintenance work in a Gnome Project that's strapped for developer time? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: Empathy for GNOME 2.22
On 9/23/07, Xavier Claessens [EMAIL PROTECTED] wrote: Le dimanche 23 septembre 2007 à 16:00 -0500, Jason D. Clinton a écrit : -1 Needless duplication of work covered by Pidgin and Ekiga (and, so far, done better). This is a reimplementation of the wheel. If the last two Gnome releases are any indication, we are strapped for resources - taking on new modules that add absolutely nothing features-wise but DO add additional maintenance work doesn't seem like a good idea ... for now ... Maybe in 2.24. I strongly disagree, Empathy do NOT reimplement the wheel! Empathy is not just an IM client like all others, it's an IM framework and is the only project that makes possible for other applications to integrate IM features. Isn't that exactly what libpurple is which you mention below (which is already stable and implemented)? I'm currently working on Voice+Video support so Empathy will be the first client to support that for SIP, Jabber, and MSN at some point. So why not wait until 2.24 when you have those features? For the additional maintenance problem Empathy and Telepathy framework is supported by companies like Collabora, Nokia, OLPC (RH) and Intel and some community guys are starting to submit patches too. And we can even use libpurple (from pidgin) in Empathy thanks to telepathy-haze. But why is this duplication occuring? Currently GNOME has no IM program at all, Ekiga does only voice and video AFAIK. See my other reply regarding Pidgin's de facto status as the Gnome desktop IM client. Why are you competing with them? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: Empathy for GNOME 2.22
On 9/23/07, Reinout van Schouwen [EMAIL PROTECTED] wrote: Op zondag 23-09-2007 om 16:00 uur [tijdzone -0500], schreef Jason D. Clinton: Needless duplication of work covered by Pidgin and Ekiga (and, so far, done better). This is a reimplementation of the wheel. Are you serious? Although I have my own gripes with Empathy[1], at least it tries to integrate with GNOME. Pidgin isn't part of GNOME in the first place, but moreover it doesn't even pretend to have any sort of GNOME integration, short from using GTK for its user interface. I'm completely serious. Pidgin integrates with Gnome (see Evolution contact sharing) and even correctly implements the notification icon that you fault Empathy for getting wrong. Have you actually tried using Pidgin? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: Empathy for GNOME 2.22
On 9/23/07, Olav Vitters [EMAIL PROTECTED] wrote: On Sun, Sep 23, 2007 at 04:56:34PM -0500, Jason D. Clinton wrote: It's Pidgin and it's non-inclusion in Gnome is irrelevant. Every single distro ships it as the pre-installed IM client for a desktop install. For better or worse, it's the application filling the IM space at the moment and I don't mind saying that it does a damn good job at this. Why are we trying to compete with them? Ehr, you seem to be arguing that people shouldn't start their own projects, but rather join an existing one. IMO you cannot dictate what people do with their time. People will write the same application 5 different times, then again when some new language comes out. Pidgin is just as welcome to propose themselves to be part of the GNOME project. Said developer is free to do whatever they want with their time. Said developer has asked for project resources to assist in his effort in a competing with an existing project that gives users exactly what they need, today. Are we going to help Empathy with it's effort to some day offer a point-for-point feature match? That's what we are discussing. I'm saying it's a bad idea right now. Let's revisit it when it actually has the features proposed. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: Empathy for GNOME 2.22
On 9/23/07, Olav Vitters [EMAIL PROTECTED] wrote: today. Are we going to help Empathy with it's effort to some day offer a point-for-point feature match? That's what we are discussing. I don't believe this is what is meant with joining the GNOME project. It is not that we do a 'oh, lets reassign some persons from $PROJECT to Empathy'. I agree with your statement about developer allocation. But that's not what I mean. Inclusion in the official Gnome suite adds a certain level of additional credibility to a project. And while this is always good for the project in question, in this case, we would publicly be encouraging the fragmentation of the de facto Gnome desktop IM space. Would the benefits of telepathy over libpurple outweigh the damage done to community coherancy? At this point, it seems that it would have a net negative effect on end user experience over the course of the next 2-3 years in the sense that two integratable IM projects would have competing teams of folks working on integrating said applications with the Gnome deskop applications. In practice, this means more work for module maintainers who have to accept patches from two different IM projects. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: Empathy for GNOME 2.22
On 9/23/07, Xavier Claessens [EMAIL PROTECTED] wrote: I'm pretty sure there is lots more developers working on the Telepathy stack than on pidgin, maybe it's the other way the fragmentation happens, pidgin developers should stop working on a dead project and contribute to Empathy/Telepathy? I would be very interested to see any evidence to back-up this claim. Such evidence would be enough to sway my opinion if Pidgin is dead as you claim. Or maybe everybody is free to work on the project he likes... We're discussing whether or not to include your project in Gnome, not whether or not you should be allow to develop what you will. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mercurial - Distributed SCM in Gnome (Was: Git vs SVN (was: Can we improve things?))
On 9/23/07, Sean Kelley [EMAIL PROTECTED] wrote: I think GIT is not a very user friendly SCM for those coming from other version control systems. It is far too rough around the edges. Will it get better? I am sure over time it will. But I certainly wouldn't impose it on the multitude of Gnome developers who have varying degress of SCM experience from the git go. :-) Garmin's massive one-way pulling of source from a ton of projects probably dosen't make for a good test case. There's a number of things about your situatation that are unique and won't apply to those of us maintaining modules. As I understand it from those I know on the inside, you're more-or-less forking what you deem to be stable snapshots of OSS libraries and maintaining your own company-local repositories that only Garmin developers use. The only merging your doing is taking patches from upstream and backporting them to the libraries you guys have decided to use for your hand helds... please correct me if I'm miss-informed. I'm a little skeptical that your experience will apply to anyone else (except perhaps Nokia and Motorola) based on what I know... ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: Empathy for GNOME 2.22
I read your message three time but I still can't figure out if you're for or against Empathy in Gnome. On 9/23/07, Andrew Cowie [EMAIL PROTECTED] wrote: On Sun, 2007-09-23 at 17:07 -0500, Jason D. Clinton wrote: See my other reply regarding Pidgin's de facto status as the Gnome desktop IM client. Being a part of GNOME is not just writing an app that happens to use GTK (and don't even talk about the evolution - great way to smash your addressbook). The fact that it is a successful, widely used program doesn't come into it. It's not a GNOME program (in all the meanings that that has, the least of which is has it actually been accepted into GNOME!) and doesn't want to be. So fine. If one or three other groups want to work on capabilities that _will_ integrate properly with the GNOME desktop and allow other apps to use it, then all the better. AfC Sydney -- Andrew Frederick Cowie We are an operations engineering consultancy focusing on strategy, organizational architecture, systems review, and change management procedures: enabling successful use of open source in mission critical enterprises, worldwide. http://www.operationaldynamics.com/ Sydney New York Toronto London ___ 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: Module proposal: Empathy for GNOME 2.22
You appear to have not read the thread. On 9/23/07, Travis Reitter [EMAIL PROTECTED] wrote: Jason, Motivation for unpaid Free Software development isn't the same as for commercial software. You can't just tell someone which project(s) they get to work on. They will work on which project(s) they think are most interesting and/or important or they'll choose to do something else with their time. Duplication of effort is frustrating, but that's just how this development model works. And it's important to note that Pidgin, Ekiga, and Empathy have different goals and implementations, so it's not like they're all trying to do literally the same things. Thus any perceived duplication of effort isn't as bad as it may seem. -Travis On Sun, 2007-09-23 at 16:00 -0500, Jason D. Clinton wrote: -1 Needless duplication of work covered by Pidgin and Ekiga (and, so far, done better). This is a reimplementation of the wheel. If the last two Gnome releases are any indication, we are strapped for resources - taking on new modules that add absolutely nothing features-wise but DO add additional maintenance work doesn't seem like a good idea ... for now ... Maybe in 2.24. On 9/23/07, Xavier Claessens [EMAIL PROTECTED] wrote: Hi, * Proposal: Include Empathy in GNOME 2.22 desktop. * Purpose: Empathy [1] consists of a rich set of reusable instant messaging widgets, and a GNOME client using those widgets. It uses Telepathy and Nokia's Mission Control, and reuses Gossip's UI. The main goal is to permit desktop integration by providing libempathy and libempathy-gtk libraries. libempathy-gtk is a set of powerful widgets that can be embeded into any GNOME application. * Dependencies: glib-2.0 = 2.14.0 gconf-2.0 = 1.2.0 libxml-2.0 gnome-vfs-2.0 libtelepathy = 0.0.57 libmissioncontrol = 4.33 gtk+-2.0 = 2.12.0 libglade-2.0 = 2.0.0 libgnomeui-2.0 libebook-1.2 libpanelapplet-2.0 = 2.10.0 * Resource usage: Already using GNOME FTP, GNOME SVN and GNOME bugzilla. * Adoption: It is packaged at least for debian, ubuntu, mandriva, gentoo and fedora. It is used by Intel for the moblin [2] platform. There is patches for Totem and nautilus-send-to [3] to make use of libempathy(-gtk). Someone was working on integration in gtetrinet but I don't know the status of that work. There is also an epiphany plugin [4]. Work was being done for GSoC to integrate Empathy into Jockosher [5]. Empathy is also used by Soylent [6]. * GNOME-ness: The community reports bugs in GNOME bugzilla and attach patches, I review and commit in GNOME's SVN. Some i18n teams already started to commit translations. I take care of usability thanks to loads of usability bugs opened by Vincent Untz. User documentation is not started yet, I guess we can pick gossip's doc and adapt it for Empathy since the UI is almost the same. * Miscellaneous: - There is patches to support File Transfer, Voice and Video. I think it will be ready before GNOME 2.22 feature freeze. - Empathy is still a young project with some bugs but I'm pretty sure we can fix them in time for GNOME 2.22. - At some point we'll have same features than Ekiga which is already in GNOME desktop. The big advantage of Empathy is it uses Telepathy framework which make easy for desktop integration and means we'll have VoIP for all protocols (SIP, MSN, Jabber, etc). Empathy supports all IM features (private chat, chatroom, presence, avatar, alias, etc), not only Voice and Video. Ekiga don't have those advantages. Thanks, Xavier Claessens. [1] http://live.gnome.org/Empathy [2] http://www.moblin.org/projects_chat.html [3] http://www.barisione.org/blog.html/p=100 [4] http://blog.senko.net/2007/07/19/emphatic-epiphany [5] http://blog.mikeasoft.com/2007/05/07/jokosher-soc [6] http://live.gnome.org/Soylent ___ 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: Module proposal: Empathy for GNOME 2.22
On 9/23/07, Alex Jones [EMAIL PROTECTED] wrote: Hi Xavier On Sun, 2007-09-23 at 23:19 +0200, Xavier Claessens wrote: Currently GNOME has no IM program at all, Ekiga does only voice andvideo AFAIK. Surely you haven't forgotten Gossip already. :P FWIW, I'm extremely keen on keeping Gossip going. I personally feel that Telepathy is potentially dangerous to our cause. I mean, great, you can voice-video chat with your MSN friends, but you still need an MSN account. One step forward, two steps back. I've been diving deeper in to the code involved here and the more I see the more I dislike. Xavier, it seems that you implemented gossip-telepathy and then forked Gossip to create Empathy? Can you provide some history for us please? What is going on here? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: Empathy for GNOME 2.22
On 9/23/07, Travis Reitter [EMAIL PROTECTED] wrote: I read the thread - I just responded in general. But let me get a little more specific: From my own perspective, I would describe the three competing applications as: Empathy is a general communications program based around Telepathy, and meant to be well-integrated into Gnome. ... The main benefit here is that Telepathy is a plugin-based general communications stack which has a lot of community and commercial support and in my (and many other peoples') opinion a well-designed framework which is increasingly polished and increasingly-relevant to Gnome. Because Empathy builds on Telepathy, instead of building its own silo, I don't think it's fair to call it a duplication of effort. And I'd say that the Empathy/Telepathy stack is certainly worth inclusion in Gnome when we all decide it's polished enough. I'm not against Telepathy per se. I'm not sure that Empathy is the right way to get it in to Gnome, though. At least at this moment. Let me summarize the concerns that I see so far: * It appears to be a fork of Gossip and intended to replace Gossip. The Gossip author has stated that Gossip is not dead. Gossip has telepathy support... * It appears to want to replace Ekiga. There appears to be no buy-in from Ekiga developers. * It appears to want to replace the default IM client installed in distros (Pidgin). * Poor documentation status (could be fixed) * It doesn't implement all of the features it lists as its benefits. (maybe could be fixed by 2.22 release) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: Empathy for GNOME 2.22
On 9/24/07, Jaap Haitsma [EMAIL PROTECTED] wrote: * It appears to want to replace Ekiga. There appears to be no buy-in from Ekiga developers. * It appears to want to replace the default IM client installed in distros (Pidgin). If the consensus is that empathy is better I don't see the problem if it would replace other applications. Evince for example replaced gpdf a couple of releases ago. Once again, the tired refrain: maybe someday but it doesn't appear that it can even come close with only 6 months remaining. Maybe it will be ready for 2.24. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: Empathy for GNOME 2.22
On 9/24/07, Peter Gordon [EMAIL PROTECTED] wrote: So? Distros are free to package and ship GNOME components however they see fit so long as they comply with any applicable copyright/trademark licensing. Unfortunately, as a good analogy, most tend to ship Firefox or Seamonkey as the default browser instead of Epiphany - Does this mean we should just stop hacking on Epiphany entirely? That would be far counterproductive to GNOME's goal of being a consistent, user-friendly desktop. The critical difference in that analogy is that the thousands and thousands of man-hours spent on Gecko are reused in the Gnome-ification called Epiphany. As Empathy is proposed, all the work in protocol implementation that has come before in the form of Ekiga and Pidgin appears to be thrown out the window. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: gio and gvfs for gnome 2.22?
On 9/24/07, Alexander Larsson [EMAIL PROTECTED] wrote: I've been working on gvfs and gio for a while, and its starting to reach some minimal level of maturity. As long as there is consensus on a path from gnome-vfs to gio+gvfs, I would like to see this in 2.22. Which module are you proposing? Platform? And how long will the transition from gnome-vfs be allowed? I'd like to hear from some of the powers that be; their opinions are really critical to whether this would succeed or fail. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New clock applet for 2.22
On 9/24/07, Matthias Clasen [EMAIL PROTECTED] wrote: Since everybody is making proposals for 2.22, here is my contribution: we should merge the clock applet with the intlclock that Novell has written. Why not include this in the existing gnome-panel module and avoid having two competing clock applets? It doesn't seem like creating a whole new module for these would be a good idea. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New clock applet for 2.22
On 9/24/07, Matthias Clasen [EMAIL PROTECTED] wrote: If you read my mail carefully (merge), that is exactly what is being proposed here. Two clock applets makes no sense at all, which is why we did not ship the intlclock in F8. Sorry, I thought you were asking for module proposal acceptance which is what period we are in now. Wouldn't it be up to the gnome-panel maintainer (Vincent Untz) what is and is not in his module? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed module: empathy
Since you're patronizing me, I'll return the favor. Let's start with the basic discussion topics: - How's the API? Stable yet? - Committed maintainers? - How's documentation? - I10n? I think telepathy is good to go; I'm looking for dissenting opinions here. On 12/21/07, Ross Burton [EMAIL PROTECTED] wrote: On Thu, 2007-12-20 at 17:12 -0600, Jason D. Clinton wrote: So in summary, WTF is Telepathy and Topaz and why should I care? (Or for the tin-foil-hat brigade: why does Nokia/Collabora care about this so much?) From http://telepathy.freedesktop.org/wiki/: Telepathy development is supported by Collabora Limited. From http://maemo.org/development/documentation/how-tos/4-x/implementing_custom_connection_managers.html : The messaging framework in Internet Tablet OS is based on Telepathy framework architecture. I think that pretty much sums up why Nokia (they use it) and Collabora (they wrote it) are about Telepathy. Ross -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
gnome-games 2.22 branced
The gnome-games SVN has been branched for the 2.22 stable series. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Session Management in 2.24
Thank you for doing this hard work. Dan, too. On Mon, Mar 24, 2008 at 4:54 PM, Lucas Rocha [EMAIL PROTECTED] wrote: So, now the code reached a functional state and I've just merged the new-gnome-session branch in trunk. Vincent Untz and I will be working on making the new code shine for 2.24. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ANNOUNCEMENT: The Future of Epiphany
On Tue, Apr 1, 2008 at 8:21 AM, Christian Persch [EMAIL PROTECTED] wrote: This single back-end will be * WebKit *. Hoping this is not an April Fool's joke, also. +1 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Call for hackfest ideas
A bling hackfest would be a good one--given our competition from the KDE folks as of late. I can think of at least a dozen little projects all over Gnome that fall in this category. On Tue, Apr 15, 2008 at 8:36 AM, Vincent Untz [EMAIL PROTECTED] wrote: So if you can think of a topic that would be suitable for a hackfest, please talk about it with a few people and share your idea. For budget reasons, it'd be better to keep the hackfests small (ie, not too many people). Note that a good hackfest is not just a good topic: you need to have the right people and a good agenda so that things actually get done. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Dependency Proposal: Clutter 0.6.2, ClutterMM 0.6
Hi, For Gnome Games 2.24, I would like to have an optional hardware-accelerated Gnometris theme. This would be enabled by default on installations where glxinfo reports Direct Rendering: Yes. All of the old themes will continue to be present and used as fall-backs when the hardware is not there. After much research, clutter appears to be the most Gnome-friendly, stable, and active canvas-like project. Others which may come up in this discussion are largely inactive (goocanvas) or sufficiently incomplete (hippocanvas) as to make them unusable for implementation of a Tetris-like game animation. pigment is out because it's Python-only (or so I am told). I'm not saying anything bad about any of the above: just that they don't meet my requirements, right now. I considered other non-Gnome canvas options too such as QGraphicsView and Webkit canvas and decided against both due to very difficult implementation details. I suspect that this will make Gnometris more attractive for embedded use since many mobile devices now support OpenGL--though, no one has said they will use it for embedded use. I solicited objections to using clutter on our gnome-games mailing list and on my blog which is aggregated on Planet. There were no objections. Yes, it's yet another canvas. But, it appears to be widely available in distributions and no one is (yet) proposing it for inclusion in the Gnome officially. With a little work, the new rendering engine will add a lot of bling for very little coding investment. It will probably be something--at least--worth mentioning in the release notes. The fact that some drivers do not yet have OpenGL support is irrelevant as there are no plans to deprecate the existing theme engines. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Dependency Proposal: Clutter 0.6.2, ClutterMM 0.6
On Sun, Apr 20, 2008 at 6:33 PM, Gustavo J. A. M. Carneiro [EMAIL PROTECTED] wrote: 1. It does not use Cairo; The implementation that I'm proposing will blit Cairo-rendered surfaces to textures using cluttermm. I couldn't make pretty, scalable 2D graphics without Cairo. So, they complement each other... ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Dependency Proposal: Clutter 0.6.2, ClutterMM 0.6
On Mon, Apr 21, 2008 at 10:03 AM, Adam Schreiber [EMAIL PROTECTED] wrote: On Mon, Apr 21, 2008 at 10:08 AM, Gustavo J. A. M. Carneiro [EMAIL PROTECTED] wrote: On Sun, 2008-04-20 at 18:59 -0500, Jason D. Clinton wrote: On Sun, Apr 20, 2008 at 6:33 PM, Gustavo J. A. M. Carneiro [EMAIL PROTECTED] wrote: 1. It does not use Cairo; The implementation that I'm proposing will blit Cairo-rendered surfaces to textures using cluttermm. I couldn't make pretty, scalable 2D graphics without Cairo. So, they complement each other... Well, Cairo is not just a checkbox that you can check and make everyone happy; unless the entire output is Cairo, you cannot easily print the content with high quality vector graphics. You can't convert OpenGL graphics to PS or PDF... But I want to make clear that it is just a general comment I make about Clutter. In this specific case, gnome-games, it doesn't apply; I don't think people will care much about high quality printing of a chess game :) Unless you're writing a book or website where high ranking games of chess are recreated and commented on. Not that I want to do that, just a counter example. Since the existing high-resolution 2D Cairo engines are still present and their code is being reused for the accelerated version, there's no need to worry about the deprecation of 2D. We all understand the value of 2D and we aren't going to be carving it out any time soon. Not until--at least--the far future when we're at war with talking badgers... (How's that for straying from the subject!) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed external dep: PolicyKit
On Wed, May 7, 2008 at 12:29 PM, Brian Cameron [EMAIL PROTECTED] wrote: I do not think it is a problem for PolicyKit to be an external dependency for GNOME. However, there will probably be people at Sun working to #ifdef out PolicyKit code in the modules that tend to get shipped with Solaris. From Sun's perspective, I think it would be best if PolicyKit were considered more of an optional dependency. If Sun wants to do something completely different from what the rest of the community is doing, it seems like the responsibility for bearing the consequences of that course of action should lay squarely on the shoulders of Sun's engineering teams. Since there appears to be a clear way forward for you to write some layer of compatibility with your different way, I don't understand why we should hold back on mandatory dependencies. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Announce: Gnome Games 2.22.2
gnome-games 2.22.2 == This service release contains fixes for build problems related to Python and a few crashers. A handful of fixes to Aisleriot are specific to the Maemo platform. Aisleriot: - Don't crash on double click (Vincent Povirk, Christian Persch, Bug #443307) GLChess: - Don't modify sys.path as this can cause modules to be loaded that don't match the interpreter version (Robert Ancell, Bug #528953) - Fix crash decoding empty GGZ strings (Robert Ancell, Bug #526252) - Check PID returned on SIGCHLD (Robert Ancell, Bug #527686) - Handle missing throbber icons (Robert Ancell, Bug #524829) - Disable room 'new' and 'join' buttons when network protocol is busy (Robert Ancell, Bug #523818) - Import the main module on initialisation not runtime (Robert Ancell, Bug #524665) - Abort history saving if cannot create history directory (Robert Ancell, Bug #523076) - Abort 3D render if widget_get_gl_context() returns None (Robert Ancell, Bug #512068) - Add Gambit Fruit to AI list (Robert Ancell, Bug #521623) - Handle AI players dying before the game starts (Robert Ancell, Bug #522341) Sodoku: - Don't modify sys.path as this can cause modules to be loaded that don't match the intepreter version (Robert Ancell, Bug #528953) Translations updated: Czeck (Lucas Lommer, Petr Kovar), Bulgarian (Yavor Doganov, Alexander Shopov), Catalan (Jordi Mallach) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Gnome Games 2.22.2.1 Brown Paper Bag
gnome-games 2.22.2.1 This is a brown-paper-bag release to fix a crash-on-start in GLChess. GLChess - Fix our sys.path usage (Jason Clinton, Josselin Mouette, Bug #524665, Bug #528953) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: minimum cairo dependency
On Mon, Jun 2, 2008 at 9:03 AM, Matthias Clasen [EMAIL PROTECTED] wrote: It was pointed out to me that http://live.gnome.org/TwoPointTwentythree/ExternalDependencies still lists cairo 1.2.6 as minimum version. I recently bumped the cairo dependency in GTK+ 2.13 to 1.6 (it already was at 1.5.2 before). I think we should bump the minimum required version of cairo to 1.6.0 for Gnome 2.24. I believe that 1.6.4 is currently considered all-the-rage as far as bug fixes are concerned. For sanity's sake, lets align ourselves with other projects and bump to that version. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Gnome Games 2.23.3
gnome-games 2.23.3 == This development release incorporates a few critical bugfixes. No new features over the previous 2.23.1 have been added. Overall: - Set AM_MAINTAINER_MODE (Josselin Mouette, Andreas Røsdal, bug #53255) - Stop distributing generated defaults.py (Robert Ancell) - Add the new parameter --with-ggz-server=force (Josselin Mouette, Andreas Røsdal, bug #532555) - Drop server configuration files to ggzdconfdir (Josselin Mouette, Andreas Røsdal, bug #532553) Sudoku and GLChess: - Fix our Python sys.path usage to make it easier to package for distros and possible to run directly out of the build directory for developers (Jason Clinton, Josselin Mouette, Robert Ancell, bug #528953, bug #524665) - Open files in binary mode so they work in Windows. (Robert Ancell) - Massive GGZ multiplayer fixups (Robert Ancell) Gnotski: - Remove Minoru Climb. Aisleriot: - Don't crash on double click (Christian Persch, Vincent Povirk, bug #443307) Translations: Jonh Wendell, Vladimir Melo, Clytie Siddall, Vincent van Adrighem, Djihed Afifi, Tino Meinen, Kjartan Maraas, Petr Kovar, Lucas Lommer, Priit Laes, Ivar Smolin ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: Empathy for GNOME 2.24
2008/6/12 Xavier Claessens [EMAIL PROTECTED]: I hope this will help the adoption of Empathy for GNOME 2.24. -1 (I haven't said anything during the 2.24 release cycle. I just reviewed the application as it stands at version 0.23.1 and I believe that it simply is not ready to be included. Perhaps in 2.26.) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Dependency Proposal: Clutter 0.6.2, ClutterMM 0.6
On Sat, Jun 14, 2008 at 9:17 AM, Emmanuele Bassi [EMAIL PROTECTED] wrote: On Sat, 2008-06-14 at 15:27 +0200, Andre Klapper wrote: Am Mittwoch, den 23.04.2008, 10:23 +0100 schrieb Emmanuele Bassi: Le lundi 21 avril 2008, à 17:10 +0100, Emmanuele Bassi a écrit : Clutter is already providing a (portable) integration with GTK+, Webkit, Cairo, GStreamer and event a physics engine - and we are committed to release the current trunk as 0.8 before GNOME 2.24 is API frozen[3]. we plan to release 0.8 by June, at this point; we have some pending items to merge into trunk before we can start pushing out developers snapshots. so this is still the plan? just saw that 0.7.0 was released yesterday, and GNOME API freeze is July 28. took a little bit more than expected, but the plan still holds: 0.8.0 will be released before GUADEC. we'll keep pushing out developers snapshots for people to test and play with the new API and features. AFAIK, only Gnome Games and some work on GThumb full screen previews that are modules inside GNOME have officially started using Clutter. If we can get buy-in from the GThumb (I'm in) we can depend on just 0.8 instead of on 0.6.2 and 0.8 for 2.24. Though, at this point, my work won't be ready by the feature freeze so it's not going to make it in to 2.24 anyway. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Gnome Games 2.23.4
gnome-games 2.23.4 == Gnibbles: - Improved AI search algorithm. Solves AI problems with level 15 (ais523) - Fix problem where worms crash on the starting square of dead worms (ais523) Gnometris: - code clean up (Jason Clinton) - fix compiler warnings (Jason Clinton) Sudoku: - code clean up (Jason Clinton) Translations: - ar: Djihed Afifi - de: Mario Blättermann - ru: Aleksandr Burobin ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Need Leadership
I know that a lot of discussion around this topic will be taking place (in smoke filled rooms) at GUADEC but for those of us who can't afford to make the trip, some of this conversation needs to be had here on this mailing list (and pointedly not on foundation-list on which many developers are not subscribed). This mail is born out of a combination of frustration over a lack of action taken from Decadence Thread and the continuing reality check that Linux Haters Blog is giving our collective community. We need to tap in to the wave of energy generated by the The Thread on Planet Gnome. Already, it's apparent that the fervor that surrounded it has started to dwindle. A ton of interesting ideas were thrown out and lot of belly-aching about no one taking responsibility for making it happen was heard. I'm going to keep this short because I know attention spans are, as well. Please keep the conversation here and NOT on P.G.O--this should be a conversation that everyone feels invited to participate in and which hopefully spans the length of GUADEC, itself. It's clear from The Thread that we need to Get Our House In Order. There's nearly universal agreement that Gnome lacks leadership in the sense that there's someone that sets release goals. In my opinion, whatever The Next-Gen Gnome is, it isn't going to happen until we really, really have a deep maintenance cycle going on here. That means fixing a Handful of Giant Warts on our maintenance process: 1. DVCS needs to happen; now. It's time. The number of people using a DVCS frontend to circumvent the insanity of SVN continues to grow. In that vein, we need to a) debate the One True DVCS for Gnome, b) delinate the work that needs to be done to get there and set a timeframe, and c) find the man power to do it. 2. The Giant Rift in the Gnome community over Mono has to end. I hate Mono as much as the next guy but it's quite apparent now that some really cool stuff with financial backing from Big Linux Distributor is not going away: Gnome Main Menu, Banshee, F-Spot, Beagle, Tomboy, etc. We have to get rid of the rift and bring the two diverging communities back together. Whatever damage that might incur in the minds of the Slashdot crowd has already been done--Gnome is perceived (rightly or wrongly) to be largley 'infested with Mono' in the minds of our critics. We cannot capitulate on this to appease a vocal minority of users that detest Mono. It's obvious it's not going away and, with a trivial amount of work, we can mend the rift by including the afore-mentioned mondules in our official releases. Let's just do it and move on with our lives. 3. Marketing to developers must get ramped up; we agree that we need a new generation of awesome developers to bring new ideas and blood in to our process. A number of our Gnome modules are in barely maintained mode. With new blood, we can reinvigorate 2.x while looking to the future. And I've volunteer for this one in the form of 15 minute screen casts. However, it needs web hosting space. And that needs Gnome resources. What do we have to do to make this hosting happen? What else can we do to get more developers? Please keep this thread a conversation and not an arguement. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Need Leadership
On Sat, Jun 21, 2008 at 12:37 PM, Hubert Figuiere [EMAIL PROTECTED] wrote: On Sat, 2008-06-21 at 11:57 -0500, Jason D. Clinton wrote: 2. The Giant Rift in the Gnome community over Mono has to end. I hate Mono as much as the next guy but it's quite apparent now that some really cool stuff with financial backing from Big Linux Distributor is not going away: Gnome Main Menu, Banshee, F-Spot, Beagle, Tomboy, etc. We have to get rid of the rift and bring the two diverging communities back together. Whatever damage that might incur in the minds of the Slashdot crowd has already been done--Gnome is perceived (rightly or wrongly) to be largley 'infested with Mono' in the minds of our critics. We cannot capitulate on this to appease a vocal minority of users that detest Mono. It's obvious it's not going away and, with a trivial amount of work, we can mend the rift by including the afore-mentioned mondules in our official releases. Let's just do it and move on with our lives. I don't see what Gnome Main Menu is doing in your anti-Mono rant. Or maybe you are and editing contributor of BoycottNovell.com and decided to spread the misinformation here where people actually tend to know what they are talking about. How does this is really cool stuff constitute an anti-Mono rant? You seem to have interpreted that paragraph as 100% opposite from what I wrote... *frustration* ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Need Leadership
On Sat, Jun 21, 2008 at 1:27 PM, Alberto Ruiz [EMAIL PROTECTED] wrote: 2008/6/21 Jason D. Clinton [EMAIL PROTECTED]: And there's a discussion about it already, there's even a BoF at GUADEC around the topic. PGO is the wrong place for that discussion and as I said in the first sentence of my email, this thread is for everyone; not just those that can afford to go to GUADEC or who blog to PGO. 3. Marketing to developers must get ramped up; we agree that we need a new generation of awesome developers to bring new ideas and blood in to our process. A number of our Gnome modules are in barely maintained mode. With new blood, we can reinvigorate 2.x while looking to the future. And I've volunteer for this one in the form of 15 minute screen casts. However, it needs web hosting space. And that needs Gnome resources. What do we have to do to make this hosting happen? What else can we do to get more developers? Is there anything preventing you to put the videos at your GNOME's home directory and serve it through http? I can't see why those screencasts should wait before the hipotetically needed bandwidth is there. This is a marketting effort. Nothing hurts something like that more than a false-start. We need to make sure the bandwidth is there first. Actually, you can just put those videos at youtube and provide a secondary ogg link, that will solve the bandwidth problem and it wil provide an usable way to watch the video for most people, and a freedom-compilant version of the video. YouTube doesn't provide sufficient quality for a screen cast. A screen cast where you can't read the text defeats the purpose. As a side note, if you want to drive leadership I will strongly encourage you to avoid any sentence that starts with I hate, if you have something against some developers' decisions on the tools they want to use, just give your rationale behind your opinion and recognize the benefits of what they use as well. Don't assume people is just wrong since that will inevitably drive the discussion into a passionate argue instead of a constructive conversation. Remember, encouraging people to move forward is way more important than making your personal points clear. You also appear to have misread my email. I'm *advocating* the inclusion of Mono with 100% approval so that we can MEND the rift in our community. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Need Leadership
On Sat, Jun 21, 2008 at 2:07 PM, Cody Russell [EMAIL PROTECTED] wrote: On Sat, 2008-06-21 at 13:47 -0500, Jason D. Clinton wrote: I don't see what Gnome Main Menu is doing in your anti-Mono rant. Or maybe you are and editing contributor of BoycottNovell.com and decided to spread the misinformation here where people actually tend to know what they are talking about. How does this is really cool stuff constitute an anti-Mono rant? You seem to have interpreted that paragraph as 100% opposite from what I wrote... I think he was questioning why you included Gnome Main Menu in the paragraph about Mono, since Gnome Main Menu is written in C. But considering how you say you hate Mono as much as the next guy, it did come across as kind of an anti-Mono rant. Unless the next guy is someone like me who actually likes Mono, then I suppose it could be interpreted that you like Mono. But I don't think anyone is reading it that way. ;) I can see how it could be taken that way. I also see now that Beagle has become an optional dependency of gnome-main-menu. Apologies for the confusion. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Need Leadership
On Sat, Jun 21, 2008 at 1:26 PM, Havoc Pennington [EMAIL PROTECTED] wrote: 2008/6/21 Jason D. Clinton [EMAIL PROTECTED]: In my opinion, whatever The Next-Gen Gnome is, it isn't going to happen until we really, really have a deep maintenance cycle going on here. That means fixing a Handful of Giant Warts on our maintenance process: I bet the next-gen gnome will happen when someone writes it. I would suggest people think in terms of getting something going by themselves, and once it's at least roughly usable, think about recruiting 2 or 3 or 5 other people to the project. But getting hundreds of people to agree up front isn't too likely. Think 5 not 500. I'd suggest also that next-gen gnome is a bad framing. It's the same broken mindset as GNOME 3.0. GNOME _the desktop_ does not need a 3.0 or a next-gen in particular. I think most of the current users, and current involved OS vendors would basically be against major change in the target audience of today's GNOME desktop (current Linux users). I mean, even if individuals at those companies are in favor in principle, it's not their day job and their day job has major pressures to focus on the current audience. I apologize for I intended this thread to be about getting our ducks-in-a-row with regard to 2.x maintenance. It's my own fault for piggy-backing off of Decadence Thread of which so much of that has been about Gnome++. I whole-heartedly agree with you that setting some lofty goal that everyone has to buy-in to is antithetical to a healthy development process. But, again, I got us off on the wrong foot by including the above sentence in my post. Hopefully this thread can be more about doing the things that make incremental improvements even easier and radical new experimentation trivial. Allow me this one concrete example: in Bugzilla, there's a bug open against Iagno in which a non-native English speaker has re-written the entire game from the ground-up adding multi-player; the diff is 4,000 lines. I really like where it's going but unfortunately, as someone new to FOSS he really didn't understand the contributing patch-sets custom that we've come to all agree on. Now, if we were using DVCS, I could have this new version of Iagno incorporated in a mater of days because all the changes would be incrementally documented with rationale. Instead, we're looking at months of work to break his changes in to peer-reviewed patch-sets that are documented and transparent from the perspective of the ChangeLogs. (ie. blame outputting a person's name and the rational for a change on a per-line basis). Don't misunderstand my point here: I don't think anyone should cave to current users or commercial pressures. I do think that it's impractical to ignore almost everyone currently working on or using the software, though. You just can't fight that momentum. It isn't even correct to fight it. There are lots of users there with expectations. The goal is not to randomly churn up the GNOME desktop as it exists today (window manager, session manager, panel, etc.) - that thing should just keep evolving in incremental fashion, getting better all the time for the people who use it. +1 The goal should be to find all the new directions, and see if GNOME can start to be about those too. Right now there are lots of new directions in mobile, set-top boxes, EeePC-type thingies, for example. Why does the front page of gnome.org still say GNOME offers a desktop - excluding these directions from GNOME? That's a problem. The GNOME stack potentially has much wider applicability. Excellent point. Is there a list somewhere of the rich ecosystem of consulting companies and libraries and products that build on the GTK/GNOME technology stack? Why isn't gnome.org positioned as about that list, with the desktop as only one of the things on the list? I bet a solid fraction of our community isn't even primarily focused on the desktop anymore... could be a majority even. But the Fedora/Ubuntu/Suse framing of GNOME-as-desktop remains dominant despite all the smaller companies who are doing other stuff. Yes. And your concerns are right. For example, Cristian Persch has been working in my module on making games run on Maemo. Others have worked on Windows ports. I, personally, love this work. What I would love to see, however, is the development process and release schedule take in to account the possibility that modules in Gnome are not all 100% aimed at the desktop. For example, there hasn't been enough emphasis on release goals that have targeted making our modules more portable. It seems we're stuck thinking: What will this look like in the Release Notes when Gnome 2.x is release? As opposed to what would perhaps be a more healthy: How does this make my module more universal? Setting release goals and rallying the troops to them is very much a leadership issue. GNOME could be instead of a desktop something like a development
Gnome Games ChangeLog is now dynamic
I have copied Epiphany's method of generating ChangeLog on make distcheck for distribution purposes from the VCS commit log. Gnome Games 2.24 will release this way (trunk). SVN commit messages are now canonical and should be verbose to the point that the change is succinctly described with the bug number that it relates to. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Gnome Games 2.22.3
This is the final service release for 2.22 series. We have all worked to back- port fixes from trunk; especially those that cause crashers. General: - Fix allocator/deallocator mismatch. (Yanko Kaneti, Christian Persch, Bug #535214) GLChess: - Don't disable load button on load dialog as we cannot tell if the user has selected a valid file (Robert Ancell, Bug #540527) - Handle empty combo boxes in the preferences dialog (Robert Ancell, Bug #532908) - Disable network controls when disconnected (Robert Ancell, Bug #523818) - Backport trap ImportError and give the user and helpful message about their installation being broken (Jason Clinton) - Backport the sys.path fixes from trunk. (Jason Clinton) Gnome Sudoku: - Backport redraw() crash fixes from trunk (Jason Clinton) Translators: Leonardo Ferreira Fontenelle, Vladimir Melo, Clytie Siddall, Christian Kirbach, Mario Blättermann ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Using vala in GNOME
On Mon, Jun 30, 2008 at 9:47 AM, Gustavo J. A. M. Carneiro [EMAIL PROTECTED] 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. 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. IMO, the only hope that we can get away from autofoo is the Quagmire effort. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed external dep: PolicyKit
On Fri, Jun 20, 2008 at 1:47 PM, David Zeuthen [EMAIL PROTECTED] wrote: On Fri, 2008-06-20 at 15:57 +0200, Murray Cumming wrote: Going off topic a bit: It would be really nice if PolicyKit had a proper web page and mailing list. It's too important for information on it to be so fragmented. Right. I'm actually going to try and fix this (dedicated mailing list and website); stay tuned. Hi, I am tracking relatively unstable development repositories. As a result, I have hal 0.5.11 installed which appears to have--undocumentedly--suddenly required PackageKit as a hard dependency. For example, removable storage mounting no longer works if PK is not installed due to the way that the default dbus fdi rule is written. Aside from the hal harddep problem, it appears that PK is sorely, sorely missing its documentation. For example, having this new dependency thrust upon me would have been fine if things like /usr/share/doc/policykit-gnome/README didn't contain: TODO: write me If RH is going to thrust PK on us, please, please, please provide some kind of documentation (not an API reference). When things don't work (as they aren't now and were previously) I have absolutely no idea what's wrong, where to look or who to blame. Most importantly, I wanted to file a bug but couldn't even manage that with the spectular lack of information out there. Luckilly, Rob Taylor was gracious enough to point me in the right direction from what he has in his own memory. Alas, correcting for an obvious packaging error hasn't solved to problem so I'm stuck again. I'm sure others would not be even this fortunate... Ever so politely, ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed external dep: PolicyKit
On Tue, Jul 22, 2008 at 10:03 AM, David Zeuthen [EMAIL PROTECTED] wrote: So maybe you just haven't tried hard enough. Fuck you. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed external dep: PolicyKit
On Tue, Jul 22, 2008 at 7:02 PM, Michael Biebl [EMAIL PROTECTED] wrote: 2008/7/22 Rob Taylor [EMAIL PROTECTED]: Hi Rob, Just as a quick note, Jason's problem is completly a debian unstable packaging issue, as far as I can tell. Care to eloborate, why and what the actual problem actually is (especially regarding Debian)? /usr/share/PolicyKit/policy files in the 0.5.11 upstream distribution are not being installed by the Debian hal package. But as I said in the last line of my email which apparently no one has read, after correcting for the packaging problem, it's still broken. So that's only a tiny aspect of the issue. The issue is that there is no user documentation at all. Not in the distribution. Not in the GUI with a Help button. Not in stub README files. Nothing. ... Unless you're a programmer and want to read developer documentation to get your USB hotplug working again. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed external dep: PolicyKit
On Tue, Jul 22, 2008 at 8:09 PM, Michael Biebl [EMAIL PROTECTED] wrote: If that's your policy, then you need to patch /etc/dbus-1/system.d/hal.conf to NOT use PolicyKit in a package that doesn't have support for it. This is--AFAICT--an upstream bug in hal that this stanza is not removed when ./configure finds that PK is not going to be enabled. Now THAT is a bug I could file. But, as I've said, I already corrected for that and the problem appears to be deeper. I'm honestly not sure what you are talking about, sorry. There are no PolicyKit bits in Debians hal.conf. We use the group based approach as we always did. This is the PK bits that David was discussion in his previous message that are in the Debian hal which appears to be a security problem, if nothing else: http://gitweb.freedesktop.org/?p=hal.git;a=commitdiff;h=5b4c664f7b40e85148bd3c32946388e23fe8b384 Would you like me to open the BTS bug? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed external dep: PolicyKit
On Tue, Jul 22, 2008 at 8:27 PM, Jason D. Clinton [EMAIL PROTECTED] wrote: This is the PK bits that David was discussion in his previous message that are in the Debian hal which appears to be a security problem, if nothing else: http://gitweb.freedesktop.org/?p=hal.git;a=commitdiff;h=5b4c664f7b40e85148bd3c32946388e23fe8b384 Would you like me to open the BTS bug? Never mind, I was looking at the Debian hal.conf cross-ways while examining the one I installed as a part of my jhbuild work tracking 2.23. There's nothing wrong with the Debian package; it correctly kills PK support as suggested by the configure.in message that David referenced. jhbuilding appears to be the source of PK being enabled WRT to hal. When I have time I'll investiage why the default allow policy is having PK returning permission denied for active sessions. It'll have to be some time next week. Thank you for your attention to the Debian side of things, Michael. Here is the Debian patch, FTWCA such things: diff --git a/hal.conf.in b/hal.conf.in index ef97b8f..3646deb 100644 --- a/hal.conf.in +++ b/hal.conf.in @@ -40,6 +40,26 @@ !-- Default policy for the exported interfaces; if PolicyKit is not used for access control you will need to modify this -- policy context=default +deny send_interface=org.freedesktop.Hal.Device.SystemPowerManagement/ +deny send_interface=org.freedesktop.Hal.Device.VideoAdapterPM/ +deny send_interface=org.freedesktop.Hal.Device.LaptopPanel/ +deny send_interface=org.freedesktop.Hal.Device.Volume/ +deny send_interface=org.freedesktop.Hal.Device.Volume.Crypto/ + /policy + + !-- Debian groups policies -- + policy group=powerdev +allow send_interface=org.freedesktop.Hal.Device.SystemPowerManagement/ +allow send_interface=org.freedesktop.Hal.Device.VideoAdapterPM/ +allow send_interface=org.freedesktop.Hal.Device.LaptopPanel/ + /policy + policy group=plugdev +allow send_interface=org.freedesktop.Hal.Device.Volume/ +allow send_interface=org.freedesktop.Hal.Device.Volume.Crypto/ + /policy + + !-- You can change this to a more suitable user, or make per-group -- + policy user=root allow send_interface=org.freedesktop.Hal.Device.SystemPowerManagement/ allow send_interface=org.freedesktop.Hal.Device.VideoAdapterPM/ allow send_interface=org.freedesktop.Hal.Device.LaptopPanel/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: indentation of c code
On Mon, Aug 18, 2008 at 7:22 AM, Dodji Seketeli [EMAIL PROTECTED] wrote: BJörn Lindqvist a écrit : [...] There is no GNOME standard for indenting C code -- every project use their own indentation style (unfortunately). But to reformat a file to an indentation style many projects use, you can just run indent without any arguments. I am sorry, but I think there is a GNOME standard for indenting C code. It's at http://developer.gnome.org/doc/guides/programming-guidelines/book1.html, chapter http://developer.gnome.org/doc/guides/programming-guidelines/code-style.html . If GNOME C projects use their own indentation style, I think it's just because only a few people have read that documentation or because GNOME as a project does not enforce it that much. GTK+ uses the GNU indentation style that is documented at http://www.gnu.org/prep/standards/standards.html. I would love to clean up indentation in my module but I fear that it creates useless svn blame output henceforth. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Laptop power disconnect alarm
This should probably be done as a patch to gnome-power-manager. Thinkpad laptops in particular already do something like this (it's implemented in the BIOS) that does a chime to notify the user that the laptop is still on when the lid is closed and the power cord is detached to prevent people from putting their laptop in their bag and having it overheat. On Sun, Oct 12, 2008 at 5:26 AM, Bram Neijt [EMAIL PROTECTED] wrote: Dear GNOME developers, I have a program idea that I would like to create and test out, but I have no idea whether something like this has already been created and what documentation to read in order to create it. I want an application that will sound an alarm if my laptop adapter is unplugged while the screen is locked. The idea is that if somebody tries to steal my locked laptop, disconnecting the power, it will start shouting I'm being stolen! (by playing a sound file). Because it needs both power information and screen-lock information and is laptop specific, I think a separate program is needed. The questions I have are: - How do I keep an eye on the power status? What interface should I register, dbus something?? - How do I keep an eye on the screen-saver status, where can I register for locking/unlocking events? - Is there something like this already created, would it be scriptable instead of programming it out completely? For most of these questions, links would suffice. Any ideas are of course also welcome. Greetings, Bram Neijt ___ 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
Dependency bump request for Clutter
0.6 was cleared for use for 2.24 but no module actually ended up using it. I would like to request that the dependency be bumped to 0.8.2. Aisleriot now supports Clutter thanks to the work of Neil Roberts. The gnome-games team is committed to releasing 2.26 with some Clutter support. For 2.26, the 0.8 series seems like the way to go. As we near release, I may update this bump request to the 1.0 API. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: new module proposal: brasero
2008/11/1 Philippe Rouquier [EMAIL PROTECTED] Hi, We'd be interested in having brasero integrated into the GNOME desktop. +1, a wonderful application. n-c-b should be completely removed. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.25.1 Released!
Why was Gnome Games omitted from the release notes? This was the worst possible release that could have been left out. There are more changes in dependencies and packaging in this release than any other point in my recent memory. On Thu, Nov 6, 2008 at 6:02 AM, Vincent Untz [EMAIL PROTECTED] wrote: GNOME 2.25.1 Development Release ... desktop - http://download.gnome.org/desktop/2.25/2.25.1/NEWShttp://mail.gnome.org/mailman/listinfo/devel-announce-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: update of jhbuild module dependencies
On Sat, Nov 8, 2008 at 3:06 PM, Luca Ferretti [EMAIL PROTECTED] wrote: * a little mess with clutter stuff: we have clutter in gnome-external-deps-2.26 (0.8.2 targz) and in gnome-2.26 (svn trunk) and clutter-0.8 (svn branch) as well as a lot of clutter-XXX-0.8: clutter 0.8.x is official external dep for GNOME 2.24. Will we switch to 0.9/1.0 in 2.26? Emmanuele? No, 0.6.x is official external for 2.24. My request bumped that to 0.8 for 2.26. 1.0's release is scheduled too close to our freezes, I think. clutter-cairo, -gstream, -gtk, should all be set to the latest releases of those modules. 0.8.x is API stable. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME DVCS Survey Results
On Sun, Jan 4, 2009 at 8:51 AM, Olav Vitters o...@bkor.dhs.org wrote: That isn't a contest. It is a survey. Please don't read more in to my email than I intended. There's no need to get defensive. http://www.gnome.org/~shaunm/survey/first-picks-permutations.png It seems to me that a lot of brain power, sysadmin time, and general I am a sysadmin and disagree with your notion that sysadmin time is somehow saved. I'd rather asses such things myself. Further, sysadmin time is not so important. Thank you for voicing your opinion. just all move on? Further, your explanation is incomplete. As you said, the graph is about people knowing two DVCS systems. I wouldn't say I knew 2. Those 6 are incomplete. I highlighted this statistical analysis because those 6 contain the subset of 4 vocal users demanding that we /also/ support bzr. Now before you reply: we have a clear need for git to work (ranked 1st 50% of the time, etc). But if you say move on, how do you think a switch is made? Magic? Please don't be patronizing. I'm not an idiot. Anyway, I'd rather add John Carr to the sysadmin team. I plan to make a proposal to switch GNOME to a DVCS where Git works using Johns suggestion. Then other sysadmins[1] can suggest whatever proposal they want. These proposals can be investigated on merit and then a one can be chosen (chosen as in: go ahead and try if this would work, not go ahead blindly; everything must be tested before a cutover). John's idea is a good one but it patently loses on technical merit. As stated by John here, git will only be support in a degraded, bastardized form because he chose bzr as the repository format: http://blogs.gnome.org/johncarr/2008/12/11/dvcs-for-gnome/#comment-172 Are we really going to go back to the days of CVS where file moves aren't supported? It strikes me that this very vocal minority--John and Robert Carr, Karl Lattimer and Rob Taylor (whom are four of the six people I mentioned above)--are potentially delaying even longer what we've wanted for more than two years, now. It is from these same people that came the suggestion that git users were a rapid, vocal minority. Why are we letting them derail this process? Moving will not be easy, obviously. But doing it John's way will be, in my technical analysis, an order of magnitude more painful. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME DVCS Survey Results
On Sun, Jan 4, 2009 at 2:43 AM, Karl Lattimer k...@qdh.org.uk wrote: Elijah Newren did an initial analysis of the data. His analysis also includes the survey questions and answers. Find it at: http://blogs.gnome.org/newren/2009/01/03/gnome-dvcs-survey-results/ This is pretty decent analysis going on here :) I'd like to remind people of John Carr's recent blog post too, someone mentioned in the survey results actually. JC has been working on bzr with git protocol support, which would fulfil many of the requirements for having a GNOME DVCS. I'd like to point out that--of the 15 people who regularly use git and bzr--git still won. http://www.gnome.org/~shaunm/survey/first-picks-permutations.png It seems to me that a lot of brain power, sysadmin time, and general proliferation of Things To Learn for New People(tm) can be saved if the six people (1.04% of respondents) who ranked bzr above git in that graph can just bite the bullet and admit that git won. Can we please just all move on? My fear is that this effort to keep bzr on life support will cause bzr to show up as a requirement in distcheck for modules maintained by people who are still holding out. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME DVCS Survey Results
On Sun, Jan 4, 2009 at 11:48 AM, John Carr john.c...@unrouted.co.uk wrote: I'm not a complete idiot - if it was going to be a degraded, bastardized form of Git I wouldn't waste my time on it. I suppose I might be an evil genius stalling for Bazaar DS9 to be written (sorry for the very bad joke that probably only i get...). I don't think you're an idiot. I think you're quite smart. Can you please tell us exactly what your words, This is a price that a maintainer pays for using Git and one reason why eventually they might decide to (and have the option to) switch to using Bazaar, mean and to which git features you are planning on this statement applying to encourage people to use bzr? Or do you mean that you taking that sentence back? Also, can you tell us if Canonical is directing you to work on this? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME DVCS Survey Results
On Sun, Jan 4, 2009 at 3:01 PM, Zeeshan Ali (Khattak) zee...@gmail.com wrote: How about we set-up a task-force of volunteers who would want to help in the move, each volunteer promising at least 3 hours a week? 3 hours is a very small amount of time but I am hoping that we'll be able to gather at least 10 volunteers and together we can do it, even using our spare time. I can commit that much time as long as there's clear delegation of work by--preferably--the sysadmin team. I don't want to sit on a committee that does a lot of deciding and no actual doing. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME DVCS Survey Results
On Sun, Jan 4, 2009 at 3:27 PM, Olav Vitters o...@bkor.dhs.org wrote: I can commit that much time as long as there's clear delegation of work by--preferably--the sysadmin team. I don't want to sit on a committee that does a lot of deciding and no actual doing. What do you mean with delegation? Which do you mean: (yes, exaggerating) - Hey, do the switch, hopefully it'll work out in the end? - Run this command, then this one, then that More of a, Given this requirement, you find a solution to this specific problem. Report back in a week and ask for help if you get stuck, where solution may involve writing code in the form of post-commit hooks. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME DVCS Survey Results
On Sun, Jan 4, 2009 at 3:47 PM, Luca Ferretti elle@libero.it wrote: bzr allows lightweight checkouts [1]. What about git? Yes, it does. This is not an issue. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New Module Proposal: libseed
On Mon, Jan 5, 2009 at 9:12 PM, Robert Carr ca...@rpi.edu 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). +1 from me, obviously. Even if this is approved as a blessed depends, we may not end up turning Lightsoff on by default for 2.26 simply due to the number of outstanding tasks; we'll just have to see where we stand when feature freeze comes. It seems like a good time to make this a blessed dependency so that there's more than just Gnome Shell doing JS+GOI when/if it becomes the default shell for 3.0. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: JavaScript engines
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 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: JavaScript engines
On Tue, Jan 6, 2009 at 12:26 PM, Alexander Larsson al...@redhat.com wrote: The APIs will certainly not automatically be the same. There are lots and lots of little decisions you have to make when you bind gtk. If just one of these differ then they won't be compatible. It's not clear to me why this would not be considered a bug. Hopefully Robert will jump in here and say he's willing to treat GJS as the reference implementation and then everyone can just be happy with two implementations with the same API on which any app can Just Work. Let's wait for Robert to reply before we get too carried away... ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Dependency bump for GGZ
Gnome Games has bumped the GGZ dependency from 0.0.14 to 0.99.5 due to this library breaking API. It appears that no distro. (at least Debian and Fedora) has decided to do versioned soname for libggz so we are forced bump dependency to continue to be able to build in these distros. See bug #551455. I'll take the liberty of updating l.g.o ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Dependency bump for GGZ
On Sun, Jan 18, 2009 at 1:41 PM, Jason D. Clinton m...@jasonclinton.com wrote: Gnome Games has bumped the GGZ dependency from 0.0.14 to 0.99.5 due to this library breaking API. It appears that no distro. (at least Debian and Fedora) has decided to do versioned soname for libggz so we are forced bump dependency to continue to be able to build in these distros. See bug #551455. I'll take the liberty of updating l.g.o As an addendum, upstream is really unhappy with the soname situation in both Debian and Fedora. If upstream can manage to get either of these to revert the change to 0.99.5 or make it a soname bump instead, Gnome Games will revert to 0.0.14. I'll update this list as I hear more. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Dependency bump for GGZ
On Mon, Jan 19, 2009 at 5:41 AM, Josselin Mouette j...@debian.org wrote: Le dimanche 18 janvier 2009 à 14:52 -0600, Jason D. Clinton a écrit : On Sun, Jan 18, 2009 at 1:41 PM, Jason D. Clinton m...@jasonclinton.com wrote: Gnome Games has bumped the GGZ dependency from 0.0.14 to 0.99.5 due to this library breaking API. It appears that no distro. (at least Debian and Fedora) has decided to do versioned soname for libggz so we are forced bump dependency to continue to be able to build in these distros. See bug #551455. I'll take the liberty of updating l.g.o As an addendum, upstream is really unhappy with the soname situation in both Debian and Fedora. If upstream can manage to get either of these to revert the change to 0.99.5 or make it a soname bump instead, Gnome Games will revert to 0.0.14. I'll update this list as I hear more. For the record, if the soname has not changed between the two while the ABI is broken, this is a clear violation of our policy so we'll have no trouble to get it changed. Alright, Gnome Games is reverted to 0.0.14. Updating all the relevant pages. Fedora will have to revert their rawhide version to continue to build. Bump retracted. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.26 module inclusion discussion heats up
On Mon, Jan 19, 2009 at 8:46 AM, Lennart Poettering mzta...@0pointer.de wrote: Oh, is that so? This is some old Topaz mockup: http://farm1.static.flickr.com/20/70003494_668cfdc0dd.jpg Your attitude is making it really hard to take sides with PA. Yes, it's *the* only way forward at the moment. But you don't need to be a dick about it. Why are you (and your supporters) resisting a fall back mode so strongly? BTW, I updated the proposal pages some time ago to indicate that PA is essentially being proposed as a dependency as a result of this thread. What about your attitude toward hardware compatibility lends to the argument that we *should* depend on PA at this point? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module decisions for 2.26
On Wed, Jan 21, 2009 at 1:41 PM, Damien Sandras dsand...@seconix.com wrote: Perhaps pulseaudio developers could try ekiga before we write a pulseaudio plugin for it ? Lennart's last blog post on the matter[1] indicated that we should be using alsa--not writing pulseaudio plugins for our apps. So, it should Just Work... This is how I have been working on a private git branch for Gnome Games. I didn't see that ticket 23 until now. Quite scary. [1] http://0pointer.de/blog/projects/guide-to-sound-apis-followup.html ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Dependency bump for Clutter for Gnome 2.28
Okay to bump official depends on Clutter and Clutter-GTK from the 0.8.x API to 0.9/1.0 API? I fully expect it to stabilize and have a 1.0 release before 2.28. Also, Clutter Cairo is now part of Clutter. Also, it's unclear from reading the archives but is libcanberra blessed now? Planning on using it as a poor man's replacement for SDL mixer... ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Dependency bump for Clutter for Gnome 2.28
On Tue, Mar 17, 2009 at 8:26 AM, Olav Vitters o...@bkor.dhs.org wrote: On Mon, Mar 16, 2009 at 10:54:58PM -0500, Jason D. Clinton wrote: Okay to bump official depends on Clutter and Clutter-GTK from the 0.8.x API to 0.9/1.0 API? I fully expect it to stabilize and have a 1.0 release before 2.28. Also, Clutter Cairo is now part of Clutter. You mean as of 2.27.x? Yes. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME accepted as a Google Summer o Code project
On Wed, Mar 18, 2009 at 5:00 PM, Adam Schreiber sa...@clemson.edu wrote: GNOME has been accepted as a GSoC project for 2009. If you're interested in being a mentor and/or reviewing student applications, make your way to [1] and sign up. As far as I can tell, students have to start submitting their proposal in five days and we have not yet triaged the bug proposals. Can we do this soon; do you need help? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Gnome Games will make 3D mandatory for 2.28
Now that 2.26 is out and we've begun to work on 2.28, I want to get this out early so that no one feels like this was a last minute surprise. This has been a year in the making and this development cycle appears to be the right time to put some polish on our new game engines and make them the default. This is not a proposal or RFC. This is what is happening; I am merely make it abundantly clear well in advance of it being released to the general public. Games which will require 3D for 2.28: * Gnometris * Lights Off (pending approval of Seed/GJS dependency during proposal period) * Same Gnome (pending approval of Seed/GJS dependency during proposal period) Games which may require 3D depending on the maturity of the engine for 2.28: * Aisleriot * GSoC project results (whatever they may be) I anticipate that two parties will be disappointed: LTSP deployments and owners of ATI graphics cards. Taking the later first, this group appears to be being well-addressed by Airlied's work; hopefully everything will just work by the time 2.28 is released. As a former LTSP admin/engineer/slave, I believe that this style of Linux terminal server deployment is deeply flawed and well on the way to being replaced by Live environments. Whatever your opinion, remember: these are just games. Don't take this announcement too seriously. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome Games will make 3D mandatory for 2.28
On Tue, Mar 24, 2009 at 10:58 AM, Olav Vitters o...@bkor.dhs.org wrote: On Mon, Mar 23, 2009 at 06:21:48PM -0500, Jason D. Clinton wrote: This is not a proposal or RFC. This is what is happening; I am merely make it abundantly clear well in advance of it being released to the general public. Games which will require 3D for 2.28: * Gnometris * Lights Off (pending approval of Seed/GJS dependency during proposal period) * Same Gnome (pending approval of Seed/GJS dependency during proposal period) So I assume release team should announce some dependencies earlier if it appears to be a no brainer? Well, Clutter 1.0 is already in so we're good there. Regarding the JavaScript games, it seems that everyone agrees that JavaScript is going in to Gnome 2.28. GJS seems to have the leg-up as the Gnome-Shell preferred engine. As for which one, Robert Carr has plans to make Seed and GJS run-time compatible (to the extent that the underlying engines have implemented the ECMA specs and same features) by the time the module proposal period opens. I was planning on leaving the proposal up to him due to the requirement that the proposal must be made by the module maintainer. Currently, ScriptCore (as seen in gtkwebkit 1.1, Safari 4 beta, Chrome 2 beta) is about 2x faster than Tracemonkey (as seen in Firefox 3.1 beta) on the Sunspider benchmarks. It seems like allowing both as dependencies is the only way to go forward and since they should be (mostly) run-time compatible, it shouldn't matter, really. The only thing that worries me is Seed/GJS's both depend on the stability of GIR/GOI. But since Owen knows more about the status of that than I do and seems comfortable with the timeline, I do not foresee this really being an issue. Whatever your opinion, remember: these are just games. Don't take this announcement too seriously. I saw you commenting (blog IIRC) about this, this is existing code right that is now used as the only method (scrapping of 2D)? Or totally new code? Assume new for Lights Off and Same Gnome. Anyway, looking forward to the change. Aisleriot is the only game that we are committing to maintaining the old 2D engine on, for now. We're strapped for resources and the thought of doubling our maintenance burden for every game that gets an upgraded engine is not appealing. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity, Mutter, GNOME Shell, GNOME-2.28
On Tue, Mar 24, 2009 at 12:33 PM, Xavier Bestel xavier.bes...@free.fr wrote: On Tue, 2009-03-24 at 10:28 -0700, Sandy Armstrong wrote: On 03/24/2009 08:47 AM, Owen Taylor wrote: Using Compiz to create a GNOME desktop using GNOME applications, the GNOME control-center, and so forth will of course remain possible. We have no current plans to create hard dependencies on GNOME Shell within the GNOME desktop (just as there are no hard dependencies on gnome-panel now.) Yeah, but I can still use gnome-panel in compiz. I understand the reasoning here, and don't have any suggestions or anything, but it's a bit disappointing that the new desktop experience will be so tied to the window manager. Asking to leave all the compiz goodness will be a tough sell :) There is nothing good about compiz other than as a spectacle and general proof of concept. It has myriad application compatibility issues and configuring it is a usability nightmare. It tried to be desktop agnostic, so now it has four configuation backends and three window decorators--all of which are half-baked. The community around it very nearly died about a month ago. I would encourage you to try gnome-shell before you lament compiz. You'll see that already it is quite functional and there's lots of bling for those who care about such things. And since it's based on Metacity, all the app. compatibility bugs in compiz are gone. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity, Mutter, GNOME Shell, GNOME-2.28
On Mon, Apr 6, 2009 at 11:37 AM, Alberto Ruiz ar...@gnome.org wrote: You are missing the remote desktop scenario here. This is not only a matter of working on old hardware, being able to run gnome smoothly on a thin client solution through XDM, or VNC, or whatever is also needed. VNC is not an issue--it works regardless of the compositor/WM running. Speaking as a former LTSP admin/slave/developer, remote X11 is *always* a non-starter regardless of whether we are talking about 3D or not. More doesn't work than does. An approach similar to what Dave Richards is using at City of Largo is actually the right way to do this: the compositor and a few video-intensive apps run locally on the hardware. There's no technical reason that Shell couldn't do the same thing. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: eggsmclient code syncing
On Wed, Apr 8, 2009 at 1:38 PM, Matthias Clasen matthias.cla...@gmail.com wrote: good idea to sync the eggsmclient code in the modules that use it for 2.26.1, which seems to be at least the following: ... gnome-games Done on master and gnome-2-26 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
On Tue, Apr 21, 2009 at 3:32 PM, Tristan Van Berkom t...@gnome.org wrote: Sure, on the other hand projects with ChangeLogs that are hand-tended to are, in my personal experience richer than logs of arbitrary commits, if only by the simple virtue of forcing you to spend time caring for it. Anyway, lets see what some experiments yield ;-) Anyone submitting patches to our module without a proper commit log message will likely have their patch gently rejected until it's fixed. That certainly is the case with the vast majority of FOSS projects out there using git. See git format-patch. Likewise, at some point, translators making a commit log message that reads Updated a file. will have their commit reverted with an explanation in the commit log as to why it was reverted. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-games requires clutter 0.9.x
On Sun, May 3, 2009 at 2:39 PM, Kjartan Maraas kmar...@broadpark.no wrote: gnome-games stopped building in jhbuild for me since we still have clutter-0.8.8 there and the games want to use 0.9.x from what I can see in the logs. The request was made Mar. 17th with no objections. So, it's mandatory now. Time to move forward for everyone? Anyone else using clutter and thus need to port to the new version first? It's up to whoever is using it. 0.8 and 1.0 are co-installable. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-games requires clutter 0.9.x
On Mon, May 4, 2009 at 12:43 PM, Brian Cameron brian.came...@sun.com wrote: clutter-gtk 0.9 is not yet available. Yet gnome-shell requires clutter-gtk 0.9 to build, so you currently have to build it from git master. Might it be better to wait until clutter-gtk 0.9 is released before jumping to the new version in jhbuild? 2.27 doesn't build with 0.8.x; the API has changed. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-games requires clutter 0.9.x
On Tue, May 5, 2009 at 7:37 AM, Frederic Peters fpet...@gnome.org wrote: Emmanuele Bassi wrote: Hrm, then what's the point of the development tarballs? :-) providing snapshots, just like glib and gtk+ :-) but the API might change during the development cycle, so you should be aware of that. as far as I know, jhbuild does not build glib and gtk+ from tarballs either. Clutter is an external dependency, while glib and gtk+ are part of the platform. Policy (and experience) tells to build external dependencies from released tarballs. It seems that we're well on our way to making Clutter part of our platform so this formal distinction seems relatively meaningless at this point. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-games requires clutter 0.9.x
On Tue, May 5, 2009 at 11:01 AM, Andre Klapper ak...@gmx.net wrote: It's not only a formal distinction. Such policies do not exist just because people are bored. It's based on bad experiences in the past. Why are we having this argument? Is release team going to veto Clutter for 2.28? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
