Re: Time to heat up the new module discussion (RESEND)

[Darren Kenny <Darren Kenny Sun COM>]

RESEND since first attempt didn't seem to make it...
----------------------------------------------------

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/msg00009.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