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 happen since the use of things like GNOME in small devices serves the help GNOME improve performance greatly on large devices :) > >> 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". Darren. > > iain > _______________________________________________ > desktop-devel-list mailing list > [email protected] > http://mail.gnome.org/mailman/listinfo/desktop-devel-list _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
