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
[email protected]
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Reply via email to