Re: Mono/GTK#/Tomboy
On Sun, 2006-07-16 at 21:26 +0200, Murray Cumming wrote: > On Sat, 2006-07-15 at 18:10 -0700, Alex Graveley wrote: > > Hi Murray, > > > > As I hinted at back in April[1], I don't think Tomboy is a blanket > > replacement for sticky notes. As I said, into the abyss, a first-run > > wizard for importing existing sticky notes makes more sense. > > In my opinion, having both would be a very odd duplication of > functionality, and would be confusing for users and distros. What can > sticky notes do that Tomboy can't? Sticky Notes is SIMPLE. I love them. If I need to quickly write a telephone number down I can create a nice, yellow(!) Sticky Note with one click, type the number, and be done. With Tomboy I need to think about a note title. As simple a task as that is, most of the time I really can't be bothered. Also, having pale yellow Sticky Notes with dropshadows and such is a VERY nice effect with Compiz! I love the way they all hide away! :) So, I answer your question with another question. Why do you think they occupy the same use profile? I think tomboy is more for organising information than for jotting down phone numbers. > > > I'm somewhat unfamiliar with the GNOME acceptance process. Was I > > expected to do this work in the interim time frame? > > You're not hostage to every guy who emails on d-d-l list, but you need > to make the release-team feel that there's consensus and that nothing > odd is going to happen. More or less. I'm not on the release team. > -- Alex Jones <[EMAIL PROTECTED]> ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mono/GTK#/Tomboy
> > How do we deal with the tarballs on the ftp servers? (there's no > > packages there). We only want the supported bindings in > > http://ftp.gnome.org/pub/GNOME/bindings/2.x/2.x.y/sources/ > > I'm not sure where you're going, everything in gtk# should be supported, > or is there something you think isn't? Just an unclear word - the distinction is stable Platform APIs vs. unstable APIs available elsewhere (throughout the Desktop suite, for instance). - Jeff -- linux.conf.au 2007: Sydney, Australia http://lca2007.linux.org.au/ "A 'lame' server is a server that is SUPPOSED to be authoritative, but, when asked, says: 'Me? I know nothing, I'm from Madrid!'" - Ralf Hildebrandt ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mono/GTK#/Tomboy
On Mon, 2006-07-17 at 10:12 -0400, JP Rosevear wrote: > On Fri, 2006-07-14 at 09:58 +0200, Jan de Groot wrote: > > On Fri, 2006-07-14 at 08:32 +0200, Murray Cumming wrote: > > > And while there were almost no objections to Python, there are clearly > > > many objections to Mono. > > > > I used to have objections against the python bindings, but after those > > got splitup in pygtk, gnome-python, gnome-python-desktop and > > gnome-python-extras, I don't have big problems with it. > > > > Looking at mono, all of these bindings are in one package: gtk-sharp-2. > > I think, to get mono as accepted binding language, we should have a > > splitup similiar to the splitup that has been done to the python > > bindings. > > This is really just a packaging issue, on opensuse/SLED they are all > individual packages (glib-sharp, gtk-sharp, etc). > > -JP On archlinux where we maintain a 1-1 relation on source and binary, we will have to do a manual splitup of these modules. There's no possible way of configuring anything with switches like --disable-gnomevfs, all modules present on the system get built by default. When I take a look at how nice the C++ bindings have been maintained for ages, I would wish to have such a system for the C# bindings too. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mono/GTK#/Tomboy
On Mon, 2006-07-17 at 17:30 +0200, Vincent Untz wrote: > Le lundi 17 juillet 2006, à 10:12, JP Rosevear a écrit : > > On Fri, 2006-07-14 at 09:58 +0200, Jan de Groot wrote: > > > On Fri, 2006-07-14 at 08:32 +0200, Murray Cumming wrote: > > > > And while there were almost no objections to Python, there are clearly > > > > many objections to Mono. > > > > > > I used to have objections against the python bindings, but after those > > > got splitup in pygtk, gnome-python, gnome-python-desktop and > > > gnome-python-extras, I don't have big problems with it. > > > > > > Looking at mono, all of these bindings are in one package: gtk-sharp-2. > > > I think, to get mono as accepted binding language, we should have a > > > splitup similiar to the splitup that has been done to the python > > > bindings. > > > > This is really just a packaging issue, on opensuse/SLED they are all > > individual packages (glib-sharp, gtk-sharp, etc). > > How do we deal with the tarballs on the ftp servers? (there's no > packages there). We only want the supported bindings in > http://ftp.gnome.org/pub/GNOME/bindings/2.x/2.x.y/sources/ I'm not sure where you're going, everything in gtk# should be supported, or is there something you think isn't? -JP -- JP Rosevear <[EMAIL PROTECTED]> Novell, Inc. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mono/GTK#/Tomboy
Le lundi 17 juillet 2006, à 10:12, JP Rosevear a écrit : > On Fri, 2006-07-14 at 09:58 +0200, Jan de Groot wrote: > > On Fri, 2006-07-14 at 08:32 +0200, Murray Cumming wrote: > > > And while there were almost no objections to Python, there are clearly > > > many objections to Mono. > > > > I used to have objections against the python bindings, but after those > > got splitup in pygtk, gnome-python, gnome-python-desktop and > > gnome-python-extras, I don't have big problems with it. > > > > Looking at mono, all of these bindings are in one package: gtk-sharp-2. > > I think, to get mono as accepted binding language, we should have a > > splitup similiar to the splitup that has been done to the python > > bindings. > > This is really just a packaging issue, on opensuse/SLED they are all > individual packages (glib-sharp, gtk-sharp, etc). How do we deal with the tarballs on the ftp servers? (there's no packages there). We only want the supported bindings in http://ftp.gnome.org/pub/GNOME/bindings/2.x/2.x.y/sources/ Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mono/GTK#/Tomboy
On Mon, 2006-07-17 at 10:12 -0400, JP Rosevear wrote: > This is really just a packaging issue, on opensuse/SLED they are all > individual packages (glib-sharp, gtk-sharp, etc). Not taking a side but I would like to point out that they are also separately packaged on Ubuntu and Debian-based distros. signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mono/GTK#/Tomboy
On Fri, 2006-07-14 at 09:58 +0200, Jan de Groot wrote: > On Fri, 2006-07-14 at 08:32 +0200, Murray Cumming wrote: > > And while there were almost no objections to Python, there are clearly > > many objections to Mono. > > I used to have objections against the python bindings, but after those > got splitup in pygtk, gnome-python, gnome-python-desktop and > gnome-python-extras, I don't have big problems with it. > > Looking at mono, all of these bindings are in one package: gtk-sharp-2. > I think, to get mono as accepted binding language, we should have a > splitup similiar to the splitup that has been done to the python > bindings. This is really just a packaging issue, on opensuse/SLED they are all individual packages (glib-sharp, gtk-sharp, etc). -JP -- JP Rosevear <[EMAIL PROTECTED]> Novell, Inc. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mono/GTK#/Tomboy
The thing is that the user models are very different. If a sticky notes user is accustomed to always seeing his notes on his desktop, all at the same time, if after an upgrade his notes are locked away in a menu with no easy way to get them all to display again, he might be confused and probably annoyed. -Alex Murray Cumming wrote: > In my opinion, having both would be a very odd duplication of > functionality, and would be confusing for users and distros. What can > sticky notes do that Tomboy can't? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mono/GTK#/Tomboy
On Sat, 2006-07-15 at 18:10 -0700, Alex Graveley wrote: > Hi Murray, > > As I hinted at back in April[1], I don't think Tomboy is a blanket > replacement for sticky notes. As I said, into the abyss, a first-run > wizard for importing existing sticky notes makes more sense. In my opinion, having both would be a very odd duplication of functionality, and would be confusing for users and distros. What can sticky notes do that Tomboy can't? > I'm somewhat unfamiliar with the GNOME acceptance process. Was I > expected to do this work in the interim time frame? You're not hostage to every guy who emails on d-d-l list, but you need to make the release-team feel that there's consensus and that nothing odd is going to happen. More or less. I'm not on the release team. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mono/GTK#/Tomboy
Hi Alex, On sam, 2006-07-15 at 18:10 -0700, Alex Graveley wrote: > Hi Murray, > > As I hinted at back in April[1], I don't think Tomboy is a blanket > replacement for sticky notes. As I said, into the abyss, a first-run > wizard for importing existing sticky notes makes more sense. > > I'm somewhat unfamiliar with the GNOME acceptance process. Was I > expected to do this work in the interim time frame? I believe it would really help for the decision to be able to import the sticky notes data, yes. Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mono/GTK#/Tomboy
On ven, 2006-07-14 at 12:10 -0500, Federico Mena Quintero wrote: > The main point about performance is whether users think it is a good > deal. > > So Firefox eats 400 MB. Do I think it's a good deal? Absolutely! It's > the best browser out there. > > So Tomboy eats 15 MB. Do I think it's a good deal? Absolutely! It's > the best note-taking app I know. > > So OpenOffice takes 100 MB. Do I think it's a good deal? Absolutely! > I wouldn't go back to Magicpoint EVER. > > So F-spot takes MB. So what? It's the best photo > cataloguing app we have. > > Can those numbers be improved? Absolutely. And we should do it. Federico, I love you. But really, you should switch to epiphany ;-) Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mono/GTK#/Tomboy
Hi Murray, As I hinted at back in April[1], I don't think Tomboy is a blanket replacement for sticky notes. As I said, into the abyss, a first-run wizard for importing existing sticky notes makes more sense. I'm somewhat unfamiliar with the GNOME acceptance process. Was I expected to do this work in the interim time frame? -Alex [1] http://mail.gnome.org/archives/desktop-devel-list/2006-April/msg00281.html Murray Cumming wrote: > On Fri, 2006-07-14 at 17:19 -0400, Ben Maurer wrote: > [snip] >> Given the lateness in the release cycle, it would seem reckless to >> *remove* sticky notes. > [snip] > > Yes, hence I don't think Tomboy can go in, regardless of anything else. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mono/GTK#/Tomboy
Hello, > I'm way past my quota of repeating myself, and deep in rant land, but > this is what happened with Bonobo. Developers knew it wasn't ready, knew > it wasn't suitable for such deep use, and knew there was a risk to > making it central to GNOME. It was pushed through anyway, and that was > allowed in order to avoid a split among the developers. But I hope that > our community is stronger now. No, this is not what happened with Bonobo. Bonobo was a completely different ball game. It was a technology that we created initially for creating compound documents in Gnumeric, I was maintaining both at the time. Bonobo later got reused for embedding controls, which is something that we wanted in Evolution and something that Eazel decided they wanted to use to support menu merging across components. There was not even a discussion of this kind about Bonobo, Bonobo was merely a dependency to get certain features working. The problems Bonobo tried to solve, turned out to be very complex and the solution turned out to be very complex. In fact, the steering committee, which lead to the creation of the foundation, which lead to the board, and to today's release engineering was created out the need to have a stable release of a number of components at the time and to mediate between Eazel and Ximian's product schedules. We had some cross-company interlock dependencies. We needed to come to an agreement about how fast each company could deliver and complete the components they were in charge. Miguel. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mono/GTK#/Tomboy
On Fri, 2006-07-14 at 17:19 -0400, Ben Maurer wrote: [snip] > Given the lateness in the release cycle, it would seem reckless to > *remove* sticky notes. [snip] Yes, hence I don't think Tomboy can go in, regardless of anything else. > 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. [snip] Peoples' concerns are not silly (or FUD as Miguel called them). I'd understand if Mono's supporters acknowledged the problems and risks but said that they didn't think they were significant, and that they are prepared to take the risk. Then we could just disagree about priorities. but I'm scared at the idea of just pretending that everything is OK. I'm way past my quota of repeating myself, and deep in rant land, but this is what happened with Bonobo. Developers knew it wasn't ready, knew it wasn't suitable for such deep use, and knew there was a risk to making it central to GNOME. It was pushed through anyway, and that was allowed in order to avoid a split among the developers. But I hope that our community is stronger now. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mono/GTK#/Tomboy
Hi Miguel, > Today the issue of resource usage is brought up as if it were the end of > the world, back in the day, Jonathan made the following comment: To me it's not the resource usage of any such language as such on its own. I'm living under the delusion (for the sake of argument) that a python app and a mono app are comparable in their resource usage. > I do not think there should be only "one way" of building applications > for Gnome. We would not have the official language bindings release if > we thought that only C code was worth having. I think any language is fine for writing a Gnome app. The issue is more about what is officially put in a Gnome desktop release as such - how many managed languages with their own runtime do we want as part of a default Gnome desktop ? Thomas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Deskbar experience (was: Mono/GTK#/Tomboy)
Hi ! > 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). I like to consider deskbar as a prototype too. Keep in mind however that nobody has yet proposed me to rewrite it in C, i certainly don't have time nor will to do it myself, and i would loose my two other developers because of that, leaving deskbar with no maintainers. It's easy to say let's first write it in python/whatever highlevel language, then port it to C for performance or memory usage. The reality is that you either spend your time in fixing actual bugs or adding new features that are worth it (and python/foobar makes this really easy). Given that spending more time in porting with no added benefit beside hypothetical memory/speed, and loosing with that process maybe half of the bugfixing time spent earlier, without mentioning that you have now a beautiful C code, that nobody want to touch and you get no more contributions. So you end up with two choice accepting that less people want to create and maintain C applications than before and including applications like deskbar. Or deciding that you don't care about new innovative applications (and i'm not saying that) just because they are written in a language that eats memory (given the present RAM value, running deskbar costs approximately $2 which is even less if you are in europe :)) and loose the wow factor, and the people working on those, because not being acknowledged by GNOME when you do gnome applications sucks. $2 is a price i'm willing to pay to run deskbar, by the way. Raf ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mono/GTK#/Tomboy
> Right now, there are C# apps that overlap with some of the functionality > in the official GNOME desktop, rhythmbox and banshee come to mind. Rhythmbox is not in the Desktop suite. - Jeff -- linux.conf.au 2007: Sydney, Australia http://lca2007.linux.org.au/ "The postmodern version is: If all you have is duct tape, everything starts to look like a duct. Right. When's the last time you used duct tape on a duct?" - Larry Wall ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mono/GTK#/Tomboy
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 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mono/GTK#/Tomboy
Miguel de Icaza wrote: >1. Microsoft, the FUD argument, I wont say anything more that has > not been addressed in the past, other than from a legal > standpoint we created the "Open Invention Network" to protect > open source with teeth. > > Status: FUD. I'm not that sure it's FUD. Well, certainly if it's FUD is due to its current market share numbers. However, if GNOME becomes more popular I'm really afraid it'd become a real problem. >2. Additional Framework: yes, it is an additional and *optional* > framework. Nobody is forcing you to use it. > > Status: minor concern, its optional. Minor concern? What an optimistic point of view. For me this is a major concern. If we open the door to more additional frameworks, we are allowing anyone to base every type of applications on it, which is something that will bring a bunch of problems that we don't want to suffer. >3. GNOME is the only platform which would depend on an extra > framework. > > Status: debunked. > > You quoted KDE, and I pointed to you that KDE has support for > Mono, Ruby, Python, JavaScript and Perl. You conveniently > have ignored the evidence contrary to your statements. There are not basic KDE written on anything but C++. I'm right. They can have Mono binding, Python binding, and whatever they want, but there aren't important applications based on them. So, yeah.. it seems that GNOME is the only desktop with people interesting on doing such thing. >4. Resources: yes, Mono takes more memory, we are not making it > mandatory for Mono applications to be part of the core desktop. > > It is optional; Dont like it, dont run it. > > Status: Minor concern. Ey, that would be fair enough, the consensus solve. But, for don't running it, we have to ensure that all the basic desktop apps are based only on the GNOME framework. It is fine if there are "Mono + GNOME" applications out there, but not inside the basic GNOME desktop. So, again, this is a quite big concern. Have you read Darren's mail on this issue? It's pretty interesting. >5. Managed/interpret code is slow/larger > > Yes, it is. So we should block any managed/interpreted systems > to provide bindings to Gnome, because everyone must use > C/C++/another compiled language? Why should we should do something that radical? :-? The only thing we shouldn't do is to allow they use of the basic GNOME desktop application. > Status: Minor issue. I'm sorry to disagree. Slow code is not a minor issue, no matter how positive you're trying to be. >6. Original authors could not use it. > > You used a gossip article, I pointed to you to the real > reason for the Longhorn failures, which you conveniently > ignored. > > You did not reply to whether we can do better than Microsoft > (again, conveniently ignored). > > But in addition, Microsoft has a lot of .NET code in shipping > products, so the whole argument goes down: > > http://blogs.msdn.com/danielfe/archive/2005/12/16/504847.aspx > > Status: debunked. Miguel, you know way much more than me about Microsoft and .NET, that is crystal clear. So there was no point on arguing on that with you. In anyway, the fact is that they haven't used it.. and despite the reasons, that tells me something. >7. Build Time Complexity > > A real issue, but someone has pointed out that every Linux distro > has already sorted that out. Besides, Mono is only one extra > tarball dependency. > > And its only a dependency for the Gtk# binding, what we are > discussing. > > If we are going to have an issue over adding a new tarball as a > dependency, we might as well not even have a process to expand > Gnome in the first place. > > Status: unless we are willing to make a case for no-new-packages > I do not consider this an issue. It is not the same to add a new library than to add a new huge development framework: a bast class library, compilers and stuff. So, again, we shouldn't be that radical, we can perfectly extend GNOME but take care of what we use to extend it. >8. Why Python can and Mono cant. > > Its hard to argue with someone that thinks that Python was a > mistake in the first place (from your email). > > Status: pending. Why is that difficult? Is it that difficult to understand that I don't want to waste a few megabytes of memory in my desktop just because there is an applet written in a convenience language? By the way, I do like Python. However, I also think that a GNOME applet that is shipped by default is not the right place for it. >9. Political > > Your company does not have to ship Mono, it is not mandatory, > and the core is not being rewritten to use it. > >
Re: Mono/GTK#/Tomboy
Miguel de Icaza wrote: And while there were almost no objections to Python, there are clearly many objections to Mono. >>> What objections? So far, the only two objections I've heard are: >> Obviously, there are many. > > Please enumerate all the objections. It seems from reading this list, that these are: * Large memory usage. Perhaps not for an application, but when used as a part of the Desktop or long running process. * Startup time. Again one can wait for an application, but when part of the desktop it becomes problematic. * Proliferation of too many frameworks in the GNOME desktop. * Having large parts of the Desktop become dependent on Mono components. Mono as an integral part of GNOME. * Worries about Microsoft. * Microsoft not using .NET on their Desktop. Note that these aren't my objections, and for details you'll have to go back and read the various threads. So, no need to feel pressured to defend against these objections right here. Cheers, Nate ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mono/GTK#/Tomboy
Hello, > > > > What's the compelling reason to ship bindings? > > > > Great apps. > > > > > > I personally think that "Great development environment" is a more > > > compelling reason, given that the majority of software development is > > > in-house stuff that will never be on distros. That really is a vast > > > huge immense amount of unseen software. > > More than once you have confused the acceptance of bindings with the > acceptance of the use of those bindings in the desktop. My quote above > does not contain this confusion. I stand corrected. > > The same applies here. > > > > I do not think there should be only "one way" of building applications > > for Gnome. We would not have the official language bindings release if > > we thought that only C code was worth having. > -- Miguel de Icaza <[EMAIL PROTECTED]> ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mono/GTK#/Tomboy
On Fri, 2006-07-14 at 15:01 -0400, Miguel de Icaza wrote: [snip] > Murray at the time posted the following eloquent email on this subject: > > > > What's the compelling reason to ship bindings? > > > Great apps. > > > > I personally think that "Great development environment" is a more > > compelling reason, given that the majority of software development is > > in-house stuff that will never be on distros. That really is a vast > > huge immense amount of unseen software. More than once you have confused the acceptance of bindings with the acceptance of the use of those bindings in the desktop. My quote above does not contain this confusion. > The same applies here. > > I do not think there should be only "one way" of building applications > for Gnome. We would not have the official language bindings release if > we thought that only C code was worth having. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mono/GTK#/Tomboy
Hello, > Python was the first language to reach enough maturity and ruffle the > least amount of feathers, and that is a point of differentiation with > any language that comes in later. > > The important thing we wanted when Python got accepted was to have at > least one higher-level language to be available for use, and not have a > lot of them. > > So in short, I don't think there is an equal footing, and if people > would want Mono in, it should replace Python, not sit side by side to > it. This is radically different than your original proposal, when you brought Python up in September 2004. This is what you said: > Why prove Havoc right so quickly ? The discussion on "what language > should go in" has been hashed out numerous times already, don't give > Havoc the satisfaction of predicting our behaviour of degenerating the > discussion into a language discussion. > > I am asking a very concrete, specific thing - here's a module I'm > maintainer of and which I feel would benefit from being written in > something more flexible than C, and I want to use python for it. > > What would happen to the modules involved ? Today the issue of resource usage is brought up as if it were the end of the world, back in the day, Jonathan made the following comment: > I would love to see limited use of python in the desktop release for > GNOME 2.10. I'm not sure we want to see applets or core components > written in python yet, primarily because of the assumed resource hit. > I'd love to be proven that it is feasible, though. It certainly makes > sense for applications with a limited lifespan, such as those in the > control-center or gnome-utilities. Murray at the time posted the following eloquent email on this subject: > > What's the compelling reason to ship bindings? > > Great apps. > > I personally think that "Great development environment" is a more > compelling reason, given that the majority of software development is > in-house stuff that will never be on distros. That really is a vast > huge immense amount of unseen software. The same applies here. I do not think there should be only "one way" of building applications for Gnome. We would not have the official language bindings release if we thought that only C code was worth having. Miguel. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mono/GTK#/Tomboy
Hello, Ben presented a case (2 points) and you said "there are many more". I appreciate your list, but your list contains multiple points that have been debunked by various people. Am sorry if this email seems dismissive, but you conveniently quoted the pieces you wanted and ignored follow up messages that addressed these problems. 1. Microsoft, the FUD argument, I wont say anything more that has not been addressed in the past, other than from a legal standpoint we created the "Open Invention Network" to protect open source with teeth. Status: FUD. 2. Additional Framework: yes, it is an additional and *optional* framework. Nobody is forcing you to use it. Status: minor concern, its optional. 3. GNOME is the only platform which would depend on an extra framework. Status: debunked. You quoted KDE, and I pointed to you that KDE has support for Mono, Ruby, Python, JavaScript and Perl. You conveniently have ignored the evidence contrary to your statements. 4. Resources: yes, Mono takes more memory, we are not making it mandatory for Mono applications to be part of the core desktop. It is optional; Dont like it, dont run it. Status: Minor concern. 5. Managed/interpret code is slow/larger Yes, it is. So we should block any managed/interpreted systems to provide bindings to Gnome, because everyone must use C/C++/another compiled language? Shortsighted. Status: Minor issue. 6. Original authors could not use it. You used a gossip article, I pointed to you to the real reason for the Longhorn failures, which you conveniently ignored. You did not reply to whether we can do better than Microsoft (again, conveniently ignored). But in addition, Microsoft has a lot of .NET code in shipping products, so the whole argument goes down: http://blogs.msdn.com/danielfe/archive/2005/12/16/504847.aspx Status: debunked. 7. Build Time Complexity A real issue, but someone has pointed out that every Linux distro has already sorted that out. Besides, Mono is only one extra tarball dependency. And its only a dependency for the Gtk# binding, what we are discussing. If we are going to have an issue over adding a new tarball as a dependency, we might as well not even have a process to expand Gnome in the first place. Status: unless we are willing to make a case for no-new-packages I do not consider this an issue. 8. Why Python can and Mono cant. Its hard to argue with someone that thinks that Python was a mistake in the first place (from your email). Status: pending. 9. Political Your company does not have to ship Mono, it is not mandatory, and the core is not being rewritten to use it. That being said, your company, Sun, of all companies, has a patent license to all Microsoft technologies, so there are no technical or legal barriers. There are merely strategical and ideological barriers that are barring Sun from shipping Mono. Status: Sun's problem. Not Gnome's. 10. Human Resources Status: minor. Your argument assumes that Gnome and Mono can not grow, that they are frozen in time. I do not believe for a second that Gnome has reached its peak, if anything more developers are joining the effort. Those choosing to use Mono will depend on Mono bug fixes for its bug fixes. But so does anyone depending on any other library, language and framework. Miguel. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mono/GTK#/Tomboy
Miguel de Icaza wrote: And while there were almost no objections to Python, there are clearly many objections to Mono. >>> >>> What objections? So far, the only two objections I've heard are: >> >> Obviously, there are many. > > Please enumerate all the objections. We have been discussing the objections all these days, I thought you were reading. Anyway, here you have a few quotes from the thread (without any special order): 1 - Microsoft: = > The answer is known: It is that enormous elephant standing in the > corner that folks have been politely tip-toeing around, trying to > ignore. The Mono project ultimately advances the interests of > Microsoft, a company that is no friend to the open source > movement. I question whether it is prudent for GNOME to be > complicit. = = > And you are ignoring the objections to relying on a techology that > is controlled by Microsoft, who: > > - want to destroy us, and have left open legal ways to do this. > - have a history of being technically incompetent, . > - have a history of ruining anything that their non-incompetent >people created, yet we must chase compatibility with them. > > Not many people are bothering to repeat these problems in this > thread, because they are rather obvious and they shouldn't have > to. I don't understand why it is necessary for some people to > pretend that they are not real concerns. > > I am at least glad that we have at least have a consensus that Mono > will never be used in the GNOME Platform, but as the Desktop becomes > more integrated, it will still be difficult to remove parts of it if > necessary. = 2 - Additional framework: = > 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. = = > 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. = 3 - GNOME is the only framework/desktop which could depend on another few additional frameworks: = > Think of another desktop, choose the one you want.. let's say KDE: > it's one framework, one desktop and innovative applications. So, > yeah, rather than something strange, it's the usual business for > everybody else. = 4 - Resources: = > 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. = = > A good start would be: let's take an old (but still existing) > platform, like a pIII with 128 or 256 Mb RAM, and have a basic > desktop running fine on it. [..] > As said elsewhere, temporary apps (like a menu editor) don't matter > but long-running ones (mailer, panel, applets, filemanager) should > have a deterministic, capped memory usage. = = > Does it make sense to you to use have three or four different DOM > parsers in memory at the same time? (libxml2, python, mono and java > for example). In fact, if it was only that, it wouldn't be that bad; > the problem is that there are many other pieces that are also > overlapping with the GNOME framework = = > 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.) > > 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. = 5 - Managed / Interpreted code = > Jits on the desktop are usually bad not just because they do take > more memory but also because you need the build system of mono > installed which means more bloat. = = > Every compacting GC automatically doubles memory use - you have two > managed heaps ergo twice the RAM required. If you copy MS and go for > a three generation one then you risk trebling memory use over using > a non-compacting one. > > (malloc and free do not return memory to the OS on linux and most > other systems - the memory is retained for reuse for the app). > > Mmap'ping blocks of memory can be returned to the OS but they are at > least 5x slower than malloc/free and are only worth using wi
Re: Mono/GTK#/Tomboy
On Fri, 2006-07-14 at 10:50 +0200, 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.
baseline.py:
import gtk
window = gtk.Window ()
window.show ()
gtk.main ()
pmap says:
3532K writable-private, 14284K readonly-private, and 28K shared
baseline.cs:
using Gtk;
class Foo {
public static void Main (string[] args)
{
Gtk.Window window;
Gtk.Application.Init ();
window = new Gtk.Window (Gtk.WindowType.Toplevel);
window.Show ();
Gtk.Application.Run ();
}
}
pmap says:
3324K writable-private, 16224K readonly-private, and 4868K shared
"Look, Mono uses 200 KB less writable memory! And, uh, it shares more
data! Or something!"
These numbers mean nothing. Those tiny "apps" are perfectly useless.
> 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.)
The main point about performance is whether users think it is a good
deal.
So Firefox eats 400 MB. Do I think it's a good deal? Absolutely! It's
the best browser out there.
So Tomboy eats 15 MB. Do I think it's a good deal? Absolutely! It's
the best note-taking app I know.
So OpenOffice takes 100 MB. Do I think it's a good deal? Absolutely!
I wouldn't go back to Magicpoint EVER.
So F-spot takes MB. So what? It's the best photo
cataloguing app we have.
Can those numbers be improved? Absolutely. And we should do it.
Federico
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mono/GTK#/Tomboy
Hi, > Further, the objections mentioned all seem to apply equaly to python and > mono. Python is allowed for desktop apps already. If nobody can come up > with objections to mono that don't apply equally to python, it would seem > that mono and python should be on equal footing. I don't think that is true; if that were true, any language that satisfies the same basic requirements would be acceptable. Clearly it is not ideal at all to have five different runtimes side by side all eating memory in their own way. Python was the first language to reach enough maturity and ruffle the least amount of feathers, and that is a point of differentiation with any language that comes in later. The important thing we wanted when Python got accepted was to have at least one higher-level language to be available for use, and not have a lot of them. So in short, I don't think there is an equal footing, and if people would want Mono in, it should replace Python, not sit side by side to it. Thomas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mono/GTK#/Tomboy
Hello, > >> And while there were almost no objections to Python, there are > >> clearly many objections to Mono. > > > > What objections? So far, the only two objections I've heard are: > > Obviously, there are many. Please enumerate all the objections. Miguel. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mono/GTK#/Tomboy
Murray Cumming wrote: > 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.) > > 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. I'm glad you summarized my concerns so well :-) > I am at least glad that we have at least have a consensus that Mono will > never be used in the GNOME Platform, but as the Desktop becomes more > integrated, it will still be difficult to remove parts of it if necessary. That's why we have to think about it twice. Many Gnome apps written in mono are already around (as well as apps written in Ruby and such), but does it mean we have to bless them already? It looks like many people here still have to be convinced that mono is as good as some people say. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mono/GTK#/Tomboy
On Sex, 2006-07-14 at 10:50 +0200, Murray Cumming wrote: > > On Fri, 14 Jul 2006, Murray Cumming wrote: > >> And while there were almost no objections to Python, there are clearly > >> many objections to Mono. > > > > What objections? So far, the only two objections I've heard are: > > > > 1. Performance -- I feel that I've addressed this in other emails. > > 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. > > 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. > > 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. > > 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.) > > 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. I don't think deskbar is a problem because: 1. deskbar is a kind of "power user" tool; 2. deskbar is not loaded by default; the user has to explicitly find it and loaded. So the fact that python apps are acceptable to the GNOME desktop doesn't not imply that the GNOME desktop is more bloated. Regards, -- Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> The universe is always one step beyond logic. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mono/GTK#/Tomboy
Ben Maurer wrote: >> And while there were almost no objections to Python, there are >> clearly many objections to Mono. > > What objections? So far, the only two objections I've heard are: Obviously, there are many. > 1. Performance > 2. Vague references [..] You exposed your point of view. You did not show that the people who are concerned is wrong. The problems remain the same. > Further, the objections mentioned all seem to apply equaly to python > and mono. Python is allowed for desktop apps already. If nobody can > come up with objections to mono that don't apply equally to python, > it would seem that mono and python should be on equal footing. My opinion: the Python adoption was a mistake. In any case, it's too late for that, so let's stop worrying about Python. BTW, that "if Python did, Mono should do as well" doesn't make sense. Will we do the same with Java? anc C++? and ObjectiveC? Ada? How many languages and extra platforms do we need to keep everyone happy? -- Greetings, alo. http://www.alobbs.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mono/GTK#/Tomboy
> On Fri, 14 Jul 2006, Murray Cumming wrote: >> And while there were almost no objections to Python, there are clearly >> many objections to Mono. > > What objections? So far, the only two objections I've heard are: > > 1. Performance -- I feel that I've addressed this in other emails. 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. 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. 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. 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.) 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. > 2. Vague references to TLAs such as ISV, OEM, API, ABI without refering to > specific problems. Mono provides a very strong ABI in the base class > libraries (we implement the same API as the .NET framework). For mono > specific libraries, Mono commits to a similar stability level. And you are ignoring the objections to relying on a techology that is controlled by Microsoft, who: - want to destroy us, and have left open legal ways to do this. - have a history of being technically incompetent, . - have a history of ruining anything that their non-incompetent people created, yet we must chase compatibility with them. Not many people are bothering to repeat these problems in this thread, because they are rather obvious and they shouldn't have to. I don't understand why it is necessary for some people to pretend that they are not real concerns. I am at least glad that we have at least have a consensus that Mono will never be used in the GNOME Platform, but as the Desktop becomes more integrated, it will still be difficult to remove parts of it if necessary. > Further, the objections mentioned all seem to apply equaly to python and > mono. Python is allowed for desktop apps already. If nobody can come up > with objections to mono that don't apply equally to python, it would seem > that mono and python should be on equal footing. [1] http://mail.gnome.org/archives/gnome-hackers/2006-April/msg00015.html Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mono/GTK#/Tomboy
On Fri, 14 Jul 2006, Murray Cumming wrote: > And while there were almost no objections to Python, there are clearly > many objections to Mono. What objections? So far, the only two objections I've heard are: 1. Performance -- I feel that I've addressed this in other emails. 2. Vague references to TLAs such as ISV, OEM, API, ABI without refering to specific problems. Mono provides a very strong ABI in the base class libraries (we implement the same API as the .NET framework). For mono specific libraries, Mono commits to a similar stability level. Further, the objections mentioned all seem to apply equaly to python and mono. Python is allowed for desktop apps already. If nobody can come up with objections to mono that don't apply equally to python, it would seem that mono and python should be on equal footing. -- Ben ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mono/GTK#/Tomboy
On Fri, 2006-07-14 at 08:32 +0200, Murray Cumming wrote: > And while there were almost no objections to Python, there are clearly > many objections to Mono. I used to have objections against the python bindings, but after those got splitup in pygtk, gnome-python, gnome-python-desktop and gnome-python-extras, I don't have big problems with it. Looking at mono, all of these bindings are in one package: gtk-sharp-2. I think, to get mono as accepted binding language, we should have a splitup similiar to the splitup that has been done to the python bindings. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mono/GTK#/Tomboy
> > Hi, > > Elijah said: >> 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)? > > Let me rephrase that question: > > (Language X) is par of the bindings set. Should we consider that > applications written in (Language X) can be considered for the desktpo > release? > > I think that should be the case. The bindings depend on the platform, > and I have no issue having Python, C++ or C# applications (or Java for > that matter, if java-gnome joins the bindings set) being considered for > inclusion in the desktop release (on condition that there is no > dependence on non-free software implied in that). > > The desktop already depends on the presence of the bindings, on the presence of one binding - pygtk. We reached consensus a while ago that python was an acceptable programming language for the implementation of applications in the Desktop release set. There were no big objections to python in general. Now the question is whether other programming languages (and their bindings) are acceptable. As before there are still a lot of people who think it would make development difficult if we use multiple programming languages. And while there were almost no objections to Python, there are clearly many objections to Mono. > so the only > question is whether GTK# is ready and willing to be in the bindings set > (or am I missing something?) So it's not that simple. These are two separate questions. Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Mono/GTK#/Tomboy
Hi, Elijah said: > 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)? Let me rephrase that question: (Language X) is par of the bindings set. Should we consider that applications written in (Language X) can be considered for the desktpo release? I think that should be the case. The bindings depend on the platform, and I have no issue having Python, C++ or C# applications (or Java for that matter, if java-gnome joins the bindings set) being considered for inclusion in the desktop release (on condition that there is no dependence on non-free software implied in that). The desktop already depends on the presence of the bindings, so the only question is whether GTK# is ready and willing to be in the bindings set (or am I missing something?) Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] Lyon, France ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
