Re: Time to heat up the new module discussion
Alvaro Lopez Ortega wrote: Dan Winship wrote: [snip] And if your argument is really languages that come with their own frameworks are bad,and not just I hate mono, then why didn't you argue against allowing python-based apps in the platform when that came up a year and a half ago? I missed it. :-/ Actually, what is puzzling me is that nobody else did it. You cannot even imagine how many people think like this.. I guess there are too many interests around these adoptions, I don't know. In any case, IMHO using Python to develop basic desktops applications is as wrong as using Mono or any other framework. And, don't take me wrong. I said *basic* desktop applications. Projects like Alacarte are okay; those are applications that you may use once a week/month. However, when we speak about an applet that will be loaded each single time you boot for PC things change. We ought to be extra careful with those. I'm going to go ahead and pipe up here because I feel like I need to voice my opinion that Mono should _not_ be part of the core set of modules for the GNOME Desktop. This is for a number of concerns which have already been stated, but it boils down to 1) this is still too controversial of a topic to make a decision in a single six month release cycle (with only 3 or so months left) and 2) I think is a topic that should be left to ISVs to decide. That being said, I use tomboy/f-spot and I'm glad that a certain ISV packages Mono and applications based on it, but I don't see how adding it lends any coherence or consistency to the GNOME framework. -- Brent Smith [EMAIL PROTECTED] IRC: smitten / #docs ___ 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
From an embedded developers standpoint working with Gnome as a part of the Gnome Mobile and Embedded group, C and C++ are extremely relevant for our devices. Mono like .NET are quite frankly a no go in terms of memory and performance. Sean On 7/13/06, Ben Maurer [EMAIL PROTECTED] wrote: Hi On Fri, 14 Jul 2006, [ISO-8859-1] Steve Frécinaux wrote: Iain * wrote: I'm not really against having C# apps in the core (in fact I don't really mind), what I'm more frightening about is having applications that run all the time, using managed languages, and, as a consequence, taking up a fairly large amount of memory, from the computer start to the shutdown. Think about it: having an application you run a short time do not really impact on your available memory, so it's not a real issue on low-memory system (like mine: 224 Megs are not much memory these days), but long-running ones do. Please read my previous emails. Designing everything in C will not help. Evolution, OpenOffice and Firefox are evidence that writing your app in C does not make it memory efficient. In the long term, a moving GC may be beneficial. At some point, we also have to realize that users with less memory do need to make compermises. For example, such a user might want to choose not to use Beagle. -- Ben ___ 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: Time to heat up the new module discussion
Em Qua, 2006-07-19 às 06:48 -0500, Sean Kelley escreveu: From an embedded developers standpoint working with Gnome as a part of the Gnome Mobile and Embedded group, C and C++ are extremely relevant for our devices. Mono like .NET are quite frankly a no go in terms of memory and performance. Sean Isn't that true for a lot of the modules in the current desktop set already? Cheers, Evandro ___ 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
[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. [snip] Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ 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 Well, you can't make C development as fast but that doesn't mean that all unmanaged languages are unsuitable for RAD. I'm trying to create a language[1] with many features from modern programming languages without any runtime overhead and it doesn't seem to be impossible. Jürg [1] http://www.paldo.org/vala/ ___ 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
Hi Lennart, I think there's come confusion about the libnss implementations... Lennart Poettering wrote: On Fri, 14.07.06 14:56, Darren Kenny ([EMAIL PROTECTED]) wrote: An example that effected us in Sun recently is Avahi - Avahi is excellent work and a good implementation of the Zeroconf networking stack - but it is very high level and has a dependency on D-Bus - so to implement something to support it's use in the nsswitch.conf file (that maps gethostent calls to files/dns/nis/ldap in a transparent way) we would have to include dependencies on LOADS of, what would be generally considered application layer APIs, in to an area that it simply wouldn't make sense (libnss tends to be VERY low down the stack in regards to APIs that people use). D-Bus in turn has a Python dependency - now while I know this is optional - it makes for a difficult argument as to how to package it, etc. Ahem, Avahi is actually a very bad example for your case. libnss-mdns doesn't depend on Avahi. libnss-mdns is much older than Avahi. libnss-mdns comes with its own mini-mDNS stack which implements enough to do host name resolution, but not much more. Recent versions of nss-mdns gained the ability to contact a running avahi server over a UNIX socket and use its cache. However, this is fully optional and detected during runtime, requires no common code and definitely no DBUS. I wasn't talking about libss-mdns - at least not your version, which is incompatible with Solaris' libnss implementation, so much that we have to write our own implementation from scratch. Of course we don't want to write everything, and as such would have liked to use the Avahi C API, but the Avahi developers don't guarantee stability levels in the core C API, so we in Sun can't use it. The only API you guarantee stability for is the D-Bus API. This is what I was referring to. You can run nss-mdns without avahi and vice versa. If you run both at the same time you get some extra functionality. libnss-mdns.so depends on libc.so and nothing else. Again, as I say, not the case when we wanted to write a new implementation... Darren. Lennart (who happens to be the developer of both libnss-mdns and Avahi) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Some python/mono AB history [was: Time to heat up the new module discussion]
Thanks Jason for the summary. I was on the Board during an Advisory Board meeting where the higher-level languages issues came to the fore. I think there may be a common misunderstanding or two about the python/mono issues which ought to be pointed out. * 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). I don't think the Anti-Mono folks are arguing against higher-level languages. Personally I think arguing against higher-level languages (in general) is pointless at this stage. * Python is there, so why not Mono? Anti-Mono folks argue that - in some ways (Deskbar) - including Python was a mistake. I think this is a serious misconception. It may be a minority view, but it isn't a consensus among those hesitant to include a Mono dependency in the official GNOME 2.16 release. In the Advisory Board meeting I am referring to, the higher-level-language issue was seen as a very big deal, a make or break issue for Gnome. At the time, Java and Mono were both being proposed, and the big issues were Java's freeness (or lack thereof), and Mono's .NET heritage/possible IP issues/etc. Call it politics if you like, the discussion was not about technical issues. Python was proposed, and accepted in theory, as the higher-level environment that was acceptable to all parties (if not the first choice of anyone at the table). In that respect, I don't think that Python's inclusion was intended as a precedent for Mono or Java, but rather as something that would defuse a potential crisis. In the meantime, things have changed a bit - there is arguably more time/experience for lawyers to grapple with Mono IP issues (real or imagined), or strategic issues of how a .NET technology might affect the future of GNOME. Great progress has been made with respect to Sun's new LDJ Java licensing. And Sun, at least, has agreements with MS which may make .NET technologies more palatable to Sun. I can't address the issue of Sun's official party line towards Mono/C#/.NET integration in its systems, but certainly for distros other than Sun I think the old objections haven't been diluted much. * 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. But not everyone agrees or believes the argument is closed. Just calling it FUD is not helpful either, unless the goal is for things to deteriorate into a flame war. This is still a divisive issue and we as a community should carefully weigh the benefit/cost of forcing the issue. IMO it requires more than one or even two killer apps (beagle? f-spot?) to make it worth the pain. * 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. I think the above argument is wrong on several counts. It seemed very clear to me over the years, and it was certainly a consensus in the Board/Advisory Board meetings I attended, that Java's freeness was the primary impediment to its adoption by Gnome in a meaningful way. Now that some of the freeness issues are being dealt with constructively, it's probably too late. On a pure-numbers basis there are lots more free Java apps floating around than C# apps (though I would agree that technical considerations might remain a barrier for Java). My point is that this issue has been around awhile, and the most important objections don't seem to be 'technical'. I think the 'general' question to answer here is about what sorts of technologies (with what licenses, from what sources, and with what potential politico-legal pitfalls) we can accept as Gnome dependencies. Having said this, I'd prefer if others continue the discussion (if continue we must). best regards, Bill ___ 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
Jason D. Clinton me at jasonclinton.com writes: * 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). There also another solution that seems to be completely ignored each and everytime in the equation: what about C++. C++ would allow lot of things to be done easier than in C (look are how many lines of code you need to write to just create a new gobject? why is there gob again?). That would probably solve lot of issues people have with maintaining or writing C application for Gnome. 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 required (Ekiga and AbiWord are good examples of C++ application using plain C APIs). On more advantage is that using C libraries comes for free. No need to write binding or wrapper or whatever to use them. And it is fairly easy to write C++ libraries that gets good C APIs Just to outline that managed language are not the only answer to C application are getting harder to maintain. Hub ___ 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 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 ... 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. Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ 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 07/14/06 Jamie McCracken wrote: Every compacting GC automatically doubles memory use - you have two managed heaps ergo twice the RAM required. If you copy MS and go for a three generation one then you risk trebling memory use over using a non-compacting one. This info is completely wrong. First, it is a particular kind of compacting GC that requires the double of the used memoryr: copying GC. Nobody uses that design for production. There are many alternative designs neither of which requires much more memory than the amount used, mostly the same amount wasted for fragmentation and bookeeping in malloc implementations. Usually a copying GC design is used only for the young generations in a generational GC design. The current mono code uses copying-like GC for the old generation, but this is only a temporary implementation to focus first on the support the runtime needs for a moving GC (it is only 200 lines of code and reuses the young generation GC code, so it helps with debugging). Later it will be implemented using mark-compact, which doesn't require any additional memory. Similarly, it's completely false that a three generation GC requires three times the memory, there is a lack of basic understanding of garbage collectors here. In the end you have to choose between fast garbage collection (and up to 6x memory use) or slow garbage collection with more modest RAM requirements - there is no perfectly efficient *and* fast GC out there and they have been searching for it for the last 50 years. There is no perfectly efficient *and* fast anything in computing that is not for extremely trivial issues, so not sure what value that remark has. There are several papers that show that GCs can be faster than explicit memory management with comparable memory overhead. lupus -- - [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better ___ 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: Time to heat up the new module discussion
Hubert Figuiere wrote: C++ is not taught in university, etc[2] This is wrong, I had a (quite deep) course of C++ this year at university. The course was primarily focused on the inner working of C++ (VTables, inheritence, inference, etc), basically what GObject reimplements in C ;-) Just for note. ___ 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 7/17/06, Jason D. Clinton [EMAIL PROTECTED] wrote: 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 ... He was just trying to correct your email. Your original email said that I spent two hours reading every email sent in April, May and July about including Mono as an official part of the GNOME platform which was misleading. We have a platform release (with certain API/ABI rules), a bindings release suite (with different API/ABI rules), and a desktop release. Mono has not been proposed for the platform release; it was proposed for the bindings release. Murray was just trying to clarify that. If you're still wondering about the dependency issues, it's basically this: Modules in the platform cannot depend on modules in the other two releases (that would violate the API/ABI constraints). Modules in the bindings release cannot depend on modules in the desktop (that would violate the API/ABI rules as well). desktop modules can depend on the platform modules, and, currently, can depend on the python bindings but not the others. The huge threads and arguments are about whether desktop modules should be allowed to depend on other bindings that are in or are proposed to be in the bindings release (in particular, Gtk#). ___ 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
I think using Star-Bellied Sneetches and Plain-bellied Sneetches would work well, if you're in to the whole brevity thing. -Alex Jason D. Clinton wrote: 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. ___ 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: Time to heat up the new module discussion
Hi, Ghee, On jeu, 2006-07-13 at 16:08 +0100, [EMAIL PROTECTED] wrote: Rodrigo Moya wrote: On Tue, 2006-07-11 at 14:16 -0600, Elijah Newren wrote: And the big question: We currently allow desktop modules to depend on the pygtk bindings, but no others. Should we extend that to include the gtk# ones (assuming, of course, that gtk# is added to the bindings set)? IMO we should allow modules to depend on any of the official bindings. What makes up of the official bindings? How does a bindings being made official? What is the process of making a binding offical? There's no official bindings. But we have the GNOME Bindings set: http://live.gnome.org/TwoPointFifteen/Bindings Inclusion is officially decided by the release team, but really, the community is deciding. You might be interested in the requirements: http://live.gnome.org/ReleasePlanning/ModuleRequirements/PlaformBindings Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Time to heat up the new module discussion
Hi, I'm glad to see the flamewar already started ;-) On mar, 2006-07-11 at 14:16 -0600, Elijah Newren wrote: So, to start of the discussion, the proposed modules AFAIR are: * orca (as a replacement to gnopernicus) Yes * alacarte It's better than the current menu editor. I guess we'll have to stop shipping the current one, then. * gnome-power-manager Yes. * Tomboy I honestly don't know :-) I'm wondering about what we'll do with the sticky notes applet since it might be redundant. * Gtk# Was Gtk# updated to bind GTK+ 2.10 (and other libraries)? There's one additional issue to address as well: * Okay to have desktop modules depend on gtk# bindings? I've no strong opinion for now. Well, my opinion is that we shouldn't look at it this way: we should stop delivering a fixed desktop set with apps A, B, C, ... But that won't help with this question right now ;-) Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 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: Time to heat up the new module discussion
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. Mono comes with a complete set of tools and the only reason we even have to have this debate is the excellence of the applications it enables us to ship... this is a luxury problem. The question isn't if we want to rewrite all of GNOME in C# but do we want the applications it enables us to ship or don't we. Yes, beagle sometimes eats small furry children for breakfast but we aren't debating beagle for inclusion.. yet, by the time we will being having that debate, naturally it would prudent to examine if it still displays grotesk ressource abuse and if we can fix it. We are specifically talking about Tomboy this time around. - David Nielsen ___ 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
Ben Maurer wrote: Yeah, 100% agree. That is exactly the problem: applications would use another framework rather than the one that they are suppose to use (we are speaking about GNOME apps). libxml is an XML library for *C* apps. It's not designed to be usable in any other language. Agree. So they use their libraries with their language. That's the point. I understand the desktop framework as the common infrastructure in which almost all the desktop applications are based on. If we move from a scheme in which there is an unique group of common stuff to one in which there are a few of them (GNOME, Python, Mono, Java?) it may become a little messy. IMO. We're not proposing Java. Don't try to inflate your numbers by putting stuff not under consideration in there. Of course, that was just an example. Actually, I put an interrogation mark after Java. However, if we accept the dependency of extra frameworks, it could end up being like that in a couple of years, so it wasn't a crazy idea either. First, let's observe that almost everyone seems to desire a move in the managed code direction. Microsoft has invested quite a bit of engineering effort into their Vista based framework. Sun is investing by improving Java on the desktop (including by making Swing apps look native in gtk, for Mustang/Java 6. This work is very impressive). IBM and Sun design processors, and that doesn't mean that we're on that business. BTW, if you read Sun's people arguments on this thread, it seems that they don't like much the idea. Novell's desktop now includes many Mono based applications. That is the right way. Novell should take advantage for their technology, not try force the rest to adopt it. -- Greetings, alo. http://www.alobbs.com ___ 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 Fri, 2006-07-14 at 18:58 -0400, Ben Maurer wrote: On Fri, 14 Jul 2006, Alvaro Lopez Ortega wrote: Yeah, 100% agree. That is exactly the problem: applications would use another framework rather than the one that they are suppose to use (we are speaking about GNOME apps). libxml is an XML library for *C* apps. It's not designed to be usable in any other language. I imagine Daniel wouldn't agree with that statement, since he maintains libxml2's Python bindings, right inside the libxml2 module on Gnome CVS, in fact. -- Shaun ___ 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
Ben Maurer wrote: On Fri, 14 Jul 2006, Nate Nielsen wrote: I'd imagine that those who have worked so hard on GNOME performance issues would be disappointed if they saw a C applet take 18 - 20 megs (resident) or take 10 seconds to load. PLEASE learn how to measure memory. Resident is *NOT* a good measure of memory. You must use smaps to even begin getting an accurate measurement. Not a single person other than Federico and myself have used a number about performance that is relevant. This suggests that there are many people `me too'ing and not thinking about what they are saying. If you want to make groundless claims, comment on slashdot. Setting aside the talking down for a moment, I think this is an important point... I'd wager that because the numbers and tools that come with the OS are so useless, many people shy away from saying any numbers at all, because they'll get shot down as irrelevant for some reason or another. Nate ___ 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
Le jeudi 13 juillet 2006 à 17:40 -0400, Dan Winship a écrit : [...] And if your argument is really languages that come with their own frameworks are bad, and not just I hate mono, then why didn't you argue against allowing python-based apps in the platform when that came up a year and a half ago? IIRC people have argued against Deskbar's inclusion for exactely the same reasons (in the panel, python VM is bloat), but flashiness prevailed. Xav ___ 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 7/15/06, Alvaro Lopez Ortega [EMAIL PROTECTED] wrote: Of course, that was just an example. Actually, I put an interrogation mark after Java. However, if we accept the dependency of extra frameworks, it could end up being like that in a couple of years, so it wasn't a crazy idea either. So, in a couple of years, if the java gtk+ bindings are good and there's a couple of really cool apps that take advantage of them, whats the problem if we let java apps in? I'd say that if it was started today, it would be 3 years before we reach that spot, what sort of systems will we be using in 3 years? I have no idea...I don't think we can let our fears of the unknown distant future shape our decisions today. ___ 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 Fri, 2006-07-14 at 18:58 -0400, Ben Maurer wrote: We're not proposing Java. ... No, but one of these days GNOME developers who happen to be working in Java on will be on the receiving end of the same discussion, so I for one appreciate the inclusiveness of the conversation. Sun is investing by improving Java on the desktop (including by making Swing apps look native in gtk, On the other hand, people working on applications in that use java-gnome are writing programs that *ARE* native in GTK. It's sort of a shame that through the last few years the bulk of apps written by people using java-gnome were in-house corporate projects, rather than generic applications targeted for widespread desktop usage. But there is a good level of continued interest and a number of public applications are coming along nicely. Pancake wrote a digital channel surfer called gDVB. Sean wrote evolution-data-server bindings and tied his Contacts viewer and vCard parser to it. I'm working on several apps targetted at small business operations and finance. And oh boy, wait until the execution analysis tool Frysk hits the big time. Amazing. So still under most people's radar, but serving a niche that's important to me: opening the GNOME ecosystem to new contributors. As for Sun's 1.6 efforts, all good, I guess - and something I wish they'd one circa Java 1.2. Oh well. And meanwhile, the Classpath hackers have a AWT Swing implementation with a GTK peer back end which is getting stronger and stronger, so even people working in Swing (yick) are getting closer to being able to create a vaguely GNOMEish app. It's a start. But we made a platform commitment to GNOME a long time ago and I'm happy working directly in [Java/]GTK. So there we are. [multiple simultaneous managed runtime environments] Is memory consumption and contention between multiple apps all running in various managed runtimes a concern? Theoretically, yes. As one who lives it in practice is it actually a problem? Surprisingly, no. But then, that's always been the point of the evil of premature optimization. AfC London -- Andrew Frederick Cowie Managing Director Operational Dynamics Consulting Pty Ltd http://www.operationaldynamics.com/ Management Consultants specializing in strategy, organizational architecture, procedures to survive change, and performance hardening for the people and systems behind the mission critical enterprise. Worldwide: Sydney+61 2 9977 6866 New York +1 646 472 5054 Toronto +1 416 848 6072 London+44 207 1019201 ___ 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 (from digest)
Hi, Alvaro Lopez Ortega said: BTW, if you read Sun's people arguments on this thread, it seems that they don't like much the idea. snip That is the right way. Novell should take advantage for their technology, not try force the rest to adopt it. I haven't seen any opinion from this person called Sun. Or a person called Novell. And I don't think it's helpful to think of this argument as a Sun vs Novell thing. Dave. -- Dave Neary [EMAIL PROTECTED] Lyon, France ___ 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 Thu, 13 Jul 2006, Ben Maurer wrote: On Thu, 2006-07-13 at 02:00, Ben Maurer wrote: [...] In the long term, Mono can potentially reduce our performance problems. In the short term, there are performance problems and Mono will worsen them. In the short term, Mono will deliver us applications many times more innovative than what we currently have. They might consume a bit more memory than what they would have if written in C. However, writing in them C would mean waiting much longer. If we can write the basic functionality faster, we have more time to spend on performance. I think both the mono platform and the python languages are great plat- forms. I also think they have certain usages, but with certain restric- tions: * Great platforms for ISV's to write applications. ISV's can specify mi- nimal system requirements (both in terms of memory and in terms of other platforms needed), and companies wishing to use those apps just have to adapt to those requirements (they can buy whatever hardware is needed, after all). We as gnome want our desktop to be usable on even low-end hardware, like that old pentium 2 sitting in the corner. * Great way to *prototype* an application. I myself intend to write a little app, but I would not want to impose python or mono restrictions on possible users. Initial implementation will probably be in python, but after the feature-set is complete it will be ported to C. The point here is: the thing you want to get right first is the application *logic* (how it behaves, the rules for interacting with the user). For this purpose, languages like python and the mono platform are great. * The core of the desktop should be in C (or possibly C++). This includes libraries, the panel, the core applets (like the clock, taskbar switch- er), nautilus (and probably some others). The user with his old pentium 2, who just requires a basic desktop, should never have to use python or mono. * Libraries should be in C no matter what. This excludes beagle for example. Reason for this: anything other than C pulls in extra libs, like libstdc++ etc, which make other language bindings a pain. Oh, and as a totally seperate personal gripe of mine (but also an example as of how to *not* do things): I would like the gnome-terminal dependency on libglade to be gone again. We had a perfectly working gnome-terminal without libglade several years ago. Then, for exactly no good reason, a libglade dependency was introduced. The reason it was introduced was pro- bably for (GUI) maintainability, which is totally void, as the GUI of gnome-terminal changed exactly zilch (or very little, which would have been easily made to the non-glade version), and as a result we have an extra dependency, and increased loading time. This is the exact opposite of what I would like to see happen (and have touched upon shortly above: reducing dependencies, and prototyping in a high-level language, following a reimplementation in a lower-level lan- guage): we had a perfectly working code base, and the GUI part had been static for years, still *is* static, and is most likely to be static for the rest of its life. There was exactly nothing (or extremely little) to be gained from this change. kr, Chipzz AKA Jan Van Buggenhout -- UNIX isn't dead - It just smells funny [EMAIL PROTECTED] Baldric, you wouldn't recognize a subtle plan if it painted itself pur- ple and danced naked on a harpsicord singing 'subtle plans are here a- gain'. ___ 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
Ben Maurer wrote: Mono will *not* be taking resources from the current GNOME community. Even if there is on occasion, a but in Mono that needs to be fixed, it seems that this is a net win given the increased development speed. I'm sure Joe Shaw, Aaron Bockover, and Larry Ewing (among many others) would attest to the benefit which Mono has provided as they developed applications. Let's be sincere. Mono does not provide more benefits than what Java has been providing since more than a decade.. and we have not used it. Nobody joint the GCJ or Classpath library effort, and basically nobody cared about it. How many Desktop Java based applications has you used in the last few years? Ok, and now, think again in all those benefits that Mono is supposed to bring to us. It makes increasingly less sense to write applications in C. If you look at where the interesting and innovative development has been in terms of applications in GNOME, virtually zero of them are C apps. They're all either Python or Mono. This isn't a coincidence. For me the problem is not the language, but the addition framework. So, given the choice of: - virtually zero...interesting and innovative development or - Two frameworks You are suggesting less innovative development? There is absolutely nothing suggesting that over the next 5 years, C applications will become easier to develop. On the other hand, substantial improvements in managed languages (such as generics, and the many enhancements coming in C# 3.0). Think of another desktop, choose the one you want.. let's say KDE: it's one framework, one desktop and innovative applications. So, yeah, rather than something strange, it's the usual business for everybody else. Does it make sense to you to use have three or four different DOM parsers in memory at the same time? (libxml2, python, mono and java for example). First, java is not under consideration at this point. Let's not cloud the discussion with off-topic issues. Currently, python and mono are where the innovation that Joe has been talking about is happening. Yeah, we are arguing about different things. Actually, you worry about pushing for Mono, and I'm worrying about stopping any new dependency for the GNOME framework on a third party one. The Mono case is exactly the same as the Python or the Java one; and from my point of view all them carry the same set of problems to GNOME: Huge dependencies, resource wasting, and the bast amount of APIs in which the applications will be based and that are controlled by somebody else (API may change, ABI may be broken, etc). By the way, I have no idea.. I'm just wondering.. Isn't the Mono Class libraries bigger than the GNOME ones. Wouldn't it look weird to depend on a secondary framework bigger than itself? -- Greetings, alo. http://www.alobbs.com ___ 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
Dan Winship wrote: Does it make sense to you to use have three or four different DOM parsers in memory at the same time? No, it doesn't, but we already have three XML(ish) parsers linked into every C-based GNOME app (libxml2, expat, and GMarkup). And yet, GNOME is *better* now than it was when we only had one XML parser. I bet guys running GNOME in old computers wouldn't agree with this. the problem is that there are many other pieces that are also overlapping with the GNOME framework, and that can do nothing but mess up the desktop. How exactly are these apps going to mess up the desktop? Let's take Tomboy, since it's on the table. What *precisely* does Tomboy do that messes up the desktop (that it wouldn't do if it was written in C)? And if your argument is really languages that come with their own frameworks are bad,and not just I hate mono, then why didn't you argue against allowing python-based apps in the platform when that came up a year and a half ago? I missed it. :-/ Actually, what is puzzling me is that nobody else did it. You cannot even imagine how many people think like this.. I guess there are too many interests around these adoptions, I don't know. In any case, IMHO using Python to develop basic desktops applications is as wrong as using Mono or any other framework. And, don't take me wrong. I said *basic* desktop applications. Projects like Alacarte are okay; those are applications that you may use once a week/month. However, when we speak about an applet that will be loaded each single time you boot for PC things change. We ought to be extra careful with those. -- Greetings, alo. http://www.alobbs.com ___ 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
Steve Frécinaux wrote: Ben Maurer wrote: Please read my previous emails. Designing everything in C will not help. Evolution, OpenOffice and Firefox are evidence that writing your app in C does not make it memory efficient. In the long term, a moving GC may be beneficial. Does using a GC really mean you have to use a big bloated memory-hungry virtual machine ? Well, no. Inkscape uses a GC, and it is written in C++. D should provide a GC while not resting on a VM. Thats right GC is not specific to mono/jave or managed runtimes. D language proves you can have the same RAD, GC and ease of use of managed languages but with native code and none of the significant overhead of managed code nor its big bloated runtimes. (on windows I use Delphi which is very similiar to D in design and it totally blows away .net and java in every area - startup speed, overall speed, memory usage and non bloatedness) The we need managed code is a total myth on the *desktop* - there are no benefits only disadvantages. On the server its a different story where you might need the sandboxing features of managed code to create secure web services. But like you said, Im not objecting to mono going into the desktop as such - Im just dispelling some of the myths. If ever VM were able to share libs, it would be a great improvement, but currently they can't. It means the managed part of the code is loaded for every managed app you launch. Which is far from optimal in the case of permanently running apps. As I said, I don't care about apps that don't stay alive in background. At some point, we also have to realize that users with less memory do need to make compermises. For example, such a user might want to choose not to use Beagle. I don't use Beagle, and in fact I hope the alternate Tracker project will solve this problem. It already does - tracker uses a tiny 3-6 MB RAM and provides considerably faster indexing and search retrieval of results. I developed it for use on my 256MB notepad so its designed from scratch to be super memory efficient. -- Mr Jamie McCracken http://jamiemcc.livejournal.com/ ___ 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
Ben Maurer wrote: On Fri, 14 Jul 2006, [ISO-8859-1] Steve Fr�cinaux wrote: Ben Maurer wrote: Please read my previous emails. Designing everything in C will not help. Evolution, OpenOffice and Firefox are evidence that writing your app in C does not make it memory efficient. In the long term, a moving GC may be beneficial. Does using a GC really mean you have to use a big bloated memory-hungry virtual machine ? Here we go with the X is bloated track again. I'm sure that gtk+ is very bloated because evolution is memory hungry. evolution is a badly designed app which suffers terribly from featuritis. I dont mean any disrespect nor do I portion any blame towards its developers cause evolution predates gnome 2's simplification phase and was designed to compete with MS outlook. Evo should be split into several seperate apps - one for mail reading others for organiser style apps. Its overkill if all you want is a tool to read your mails. (I dont use evolution as a result) Well, no. Inkscape uses a GC, and it is written in C++. It's fairly hard to do this. A moving gc in C++ would be even harder. If ever VM were able to share libs, it would be a great improvement, but currently they can't. It means the managed part of the code is loaded Mono can do this. Read about AOT AOT is not widely used because it does not offer the same performance of JIT for every managed app you launch. Which is far from optimal in the case of permanently running apps. Even when we are not AOTing, the amount of ram dedicated to JITed code is small. If you are going to bitch, bitch with NUMBERS. The only performance data on this thread was the vmsize of a few applets, which means absolutely nothing. Jits on the desktop are usually bad not just because they do take more memory but also because you need the build system of mono installed which means more bloat. Just as a number for starters: when launching banshee without AOT, it takes 600 kb of JITd code space. Let's say it's really more like 1 MB after lots of use (probably higher than it actually is). Maybe there are 4 managed apps (Banshee, F-Spot, Beagle, Tomboy). That's 4 MB vs 1 MB if 100% of it was shared as in C. Not a lot. In the long term, we'll probably get more of a win with compacting from a GC than this. Every compacting GC automatically doubles memory use - you have two managed heaps ergo twice the RAM required. If you copy MS and go for a three generation one then you risk trebling memory use over using a non-compacting one. (malloc and free do not return memory to the OS on linux and most other systems - the memory is retained for reuse for the app). Mmap'ping blocks of memory can be returned to the OS but they are at least 5x slower than malloc/free and are only worth using with memory pools. In the end you have to choose between fast garbage collection (and up to 6x memory use) or slow garbage collection with more modest RAM requirements - there is no perfectly efficient *and* fast GC out there and they have been searching for it for the last 50 years. -- Mr Jamie McCracken http://jamiemcc.livejournal.com/ ___ 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 Thu, 2006-07-13 at 20:45 +0100, Alvaro Lopez Ortega wrote: Joe Shaw wrote: It is a very different situation. While the power manager support provides new functionality, GTK# would only provide duplicate functionality for another development framework that overlaps with GNOME. Perhaps I am misunderstanding, but this argument doesn't make any sense to me. Gtk# isn't an application, so by itself it's not useful and doesn't really duplicate anything. It does provide a native API to Gtk#, but traditionally language bindings have been considered a strength of GNOME. Gtk# calls into Gtk+, so it's not like we have two competing implementations of the toolkit here. I don't see the duplicate functionality here. My mistake, I didn't explain it correctly. What I meant was that the group of Gtk# plus Mono overlaps with a big chunk of the desktop. My understanding is that GNOME is a development framework and Mono is another one completely unrelated. Both of them have quite big class libraries: XML parsers, string management, asynchronous I/O, etc. Of course it is possible to use both of them for writing a single cool application, although it doesn't seem to be technically correct because of all the duplicate code: there would way too many unneeded possible failure points and wasted resources. you are right, but what is so different with Mono that this wasn't raised when Python was included? -- Rodrigo Moya [EMAIL PROTECTED] ___ 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
Iain * wrote: On 7/12/06, Darren Kenny [EMAIL PROTECTED] wrote: I'm concerned about the inclusion of GTK# - and hence all the rest of Mono into the core GNOME. It doesn't pull mono into the core of gnome anymore than having python applets pulls python in. You are correct, it doesn't but that doesn't make it right - I'm not that happy about Python being in the core desktop which is why I mentioned about breaking things up into Core GNOME and others. And it worries me that this is opening a door for a slew of C# based applications into the core GNOME. And this is a bad thing because...? I'm not totally against C# applications themselves - what I am for is choice. I don't think any thing other than C should be part of Core GNOME - to put anything other than C into here can cause loads of problems - what happens if we start to do all our main development in C# (or anything else for that matter) going forward, then less and less of GNOME will be re-usable without Mono since all the innovation will be in C#. This is why I think we need a definition of what is core... An example that effected us in Sun recently is Avahi - Avahi is excellent work and a good implementation of the Zeroconf networking stack - but it is very high level and has a dependency on D-Bus - so to implement something to support it's use in the nsswitch.conf file (that maps gethostent calls to files/dns/nis/ldap in a transparent way) we would have to include dependencies on LOADS of, what would be generally considered application layer APIs, in to an area that it simply wouldn't make sense (libnss tends to be VERY low down the stack in regards to APIs that people use). D-Bus in turn has a Python dependency - now while I know this is optional - it makes for a difficult argument as to how to package it, etc. Now while there are ways to combat this - it's a prime example of where there is a severe overlap in things, and where it makes sense for projects to be broken in to core and non-core elements so that it's clear how to break things up if needed into the parts that simply can't be done without and the parts that are optional - configure is fine for some cases, but it doesn't make it easy to deliver things when a customer decides that they want the zero-conf networking without a desktop platform (CDE/KDE/GNOME) installed. It makes sense to me that Mono should remain on the out-skirts of GNOME for this very reason - core GNOME should only use native languages, and more specifically C, as to to do otherwise is likely to effect the already perceived poor performance of GNOME. Python is already used in the deskbar applet which is in core GNOME. So? Again, this is where it shouldn't be - it should be in the Python GNOME area... Just think about what happens when a user logs into a desktop that has Python and C# based applets included with C based applets: - The panel starts - It starts C/Bonobo based applets - the smallest of which already consumes approx 40Mb of memory. - It starts Python applets - each of these takes up approx 70Mb of memory - and very little of this is shared - It starts a C# based applet - and this pulls in Mono, which I'm sure isn't that small, but I guess at least it does share memory better than Python, but there is still quite a lot of additional memory pulled in. Then...umm, don't run them? That sounds fine, but if we keep developing things in something other than C, which are more than just prototypes, then there won't be much choice left, will there? I know today people say that memory is cheap, but I think that's not an excuse for working on reducing it's consumption. Limiting memory usage by limiting features is kinda a pyrrhic victory. Well, yes, we only have one button on screen, but damn we don't use any memory Maybe on a single machine, but we, in Sun here also have to seriously consider the multi-seat machine (like Sun Ray), and I'm sure other commercial companies would be interested here too. So running lots of copies of applications that have their own platform, with their own busy idle loops (garbage collection) and so on, it becomes a major issue when there are 100 users on the one machine fighting for that tiny slice of time they might get to do some processing. Also, there is the small devices like the Nokia 770 for which memory consumption is a big factor. As far as I know, no-one is attempting to run the gnome panel and python/mono applets on a 770. Yes, but if we keep developing things which are being considered major pieces of functionality in something other than C, these devices will have to invest serious effort in writing their own alternative that could be. The whole point of these devices using GNOME is to be able to provide some of the core GNOME apps on a small device, otherwise they may as well be using their own toolkit and ignore GNOME - which I think is exactly what we wouldn't want to
Re: Time to heat up the new module discussion
Rodrigo gently raises the seminal question, What is so different?. The answer is known: It is that enormous elephant standing in the corner that folks have been politely tip-toeing around, trying to ignore. The Mono project ultimately advances the interests of Microsoft, a company that is no friend to the open source movement. I question whether it is prudent for GNOME to be complicit. That being said... Mono may develop enough of a critical mass following where advancing the interests of Microsoft through Mono becomes a non-issue. Languages and frameworks come and go. We Shall see. What to do??? I would decompose GNOME into the union of two sets: core and extras. Core should be developed using a tool-chain and languages that are readily available and universally accepted on all *nix platforms: * GNU tool chain * C, C++ * bash, python, perl Extras, as the name implies, can be developed using whatever language(s) or framework(s) that one chooses. The acceptance of an extra by the user community will depend upon what that extra does and how easy it is to satisfy the external dependencies in order to run that extra. Core applications should comply to a [rigorous ???] set of standards. Extra applications should be given some slack. Both types of applications should adhere to GNOME coding [???], packaging, and testing standards. An extra may or may not be sanctioned by GNOME. A sanctioned extra is one that is blessed by GNOME and is available from gnome.org [cvs ftp]. A sanctioned extra should adhere to a set of standards that GNOME dictates for a sanctioned extra. Just some thoughts... -Joseph = On Fri, 2006-07-14 at 14:37 +0200, Rodrigo Moya wrote: you are right, but what is so different with Mono that this wasn't raised when Python was included? -- joseph_sacco [at] comcast [dot] net ___ 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
Chipzz, This is exactly the way I feel about things. Mono and Python etc are all very good in their own way, but I really don't see why they need to be part of the core GNOME desktop - this was why I wanted to break down the GNOME desktop into various groupings - so ISVs, etc. can make their own mind up about what they wish to depend upon. Someone mentioned that everyone is already shipping Mono - but that's not true either - maybe many of the major Linux distros are - but what about others like maemo, RedHat Enterprise Linux (don't know the plans on this in the future though) and Solaris. There are too many legal risks with a full Mono platform - some parts are fairly open, but there are others which are not - it's this latter part that worries us here in Sun the most (at least that's my view on things) - we're sick of fighting with MS and we don't want to give them yet another reason for one ;) Again - this is why I think there needs to be the choice to say No to mono - it may be that we do consider doing something - but we certainly don't want to be forced into it. Darren. Chipzz wrote: On Thu, 13 Jul 2006, Ben Maurer wrote: On Thu, 2006-07-13 at 02:00, Ben Maurer wrote: [...] In the long term, Mono can potentially reduce our performance problems. In the short term, there are performance problems and Mono will worsen them. In the short term, Mono will deliver us applications many times more innovative than what we currently have. They might consume a bit more memory than what they would have if written in C. However, writing in them C would mean waiting much longer. If we can write the basic functionality faster, we have more time to spend on performance. I think both the mono platform and the python languages are great plat- forms. I also think they have certain usages, but with certain restric- tions: * Great platforms for ISV's to write applications. ISV's can specify mi- nimal system requirements (both in terms of memory and in terms of other platforms needed), and companies wishing to use those apps just have to adapt to those requirements (they can buy whatever hardware is needed, after all). We as gnome want our desktop to be usable on even low-end hardware, like that old pentium 2 sitting in the corner. * Great way to *prototype* an application. I myself intend to write a little app, but I would not want to impose python or mono restrictions on possible users. Initial implementation will probably be in python, but after the feature-set is complete it will be ported to C. The point here is: the thing you want to get right first is the application *logic* (how it behaves, the rules for interacting with the user). For this purpose, languages like python and the mono platform are great. * The core of the desktop should be in C (or possibly C++). This includes libraries, the panel, the core applets (like the clock, taskbar switch- er), nautilus (and probably some others). The user with his old pentium 2, who just requires a basic desktop, should never have to use python or mono. * Libraries should be in C no matter what. This excludes beagle for example. Reason for this: anything other than C pulls in extra libs, like libstdc++ etc, which make other language bindings a pain. Oh, and as a totally seperate personal gripe of mine (but also an example as of how to *not* do things): I would like the gnome-terminal dependency on libglade to be gone again. We had a perfectly working gnome-terminal without libglade several years ago. Then, for exactly no good reason, a libglade dependency was introduced. The reason it was introduced was pro- bably for (GUI) maintainability, which is totally void, as the GUI of gnome-terminal changed exactly zilch (or very little, which would have been easily made to the non-glade version), and as a result we have an extra dependency, and increased loading time. This is the exact opposite of what I would like to see happen (and have touched upon shortly above: reducing dependencies, and prototyping in a high-level language, following a reimplementation in a lower-level lan- guage): we had a perfectly working code base, and the GUI part had been static for years, still *is* static, and is most likely to be static for the rest of its life. There was exactly nothing (or extremely little) to be gained from this change. kr, Chipzz AKA Jan Van Buggenhout ___ 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
Rodrigo Moya wrote: It is a very different situation. While the power manager support provides new functionality, GTK# would only provide duplicate functionality for another development framework that overlaps with GNOME. Perhaps I am misunderstanding, but this argument doesn't make any sense to me. Gtk# isn't an application, so by itself it's not useful and doesn't really duplicate anything. It does provide a native API to Gtk#, but traditionally language bindings have been considered a strength of GNOME. Gtk# calls into Gtk+, so it's not like we have two competing implementations of the toolkit here. I don't see the duplicate functionality here. My mistake, I didn't explain it correctly. What I meant was that the group of Gtk# plus Mono overlaps with a big chunk of the desktop. My understanding is that GNOME is a development framework and Mono is another one completely unrelated. Both of them have quite big class libraries: XML parsers, string management, asynchronous I/O, etc. Of course it is possible to use both of them for writing a single cool application, although it doesn't seem to be technically correct because of all the duplicate code: there would way too many unneeded possible failure points and wasted resources. you are right, but what is so different with Mono that this wasn't raised when Python was included? Nothing is different. That's exactly why we shouldn't make the same mistake twice. I have nothing against Mono. Actually, you know that I'd think the same if it was Java, Perl, or whatever other high level language caring another bast class library and/or execution environment. Let's keep GNOME neutral and fast.. and then it will be up to each distro or operating system to add their own bits each (written in Python, Mono, Java, ..). We ought to reach the complete consensus before accepting the dependency on a framework that is probably bigger than the GNOME framework itself. -- Greetings, alo. http://www.alobbs.com ___ 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
Hello, Let's be sincere. Mono does not provide more benefits than what Java has been providing since more than a decade.. and we have not used it. Nobody joint the GCJ or Classpath library effort, and basically nobody cared about it. This is a bogus statement. Dan already posted the list of applications using Mono and Java from gnomefiles.org. 110 python/pygtk apps/libs 59 mono/C#/gtk# 37 gtkmm/C++ 27 perl 16 java 5 ruby So what about using facts and figures instead of empty rhetorical statements. Now, regarding why people have not helped free Java, I have covered that in the past in my blog. But here is a summary: Mono has benefited from two kinds of contributors: believers in free software and people that wanted to get their critical .NET application running on Mono.Free Java on the other hand has suffered because they only have the believers of free software helping them. The pragmatists just happen to run proprietary java. That is why you see a different level of caring between free Java and free .NET. How many Desktop Java based applications has you used in the last few years? Ok, and now, think again in all those benefits that Mono is supposed to bring to us. Azureus and Eclipse come to mind. I personally use these Mono apps: last-exit, banshee, beagle, f-spot, gfax, gimp# (it runs PhotoShop plugins) and tomboy. (And a couple more of Novell ones, but I doubt you care about those) Think of another desktop, choose the one you want.. let's say KDE: it's one framework, one desktop and innovative applications. So, yeah, rather than something strange, it's the usual business for everybody else. The KDE guys have no problems including Mono bindings (or Ruby, or Java, or JavaScript, or Python ones or Perl ones): http://developer.kde.org/language-bindings/ As for the Mono ones, they are actually on their second iteration (Qt# first, Kimono is the new one): http://www.kdedevelopers.org/node/2090 So maybe your KDE example is not the best one of a desktop that does not bring third-party frameworks into their system. The Mono case is exactly the same as the Python or the Java one; and from my point of view all them carry the same set of problems to GNOME: Huge dependencies, resource wasting, and the bast amount of APIs in which the applications will be based and that are controlled by somebody else (API may change, ABI may be broken, etc). By the way, I have no idea.. I'm just wondering.. Isn't the Mono Class libraries bigger than the GNOME ones. Wouldn't it look weird to depend on a secondary framework bigger than itself? The Linux Kernel and libc are also larger than Mono. That a weird dependency. Miguel. ___ 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 7/13/06, Dan Winship [EMAIL PROTECTED] wrote: Alvaro Lopez Ortega wrote: Does it make sense to you to use have three or four different DOM parsers in memory at the same time? No, it doesn't, but we already have three XML(ish) parsers linked into every C-based GNOME app (libxml2, expat, and GMarkup). And yet, GNOME is *better* now than it was when we only had one XML parser. But doesn't it really SUCK for developers that they have to learn three different XML parsers? Similarly, wouldn't it really SUCK for the Gnome project as a whole if each and every component was implemented in a different language? I very much like Python and have never used Mono/C#. But I would very much rather see Mono/C# (or Java.. yuck!) chosen as THE managed language to use in the Gnome platform than have to deal with two or more managed languages and their class libraries. -- mvh Björn ___ 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 7/14/06, Darren Kenny [EMAIL PROTECTED] wrote: And it worries me that this is opening a door for a slew of C# based applications into the core GNOME. And this is a bad thing because...? I'm not totally against C# applications themselves - what I am for is choice. I don't think any thing other than C should be part of Core GNOME - to put anything other than C into here can cause loads of problems - So, by limiting choice you are attempting to promote choice? what happens if we start to do all our main development in C# (or anything else for that matter) going forward, then less and less of GNOME will be re-usable without Mono since all the innovation will be in C#. All the innovation is in C# (and python...) - Gimmie - Deskbar - Tomboy - Banshee/Muine - Jokosher Compare the speed that Jokosher has progressed in 4 months with the length of time its taken me to get Marlin anywhere (about 4 years, on and off). Yes, they have different aims and Jokosher has more people and isn't as advanced, but I think its interesting. In fact I have been tempted to rewrite Marlin in C#, but we'll see. D-Bus in turn has a Python dependency - now while I know this is optional - it makes for a difficult argument as to how to package it, etc. It doesn't anymore, the bindings have been moved out, but, this is a minor packaging issue, which as far as I can tell, both ubuntu and maemo have managed to solve, so I'd imagine the people at Sun can do as well. Python is already used in the deskbar applet which is in core GNOME. So? Again, this is where it shouldn't be - it should be in the Python GNOME area... Maybe you're missing the meanings here... There are two current splits - platform - desktop Platform is the libraries and these are in C. Only C and don't think that is changing anytime soon. Desktop is applications and some other libraries. Platform is core the stuff you can't do without Desktop is optional, you can install bits of it and not install other bits. We're talking here about putting stuff into the Desktop platform. I don't see what advantage splitting things anymore would do. If people want application XYZ then they have to install application XYZ. If it has dependancies they don't like, then they don't get to use application XYZ. That sounds fine, but if we keep developing things in something other than C, which are more than just prototypes, then there won't be much choice left, will there? Thats life...if we limit stuff to C then we're not going to get anywhere, because really, C sucks (and this is speaking as someone who has coded in C for 13/14 years). Maybe on a single machine, but we, in Sun here also have to seriously consider the multi-seat machine (like Sun Ray), and I'm sure other commercial companies would be interested here too. So running lots of copies of applications that have their own platform, with their own busy idle loops (garbage collection) and so on, it becomes a major issue when there are 100 users on the one machine fighting for that tiny slice of time they might get to do some processing. So, yes, things need optimised and improved, no-one is arguing against that. But, if that really is your worry, then don't install the software you don't like. That is your choice ultimately. As for .NET, even Microsoft themselves had to pull back from using it for core functionality due to performance reasons - why do we think we will do any better? As someone who is running mono based applications fairly regularly, I haven't noticed any major performance issues. We're not talking here about replacing the core libraries with c# based ones, we're talking about applications, and for me the mono based apps are just as fast as the C based ones. Again, you're probably one user on one machine - we need to think out side of the box on your desk. The claim was that Microsoft themselves had to pull back from using it for core functionality due to performance reasons. I don't imagine those performance reasons were on multiuser application systems, so I was responding within the same context. iain ___ 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
Ben Maurer wrote: Hey, On Wed, 12 Jul 2006, Darren Kenny wrote: It's been mentioned many times before that we already have too many component models in the GNOME platform - and once they are in there, it's VERY hard to get them back out again - just look at Bonobo. Bonobo is, by design, intended to be used in many applications. I don't think this applies as much to Mono. Not yet - but this is where I think we need the separation between Core GNOME. It makes sense to me that Mono should remain on the out-skirts of GNOME for this very reason - core GNOME should only use native languages, and more specifically C, as to to do otherwise is likely to effect the already perceived poor performance of GNOME. Excess memory usage has not stoped us from using alot of things -- VFS, Bonobo, etc. Many of the other modules under consideration add their own memory usage to the base desktop -- for example, accepting power manager gives us yet another daemon which takes up a few megs of ram. Distros are being even more aggressive about adopting these new programs (network manager, notification daemon). Not in all cases - and one daemon running on a machine is very different to lots of libs loaded - and the non-shared memory that comes with this. In fact I'd be all for the use of more daemons if it saved all apps having to load lots of libraries - the loading would be limited to one place! Again I think people seriously need to get out of the mind-set that there is only one desktop user on a machine - so a couple of meg for 1 user isn't a lot - but for 100 users on a single machine (even with 256Mb of RAM per user) there is a huge impact in that tiny additional platform being loaded. This is a major issue for us in Sun since we have to effectively disable the use of such things and also the use of busy idle apps (i.e. ones that poll every second or so) since the CPU share that is available to each user here is tiny... This is why we need a Core GNOME that isn't dependent on such frameworks. While I understand that Sun Ray is a special case, it's a valid case - even thinking of several VNC sessions on a single machine or some of those new machines with multiple keyboard/mouse and display combinations directly attached... Just think about what happens when a user logs into a desktop that has Py thon and C# based applets included with C based applets: - The panel starts - It starts C/Bonobo based applets - the smallest of which already consumes approx 40Mb of memory. - It starts Python applets - each of these takes up approx 70Mb of memory - and very little of this is shared These numbers are clearly vmsize, which don't make much sense. OK, they are - but each one of the had to map that much into memory before it could be figured out which parts could be shared - so there is still a cost in running them, and maintaining them. Also there is still quite a bit not shareable - as much as 8/10 MB - so for 10 applets (which is quite possible) that's 100Mb - and this is for the C based applets [I still think there must be a way to resolve this, but that's another story] - then for each python applet or Mono applet, you can add a considerable larger set of initial libraries (this contributes significantly to start-up/login time, but I admit mainly for the first-time run) and then more RSS for the platforms own processing space. Also then most of these have garbage collection routines - so they have the need to do that when supposedly idle, and so end up using more CPU - again i draw your attention to the multi-seat machine. - It starts a C# based applet - and this pulls in Mono, which I'm sure isn't that small, but I guess at least it does share memory better than Python, but there is still quite a lot of additional memory pulled in. Mono does *quite* a bit better than python in terms of memory for a Gtk# application (vs pygtk). Look at: http://bugzilla.gnome.org/show_bug.cgi?id=346211. Deskbar applet takes 13 MB of ram at startup. This has not stopped us from accepting it. Yes, and I still don't think it should be in Core GNOME, as I said I'd like to see these other platforms as being outside of the Core GNOME. Innovation comes slowly. Performance tuning is often one of the last steps of polish. I think it's clear that much innovation is coming from applications written in managed languages. Bringing in Mono will allow greater innovation in the GNOME platform. Yes, innovation comes in the form of prototypes - that doesn't mean the final solution should also use these - e.g. in MS Windows how many final applications use VB, most used VB for the prototyping, but then switched to C++/MFC for the final versions. This is where I think the main strength of C# or Python lie. In the long term, Mono can potentially reduce our performance problems. It is often easier to make performance changes in a managed language due to the cleaner
Re: Time to heat up the new module discussion
Iain * wrote: On 7/14/06, Darren Kenny [EMAIL PROTECTED] wrote: And it worries me that this is opening a door for a slew of C# based applications into the core GNOME. And this is a bad thing because...? I'm not totally against C# applications themselves - what I am for is choice. I don't think any thing other than C should be part of Core GNOME - to put anything other than C into here can cause loads of problems - So, by limiting choice you are attempting to promote choice? :) In a way, yes - if we didn't have the original GNOME desktop and libraries written in C we could have had so many language bindings in the first place? How many language bindings exist for KDE that didn't first have to present a C API to enable the binding... It's important to make the right decisions to enable maximum volume - Mozilla uses C++, but in a VERY limited and strict way - this is enable it to be compiled by the majority of C++ compilers on the market and still be compatible. what happens if we start to do all our main development in C# (or anything else for that matter) going forward, then less and less of GNOME will be re-usable without Mono since all the innovation will be in C#. All the innovation is in C# (and python...) - Gimmie - Deskbar - Tomboy - Banshee/Muine - Jokosher Compare the speed that Jokosher has progressed in 4 months with the length of time its taken me to get Marlin anywhere (about 4 years, on and off). Yes, they have different aims and Jokosher has more people and isn't as advanced, but I think its interesting. In fact I have been tempted to rewrite Marlin in C#, but we'll see. You are comparing prototyping with product ready code - again I bring up the how many good MS Windows apps are written in VB - you'll find many did the UI first in VB first - to prototype it - an then changed to a MFC/C++ for the final implementations... D-Bus in turn has a Python dependency - now while I know this is optional - it makes for a difficult argument as to how to package it, etc. It doesn't anymore, the bindings have been moved out, but, this is a minor packaging issue, which as far as I can tell, both ubuntu and maemo have managed to solve, so I'd imagine the people at Sun can do as well. Python is already used in the deskbar applet which is in core GNOME. So? Again, this is where it shouldn't be - it should be in the Python GNOME area... Maybe you're missing the meanings here... There are two current splits - platform - desktop Platform is the libraries and these are in C. Only C and don't think that is changing anytime soon. Desktop is applications and some other libraries. Platform is core the stuff you can't do without Desktop is optional, you can install bits of it and not install other bits. We're talking here about putting stuff into the Desktop platform. I don't see what advantage splitting things anymore would do. If people want application XYZ then they have to install application XYZ. If it has dependancies they don't like, then they don't get to use application XYZ. Yes, but there is a Core Desktop - I think we need a definition of this - could you consider a desktop running without metacity or gnome-panel or gnome-session as GNOME - I wouldn't think so. Applets are fairly core here - most people need the taskbar, the notification area, the date/time, the volume control, etc. - without these the desktop isn't very GNOME like, is it? If you aren't interested in a language split, then I think we should at least have a Core GNOME Desktop definition. That sounds fine, but if we keep developing things in something other than C, which are more than just prototypes, then there won't be much choice left, will there? Thats life...if we limit stuff to C then we're not going to get anywhere, because really, C sucks (and this is speaking as someone who has coded in C for 13/14 years). True - it sucks for many things - but it has it's strengths too - the main one on Unix being that it's core to the whole platform, most languages support binding to it, usually right out of the box because of this... Maybe on a single machine, but we, in Sun here also have to seriously consider the multi-seat machine (like Sun Ray), and I'm sure other commercial companies would be interested here too. So running lots of copies of applications that have their own platform, with their own busy idle loops (garbage collection) and so on, it becomes a major issue when there are 100 users on the one machine fighting for that tiny slice of time they might get to do some processing. So, yes, things need optimised and improved, no-one is arguing against that. But, if that really is your worry, then don't install the software you don't like. That is your choice ultimately. It only is if we can be sure that the Core Desktop isn't being overrun with non-C elements - once we start to move outside that box the choice
Re: Time to heat up the new module discussion
On 7/14/06, Darren Kenny [EMAIL PROTECTED] wrote: Mono and Python etc are all very good in their own way, but I really don't see why they need to be part of the core GNOME desktop - this was why I wanted to break down the GNOME desktop into various groupings - so ISVs, etc. can make their own mind up about what they wish to depend upon. They already can. Don't like mono...don't ship mono applications. None of the libraries will depend or use mono. This is not about choice. ___ 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 7/14/06, Darren Kenny [EMAIL PROTECTED] wrote: Someone mentioned that everyone is already shipping Mono - but that's not true either - maybe many of the major Linux distros are - but what about others like maemo, Maemo uses the gnome-platform libraries. it does not make sense to use the gnome-desktop applications on it. iain ___ 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
Hello, Am not quite sure what you mean by the build system of Mono, there is no such thing as the build system of mono. Maybe you mean that you need to have the mono command installed? That + all the assemblies. Ok, so the runtime libraries. These are in no way different to any of our libraries that includes more than the shared library: they include pixmaps, data files, glade files, configuration files, schemas and so on. Contrast with GCJ which links in only whats needed to create a compact native stand alone executable - that is what AOT should be IMO. (is the SoC project to create a linker basically this?) No, the SoC code is for a different purpose. Its used for people that might want to embed Mono into a smaller space, or want to create smaller/larger libraries by linking one or more assemblies into one (for instance, the Compact profile of Mono will be created by passing a list of classes and methods to the linker). so in other words it will spike every now and again EG if under Boehm GC I have 50MB heap then in compacting mode its going to spike from 50 to 100+ MB (how much higher depends on the no. of generations you have and how incremental it is of course) Yes, but the spike is not 2x the memory you have allocated. The spike is the size of the nursery (512k). Im not sure how this helps mono though except maybe you can claim it will be faster. A compacting collector helps long running applications by returning unused memory to the OS. Memory that typically would be trapped in unusable gaps. These unusable gaps are hard to predict, and they depend on the allocation pattern of each application. Miguel ___ 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
If you look at all the new applications being developed in GNOME - how many are done using C?? VERY few - this is very worrying for the future of GNOME. It is indeed very worrying for the future of GNOME if we do *NOT* embrace the trend that clearly shows no-one actually likes writing applications in C. But hey, if sun has the time and money please feel free to rewrite all our prototypes in C. iain ___ 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
Joseph E. Sacco, Ph.D. wrote: Rodrigo gently raises the seminal question, What is so different?. The answer is known: It is that enormous elephant standing in the corner that folks have been politely tip-toeing around, trying to ignore. Tiptoeing around the issue is NOT polite at this point. We are talking about letting mono into GNOME. This is it. This is the fork in the road. This is the part where we have the argument. Whatever your objections are, speak now or forever hold your peace. -- Dan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Time to heat up the new module discussion
Jits on the desktop are usually bad not just because they do take more memory but also because you need the build system of mono installed which means more bloat. Considering that Gtk# applications consume less memory than PyGtk applications am puzzled by this blank statement. I'd be interested to see any numbers backing up that statement, otherwise I'm going to be as puzzled as you by blank statements. And no, I wouldn't actually count a Hello World like program as a very representative application. Johan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Time to heat up the new module discussion
I stated my objection clearly. I do not believe that it is in the best interests of the open source community to advance the interests of Microsoft or any other commercial vendor. At this point in time I do not think adding Mono to GNOME-core is a good idea. I have no objection to adding Mono apps to GNOME-extras. In time we will learn whether or not the Mono framework will be embraced by the user community. -Joseph == On Fri, 2006-07-14 at 13:22 -0400, Dan Winship wrote: Joseph E. Sacco, Ph.D. wrote: Rodrigo gently raises the seminal question, What is so different?. The answer is known: It is that enormous elephant standing in the corner that folks have been politely tip-toeing around, trying to ignore. Tiptoeing around the issue is NOT polite at this point. We are talking about letting mono into GNOME. This is it. This is the fork in the road. This is the part where we have the argument. Whatever your objections are, speak now or forever hold your peace. -- Dan -- joseph_sacco [at] comcast [dot] net ___ 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 (from digest)
Hi, Darren Kenny wrote: I'm not totally against C# applications themselves - what I am for is choice. I don't think any thing other than C should be part of Core GNOME - to put anything other than C into here can cause loads of problems - what happens if we start to do all our main development in C# (or anything else for that matter) going forward, then less and less of GNOME will be re-usable without Mono since all the innovation will be in C#. This is why I think we need a definition of what is core... This is the core of the discussion, and strikes at the heart of another more important question. What is GNOME? Is GNOME a platform on which we allow distributors to develop the desktop experience, or is GNOME a project where we build that desktop, and enable repackaging and differentiation of distributors on a complete free software computing environment? It appears to me that significant blocks of functionality are being written in languages other than C for GNOME (this is hardly surprising, C development is slower than development in most modern high-level languages), and those applications are being built outside our community. I'd like GTK#, java-gnome, gtkmm, pygtk and ruby-gtk developers to consider themselves GNOME developers. I'd prefer GNOME to be a pick'n'mix of complete usable applications rather than a slimline core platform which generates no excitement. No-one is going to feel giddy about the low-level stuff (unless they're Mathias, maybe) - I'm reminded of Murray Cumming's reason for working on the gtkmm bindings - I wanted to write applications in C++, and the bindings needed work. The motivation is to connect with users. The only users of the platform and the bindings are application writers. But if FSpot, Gimmie and Muine are the ways to make GNOME a better free software computing environment, and we're turning them away, then my next question would be what exists which does this job better that's written in another language? Because I don't really care what language the app is written in, what I care about is what it lets me do. It's a discussion worth having, and I'm not sure all of the GNOME distributors will agree with the conclusion of that discussion. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] Lyon, France ___ 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
Hello, Jits on the desktop are usually bad not just because they do take more memory but also because you need the build system of mono installed which means more bloat. Considering that Gtk# applications consume less memory than PyGtk applications am puzzled by this blank statement. I'd be interested to see any numbers backing up that statement, otherwise I'm going to be as puzzled as you by blank statements. From my blog last year: http://tirania.org/blog/archive/2005/Feb-09.html And Paolo's: http://www.advogato.org/person/lupus/diary.html?start=15 Miguel ___ 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
Miguel de Icaza wrote: Hello, Hi, so in other words it will spike every now and again EG if under Boehm GC I have 50MB heap then in compacting mode its going to spike from 50 to 100+ MB (how much higher depends on the no. of generations you have and how incremental it is of course) Yes, but the spike is not 2x the memory you have allocated. The spike is the size of the nursery (512k). Sure for young generation collections but major collections will be 2x the allocated memory as they must include the older generations as well as the nursery. (thats pretty much what the page link you gave says unless I have misinterpreted it?) So we will see a doubling in size spike every now and again (it is after all one of the main disadvantages common to *all* copying collectors so no need to panic!) -- Mr Jamie McCracken http://jamiemcc.livejournal.com/ ___ 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
Hi, On Fri, 2006-07-14 at 16:09 +0100, Alvaro Lopez Ortega wrote: What I meant is that if you launch a KDE desktop, it'll use a single framework and execution environment. Even if they have binding, all the main desktop application have been written using a single development framework. That's not true. A KDE app written in Mono is just as likely to use the Mono XML layer just like a GNOME one would. Neither would be using their own development platform's XML library. Joe ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
One Gnome (was: Time to heat up the new module discussion)
On Thu, 2006-07-13 at 16:50 +0100, Iain * wrote: On 7/12/06, Darren Kenny [EMAIL PROTECTED] wrote: Just think about what happens when a user logs into a desktop that has Python and C# based applets included with C based applets: - The panel starts - It starts C/Bonobo based applets - the smallest of which already consumes approx 40Mb of memory. - It starts Python applets - each of these takes up approx 70Mb of memory - and very little of this is shared - It starts a C# based applet - and this pulls in Mono, which I'm sure isn't that small, but I guess at least it does share memory better than Python, but there is still quite a lot of additional memory pulled in. Then...umm, don't run them? A lot of us have been using this argument a lot lately, and I don't think it's a productive way to develop software. Sure, it's wonderful that we have choice, and we should never take that choice away from our users. That does not mean that we should force (or actively encourage) our users to choose not to run our software. Realize, Iain, that your reply was not just to a user concerned about his desktop. Darren has clearly shown in his posts that he's concerned about how this will pan out for Sun's offerings of Gnome. So you're not just telling a user he's free to run what applications he wants. You're encouraging one of our distributors to ship something other than stock Gnome. This has been a brewing problem for many years now, and we need it to stop. We need one Gnome. Many moons ago, the idea was that Gnome didn't need its own window manager. From a purely technical standpoint, that's true, especially now that we have initiatives like the EWMH. To the user, though, it's another story altogether. Having a blessed window manager means that we can put window management configuration in sensible places in the control center. It means we can document the desktop's behavior and functionality. It means we can actually talk to people about our desktop without a bunch of if's and but's. When Gnome is divided, we can't build interfaces that work the way users think; we have to expose application boundaries that aren't relevant to users. We can't market Gnome effectively, because everything we might want to say is false in at least one of our distributions. We can't document Gnome correctly, because we don't know what's actually on our users' screens. ISDs can't target a divided Gnome like they can target Mac or Windows. Having a solid and stable developer platform is wonderful, but much of what makes a great user experience comes from outside the platform. If we don't unite Gnome, we will lose it entirely. -- Shaun ___ 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
Darren Kenny wrote: Again I think people seriously need to get out of the mind-set that there is only one desktop user on a machine - so a couple of meg for 1 user isn't a lot - but for 100 users on a single machine (even with 256Mb of RAM per user) there is a huge impact in that tiny additional platform being loaded. ... This is why we need a Core GNOME that isn't dependent on such frameworks. Core GNOME might work for a little while, but I think we need to get beyond the One GNOME Policy. Shipping a desktop full of innovative (ie, C#- and python-based) apps is as necessary for Novell as it is problematic for Sun. GNOME will never be able to come up with a single one-size-fits-all list of modules that can cover 100-user Sun Rays, SLED/RHEL on top-of-the-line laptops, Debian on someone's old Pentium III, Gentoo on overclocked gamer boxes, Maemo on the 770, etc, etc, etc. Maybe the thing to do is to weaken the sense of the Desktop release. Rather than being this is what we think every GNOME Desktop should have, it would be these are programs that we think can be a nutritious part of your GNOME Desktop, with no implication that everyone should have all of them. This would also allow us to include redundant apps in the Desktop (eg, recognizing that Rhythmbox and Banshee are both good GNOME music players, and neither of them is going to go away any time soon), and not have to pick sides. The downstream distros/users could then pick a set of packages that fit together to meet their needs. Which, honestly, is what already happens. The only difference is that now we'd be helping the distros/users out, by pointing out specific GNOME-based packages that we think are cool/useful/usable/stable, and by keeping those packages' release cycles in sync with the rest of GNOME. -- Dan ___ 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
Hi, On Fri, 2006-07-14 at 09:10 +0100, Jamie McCracken wrote: I don't use Beagle, and in fact I hope the alternate Tracker project will solve this problem. It already does - tracker uses a tiny 3-6 MB RAM and provides considerably faster indexing and search retrieval of results. I developed it for use on my 256MB notepad so its designed from scratch to be super memory efficient. No offense, but Tracker has a fraction of the functionality of Beagle. It indexes files, but it doesn't index email (with attachments), addressbook and calendar entries, or instant messaging logs, all of which I search for much more often than files. Of course, Tracker is ahead of Beagle in other ways, such as having a persistent centralized data store, and its present memory usage is lower than Beagle's. But as I've said before, I don't feel like the memory issues in Beagle are insurmountable, and to compare Tracker and Beagle's present memory usage isn't exactly comparing on a level playing field. Joe ___ 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
Hi, On Thu, 2006-07-13 at 22:16 -0400, Ben Maurer wrote: On Fri, 14 Jul 2006, [ISO-8859-1] Steve Frcinaux wrote: Not really. In fact, blessing an app in the desktop has the immediate consequency that other apps can depend on it in a non-conditional way. For instance, a few distros already ship beagle by default, but most only ship it. And I just can't run beagle on my box, it eats up too much memory. So if it was proposed for inclusion, including it would mean that some Gnome apps would depend on it more or less inconditionally and I couldn't run these apps anymore. That's the kind of problem we want to avoid here. This is completely besides the point. Nobody is proposing that beagle be made a requirement for GNOME. I agree, this would cause a problem for many low memory users. In fact, this is one of the main reasons why I haven't yet proposed Beagle for inclusion in the desktop. I am thrilled by people's interest in it, and I think it's a key part of the desktop going forward, but I am not yet satisfied with its performance to suggest that everyone use it. I don't, however, believe that this is directly related to the fact that its core is in C#. It is a solvable problem (although a tricky one, yes). Joe ___ 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
Hello, so in other words it will spike every now and again EG if under Boehm GC I have 50MB heap then in compacting mode its going to spike from 50 to 100+ MB (how much higher depends on the no. of generations you have and how incremental it is of course) Yes, but the spike is not 2x the memory you have allocated. The spike is the size of the nursery (512k). Sure for young generation collections but major collections will be 2x the allocated memory as they must include the older generations as well as the nursery. (thats pretty much what the page link you gave says unless I have misinterpreted it?) The reason to perform a major collection would be to release some of the resources there (otherwise a new block would be allocated). So the new block allocated tends to be smaller than the sum of the existing memory sections, as it only accounts for live objects, not live objects plus dead objects. So we will see a doubling in size spike every now and again (it is after all one of the main disadvantages common to *all* copying collectors so no need to panic!) That is the worst case scenario, yes. Miguel. ___ 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
Joe Shaw wrote: Hi, On Fri, 2006-07-14 at 09:10 +0100, Jamie McCracken wrote: I don't use Beagle, and in fact I hope the alternate Tracker project will solve this problem. It already does - tracker uses a tiny 3-6 MB RAM and provides considerably faster indexing and search retrieval of results. I developed it for use on my 256MB notepad so its designed from scratch to be super memory efficient. No offense, but Tracker has a fraction of the functionality of Beagle. It indexes files, but it doesn't index email (with attachments), addressbook and calendar entries, or instant messaging logs, all of which I search for much more often than files. Okay sorry didn't mean to annoy you - Im not trying to dig dirt on Beagle and I respect what you are doing. I'm sure you understand the reasons for tracker as I explained to you a year or so ago - I needed the extra power of a relational Db based system that could run on lower end systems and I did try and persuade you to go the Db route with beagle long before I started on tracker. Tracker and Beagle are very different beasts but they only overlap in the indexing area. All of those things you point out are coming but none of them should have a significant effect on tracker's memory usage. Also note I did not mention Beagle's memory usage on my machine but only Tracker's I also dont have any hostile intentions towards Beagle and would when and if tracker gets into gnome ensure there would be some abstraction with beagle. We need powerful search in Gnome and Tracker can help Beagle there via an abstraction layer so both projects will benefit. -- Mr Jamie McCracken http://jamiemcc.livejournal.com/ ___ 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
Iain * wrote: They already can. Don't like mono...don't ship mono applications. None of the libraries will depend or use mono. But applications could. Including mono as a blessed platform could, as a side effect, allow current apps to allow parts written in C#, like some already do with python (epiphany, gedit, nautilus, etc). Good practice would say it should remain optional dependencies, but eh, we're not in a perfect world. Note that I'm perfectly fine with that, as long as it remains a unique common managed platform, be it python or mono. I 100% agree with thomasvs on that point: more (loading two VM for a unique app) would be too much. I think mono would even make more people happy since it provides more languages for free (that's what I've heard). But it might be too late to make a step backward and change our platform (unless mono supports python, which would bring the best of both world). I'm a great fan of python plugins for everyone, as long as it stay in apps you run when you need it, and not all the time. I just don't want to see my memory eroded by applets or daemons replacing old ones in a smarter but more expensive way. ___ 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
Joe Shaw wrote: What I meant is that if you launch a KDE desktop, it'll use a single framework and execution environment. Even if they have binding, all the main desktop application have been written using a single development framework. That's not true. A KDE app written in Mono is just as likely to use the Mono XML layer just like a GNOME one would. Neither would be using their own development platform's XML library. Yeah, 100% agree. That is exactly the problem: applications would use another framework rather than the one that they are suppose to use (we are speaking about GNOME apps). Anyway, as long as a KDE+Mono application is almost a imaginary case, it doesn't make much sense to discuss it. KDE people write their applications using C++ and the KDE framework, and even if they have Mono (Python, Java, ..) bindings, there aren't basic KDE desktop applications written with them. I understand the desktop framework as the common infrastructure in which almost all the desktop applications are based on. If we move from a scheme in which there is an unique group of common stuff to one in which there are a few of them (GNOME, Python, Mono, Java?) it may become a little messy. IMO. -- Greetings, alo. http://www.alobbs.com ___ 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
Steve Frécinaux wrote: Iain * wrote: As for .NET, even Microsoft themselves had to pull back from using it for core functionality due to performance reasons - why do we think we will do any better? As someone who is running mono based applications fairly regularly, I haven't noticed any major performance issues. We're not talking here about replacing the core libraries with c# based ones, we're talking about applications, and for me the mono based apps are just as fast as the C based ones. I'm not really against having C# apps in the core (in fact I don't really mind), what I'm more frightening about is having applications that run all the time, using managed languages, and, as a consequence, taking up a fairly large amount of memory, from the computer start to the shutdown. That's what I'm against including libraries, daemons or applets written either in C#, or in python, while having small apps you close once you're done (like alacarte) is fine. Perhaps daemons, applets and core libraries should evaluated on their performance merit independent of the language they're written in or the framework that they use. I'd imagine that those who have worked so hard on GNOME performance issues would be disappointed if they saw a C applet take 18 - 20 megs (resident) or take 10 seconds to load. If the GNOME desktop becomes dependent on one single process like that, it wipes out most of what so many people have worked hard step by step to gain as far as startup speed and memory usage. I don't think we should cut slack for a particular applet or daemon because it happens to be written using an inefficient platform. If its performance issues are not up to snuff, then it shouldn't be included as part of the GNOME desktop. That said, I bet the Mono guys could prove everyone wrong by optimizing managed code to where it approaches the startup speed and memory usage of lower level frameworks. That would be lovely. But it might mean not trying to emulate every last 'innovation' in MS .NET C# 3.0 etc... :) Cheers, Nate ___ 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 Fri, 14 Jul 2006, Iain * wrote: On 7/14/06, Darren Kenny [EMAIL PROTECTED] wrote: Mono and Python etc are all very good in their own way, but I really don't see why they need to be part of the core GNOME desktop - this was why I wanted to break down the GNOME desktop into various groupings - so ISVs, etc. can make their own mind up about what they wish to depend upon. They already can. Don't like mono...don't ship mono applications. None of the libraries will depend or use mono. This is argument is moot and you know it - this isn't just about libra- ries, this is also about application/applets etc, like the deskbar ap- plet. While I don't have a particular issue with the deskbar applet in se, since it's in no way essential, this serves as a possible example of where your argument wouldn't hold (in case deskbar was something more essential, like say the clock or taskbar switcher). Also, your statement is false. Beagle uses mono, and it is considered for inclusion (and I really wouldn't call searching 'optional' or non- core). kr, Chipzz AKA Jan Van Buggenhout -- UNIX isn't dead - It just smells funny [EMAIL PROTECTED] Baldric, you wouldn't recognize a subtle plan if it painted itself pur- ple and danced naked on a harpsicord singing 'subtle plans are here a- gain'. ___ 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 (from digest)
On Fri, 2006-07-14 at 19:50 +0200, David Neary wrote: But if FSpot, Gimmie and Muine are the ways to make GNOME a better free software computing environment, and we're turning them away, then my next question would be what exists which does this job better that's written in another language? Because I don't really care what language the app is written in, what I care about is what it lets me do. Same here. I don't really notice differences in execution speed between pygtk, C++, C# or native C programs on a quite aged GNOME desktop (I feel the pain of Java though, but those programs don't use the gnome-wrapped libs but some bad AWT shit). As package maintainer of GNOME on archlinux, I don't care if something is written in gtk-sharp-2, gtkmm, gnome-python or native gnome libs, as long as the package compiles and works together with the packaging standards. As end user, I don't care about it either, as long as the looks are quite consistent (this is why I hate firefox, it's not GUI-consistent while epiphany and galeon are). Take a look at beagle for example. GNOME 2.14 got many good reviews just because they picked a distro for the review that includes beagle. Beagle was exciting, new, easy, etc. The features of beagle are an example of something that is good for the GNOME desktop. Looking at the performance of Beagle, it should be optional, which it is. Speaking about performance, I've had beagle running on the background today with the latest released mono development versions, I didn't even notice it was running (I used to notice it was running with previous versions of both mono and beagle). No slowdowns, no swapping, etc. When mono reaches 1.2, it will be mature enough to become a blessed binding for non-core applications in the gnome desktop. ___ 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 Fri, 14 Jul 2006, Nate Nielsen wrote: Steve Frécinaux wrote: Iain * wrote: As for .NET, even Microsoft themselves had to pull back from using it for core functionality due to performance reasons - why do we think we will do any better? As someone who is running mono based applications fairly regularly, I haven't noticed any major performance issues. We're not talking here about replacing the core libraries with c# based ones, we're talking about applications, and for me the mono based apps are just as fast as the C based ones. I'm not really against having C# apps in the core (in fact I don't really mind), what I'm more frightening about is having applications that run all the time, using managed languages, and, as a consequence, taking up a fairly large amount of memory, from the computer start to the shutdown. That's what I'm against including libraries, daemons or applets written either in C#, or in python, while having small apps you close once you're done (like alacarte) is fine. Perhaps daemons, applets and core libraries should evaluated on their performance merit independent of the language they're written in or the framework that they use. I'd imagine that those who have worked so hard on GNOME performance issues would be disappointed if they saw a C applet take 18 - 20 megs (resident) or take 10 seconds to load. PLEASE learn how to measure memory. Resident is *NOT* a good measure of memory. You must use smaps to even begin getting an accurate measurement. Not a single person other than Federico and myself have used a number about performance that is relevant. This suggests that there are many people `me too'ing and not thinking about what they are saying. If you want to make groundless claims, comment on slashdot. If the GNOME desktop becomes dependent on one single process like that, it wipes out most of what so many people have worked hard step by step to gain as far as startup speed and memory usage. As you might realize, I'm one of those people. IMHO, having applications written in a framework that encourages maintainable, clean code is a step forward for performance. Do some of the Mono based applications need profiling: yes. Should we use performance as an excuse for not having Mono: no. I don't think we should cut slack for a particular applet or daemon because it happens to be written using an inefficient platform. If its I did not hear anybody suggest that. We're not cutting slack for anyone. performance issues are not up to snuff, then it shouldn't be included as part of the GNOME desktop. Should it be included by *default*: probably not. It needs to be clear that Mono applications will be accepted without bias as to their language. This is what is being requested. That said, I bet the Mono guys could prove everyone wrong by optimizing managed code to where it approaches the startup speed and memory usage of lower level frameworks. That would be lovely. But it might mean not trying to emulate every last 'innovation' in MS .NET C# 3.0 etc... :) Please show benchmarks that show issues here. Banshee and other c# apps seem to startup very fast. While memory usage isn't as good as it could possibly be, we're not talking about a huge amount here (see numbers from myself, federico). Again, in the long term, a moving GC will help us return memory to the system. -- Ben___ 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 Fri, 14 Jul 2006, Alvaro Lopez Ortega wrote: Yeah, 100% agree. That is exactly the problem: applications would use another framework rather than the one that they are suppose to use (we are speaking about GNOME apps). libxml is an XML library for *C* apps. It's not designed to be usable in any other language. I understand the desktop framework as the common infrastructure in which almost all the desktop applications are based on. If we move from a scheme in which there is an unique group of common stuff to one in which there are a few of them (GNOME, Python, Mono, Java?) it may become a little messy. IMO. We're not proposing Java. Don't try to inflate your numbers by putting stuff not under consideration in there. First, let's observe that almost everyone seems to desire a move in the managed code direction. Microsoft has invested quite a bit of engineering effort into their Vista based framework. Sun is investing by improving Java on the desktop (including by making Swing apps look native in gtk, for Mustang/Java 6. This work is very impressive). Novell's desktop now includes many Mono based applications. GNOME is not going to survive in C. Will we continue to have a nice desktop environment, yes. However, we are not going to make a computing ecosystem by sitting in our C shells. Embracing python is a good step forward. Embracing Mono will allow the innovations that Novell has made in terms of search, music and photos to be a part of GNOME. Further, because the CLI has a bytecode that supports many languages, it opens up these applications to plugins written in any language from C# to Python. Most of the Mono based apps provide functionality that GNOME never *really* had (a usable music playter that syncs to ipods, etc; a photo manager; desktop search). Multi-user setups (such as those used by your company, Sun), these applications need not be used. Innovation will continue in Mono with or without GNOMEs blessing. GNOME is what will be missing out by being stalled on a silly flamewar started by a small number of people. -- Ben ___ 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 7/14/06, Alvaro Lopez Ortega [EMAIL PROTECTED] wrote: Azureus and Eclipse come to mind. Two out of.. how many? About 5 maybe 6 if you count hello.world? ___ 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 7/14/06, Chipzz [EMAIL PROTECTED] wrote: They already can. Don't like mono...don't ship mono applications. None of the libraries will depend or use mono. This is argument is moot and you know it - this isn't just about libra- ries, this is also about application/applets etc, My point was that the only essential things are the libraries and they are not going to become c#. It was brought up that both the panel and file manager are also essential But a) they're not b) We're not talking about rewriting the entire desktop in c#. If we were, maybe there would be a problem and we would discuss it...but we're not, and its not likely to happen in the near future. Also, your statement is false. Beagle uses mono, and it is considered for inclusion As joe pointed out, no its not. (and I really wouldn't call searching 'optional' or non- core). I would...I don't search for things very often. I think that quite frankly this thread has exploded into something completely overblown. We're not talking about rewriting the desktop in C#, we're talking about adding one applet. Yes, in the future it may allow other applications written in other languages, but look, we've had python in the desktop for 2 releases now, and look how we're inundated with applications written in python...one...out of 5 things proposed. Is the fact that there were so few things proposed a sign that the C thing just isn't working? iain ___ 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 Fri, 2006-07-14 at 14:30 -0400, Dan Winship wrote: and not have to pick sides. The downstream distros/users could then pick a set of packages that fit together to meet their needs. Which, honestly, is what already happens. ... This is the gist of my comment yesterday that the debate is somewhat specious. People will ship what they ship; what GNOME's release team says is The Desktop is somewhat secondary. The miracle of open source is that it provides an opportunity for collaboration. Take Sun and Red Hat. While they are competitors, a subset of what they do is common infrastructure and so both benefit by working together in that overlap [which, as FOSS has shown, can be surprisingly large]. Coming back to earth now: I'm not a big fan of .Net for the reasons of legal ambiguity and advancing the interests of a company that actively is working against us and the freedoms we strive to represent. But on the other hand, I recognize that many people in our community don't feel that way, and meanwhile Mono is a platform with a great deal of interest and attention and vibrancy. So people want to use it to write GNOME apps? Great! And meanwhile, my work and theirs overlaps in that we both use core libraries like GTK and all benefit from improvements to it. Will I use Mono apps? Generally not. But will I, a Java guy, stand on the soap box and scream at the top of my lungs and do anything I can to keep them and their awesome applications second class citizens? Sorry, I've got better things to do. Maybe the thing to do is to weaken the sense of the Desktop release. Rather than being this is what we think every GNOME Desktop should have, I think this branch of the conversation about defining a core set of libraries and critical applications that have to run broadly and very fast and that everyone can bind a worthy one. And I'll certainly support efforts to define it - and indeed will support efforts to keep it lean and mean. After all, we can all bind C libraries. Binding to applications, regardless of language, is harder. And it's certainly quite difficult (though doable) to bind to libraries or applications written the higher level managed language runtimes. So this would seem to be the obvious interface boundary. it would be these are programs that we think can be a nutritious part of your GNOME Desktop, GNOME: A source of 9 essential vitamins! AfC London ___ 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
fre, 14,.07.2006 kl. 13.22 -0400, skrev Dan Winship: Joseph E. Sacco, Ph.D. wrote: Rodrigo gently raises the seminal question, What is so different?. The answer is known: It is that enormous elephant standing in the corner that folks have been politely tip-toeing around, trying to ignore. Tiptoeing around the issue is NOT polite at this point. We are talking about letting mono into GNOME. This is it. This is the fork in the road. This is the part where we have the argument. Whatever your objections are, speak now or forever hold your peace. Had decided to keep quiet about this since it's more of a vendor/distro issue than anything else... But here goes... I think that one of many strenghts of our project is that it embraces many different technologies and development platforms if you will. It *has* to be up to the individual companies who have put their stake in the GNOME camp to define what subset/part/release of GNOME is right for their use of it. Clearly we've had a lot of innovation within the Python/Mono/gtk# camps lately, and if we had the same amount of innovation from the rest of the stakeholders we would all be better off from it IMO. GNOME should be less about what's in and what's not and more about *real* choice. GNOME should be about a uniform user experience stemming from apps that act the same and look the same more than about what development platform/base libraries the apps were made with. It's up you guys to decide which language/platform you want to use to get there, and I sincerely think that the end user doesn't give a damn about whether the app is mono based, java based, python based or an app made from whatever C libraries are in the core. We've grown up a lot since this discussion came up last and I still don't think we have to bless any one language/platform as *the* GNOME development platform. Time will tell if I'm right though. Godspeed to y'all and may the best app win :-) This broadcast has in no way been coloured by the taint of Single Islay Whiskey. Cheers Kjartan ___ 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 Thu, 2006-07-13 at 02:00, Ben Maurer wrote: [...] In the long term, Mono can potentially reduce our performance problems. In the short term, there are performance problems and Mono will worsen them. [...] IMHO, we should define a process that does not start Python is bloated, C# is bloated. Lets not use them. We must establish clear guidelines as to what is allowed. When talking about performance, talk in megabytes, not languages. A good start would be: let's take an old (but still existing) platform, like a pIII with 128 or 256 Mb RAM, and have a basic desktop running fine on it. Basic desktop: - panel + a few applets (including power manager, network-manager ...) - nautilus - epiphany - evolution Running fine: - be responsive - don't swap too much - no need to restart apps each day As said elsewhere, temporary apps (like a menu editor) don't matter but long-running ones (mailer, panel, applets, filemanager) should have a deterministic, capped memory usage. Xav ___ 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 (RESEND)
[EMAIL PROTECTED] wrote: Is there a definition of that is acceptable as a core GNOME application - other than it's based on consensus? I think we are badly in need of a definition that defines the needs of the core GNOME Desktop? There is no doubt we need to establish a definition of what constitute GNOME core application/platform and create some layered modules which are loosely coupled rather than tightly coupled dependency. In approach currently, because there is a nice application, we pull in the the whole dependency. And in the next release, someone write any nice application with plaftform X, we pull in another platform. In no time at all, GNOME will become so overly bloated in terms of foot print and performance. Of course, we can't define what platform can go in or not go in until we the community define what constitute the core apps/platform the GNOME release is made up of. But who are the people can/should establish this? Completely agree. My vote is for not including it. GNOME is a development framework by itself, it doesn't make sense to add more huge development platforms like Mono or Python.. we already have enough performance problems for that. The platform and default desktop have to be clean of those secondary frameworks, and then, it will be up to each distribution to add whatever they want: Java, Python, Mono, etc.. There are many people pushing for very similar technologies, and GNOME should not even try to make them all happy by accepting proposals. I wouldn't like to imagine a GNOME desktop depending by default on Python, Java and Mono, for instance. -- Greetings, alo. http://www.alobbs.com ___ 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
Ben Maurer wrote: It makes sense to me that Mono should remain on the out-skirts of GNOME for this very reason - core GNOME should only use native languages, and more specifically C, as to to do otherwise is likely to effect the already perceived poor performance of GNOME. Excess memory usage has not stoped us from using alot of things -- VFS, Bonobo, etc. Many of the other modules under consideration add their own memory usage to the base desktop -- for example, accepting power manager gives us yet another daemon which takes up a few megs of ram. Distros are being even more aggressive about adopting these new programs (network manager, notification daemon). It is a very different situation. While the power manager support provides new functionality, GTK# would only provide duplicate functionality for another development framework that overlaps with GNOME. - It starts a C# based applet - and this pulls in Mono, which I'm sure isn't that small, but I guess at least it does share memory better than Python, but there is still quite a lot of additional memory pulled in. Mono does *quite* a bit better than python in terms of memory for a Gtk# application (vs pygtk). We should not even care about which one is less hoggy. This is a base problem: Do we need two (or more) development frameworks for a single desktop?. My opinion is no, we don't. But anyway, if in the worst case we end up using another one, lets ensure it's that, another one, not two or three of them. As for .NET, even Microsoft themselves had to pull back from using it for core functionality due to performance reasons - why do we think we will do any better? Attributing this to performance alone is over simplifying. Vista clearly has some high performance requirements. IMHO, part of the issue was that rewriting existing code wasn't the way to get Vista out the door. We aren't doing that, and I don't think we should. http://www.microsoft-watch.com/article2/0,1995,1820607,00.asp == Everything in Longhorn was supposed to be written in C# and to be managed code. But managed code was going to require machines that weren't going to be available for five years or more. So now Microsoft is rewriting everything in Longhorn, the developer says. Developers claim that the Windows team actually began rethinking Microsoft's .Net Framework == As Darren said, why do we think we will do any better? I'm sure there are more breakdowns possible - I just think an ISV or 3rd party developer should be able to express their dependencies for their application by saying they need GNOME Core or GNOME Mono. I'm not really aware of the issues and problems in this area. However, this doesn't seem to relate to the ideas about performance earlier in the email. Yeah, the performance is not the only issue about accepting GTK# and Mono. There are many. I also think our guidelines should be less strict on applications not launched by default. If Tomboy is added as a non-default application, we needn't be as strict about memory usage. If a non-default application is an app that is installed with the default desktop, I completely agree. Actually, in my opinion those apps should never depend on a secondary frameworks. -- Greetings, alo. http://www.alobbs.com ___ 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 Tue, 2006-07-11 at 14:16 -0600, Elijah Newren wrote: So, to start of the discussion, the proposed modules AFAIR are: * orca (as a replacement to gnopernicus) * alacarte * gnome-power-manager * Tomboy * Gtk# * nm-applet The NetworkManager applet. I proposed inclusion at GUADEC. I'd like to do what we do with, say, g-v-m and HAL. nm-applet is like g-v-m, it is a GNOME component and can go in our desktop. NetworkManager's parallel is HAL. We don't have to include the daemon itself in GNOME, just depend on something that implements the NM DBUS API. Robert Love ___ 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 Wed, 2006-07-12 at 09:46 -0600, Elijah Newren wrote: Sounds like a great thing to propose for 2.18. Unfortunately, it looks like you missed the deadline for 2.16 proposals as it was about 2 months before GUADEC. See http://live.gnome.org/TwoPointFifteen and http://mail.gnome.org/archives/devel-announce-list/2006-April/msg0.html. Also, I don't see your proposal on d-d-l anywhere; was this another of those mailing list and archive issues? Ahh I misgrokked your email and thought we were starting the discussion for 2.18. Lo siento! Robert Love ___ 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
Rodrigo Moya wrote: On Wed, 2006-07-12 at 10:21 +0100, Darren Kenny wrote: I'm concerned about the inclusion of GTK# - and hence all the rest of Mono into the core GNOME. It's been mentioned many times before that we already have too many component models in the GNOME platform - and once they are in there, it's VERY hard to get them back out again - just look at Bonobo. GTK# is not just a language binding - it's pulling in a whole platform in itself - Mono. And it worries me that this is opening a door for a slew of C# based applications into the core GNOME. python, for instance, is also a whole platform in itself, and we still include the bindings Sure. I think this is all the more we should debate how a platform bindings be made into an official one for GNOME core releases? It is mandatory or optional. In gnome 2.14 we have python, we are disussing about Mono in gnome 2.16, we could be talking about 'Java Binding' in gnome 2.1x and the Ruby etc. While we do not want to discourage innovations, but how disperse do we want GNOME to be? We now have deskbar applet in gnome 2.14 which is python based, and Tomboy proposed for gnome 2.16 which is Mono based. The list could continue.. I like to see methodical/engineering evalution to pull in new stuffs that balance out innovative stuff and performance/usability of GNOME. To example what I can see with the the current dependencies problem: GNOME currently already divide up source code into: - admin - bindings - desktop - platform For the core GNOME desktop upto gnome 2.12, I only need to compile and build platform and desktop sources everything run fine. With gnome 2.14, I now need to compile the binding stuff with python. With proposed tomboy, I have to compile the binding stuff gtk#. In the future when there is a nice Java [1] app comes along to be accepted as core GNOME app. I will have to compile and deliver the Java binding etc. I just want to highlight this dependencies and hence the growing complexities of the GNOME Desktop. Is this the way we as the community want to see GNOME to go in this direction? -Ghee [1] Of course we are still eager waiting for the Open Sourcesing of Java ;) It makes sense to me that Mono should remain on the out-skirts of GNOME for this very reason - core GNOME should only use native languages, and more specifically C, as to to do otherwise is likely to effect the already perceived poor performance of GNOME. Just think about what happens when a user logs into a desktop that has Python and C# based applets included with C based applets: - The panel starts - It starts C/Bonobo based applets - the smallest of which already consumes approx 40Mb of memory. - It starts Python applets - each of these takes up approx 70Mb of memory - and very little of this is shared - It starts a C# based applet - and this pulls in Mono, which I'm sure isn't that small, but I guess at least it does share memory better than Python, but there is still quite a lot of additional memory pulled in. I agree with all these problems, but I guess we'd better work on trying to fix them than just avoiding the use of this software. ___ 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 7/12/06, Darren Kenny [EMAIL PROTECTED] wrote: I'm concerned about the inclusion of GTK# - and hence all the rest of Mono into the core GNOME. It doesn't pull mono into the core of gnome anymore than having python applets pulls python in. And it worries me that this is opening a door for a slew of C# based applications into the core GNOME. And this is a bad thing because...? It makes sense to me that Mono should remain on the out-skirts of GNOME for this very reason - core GNOME should only use native languages, and more specifically C, as to to do otherwise is likely to effect the already perceived poor performance of GNOME. Python is already used in the deskbar applet which is in core GNOME. Just think about what happens when a user logs into a desktop that has Python and C# based applets included with C based applets: - The panel starts - It starts C/Bonobo based applets - the smallest of which already consumes approx 40Mb of memory. - It starts Python applets - each of these takes up approx 70Mb of memory - and very little of this is shared - It starts a C# based applet - and this pulls in Mono, which I'm sure isn't that small, but I guess at least it does share memory better than Python, but there is still quite a lot of additional memory pulled in. Then...umm, don't run them? I know today people say that memory is cheap, but I think that's not an excuse for working on reducing it's consumption. Limiting memory usage by limiting features is kinda a pyrrhic victory. Well, yes, we only have one button on screen, but damn we don't use any memory Also, there is the small devices like the Nokia 770 for which memory consumption is a big factor. As far as I know, no-one is attempting to run the gnome panel and python/mono applets on a 770. As for .NET, even Microsoft themselves had to pull back from using it for core functionality due to performance reasons - why do we think we will do any better? As someone who is running mono based applications fairly regularly, I haven't noticed any major performance issues. We're not talking here about replacing the core libraries with c# based ones, we're talking about applications, and for me the mono based apps are just as fast as the C based ones. iain ___ 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
Hi, On Thu, 2006-07-13 at 10:28 +0100, Alvaro Lopez Ortega wrote: It is a very different situation. While the power manager support provides new functionality, GTK# would only provide duplicate functionality for another development framework that overlaps with GNOME. Perhaps I am misunderstanding, but this argument doesn't make any sense to me. Gtk# isn't an application, so by itself it's not useful and doesn't really duplicate anything. It does provide a native API to Gtk#, but traditionally language bindings have been considered a strength of GNOME. Gtk# calls into Gtk+, so it's not like we have two competing implementations of the toolkit here. I don't see the duplicate functionality here. We should not even care about which one is less hoggy. This is a base problem: Do we need two (or more) development frameworks for a single desktop?. My opinion is no, we don't. But anyway, if in the worst case we end up using another one, lets ensure it's that, another one, not two or three of them. It makes increasingly less sense to write applications in C. If you look at where the interesting and innovative development has been in terms of applications in GNOME, virtually zero of them are C apps. They're all either Python or Mono. This isn't a coincidence. (Yes, there is a bit of an exception here for the lighterweight apps on the 770, but those are quite rightly applications designed to be better suited for smaller devices.) http://www.microsoft-watch.com/article2/0,1995,1820607,00.asp == Everything in Longhorn was supposed to be written in C# and to be managed code. But managed code was going to require machines that weren't going to be available for five years or more. So now Microsoft is rewriting everything in Longhorn, the developer says. Developers claim that the Windows team actually began rethinking Microsoft's .Net Framework == As Darren said, why do we think we will do any better? I would take anything you read on microsoft-watch.com with a huge grain of salt. What about managed code is going to require machines that aren't going to be available for five years or more? Without more information, we can't make any use of this information and it amounts to FUD. Distributions today are quite successfully shipping with a wide variety of Python and Mono applications. Are we satisfied with their performance on a P3 with 128 megs of RAM? Probably not, but these are things we can actively address. I am quite thrilled that Performance is becoming one of the core values of GNOME development. Joe ___ 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
Joe Shaw wrote: It is a very different situation. While the power manager support provides new functionality, GTK# would only provide duplicate functionality for another development framework that overlaps with GNOME. Perhaps I am misunderstanding, but this argument doesn't make any sense to me. Gtk# isn't an application, so by itself it's not useful and doesn't really duplicate anything. It does provide a native API to Gtk#, but traditionally language bindings have been considered a strength of GNOME. Gtk# calls into Gtk+, so it's not like we have two competing implementations of the toolkit here. I don't see the duplicate functionality here. My mistake, I didn't explain it correctly. What I meant was that the group of Gtk# plus Mono overlaps with a big chunk of the desktop. My understanding is that GNOME is a development framework and Mono is another one completely unrelated. Both of them have quite big class libraries: XML parsers, string management, asynchronous I/O, etc. There are some overlaps. However, I don't think we want to restrict GNOME to unmanaged code for the end of time. The substantial resources spent by Sun, Microsoft, and Novell on managed code for the desktop seem to suggest that all think that this is the way of the future. Innovative applications have been developed by using Mono that clearly would have taken much, much longer without the help of this framework. It's hard to call the C libraries we have a development framework. The environment they provide is simply not comparable to that of Python or C# Of course it is possible to use both of them for writing a single cool application, although it doesn't seem to be technically correct because of all the duplicate code: there would way too many unneeded possible failure points and wasted resources. Mono will *not* be taking resources from the current GNOME community. Even if there is on occasion, a but in Mono that needs to be fixed, it seems that this is a net win given the increased development speed. I'm sure Joe Shaw, Aaron Bockover, and Larry Ewing (among many others) would attest to the benefit which Mono has provided as they developed applications. It makes increasingly less sense to write applications in C. If you look at where the interesting and innovative development has been in terms of applications in GNOME, virtually zero of them are C apps. They're all either Python or Mono. This isn't a coincidence. For me the problem is not the language, but the addition framework. So, given the choice of: - virtually zero...interesting and innovative development or - Two frameworks You are suggesting less innovative development? There is absolutely nothing suggesting that over the next 5 years, C applications will become easier to develop. On the other hand, substantial improvements in managed languages (such as generics, and the many enhancements coming in C# 3.0). Also, it may become increasingly hard to attract new developers to GNOME if we only support C. Most universities (including my own, CMU) focus their cirriclum on managed languages. Does it make sense to you to use have three or four different DOM parsers in memory at the same time? (libxml2, python, mono and java for example). First, java is not under consideration at this point. Let's not cloud the discussion with off-topic issues. Currently, python and mono are where the innovation that Joe has been talking about is happening. This statement shows a clear misunderstanding of where the performance issues are in todays desktop. Much of the memory that comes from loading multiple frameworks is shared between processes. In addition, where framework bloat is causing an issue in the GNOME desktop is in places that get loaded by 20 processes (for example, GNOME-VFS). I can't imagine photo management, music playing, desktop search, and desktop wiki-notes on a low memory computer -- in C, Mono or Python. In all honesty, our biggest performance problem is coming from applications that leak. This problem won't be made worse by Mono (in fact, I believe that Mono's ease of development will help developers spend more time profiling). It should also be pointed out that Mono provides an environment for many different languages. While choices of .NET-using languages among GNOME desktop apps needs to be decided (having everone choose their own language would be a issue), Mono will allow the freedom of choosing the best tool for the task while at the same time, providing a single framework. -- Ben ___ 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
Alvaro Lopez Ortega wrote: Does it make sense to you to use have three or four different DOM parsers in memory at the same time? No, it doesn't, but we already have three XML(ish) parsers linked into every C-based GNOME app (libxml2, expat, and GMarkup). And yet, GNOME is *better* now than it was when we only had one XML parser. the problem is that there are many other pieces that are also overlapping with the GNOME framework, and that can do nothing but mess up the desktop. How exactly are these apps going to mess up the desktop? Let's take Tomboy, since it's on the table. What *precisely* does Tomboy do that messes up the desktop (that it wouldn't do if it was written in C)? And if your argument is really languages that come with their own frameworks are bad, and not just I hate mono, then why didn't you argue against allowing python-based apps in the platform when that came up a year and a half ago? -- Dan ___ 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
Iain * wrote: As for .NET, even Microsoft themselves had to pull back from using it for core functionality due to performance reasons - why do we think we will do any better? As someone who is running mono based applications fairly regularly, I haven't noticed any major performance issues. We're not talking here about replacing the core libraries with c# based ones, we're talking about applications, and for me the mono based apps are just as fast as the C based ones. I'm not really against having C# apps in the core (in fact I don't really mind), what I'm more frightening about is having applications that run all the time, using managed languages, and, as a consequence, taking up a fairly large amount of memory, from the computer start to the shutdown. That's what I'm against including libraries, daemons or applets written either in C#, or in python, while having small apps you close once you're done (like alacarte) is fine. ATM, required C#/python apps are far from required (well, I might be wrong, after all apps do not really advertise what language they are written with), but I guess we should have guidelines wrt that (and yeah, I know deskbar is already in, and no I don't use it). Think about it: having an application you run a short time do not really impact on your available memory, so it's not a real issue on low-memory system (like mine: 224 Megs are not much memory these days), but long-running ones do. ___ 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 Wed, 2006-07-12 at 11:57 +0200, Rodrigo Moya wrote: IMO we should allow modules to depend on any of the official bindings. Since I want to see GNOME opened to new audiences and new contributors, I'm broadly in favour of the inclusive view which encourages innovation across the board. However, On Thu, 2006-07-13 at 09:58 +0100, Alvaro Lopez Ortega wrote: The platform and default desktop have to be clean of those secondary frameworks, I am sympathetic to this concern since I've been involved in packaging GNOME and know how much of a nightmare that is. I'm also worried about performance and bloat issues. But for the Mono guys, I buy the argument that their performance will improve over time. As for Java (which obviously I am quite partisan about), the same applies. Also, we've got the amazing compile-to-native thing that GCJ provides (with GTK apps dropping dramatically in resident size). And I also agree with the point that overall that more usage by more applications will lead to more focus and attention being paid to performance tuning. and then, it will be up to each distribution to add whatever they want: Java, Python, Mono, etc.. Which, to be honest, I feel makes this whole discussion a bit pointless. I realize that GNOME release engineering is holy ground, but don't you see? Everyone already ships Beagle. Which means they ship Mono. Which means it's a part of the GNOME desktop. fait accompli. AfC London -- Andrew Frederick Cowie Operational Dynamics Website: http://www.operationaldynamics.com/ Blog: http://research.operationaldynamics.com/blogs/andrew/ GPG key: 0945 9282 449C 0058 1FF5 2852 2D51 130C 57F6 E7BD Sydney+61 2 9977 6866 New York +1 646 472 5054 Toronto +1 416 848 6072 London+44 207 1019201 ___ 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 Thu, 2006-07-13 at 16:51 +0100, [EMAIL PROTECTED] wrote:
[1] Of course we are still eager waiting for the Open Sourcing of Java ;)
I suppose.
Meanwhile, Free Java rocks and java-gnome builds and runs on Free Java
no problem at all, both {JITing,}VMs and in native via GCJ.[2]
Cheers,
AfC
London
[2] all before my time; big ups to the hackers over the years of both
the Java bindings to GTK/GNOME and the Classpath project GCJ for
having achieved this long ago.
--
Andrew Frederick Cowie
Operational Dynamics
Website: http://www.operationaldynamics.com/
Blog: http://research.operationaldynamics.com/blogs/andrew/
GPG key: 0945 9282 449C 0058 1FF5 2852 2D51 130C 57F6 E7BD
Sydney+61 2 9977 6866
New York +1 646 472 5054
Toronto +1 416 848 6072
London+44 207 1019201
___
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
Steve Frécinaux wrote: Iain * wrote: As for .NET, even Microsoft themselves had to pull back from using it for core functionality due to performance reasons - why do we think we will do any better? As someone who is running mono based applications fairly regularly, I haven't noticed any major performance issues. We're not talking here about replacing the core libraries with c# based ones, we're talking about applications, and for me the mono based apps are just as fast as the C based ones. I'm not really against having C# apps in the core (in fact I don't really mind), what I'm more frightening about is having applications that run all the time, using managed languages, and, as a consequence, taking up a fairly large amount of memory, from the computer start to the shutdown. That's what I'm against including libraries, daemons or applets written either in C#, or in python, while having small apps you close once you're done (like alacarte) is fine. ATM, required C#/python apps are far from required (well, I might be wrong, after all apps do not really advertise what language they are written with), but I guess we should have guidelines wrt that (and yeah, I know deskbar is already in, and no I don't use it). Think about it: having an application you run a short time do not really impact on your available memory, so it's not a real issue on low-memory system (like mine: 224 Megs are not much memory these days), but long-running ones do. +1 - you effectively summed up my view as well :) I also think what one of the SUN chaps said about having layers in Gnome makes more sense. Gnome to me is a pic 'n' mix system where everyone has basically the same core all in C (the libraries, the daemons, panel, file manager and nothing else) and everything else is optional. Trying to define a one size fits all desktop using a myriad of incompatible platforms and technologies somehow just doesn't feel right (especially if you have a low end system or limited memory). Just my thoughts... -- Mr Jamie McCracken http://jamiemcc.livejournal.com/ ___ 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
Hi On Fri, 14 Jul 2006, [ISO-8859-1] Steve Fr?cinaux wrote: Iain * wrote: I'm not really against having C# apps in the core (in fact I don't really mind), what I'm more frightening about is having applications that run all the time, using managed languages, and, as a consequence, taking up a fairly large amount of memory, from the computer start to the shutdown. Think about it: having an application you run a short time do not really impact on your available memory, so it's not a real issue on low-memory system (like mine: 224 Megs are not much memory these days), but long-running ones do. Please read my previous emails. Designing everything in C will not help. Evolution, OpenOffice and Firefox are evidence that writing your app in C does not make it memory efficient. In the long term, a moving GC may be beneficial. At some point, we also have to realize that users with less memory do need to make compermises. For example, such a user might want to choose not to use Beagle. -- Ben___ 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
Andrew Cowie wrote: Which, to be honest, I feel makes this whole discussion a bit pointless. I realize that GNOME release engineering is holy ground, but don't you see? Everyone already ships Beagle. Which means they ship Mono. Which means it's a part of the GNOME desktop. fait accompli. Not really. In fact, blessing an app in the desktop has the immediate consequency that other apps can depend on it in a non-conditional way. For instance, a few distros already ship beagle by default, but most only ship it. And I just can't run beagle on my box, it eats up too much memory. So if it was proposed for inclusion, including it would mean that some Gnome apps would depend on it more or less inconditionally and I couldn't run these apps anymore. That's the kind of problem we want to avoid here. ___ 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
Ben Maurer wrote: Please read my previous emails. Designing everything in C will not help. Evolution, OpenOffice and Firefox are evidence that writing your app in C does not make it memory efficient. In the long term, a moving GC may be beneficial. Does using a GC really mean you have to use a big bloated memory-hungry virtual machine ? Well, no. Inkscape uses a GC, and it is written in C++. D should provide a GC while not resting on a VM. If ever VM were able to share libs, it would be a great improvement, but currently they can't. It means the managed part of the code is loaded for every managed app you launch. Which is far from optimal in the case of permanently running apps. As I said, I don't care about apps that don't stay alive in background. At some point, we also have to realize that users with less memory do need to make compermises. For example, such a user might want to choose not to use Beagle. I don't use Beagle, and in fact I hope the alternate Tracker project will solve this problem. I don't use deskbar as well, nor banshee since the player is at the limit between a daemon and a classical app. But I can assure you I use python apps and even C# ones. ___ 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 Fri, 14 Jul 2006, [ISO-8859-1] Steve Fr?cinaux wrote: Andrew Cowie wrote: Which, to be honest, I feel makes this whole discussion a bit pointless. I realize that GNOME release engineering is holy ground, but don't you see? Everyone already ships Beagle. Which means they ship Mono. Which means it's a part of the GNOME desktop. fait accompli. Not really. In fact, blessing an app in the desktop has the immediate consequency that other apps can depend on it in a non-conditional way. For instance, a few distros already ship beagle by default, but most only ship it. And I just can't run beagle on my box, it eats up too much memory. So if it was proposed for inclusion, including it would mean that some Gnome apps would depend on it more or less inconditionally and I couldn't run these apps anymore. That's the kind of problem we want to avoid here. This is completely besides the point. Nobody is proposing that beagle be made a requirement for GNOME. I agree, this would cause a problem for many low memory users. Please limit this discussion to things that are being suggested. -- Ben___ 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 Fri, 14 Jul 2006, [ISO-8859-1] Steve Fr?cinaux wrote: Ben Maurer wrote: Please read my previous emails. Designing everything in C will not help. Evolution, OpenOffice and Firefox are evidence that writing your app in C does not make it memory efficient. In the long term, a moving GC may be beneficial. Does using a GC really mean you have to use a big bloated memory-hungry virtual machine ? Here we go with the X is bloated track again. I'm sure that gtk+ is very bloated because evolution is memory hungry. Well, no. Inkscape uses a GC, and it is written in C++. It's fairly hard to do this. A moving gc in C++ would be even harder. If ever VM were able to share libs, it would be a great improvement, but currently they can't. It means the managed part of the code is loaded Mono can do this. Read about AOT for every managed app you launch. Which is far from optimal in the case of permanently running apps. Even when we are not AOTing, the amount of ram dedicated to JITed code is small. If you are going to bitch, bitch with NUMBERS. The only performance data on this thread was the vmsize of a few applets, which means absolutely nothing. Just as a number for starters: when launching banshee without AOT, it takes 600 kb of JITd code space. Let's say it's really more like 1 MB after lots of use (probably higher than it actually is). Maybe there are 4 managed apps (Banshee, F-Spot, Beagle, Tomboy). That's 4 MB vs 1 MB if 100% of it was shared as in C. Not a lot. In the long term, we'll probably get more of a win with compacting from a GC than this. What's more: we can do better. When Mono improves it's code generation, every app benefits. In addition, AOT can reduce this problem. At some point, we also have to realize that users with less memory do need to make compermises. For example, such a user might want to choose not to use Beagle. I don't use Beagle, and in fact I hope the alternate Tracker project will solve this problem. I don't use deskbar as well, nor banshee since the player is at the limit between a daemon and a classical app. Just because GNOME has program X doesn't mean you have to use it. For example, having Evince doesn't prevent anyone from using acroread. -- Ben___ 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
* Jul 12 02:21 Elijah Newren [EMAIL PROTECTED]: [...] So, to start of the discussion, the proposed modules AFAIR are: * orca (as a replacement to gnopernicus) * alacarte * gnome-power-manager * Tomboy * Gtk# What about libnotify? It was proposed for 2.14 but rejected because of lack of HIG-docs IIRC? [...] -- Johan Svedberg, [EMAIL PROTECTED], http://johan.svedberg.com/ ___ 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
I'm concerned about the inclusion of GTK# - and hence all the rest of Mono into the core GNOME. It's been mentioned many times before that we already have too many component models in the GNOME platform - and once they are in there, it's VERY hard to get them back out again - just look at Bonobo. GTK# is not just a language binding - it's pulling in a whole platform in itself - Mono. And it worries me that this is opening a door for a slew of C# based applications into the core GNOME. It makes sense to me that Mono should remain on the out-skirts of GNOME for this very reason - core GNOME should only use native languages, and more specifically C, as to to do otherwise is likely to effect the already perceived poor performance of GNOME. Just think about what happens when a user logs into a desktop that has Python and C# based applets included with C based applets: - The panel starts - It starts C/Bonobo based applets - the smallest of which already consumes approx 40Mb of memory. - It starts Python applets - each of these takes up approx 70Mb of memory - and very little of this is shared - It starts a C# based applet - and this pulls in Mono, which I'm sure isn't that small, but I guess at least it does share memory better than Python, but there is still quite a lot of additional memory pulled in. I know today people say that memory is cheap, but I think that's not an excuse for working on reducing it's consumption. Also, there is the small devices like the Nokia 770 for which memory consumption is a big factor. As for .NET, even Microsoft themselves had to pull back from using it for core functionality due to performance reasons - why do we think we will do any better? I think, and this is only my opinion, we should consider the possibility of different levels (for want of a better word) for delivery of GNOME (if it's not already been done) - this would be similar to the way GStreamer has split it's modules - it makes sense from an ISV or OEM standpoint: - GNOME Core Defined as things GNOME simply couldn't be without and every distro that delivers GNOME would be expected to have this. - GNOME Native Native language bindings - i.e. not interpreted, like C++, and GNOME blessed applications - maybe we could break this down more, don't know. - GNOME Python Python bindings to GNOME Core and GNOME blessed Python applications. - GNOME Mono Mono bindings to GNOME Core and GNOME blessed Mono applications. We kind of have this informally at the moment, but what I'm proposing is that we would solidify it more. I'm sure there are more breakdowns possible - I just think an ISV or 3rd party developer should be able to express their dependencies for their application by saying they need GNOME Core or GNOME Mono. A breakdown like this also enables better enforcing of stability levels - e.g. GNOME Core should guarantee ABI compatibility. As it stands now, someone saying that they are developing a GNOME application cannot guarantee that for every GNOME platform out there their application will have all the libraries, bindings, etc. they need since different platforms can end up not delivering parts of the current core GNOME due to platform capabilities. Is there a definition of that is acceptable as a core GNOME application - other than it's based on consensus? I think we are badly in need of a definition that defines the needs of the core GNOME Desktop? That's just my thoughts on things... Thanks, Darren. Elijah Newren wrote: Hi everyone, As per the release schedule (http://live.gnome.org/TwoPointFifteen), it's time to heat up the module inclusion discussion. So, time to flame, argue, etc., etc. this week and see if we can reach consensus. The release team will try to meet next week about new module decisions with community input up to then so that the new modules can be announced in time for module freeze. We're actually optimistic enough (deluded enough?) to think we can make that deadline this time. :) So, to start of the discussion, the proposed modules AFAIR are: * orca (as a replacement to gnopernicus) * alacarte * gnome-power-manager * Tomboy * Gtk# There's one additional issue to address as well: * Okay to have desktop modules depend on gtk# bindings? Here's my biased guess (feel free to dispute) at where things stand: orca appears to be an uncontroversial choice with strong support, and which even the gnopernicus team is supporting. (There have been a number of threads and lots of comments; http://mail.gnome.org/archives/desktop-devel-list/2006-June/msg9.html seems like the best overview) There have not been many comments on alacarte; just a couple notes that looked like preliminary reviews in the thread where it was proposed (http://mail.gnome.org/archives/desktop-devel-list/2006-April/msg00305.html). So we definitely need thoughts and comments from the community. gnome-power-manager seems to have
Re: Time to heat up the new module discussion
On 7/12/06, Robert Love [EMAIL PROTECTED] wrote: On Tue, 2006-07-11 at 14:16 -0600, Elijah Newren wrote: So, to start of the discussion, the proposed modules AFAIR are: * orca (as a replacement to gnopernicus) * alacarte * gnome-power-manager * Tomboy * Gtk# * nm-applet The NetworkManager applet. I proposed inclusion at GUADEC. I'd like to Sounds like a great thing to propose for 2.18. Unfortunately, it looks like you missed the deadline for 2.16 proposals as it was about 2 months before GUADEC. See http://live.gnome.org/TwoPointFifteen and http://mail.gnome.org/archives/devel-announce-list/2006-April/msg0.html. Also, I don't see your proposal on d-d-l anywhere; was this another of those mailing list and archive issues? Cheers, Elijah ___ 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 7/12/06, Calum Benson [EMAIL PROTECTED] wrote: On 12 Jul 2006, at 08:56, Johan Svedberg wrote: * Jul 12 02:21 Elijah Newren [EMAIL PROTECTED]: [...] So, to start of the discussion, the proposed modules AFAIR are: * orca (as a replacement to gnopernicus) * alacarte * gnome-power-manager * Tomboy * Gtk# What about libnotify? It was proposed for 2.14 but rejected because of lack of HIG-docs IIRC? Hmm, I don't remember that, but I hope that wasn't the only reason. The HIG's notification section is certainly very poor at the moment, but if there's a surefire way to get us to improve it, it's to include the technology in the core platform so we have to do something about it :) It was a worry, but the bigger issue was that it depended on libsexy and lots of people didn't like the idea of adding another widget library to Gnome when we were doing our best with project Ridley to go in the opposite direction. ___ 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 (RESEND)
Darren Kenny wrote: Is there a definition of that is acceptable as a core GNOME application - other than it's based on consensus? I think we are badly in need of a definition that defines the needs of the core GNOME Desktop? There is no doubt we need to establish a definition of what constitute GNOME core application/platform and create some layered modules which are loosely coupled rather than tightly coupled dependency. In approach currently, because there is a nice application, we pull in the the whole dependency. And in the next release, someone write any nice application with plaftform X, we pull in another platform. In no time at all, GNOME will become so overly bloated in terms of foot print and performance. Of course, we can't define what platform can go in or not go in until we the community define what constitute the core apps/platform the GNOME release is made up of. But who are the people can/should establish this? -Ghee That's just my thoughts on things... Thanks, Darren. Elijah Newren wrote: Hi everyone, As per the release schedule (http://live.gnome.org/TwoPointFifteen), it's time to heat up the module inclusion discussion. So, time to flame, argue, etc., etc. this week and see if we can reach consensus. The release team will try to meet next week about new module decisions with community input up to then so that the new modules can be announced in time for module freeze. We're actually optimistic enough (deluded enough?) to think we can make that deadline this time. :) So, to start of the discussion, the proposed modules AFAIR are: * orca (as a replacement to gnopernicus) * alacarte * gnome-power-manager * Tomboy * Gtk# There's one additional issue to address as well: * Okay to have desktop modules depend on gtk# bindings? Here's my biased guess (feel free to dispute) at where things stand: orca appears to be an uncontroversial choice with strong support, and which even the gnopernicus team is supporting. (There have been a number of threads and lots of comments; http://mail.gnome.org/archives/desktop-devel-list/2006-June/msg9.html seems like the best overview) There have not been many comments on alacarte; just a couple notes that looked like preliminary reviews in the thread where it was proposed (http://mail.gnome.org/archives/desktop-devel-list/2006-April/msg00305.html). So we definitely need thoughts and comments from the community. gnome-power-manager seems to have lots of support and it appears it's getting picked up by all the major distributors (or already has been for some time now). Didn't find a clear overview email and there's been lots of threads. I guess http://mail.gnome.org/archives/desktop-devel-list/2006-April/msg00366.html works. Tomboy was proposed here: http://mail.gnome.org/archives/desktop-devel-list/2006-April/msg00253.html. Comments were very positive for the most part, but there are gtk# dependency issues that need to be resolved first (see e.g. http://mail.gnome.org/archives/desktop-devel-list/2006-April/msg00332.html). gtk# was proposed here: http://mail.gnome.org/archives/desktop-devel-list/2006-April/msg00457.html. There was one big (IMO) issue, mentioned in the thread (namely, wrapping API which had no stability guarantee) And the big question: We currently allow desktop modules to depend on the pygtk bindings, but no others. Should we extend that to include the gtk# ones (assuming, of course, that gtk# is added to the bindings set)? Cheers, Elijah ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Time to heat up the new module discussion
On Tue, 2006-07-11 at 14:16 -0600, Elijah Newren wrote: And the big question: We currently allow desktop modules to depend on the pygtk bindings, but no others. Should we extend that to include the gtk# ones (assuming, of course, that gtk# is added to the bindings set)? IMO we should allow modules to depend on any of the official bindings. -- Rodrigo Moya [EMAIL PROTECTED] ___ 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 7/12/06, Elijah Newren [EMAIL PROTECTED] wrote: On 7/12/06, Calum Benson [EMAIL PROTECTED] wrote: On 12 Jul 2006, at 08:56, Johan Svedberg wrote: * Jul 12 02:21 Elijah Newren [EMAIL PROTECTED]: [...] So, to start of the discussion, the proposed modules AFAIR are: * orca (as a replacement to gnopernicus) * alacarte * gnome-power-manager * Tomboy * Gtk# What about libnotify? It was proposed for 2.14 but rejected because of lack of HIG-docs IIRC? Hmm, I don't remember that, but I hope that wasn't the only reason. The HIG's notification section is certainly very poor at the moment, but if there's a surefire way to get us to improve it, it's to include the technology in the core platform so we have to do something about it :) It was a worry, but the bigger issue was that it depended on libsexy and lots of people didn't like the idea of adding another widget library to Gnome when we were doing our best with project Ridley to go in the opposite direction. In order to get support for the widgets notification-daemon needs from libsexy into gtk or Ridley *properly*, GtkLabel, GtkEntry, etc. would need extensive modifications. libsexy does naughty things to good widgets. It manipulates them in ways that ideally wouldn't have to be done. It works, but I wouldn't feel right trying to get those added to gtk/Ridley without GtkLabel and GtkEntry becoming more extensible. Unfortunately, that's a bigger task than I have time for. So given the things libsexy widgets do, I don't think it's too bad keeping them in their own library for now. It's a library that most distros now ship anyway, and does provide very useful functionality. Notification-daemon and libnotify are practically everywhere as well too. I would like to once again propose libnotify and notification-daemon for GNOME. I'm pretty sure it won't be accepted though because of the lack of a HIG (which could be written after it goes in, could it not?) and libsexy (which is maybe a bigger problem, but probably a necessary evil for now). If that's the case, it's a shame, because this is useful functionality for a lot of apps. I'd love to find a solution that most people are happy with. Christian ___ 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
Elijah Newren wrote: * orca (as a replacement to gnopernicus) * alacarte * gnome-power-manager * Tomboy * Gtk# Yay, I have no clue, Yay, Yay, and Yay, respectively. There's one additional issue to address as well: * Okay to have desktop modules depend on gtk# bindings? The argument here is we don't want the desktop to depend on weird languages where there aren't enough people who could fix bugs / assume maintainership in the future / etc, right? If so, I think C#/Gtk# is quite safe. There are lots of people hacking Gtk# apps these days. FWIW, searching gnomefiles turns up 110 python/pygtk apps/libs 59 mono/C#/gtk# 37 gtkmm/C++ 27 perl 16 java 5 ruby so gtk# is not as popular as python, but it's still already more popular than any of the other languages/bindings that have been around for longer than it has. And adding it to the bindings platform will presumably make it even more popular. -- Dan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Time to heat up the new module discussion
Hi everyone, As per the release schedule (http://live.gnome.org/TwoPointFifteen), it's time to heat up the module inclusion discussion. So, time to flame, argue, etc., etc. this week and see if we can reach consensus. The release team will try to meet next week about new module decisions with community input up to then so that the new modules can be announced in time for module freeze. We're actually optimistic enough (deluded enough?) to think we can make that deadline this time. :) So, to start of the discussion, the proposed modules AFAIR are: * orca (as a replacement to gnopernicus) * alacarte * gnome-power-manager * Tomboy * Gtk# There's one additional issue to address as well: * Okay to have desktop modules depend on gtk# bindings? Here's my biased guess (feel free to dispute) at where things stand: orca appears to be an uncontroversial choice with strong support, and which even the gnopernicus team is supporting. (There have been a number of threads and lots of comments; http://mail.gnome.org/archives/desktop-devel-list/2006-June/msg9.html seems like the best overview) There have not been many comments on alacarte; just a couple notes that looked like preliminary reviews in the thread where it was proposed (http://mail.gnome.org/archives/desktop-devel-list/2006-April/msg00305.html). So we definitely need thoughts and comments from the community. gnome-power-manager seems to have lots of support and it appears it's getting picked up by all the major distributors (or already has been for some time now). Didn't find a clear overview email and there's been lots of threads. I guess http://mail.gnome.org/archives/desktop-devel-list/2006-April/msg00366.html works. Tomboy was proposed here: http://mail.gnome.org/archives/desktop-devel-list/2006-April/msg00253.html. Comments were very positive for the most part, but there are gtk# dependency issues that need to be resolved first (see e.g. http://mail.gnome.org/archives/desktop-devel-list/2006-April/msg00332.html). gtk# was proposed here: http://mail.gnome.org/archives/desktop-devel-list/2006-April/msg00457.html. There was one big (IMO) issue, mentioned in the thread (namely, wrapping API which had no stability guarantee) And the big question: We currently allow desktop modules to depend on the pygtk bindings, but no others. Should we extend that to include the gtk# ones (assuming, of course, that gtk# is added to the bindings set)? Cheers, Elijah ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
