Re: Mono/GTK#/Tomboy

[Ben Maurer <bmaurer andrew cmu edu>]

On Fri, 14 Jul 2006, Murray Cumming wrote:
> I don't believe that you've adressed the memory problems, though these are
> not specific to Mono. We maybe can handle one highlevel runtime, but 2
> highlevel runtimes seems to be getting silly.

If exactly one runtime needs to be choosen, making python that choice 
seems relativly narrow sighted. Python provides *only* a scripting like 
environment. It does not seem that the project wants to provide (or should 
provide) more than that. Mono provides a framework that has been proven to 
be capable of supporting many languages (including python, in fact!).

In all honesty, I see Python as being popular for short lived applications 
(a menu editor, etc). While deskbar is contrary to this, that applet seems 
to be more of a prototype (especially given it's memory usage).

> The argument that we can fix performance later is not going down well with
> lots of users, though it makes sense in many ways. What do we say now to
> the people who say "The sticky notes applet now takes up XX megabytes more
> than before and makes GNOME start up much slower". Those people don't care
> about anybody's favorite programming language.

This is not really as much Mono as it is Tomboy (though both have room for 
optimization). However, we have been accepting many things that continue 
to add memory usage (g-power-manager adds yet another daemon taking ~2 MB 
of memory for EVERYONE, not just sticky users. network maanger, which will 
probably be accepted for the next cycle will add another process, 
notifications another).

If everyone who has spent so much energy on this thread puts just a bit 
into performance, we'll have a very cool and very light tomboy. GNOME 
opening it's arms to Tomboy and other Mono apps will likely motivate the 
authors to do things that meet GNOME's goals.

> We want to have it both ways, but we can't right now, so we must make the
> difficult decision between these pros and cons. It's not helpful to
> pretend that the decision doesn't exist.

Keeping the status quo is also a decision (granted a passive one) the 
ramifications of which must too be considered. Right now, there are C# 
apps that overlap with some of the functionality in the official GNOME 
desktop, rhythmbox and banshee come to mind. The longer GNOME is 
indecisive, the more effort is put into *both* applications.

> Also, Tomboy is an applet, intended to replace the commonly-used sticky
> notes applet, so it's likely to take up memory all the time. (I haven't
> had a response to my notes->tomboy transistion questions [1] but that's a
> non-mono issue.)

Given the lateness in the release cycle, it would seem reckless to 
*remove* sticky notes. What about accepting Mono and Tomboy for this 
release cycle and keeping sticky notes. Then, for the next release cycle, 
there is the confidence that a silly flamewar on d-d-l won't keep the 
applications out of GNOME, encouraging the authors do meet GNOME's needs.

> deskbar-applet has the same problem, of course. When we approved python I
> don't think we necessarily approved this particular use. That was a
> separate thing.

Then why can't Tomboy be accepted on the same terms as deskbar.

> And you are ignoring the objections to relying on a techology that is
> controlled by Microsoft, who:
...
> understand why it is necessary for some people to pretend that they are
> not real concerns.

Apparently, neither Novell, Red Hat nor Ubuntu considers the risks enough 
to prevent them from shipping Mono. As for your flames about Microsoft's 
technical competence, rather than making an attack on Microsoft, say 
something about the .NET framework. We could spend all day insulting and 
making generalizations.

-- Ben