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