Re: Putting the 'Mono debate' back on the rails
On Tue, 2006-07-25 at 09:33 -0600, Elijah Newren wrote: We bind six libraries that fall in the desktop set currently. I cannot split out three of them because the APIs are included in gnome-sharp.dll currently, and to split them out would break API compat for my users. Are you saying that parallel installation of libraries is impossible in the mono world? I don't see how this has to break API compatibility for your current users. Parallel-installation is a compatibility break. I think I've come up with a package division that would be acceptable from a stability standpoint for us and still satisfy this no desktop libs requirement people seem to be dogmatically enforcing. We could split gtk-sharp into two packages: gtk-sharp-2.10.0 would keep glib-sharp, pango-sharp, atk-sharp, gdk-sharp, gtk-sharp, glade-sharp, and gtkdotnet. I would propose this altered package for inclusion in the Bindings release set. gnome-sharp-2.16.0 would get gnome-vfs-sharp, gnome-sharp, art-sharp, rsvg-sharp, vte-sharp, gconf-sharp, and gtkhtml-sharp. I would propose this package for inclusion in the Desktop release set. The division should satisfy all the rules. There is no rule against a platform binding living in the Desktop release set. -- Mike Kestner [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Putting the 'Mono debate' back on the rails
Hi Mike, On Wed, July 26, 2006 17:35, Mike Kestner wrote: I think I've come up with a package division that would be acceptable from a stability standpoint for us and still satisfy this no desktop libs requirement people seem to be dogmatically enforcing. We could split gtk-sharp into two packages: gtk-sharp-2.10.0 would keep glib-sharp, pango-sharp, atk-sharp, gdk-sharp, gtk-sharp, glade-sharp, and gtkdotnet. I would propose this altered package for inclusion in the Bindings release set. (I don't know what's in gtkdotnet, but I suppose it's stuff to make it easier to use gtk+) gnome-sharp-2.16.0 would get gnome-vfs-sharp, gnome-sharp, art-sharp, rsvg-sharp, vte-sharp, gconf-sharp, and gtkhtml-sharp. I would propose this package for inclusion in the Desktop release set. The division should satisfy all the rules. There is no rule against a platform binding living in the Desktop release set. This looks like it would work. gnome-vfs-sharp, gnome-sharp and gconf-sharp could go in the bindings suite too, but this would imply either creating a third package or moving them in gtk-sharp-2.10.0. Thanks for working on this! 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: Putting the 'Mono debate' back on the rails
On Wed, 2006-07-26 at 17:47 +0200, Vincent Untz wrote: gtk-sharp-2.10.0 would keep glib-sharp, pango-sharp, atk-sharp, gdk-sharp, gtk-sharp, glade-sharp, and gtkdotnet. I would propose this altered package for inclusion in the Bindings release set. (I don't know what's in gtkdotnet, but I suppose it's stuff to make it easier to use gtk+) Stuff to allow drawing on Gdk windows with the .Net System.Drawing API. Any future additions will be of a similar flavor. Helper classes for access to .Net APIs for which we don't want to put an additional dependency on gtk-sharp.dll. The division should satisfy all the rules. There is no rule against a platform binding living in the Desktop release set. This looks like it would work. gnome-vfs-sharp, gnome-sharp and gconf-sharp could go in the bindings suite too, but this would imply either creating a third package or moving them in gtk-sharp-2.10.0. Putting all the gnome stuff in one gnome-sharp package has a certain marketability/sense to it. And gnome-sharp can't go in platform. It's the source of all this angst, because it has the dreaded print and panel APIs. -- Mike Kestner [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Putting the 'Mono debate' back on the rails
On Wed, 2006-07-26 at 18:21 +0200, Murray Cumming wrote: gtk-sharp-2.10.0 would keep glib-sharp, pango-sharp, atk-sharp, gdk-sharp, gtk-sharp, glade-sharp, and gtkdotnet. I would propose this altered package for inclusion in the Bindings release set. That seems a lot nicer. I am, however, slightly concerned that this would force people to depend on libglade even when we have a libglade replacement in GTK+. The C, C ++, Python, Java, and Perl users will be able to rewrite their applications so that they don't need libglade on the system. glade-sharp is an optional build. We're not forcing anyone to put it on their systems. -- Mike Kestner [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Putting the 'Mono debate' back on the rails
On Wed, 2006-07-26 at 11:25 -0500, Mike Kestner wrote: On Wed, 2006-07-26 at 18:21 +0200, Murray Cumming wrote: gtk-sharp-2.10.0 would keep glib-sharp, pango-sharp, atk-sharp, gdk-sharp, gtk-sharp, glade-sharp, and gtkdotnet. I would propose this altered package for inclusion in the Bindings release set. That seems a lot nicer. I am, however, slightly concerned that this would force people to depend on libglade even when we have a libglade replacement in GTK+. The C, C ++, Python, Java, and Perl users will be able to rewrite their applications so that they don't need libglade on the system. glade-sharp is an optional build. We're not forcing anyone to put it on their systems. These optional builds don't help much, unless people are using gentoo (or other source-based distros). If the binary package was built with glade support then distros are unlikely to change their binary package in the future to remove the glade support. That would be an ABI break. -- 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: Putting the 'Mono debate' back on the rails
On Mit, 2006-07-26 at 18:32 +0200, Murray Cumming wrote: On Wed, 2006-07-26 at 11:25 -0500, Mike Kestner wrote: On Wed, 2006-07-26 at 18:21 +0200, Murray Cumming wrote: gtk-sharp-2.10.0 would keep glib-sharp, pango-sharp, atk-sharp, gdk-sharp, gtk-sharp, glade-sharp, and gtkdotnet. I would propose this altered package for inclusion in the Bindings release set. That seems a lot nicer. I am, however, slightly concerned that this would force people to depend on libglade even when we have a libglade replacement in GTK+. The C, C ++, Python, Java, and Perl users will be able to rewrite their applications so that they don't need libglade on the system. glade-sharp is an optional build. We're not forcing anyone to put it on their systems. These optional builds don't help much, unless people are using gentoo (or other source-based distros). If the binary package was built with glade support then distros are unlikely to change their binary package in the future to remove the glade support. That would be an ABI break. gtk-sharp has a separate glib-sharp-2.0.pc pkg-config file, so it's relatively easy to provide multiple binary packages from one source package or am I missing something? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Putting the 'Mono debate' back on the rails
On 7/26/06, Alex Graveley [EMAIL PROTECTED] wrote: This sounds great, and will help Gtk# t be used by many more people! Sorry to add confusion, but how does this help the Tomboy discussion? I'm using gnome-sharp and gconf-sharp. And hopefully the panel APIs in the future (there is a crasher bug currently, so I'm using a local copy). Would we add gnome-sharp as a soft dependency if Tomboy is included, similar to e.g. libsoup for Evolution? Pending the gtk# discussion elsewhere, the idea would be to treat it the same as python -- stable bindings of platform modules in the bindings release, unstable bindings of desktop (and possibly even some platform) modules in the desktop release, and desktop modules allowed to depend on either of those two sets of bindings. In short, no further work required of you in regards to this particular issue. :-) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Putting the 'Mono debate' back on the rails
On Wed, 2006-07-26 at 18:40 +0200, Jürg Billeter wrote: These optional builds don't help much, unless people are using gentoo (or other source-based distros). If the binary package was built with glade support then distros are unlikely to change their binary package in the future to remove the glade support. That would be an ABI break. gtk-sharp has a separate glib-sharp-2.0.pc pkg-config file, so it's relatively easy to provide multiple binary packages from one source package or am I missing something? It might be possible, but distros generally don't do that. And once they've released a binary package and called it stable then they can't change that (unless they do a parallel install and deprecate the old binary package). gnome-python-extras is an example of an all-in-one source tarball that's currently causing me problems because it's packaged as an all-in-one binary package on debian/Ubuntu. -- 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: Putting the 'Mono debate' back on the rails
On Wed, 2006-07-26 at 18:32 +0200, Murray Cumming wrote: These optional builds don't help much, unless people are using gentoo (or other source-based distros). If the binary package was built with glade support then distros are unlikely to change their binary package in the future to remove the glade support. That would be an ABI break. Seems like you're just being argumentative, now. Is the goal here to reinvent Gtk# in Gtkmm's image, or to satisfy the requirements of the release set? Last time I checked, libglade was a platform library. -- Mike Kestner [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Putting the 'Mono debate' back on the rails
On Wed, 2006-07-26 at 11:52 -0500, Mike Kestner wrote: On Wed, 2006-07-26 at 18:32 +0200, Murray Cumming wrote: These optional builds don't help much, unless people are using gentoo (or other source-based distros). If the binary package was built with glade support then distros are unlikely to change their binary package in the future to remove the glade support. That would be an ABI break. Seems like you're just being argumentative, now. Is the goal here to reinvent Gtk# in Gtkmm's image, or to satisfy the requirements of the release set? Last time I checked, libglade was a platform library. I do not understand you (or your colleagues) always need to be so aggressive and insulting every time this is discussed. What part of my email made you feel that was necessary? -- 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: Putting the 'Mono debate' back on the rails
On Wed, 2006-07-26 at 20:09 +0200, Murray Cumming wrote: Is the goal here to reinvent Gtk# in Gtkmm's image, or to satisfy the requirements of the release set? Last time I checked, libglade was a platform library. I do not understand you (or your colleagues) always need to be so aggressive and insulting every time this is discussed. What part of my email made you feel that was necessary? Sorry you felt insulted. Thank you for your suggestion. I am well acquainted with your opinion on this matter. We have considered and declined the idea of splitting our binding into a set of tarballs for each bound library. We think that we are already providing a very packaging-friendly set of bindings. Pardon my abruptness. -- Mike Kestner [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Putting the 'Mono debate' back on the rails
On Mon, 2006-07-24 at 20:48 -0700, Eugenia Loli-Queru wrote: Ok, I am confused then... If GTK# is already modular as you claim and if Mike is willing to offer a migration path for his current apps, I don't see why all this discussion is taking place... There should not be any technical reason left as to why GTK# shouldn't be in the bindings release. Because it's only half true. Three of the desktop libs (vte, rsvg, and gtkhtml) are optional and built into their own assemblies. The other three (print/printui/panelapplet) are built into gnome-sharp.dll along with the rest of the bound Gnome namespace. -- Mike Kestner [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Putting the 'Mono debate' back on the rails
On 7/21/06, Mike Kestner [EMAIL PROTECTED] wrote: On Sat, 2006-07-22 at 00:03 +1000, Jeff Waugh wrote: * Should we include Gtk# in the Bindings suite? - the release management issues have largely been solved, aside from Gtk# not being split between Platform and Desktop (stable and unstable) APIs which is pretty important in terms of ISV/ISD communication and so on I have resisted this split, and I think the above statement gets to the heart of my issue. There is this idea that it is not possible to guarantee API stability for bindings of Desktop libraries. We (Gtk#) have made no stability exceptions for these APIs to our users. That may seem insane to some. It may make us jump through some additional hoops down the road, if the desktop developers choose to exercise their prerogative to break things. However, it has not been an issue for us to this point. We bind six libraries that fall in the desktop set currently. I cannot split out three of them because the APIs are included in gnome-sharp.dll currently, and to split them out would break API compat for my users. Are you saying that parallel installation of libraries is impossible in the mono world? I don't see how this has to break API compatibility for your current users. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Putting the 'Mono debate' back on the rails
Hi, Le dimanche 23 juillet 2006, à 16:40, Mike Kestner a écrit : On Sat, 2006-07-22 at 23:12 -0400, Joe Shaw wrote: If those guarantees are more important to you than playing by the rules of the Gnome Bindings set, than Gtk# may simply be better of staying outside... Starting to seem like it. The other alternative is to alter the rules, which I believe is better for GNOME. We didn't come to the discussion as a beggar. We came with kickass applications in our wallet. Perhaps. I can't speak for Mike, but as a user of those bindings I certainly hope compatibility isn't broken to appease the (IMO, overly strict) rules of the bindings set. Ironically, this seems to be the only rule with any teeth. I'm no expert in the bindings suite, so bear with me. These are the requirements for the bindings: http://live.gnome.org/ReleasePlanning/ModuleRequirements/PlaformBindings There is no requirement to provide any specific library or even a minimal subset of the platform set. Presumably, I could have proposed a Gtk# binding that bound only glib and it would be eligible for the bindings set. You should try to wrap the entire GNOME Developer Platform, but we do not expect everybody to wrap everything. If you don't want to freeze some of your GNOME Platform bindings then you should say that as early as possible, and package them separately from your official GNOME Binding modules. I don't think bindings for only glib would have been accepted... My Gtk#-lite 2.16 binding would be allowed to break API in 2.18 as long as I make it parallel-installable, thereby breaking all existing Gtk#-lite applications unless packagers provide Bindings release 2.16 with their 2.18 desktop. It is allowed to break API, but it's really recommended to not break it. Obviously this should be avoided because it does make it more difficult for applications to take advantage of new features, and because we prefer to have fewer API versions from which to choose. Bindings breaking API at each cycle would most probably be kicked out of the bindings suite. I don't even have to bind 2.18 if I don't feel like it. My 2.16 binding can ship as an official Gnome binding for 2.18. It can, but from what I've seen, we're encouraging the bindings authors to bind the latest API. If the rules do not seem very strict, it's probably because it's not possible to force people depending on changing API to do perfect bindings on time. So... there is no schedule guarantee - I can provide my 2.16 in 2.18. there is no meaningful stability guarantee - I can break 2.16 in 2.18. there is no content guarantee beyond what is _not_ allowed in it. We probably should drop this discussion, because even if we were to break our API and do the split, tomboy still probably doesn't get in. Just being in the bindings set doesn't really get app developers anything. And from the earlier discussion, it sure doesn't sound like there's consensus to bless Gtk# as a Desktop set dependency. People don't want Gtk# in the bindings suite to let tomboy get in. People want Gtk# in the bindings suite because it rocks, because it would make GNOME better, because they love it. If tomboy were not proposed, we'd still want to see Gtk# in the bindings. As Jeff pointed out, those are separate issues. Let me say it again: the community really wants to see Gtk# in the bindings. 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: Putting the 'Mono debate' back on the rails
Hi Miguel, Le lundi 24 juillet 2006, à 05:30, Miguel de Icaza a écrit : Hello, I know the issues splitting Gtk# can bring, but not splitting also brings issues from the GNOME point of view. And that's more important in my mind (maybe I'm alone in thinking that, though ;-)) I would be interested in understanding what the issues of non-splitting are, from the GNOME point of view. I do not know what those are. First, we have the bindings requirements, stating: Non-GNOME Platform bindings do not belong in GNOME Platform Bindings modules. [1] We can of course ignore the requirements, or even better, change them if we feel it's appropriate. It's a bit late to change them for this release cycle, though. Then, we have the meaning of this sentence. Why do we have this requirement? The bindings bind the GNOME platform. That's what we encourage ISD and ISV to use as a basis for their applications. The message is: here's our platform, and you can use those bindings to develop in other languages. For many people, the official GNOME platform will be the bindings they will use. Having libgnomeprint(ui) in there doesn't look good (and it will look even worse if we kick it out of the Desktop suite because of the gtk print stuff). Having libpanel-applet which we're trying to replace is not better either. (Also, I guess some people would comment that GNOME is selling its soul to mono, but this is not what is worrying me) And it would help in discussing whether those issues are more important than breaking existing code. Isn't it possible to provide a migration path? Vincent [1] http://live.gnome.org/ReleasePlanning/ModuleRequirements/PlaformBindings -- 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: Putting the 'Mono debate' back on the rails
[snip] That's how MS took over the world, by providing full backwards compatibility with MS-DOS apps of 1981. MS also do parallel installs in order to provide new functionality without breaking old applications. For instance, the MSVC++ DLLs. Going off topic: As someone who has wasted countless weeks creating installations for Windows applications, I believe that the idea of backwards compatability (or even compatibility between various installs of the supposedly same versions of Windows) is a myth. There are problems and people work around them. People who are tied to Windows don't bother much complaining about it because they know nobody's listening. [snip] 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: Putting the 'Mono debate' back on the rails
Vincent Untz wrote: Le samedi 22 juillet 2006, à 15:44, Joe Shaw a écrit : Hi Vincent, Vincent Untz wrote: The API in the bindings suite covers the platform API. This has to be clear to ISD/ISV and we don't want to compromise this message. Please don't consider Gtk# only, but the platform (with the bindings) as a whole. It's not about additional guarantees. It might require more work on your part (but is it so much more work?), packagers are certainly used to such splittings and users won't see a difference 99% of the time. If Mike were starting from scratch here, this would be great. But there are already users of these bindings and breaking them up would effectively break ABI for existing users. Gtk# already has its own stability guarantees. My bad: I was understanding users as end-users, not as users of the bindings. I know the issues splitting Gtk# can bring, but not splitting also brings issues from the GNOME point of view. And that's more important in my mind (maybe I'm alone in thinking that, though ;-)) Another to note for Mike is that of the libraries that gtk# included on the desktop side, libpanelapplet - is private library to panel, even though there is little activities to change this atm, but this is what we (Sun) termed as unstable/private interface. Mixing a private interface with stable interface only laying down traps for the future should the interface evolves. libgnomeprint, libgnomeprintui - as this two libraries are soon to be obsoleted by the GTK+ printing API, putting these two libraries as with the rest of the stable API like GTK+ only confuses ISV/developers. When applications have eventually switch over the GTK+, we can't remove these libraries because they are all linked in making applications unnessary bloated. It is worthwhile to think and work on this problem now that trying to fix it than later. -Ghee Vincent ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Putting the 'Mono debate' back on the rails
Mike Kestner wrote: My Gtk#-lite 2.16 binding would be allowed to break API in 2.18 as long as I make it parallel-installable, thereby breaking all existing Gtk#-lite applications unless packagers provide Bindings release 2.16 with their 2.18 desktop parallel-instabllable is the worst idea of software development. One ended with forked version of software and only create more maintaineable nightmare. We are all tremendous hackers/engineers, so stick to some good engineering principles :) -Ghee ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Putting the 'Mono debate' back on the rails
On 7/24/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Mike Kestner wrote: My Gtk#-lite 2.16 binding would be allowed to break API in 2.18 as long as I make it parallel-installable, thereby breaking all existing Gtk#-lite applications unless packagers provide Bindings release 2.16 with their 2.18 desktop parallel-instabllable is the worst idea of software development. One ended with forked version of software and only create more maintaineable nightmare. We are all tremendous hackers/engineers, so stick to some good engineering principles :) Huh? Would you really want gtk+-2.x to use the same library name as gtk+-1.x, breaking all gtk+-1.x apps? It's not even close to the worst idea. It's actually a very good idea -- when not overused. In particular, combined with each version remaining stable, parallel-installable is far better than just breaking API/ABI. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Putting the 'Mono debate' back on the rails
Elijah Newren wrote: On 7/24/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Mike Kestner wrote: My Gtk#-lite 2.16 binding would be allowed to break API in 2.18 as long as I make it parallel-installable, thereby breaking all existing Gtk#-lite applications unless packagers provide Bindings release 2.16 with their 2.18 desktop parallel-instabllable is the worst idea of software development. One ended with forked version of software and only create more maintaineable nightmare. We are all tremendous hackers/engineers, so stick to some good engineering principles :) Huh? Would you really want gtk+-2.x to use the same library name as gtk+-1.x, breaking all gtk+-1.x apps? It's not even close to the worst idea. It's actually a very good idea -- when not overused. In particular, combined with each version remaining stable, parallel-installable is far better than just breaking API/ABI. Good case. But gtk+1.x and gtk+2.x is more of the exception than norm. Didn't know how much maintaining the the gtk+ engineers still have to work on gtk+1.x, though? I can't imagine gtk+ want to do anything as dramatics as this anytime soon. The other example is gstreamer, I am sure they can share with us whether their decision to go with parallel-installable version of 0.8 and 0.10 was a pleasant exercise. Of course they were facing similar situations as is now. Of course, nothing is worst than causing a break in the applications because we change the API underneath. So therefore, it may it all the more the gtk# should be integrated into GNOME in the right libraries division, not? Because we don't want GNOME developers to keep remember which version of the API to use. -Ghee ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Putting the 'Mono debate' back on the rails
The other example is gstreamer, I am sure they can share with us whether their decision to go with parallel-installable version of 0.8 and 0.10 was a pleasant exercise. Of course they were facing similar situations as is now. Speaking as aGStreamer application author and user, it was very pleasent. It allowed me to use applications that had been ported to 0.10 and applications that had not...all at the same time! Yey for parallel installs iain ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Putting the 'Mono debate' back on the rails
Iain * wrote: The other example is gstreamer, I am sure they can share with us whether their decision to go with parallel-installable version of 0.8 and 0.10 was a pleasant exercise. Of course they were facing similar situations as is now. Speaking as aGStreamer application author and user, it was very pleasent. It allowed me to use applications that had been ported to 0.10 and applications that had not...all at the same time! Good :). But for how long? 6 months, 1 year or 3 years? I guess you don't to want to do that for very long :) or many versions. -Ghee Yey for parallel installs iain ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Putting the 'Mono debate' back on the rails
man, 24 07 2006 kl. 16:47 +0100, skrev [EMAIL PROTECTED]: Iain * wrote: The other example is gstreamer, I am sure they can share with us whether their decision to go with parallel-installable version of 0.8 and 0.10 was a pleasant exercise. Of course they were facing similar situations as is now. Speaking as aGStreamer application author and user, it was very pleasent. It allowed me to use applications that had been ported to 0.10 and applications that had not...all at the same time! Good :). But for how long? 6 months, 1 year or 3 years? I guess you don't to want to do that for very long :) or many versions. For as long as it takes for the applications to be ported or replaced with ones that use the new superior technology. Users will encourage a port if the functionality of the programs based on the newer instance is better, they will want what that adds in the applications that don't take advantage of it. We saw this with the GTK1 to GTK2 transition, sure it took a while but in the end most applications have either died out for lack of use (and been replaced with other ones if needed) or been ported because that turned out the best possible solution. You don't see many people saying, I'm going to develop a kickass application and I'm going to use GTK1 for the interface anymore - we've all realized that GTK2 is better for all involved. The upcoming release of Fedora finally managed to push GTK1 entirely out of the Core distribution, it took a while but it's inevitable progress. Smaller changes that the toolkit transition will of course take less time, gstreamer 0.10 adaption has taken surprisingly short time, I believe out of all the application I use only Thoggen has yet to be ported. The same should happen with the bindings. So long as we don't break things for the user it should matter much while the change happens. Parallel installability makes this possible. - David Nielsen ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Putting the 'Mono debate' back on the rails
Hi, On Mon, 2006-07-24 at 16:11 +0100, [EMAIL PROTECTED] wrote: parallel-instabllable is the worst idea of software development. See http://ometer.com/parallel.html for the reasons why GNOME does it this way. Regards, -- Andy Wingo http://wingolog.org/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Putting the 'Mono debate' back on the rails
On 7/24/06, Andy Wingo [EMAIL PROTECTED] wrote: Hi, On Mon, 2006-07-24 at 16:11 +0100, [EMAIL PROTECTED] wrote: parallel-instabllable is the worst idea of software development. See http://ometer.com/parallel.html for the reasons why GNOME does it this way. And forgive me if I mis-remember, but isn't versioning and parallel installability a Sun ARC requirement? I seem to remember much sun-sourced kvetching circa 2002 that .gnome should really have been .gnome-1.4 and .gnome-2.0, which seemed very reasonable to me at the time. Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Putting the 'Mono debate' back on the rails
On Mon, 2006-07-24 at 18:04 +0100, Iain * wrote: And so, I have no problem with parallel installs even 5 years after the old software became obsolete so long as it solved my needs. This thread is getting very silly. AFAICS, Ghee is actually (badly) arguing against breaking ABIs. We'd all agree that it's best to avoid breaking ABI where possible, but if an ABI has to be broken, then making it possible to parallel install the library is the only sane way to lessen the pain. Cheers, Mark. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Putting the 'Mono debate' back on the rails
Andy Wingo wrote: Hi, On Mon, 2006-07-24 at 16:11 +0100, [EMAIL PROTECTED] wrote: parallel-instabllable is the worst idea of software development. See http://ometer.com/parallel.html for the reasons why GNOME does it this way. Thanks! Look like my original wording was oversweeping. Apology :) Sun does deliver multi-version of Motif Dtterm etc in CDE when Sun adopted Motif 2.1 from Motif 1.2. It was under the similar scenarios that GTK+. Did have lots of grief initially because of duplication of symbols etc especially when applications links with libxxx.so instead of the explicit version. Sun still have to supprt and deliver Motif 1.2 library for as long as Solaris is running. Just that is the situations we are committed ourselves in for different versioning of the same libraries. -Ghee Regards, ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Putting the 'Mono debate' back on the rails
Ben Maurer wrote: This can be done today! Ok, I am confused then... If GTK# is already modular as you claim and if Mike is willing to offer a migration path for his current apps, I don't see why all this discussion is taking place... There should not be any technical reason left as to why GTK# shouldn't be in the bindings release. Rgds, Eugenia ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Putting the 'Mono debate' back on the rails
Hello, I know the issues splitting Gtk# can bring, but not splitting also brings issues from the GNOME point of view. And that's more important in my mind (maybe I'm alone in thinking that, though ;-)) I would be interested in understanding what the issues of non-splitting are, from the GNOME point of view. I do not know what those are. And it would help in discussing whether those issues are more important than breaking existing code. Miguel. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Putting the 'Mono debate' back on the rails
On Sat, 2006-07-22 at 23:12 -0400, Joe Shaw wrote: If those guarantees are more important to you than playing by the rules of the Gnome Bindings set, than Gtk# may simply be better of staying outside... Starting to seem like it. The other alternative is to alter the rules, which I believe is better for GNOME. We didn't come to the discussion as a beggar. We came with kickass applications in our wallet. Perhaps. I can't speak for Mike, but as a user of those bindings I certainly hope compatibility isn't broken to appease the (IMO, overly strict) rules of the bindings set. Ironically, this seems to be the only rule with any teeth. There is no requirement to provide any specific library or even a minimal subset of the platform set. Presumably, I could have proposed a Gtk# binding that bound only glib and it would be eligible for the bindings set. My Gtk#-lite 2.16 binding would be allowed to break API in 2.18 as long as I make it parallel-installable, thereby breaking all existing Gtk#-lite applications unless packagers provide Bindings release 2.16 with their 2.18 desktop. I don't even have to bind 2.18 if I don't feel like it. My 2.16 binding can ship as an official Gnome binding for 2.18. So... there is no schedule guarantee - I can provide my 2.16 in 2.18. there is no meaningful stability guarantee - I can break 2.16 in 2.18. there is no content guarantee beyond what is _not_ allowed in it. We probably should drop this discussion, because even if we were to break our API and do the split, tomboy still probably doesn't get in. Just being in the bindings set doesn't really get app developers anything. And from the earlier discussion, it sure doesn't sound like there's consensus to bless Gtk# as a Desktop set dependency. -- Mike Kestner [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Putting the 'Mono debate' back on the rails
Just being in the bindings set doesn't really get app developers anything. I very much disagree. Being in an official gnome release (even if that's just bindings), it is like Gnome saying to distros and devs out there: look, here's gtk#, it's now stable, it works well, go ahead, install it and use it. This inclusion alone will bring new devs that will use gtk#, because they will feel more safe regarding using it and making sure that their users won't have major dependencies problems when trying to install their apps. Being part of gnome offers some guarantees to these devs (even if eventually are not always materialized). And from the earlier discussion, it sure doesn't sound like there's consensus to bless Gtk# as a Desktop set dependency. I agree that this is a matter that the Gnome Project should find a solution regarding what's gonna be its next-gen language/environment. But I think you should start with the Bindings. There is a first step for everything. Let the naysers get used of the idea first. Be a bit strategic and diplomatic. While I am personally neither, ask other women. They know all about the art... ;-) My Gtk#-lite 2.16 binding would be allowed to break API in 2.18 as long as I make it parallel-installable I agree, this sucks. Other bindings do it like that and they irritate the hell out of me -- at least as just a user. I like compatibility at all levels. That's how MS took over the world, by providing full backwards compatibility with MS-DOS apps of 1981. That's how IBM still services and makes big bucks on programs written in 1965. Well-tested backwards compatibility (at all levels) is one thing that OSS devs don't actively seek. I do hope that this changes at least in Gnome. I personally want bindings to be really compatible with their previous versions, version after version. Miguel wrote: I would be interested in understanding what the issues of non-splitting are, from the GNOME point of view. For one, if in the future Gnome would like to provide an embedded version (there was some talk about it already), it would be easier to pick and choose components as seen fit. In a 64 MB firmware you can't fit everything, usually... Of course, I don't think that this means that you need 3 different tarballs instead of 1. As long the selective functionality is present in your current tarball (via an autoconf option), I don't see why it should be physically split in different tarballs. But some form of seperation must exist as the rest of the Gnome is very modular in its nature. Another reason is easier testing. If your third party devs get a bug and they can't figure out where it's coming from exactly, by removing components they can easier isolate the problem. Maintaining the bindings will also probably be an easier affair. Lastly, I believe that having a modular GTK# is better for GTK# itself. Think about it: a third party embedded company wants to use it, but it doesn't care about all the gnome libs stuff. It would be easier for them to pick the components they really need rather than having to compile and use everything -- and their deps. Finally, if the XFce guys would wanna use it in their desktop in the future by binding it with libxfce, now they would be able to. Right now, GTK# is so monolithic that they don't even bother. Please refer to the email I sent yesterday. You can still offer a migration path to your existing apps and maintain it as long as you see fit or needed. Not all is lost. Rgds, Eugenia ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Putting the 'Mono debate' back on the rails
On Sun, 23 Jul 2006, Eugenia Loli-Queru wrote: Miguel wrote: I would be interested in understanding what the issues of non-splitting are, from the GNOME point of view. For one, if in the future Gnome would like to provide an embedded version (there was some talk about it already), it would be easier to pick and choose components as seen fit. In a 64 MB firmware you can't fit everything, usually... Of course, I don't think that this means that you need 3 different tarballs instead of 1. As long the selective functionality is present in your current tarball (via an autoconf option), I don't see why it should be physically split in different tarballs. But some form of seperation must exist as the rest of the Gnome is very modular in its nature. This can be done today. Look at: http://svn.myrealbox.com/viewcvs/trunk/gtk-sharp/configure.in.in?rev=56950view=auto and notice how the build *won't* fail if optional stuff isn't there. Lastly, I believe that having a modular GTK# is better for GTK# itself. Think about it: a third party embedded company wants to use it, but it This can be done today! Please refer to the email I sent yesterday. You can still offer a migration path to your existing apps and maintain it as long as you see fit or needed. Not all is lost. It's already possible to link just to Gtk+. -- Ben ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Putting the 'Mono debate' back on the rails
Hello, Miguel wrote: I would be interested in understanding what the issues of non-splitting are, from the GNOME point of view. For one, if in the future Gnome would like to provide an embedded version (there was some talk about it already), it would be easier to pick and choose components as seen fit. In a 64 MB firmware you can't fit everything, usually... Of course, I don't think that this means that you need 3 different tarballs instead of 1. As long the selective functionality is present in your current tarball (via an autoconf option), I don't see why it should be physically split in different tarballs. But some form of seperation must exist as the rest of the Gnome is very modular in its nature. Nothing is stopping embedded developers from just shipping the libraries from Gtk# that they need, they do not need to ship everything that the tarball contains. In addition, you might not even need a full binding of Gtk# or any of the component libraries, or even the Mono components in an embedded deployment, you might just need a subset. This is in fact, one of the problems with the Compact Framework from Microsoft. Someone decided This is what we will support on an embedded system with no consideration for the fact that embedded systems are hardly the same, and the kinds of applications are always different (the guys screwed by Microsoft are some of our major users: they copy-paste Mono's class library code so they can get features that Microsoft left out). The right approach is to use a tool that can take a library, and using a specification that contains the features required it produces a light version of this library. There are commercial tools that do this for CIL libraries, we have our own `monodiet' which is being replaced with a simpler and more complete `CIL Linker' based on the Cecil libraries. Miguel ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Putting the 'Mono debate' back on the rails
Sorry to interrupt... To make everybody happy, may we split the desktop suite? gnome-base-desktop (C apps) which can have independently and optionnally installed on top the following: gnome-CPP-desktop-suite gnome-python-desktop-suite gnome-mono-desktop-suite gnome-java-desktop-suite gnome-ruby-desktop-suite gnome-FOOLANGUAGE-desktop-suite... Regards, Sylvain BERTRAND ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Putting the 'Mono debate' back on the rails
Hi Mike, Le vendredi 21 juillet 2006, à 11:27, Mike Kestner a écrit : On Sat, 2006-07-22 at 00:03 +1000, Jeff Waugh wrote: * Should we include Gtk# in the Bindings suite? - the release management issues have largely been solved, aside from Gtk# not being split between Platform and Desktop (stable and unstable) APIs which is pretty important in terms of ISV/ISD communication and so on I have resisted this split, and I think the above statement gets to the heart of my issue. There is this idea that it is not possible to guarantee API stability for bindings of Desktop libraries. We (Gtk#) have made no stability exceptions for these APIs to our users. That may seem insane to some. It may make us jump through some additional hoops down the road, if the desktop developers choose to exercise their prerogative to break things. However, it has not been an issue for us to this point. We bind six libraries that fall in the desktop set currently. I cannot split out three of them because the APIs are included in gnome-sharp.dll currently, and to split them out would break API compat for my users. Those are libgnomeprint, libgnomeprintui, and libpanelapplet. The first two are unlikely to have API breakage, since they are basically deprecated by Gtk 2.10. libpanelapplet is a very small exposed API for us. If splitting these APIs out is a requirement, we can remove Gtk# from consideration now. The remaining three, rsvg, vte, and gtkhtml have not proven problematic. The small portion of gtkhtml that we bind has not changed since 3.10. We have not updated the version of rsvg or vte since Gtk# 1.0, and have had no reports of breakage against newer installed versions. We currently have a policy that only Gnome Platform libraries will be considered for inclusion going forward. Since I am already committed to maintaining API stability in the existing bindings, and that seems to be the crux of the No non-platform bindings rule, I still think it should be reasonable to allow Gtk# into the bindings release as is. Hopefully that helps explain why I resist when people continue to tell me I must split up the binding to remove these unstable libraries. The resulting split would provide users no additional guarantees, would require more work on my part and for packagers and users, and would theoretically break deployed applications if upgrading Gtk# started removing installed binaries. I respectfully disagree. I'm glad to hear that you're trying as hard as possible to provide API stability for the libraries in the desktop suite. This is really great. But this is besides the point. The API in the bindings suite covers the platform API. This has to be clear to ISD/ISV and we don't want to compromise this message. Please don't consider Gtk# only, but the platform (with the bindings) as a whole. It's not about additional guarantees. It might require more work on your part (but is it so much more work?), packagers are certainly used to such splittings and users won't see a difference 99% of the time. (another solution would be to change the meaning of the bindings suite, but I do not think it's a good idea) Vincent, who'd really like to get Gtk# in the bindings suite -- 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: Putting the 'Mono debate' back on the rails
Hi Vincent, Vincent Untz wrote: The API in the bindings suite covers the platform API. This has to be clear to ISD/ISV and we don't want to compromise this message. Please don't consider Gtk# only, but the platform (with the bindings) as a whole. It's not about additional guarantees. It might require more work on your part (but is it so much more work?), packagers are certainly used to such splittings and users won't see a difference 99% of the time. If Mike were starting from scratch here, this would be great. But there are already users of these bindings and breaking them up would effectively break ABI for existing users. Gtk# already has its own stability guarantees. Joe ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Putting the 'Mono debate' back on the rails
On 7/22/06, Joe Shaw [EMAIL PROTECTED] wrote: Hi Vincent, Vincent Untz wrote: The API in the bindings suite covers the platform API. This has to be clear to ISD/ISV and we don't want to compromise this message. Please don't consider Gtk# only, but the platform (with the bindings) as a whole. It's not about additional guarantees. It might require more work on your part (but is it so much more work?), packagers are certainly used to such splittings and users won't see a difference 99% of the time. If Mike were starting from scratch here, this would be great. But there are already users of these bindings and breaking them up would effectively break ABI for existing users. Gtk# already has its own stability guarantees. If those guarantees are more important to you than playing by the rules of the Gnome Bindings set, than Gtk# may simply be better of staying outside... ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Putting the 'Mono debate' back on the rails
Le samedi 22 juillet 2006, à 15:44, Joe Shaw a écrit : Hi Vincent, Vincent Untz wrote: The API in the bindings suite covers the platform API. This has to be clear to ISD/ISV and we don't want to compromise this message. Please don't consider Gtk# only, but the platform (with the bindings) as a whole. It's not about additional guarantees. It might require more work on your part (but is it so much more work?), packagers are certainly used to such splittings and users won't see a difference 99% of the time. If Mike were starting from scratch here, this would be great. But there are already users of these bindings and breaking them up would effectively break ABI for existing users. Gtk# already has its own stability guarantees. My bad: I was understanding users as end-users, not as users of the bindings. I know the issues splitting Gtk# can bring, but not splitting also brings issues from the GNOME point of view. And that's more important in my mind (maybe I'm alone in thinking that, though ;-)) 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: Putting the 'Mono debate' back on the rails
On 7/22/06, Matthias Clasen wrote: If those guarantees are more important to you than playing by the rules of the Gnome Bindings set, than Gtk# may simply be better of staying outside... First, we have to see the problem from a high level and ask ourselves: is Mike's goal to not break compatibility with existing Gtk# apps incompatible with the rules of the Gnome Bindings release? In my opinion, it is not. You can easily say the following: you are going to follow the Gnome Binding rules, you are going to break the GTK# code to 3 sub-levels or as required by Gnome (e.g. bindings for gtk, gnome-core and gnome-desktop, with new library names), but for the next 12 months you are going to provide a fourth set of libraries and headers that are fully compatible with the old GTK# monolithic way. With these 12 months you are offering a migration path to your existing third party developers, as this fourth legacy build will be building by default (and should be configurable to not be built if a distro doesn't want it). Yes, this will add a bit of workload initially and a bit of Makefile magic, but at the end, I think it's important to abide to the Gnome rules for modularity, and at the same time to cater for your existing devs. Now, speaking as the maintainer of www.GnomeFiles.org I tend to watch developers and their activity like an owl. I usually notice who is active and who is not. The point of the matter is, GTK# has only about ~50 truly-active apps today. From these 50, the 10 of them are very well done and important for a generic Linux desktop (e.g. Banshee, F-spot, Monodevelop... Bless SportsTracker are some other favorites of mine). If you are not going to provide the suggested fourth legacy build in parallel to the new gnome-oriented modularized builds, and you indeed decide to break compatbility, I suspect that 15 of these active GTK# will update their makefiles to compile with the new set of libs/headers within a month from your gnome-oriented release. I expect another 10-15 to do so in the next 3 to 6 months. At the end, you might lose 20 applications, tops -- which is not the end of the world. And by becoming part of the Gnome ecosystem and consequently get installed by default on more distros, will bring you 20 new apps fast-enough anyway. In conclusion, I don't believe Mike's rules and Gnome's rules are incompatible. But if Mike decides that they are, he will still not lose much of the current GTK# momentum application-wise. Instead, what I am personally concerned is API/ABI stability *after* GTK# becomes part of Gnome Bindings. Currently, builds of new versions of Mono are breaking binaries compiled only 3 months ago (TomBoy is just one example in my case). This is unacceptable IMHO for a good desktop experience. If both Miguel and Mike can guarantee to the Gnome Project that newly compiled gnome-gtk# apps are guaranteed to be working in the forseeable future with newer versions of Mono and GTK#, and he abides to the Gnome Bindings rules, personally I would be very happy to see GTK# as part of the Gnome Bindings release. Rgds, Eugenia ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Putting the 'Mono debate' back on the rails
Hi, Matthias Clasen wrote: On 7/22/06, Joe Shaw [EMAIL PROTECTED] wrote: If Mike were starting from scratch here, this would be great. But there are already users of these bindings and breaking them up would effectively break ABI for existing users. Gtk# already has its own stability guarantees. If those guarantees are more important to you than playing by the rules of the Gnome Bindings set, than Gtk# may simply be better of staying outside... Perhaps. I can't speak for Mike, but as a user of those bindings I certainly hope compatibility isn't broken to appease the (IMO, overly strict) rules of the bindings set. Joe ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Putting the 'Mono debate' back on the rails
Hi Jeff, Le samedi 22 juillet 2006, à 00:03, Jeff Waugh a écrit : * Should we include Gtk# in the Bindings suite? - short term - it hasn't been proposed for 2.16, but we could grandfather it in It has been proposed, IIRC :-) - the release management issues have largely been solved, aside from Gtk# not being split between Platform and Desktop (stable and unstable) APIs which is pretty important in terms of ISV/ISD communication and so on - bindings are a very important part of GNOME, and our value proposition - it seems that few people are concerned about Gtk# adopting the release process and other standards, then being included in our Bindings suite - a social/business/non-technical issue may persist regarding GNOME using or endorsing a Microsoft derived technology; some users/vendors may not appreciate that, to the point that they may choose to disassociate from the GNOME project (this shouldn't be dismissed out of hand) Yes, we should: we want to let people use their preferred languages to develop applications that integrate in GNOME. * Should we include Tomboy in the Desktop suite? (completely independently from the fact that it uses Gtk#/Mono) - short term - it has been proposed for 2.16 - does it *need* to go in the Desktop suite at all? (genuine question, it may not be necessary to include Tomboy in the Desktop suite to achieve Tomboy's goals) I'm sorry, I'm not sure I understand this point. It might help to know what are Tomboy's (or Alex's) goals first :-) - if we say yes here, we depend on the next question (but short term, the next question only starts to matter if we say yes here!) I'm mixed about tomboy, but mainly because I can't seem to get used to it ;-) Tomboy has been praised for a long time by a lot of people. This is a good point for it. * Should Gtk#/Mono applications be accepted into the Desktop suite? - short to medium term - pathological case of 'Desktop suite pressure' (everyone wants their stuff in the Desktop suite because that's how you become enfranchised) - performance (memory and cpu) is a red herring here; we all *know* that we want to start using higher level languages for writing amazing GNOME software, so whether it's Gtk#/Mono, Python, Java, Perl or Brainfuck, we fully acknowledge that we're taking a hit for developer productivity and our ability to deliver awesome software to users. very few pieces of the software on the radar for proposal are central, 'always-on' elements of the desktop experience (think f-spot vs. beagle). performance will be an important metric for inclusion of any software, but it needs to be done on a case by case basis, not from a dogmatic perspective about competing platforms or the idea of using higher level languages at all. that horse has well and truly bolted! - can we resolve the dissonance between delivering a coherent Desktop (a goal of the Desktop suite) and suggesting that vendors deliver multiple vm/language/binding/runtime platforms to satisfy it, and demand that users stomach it too? (this has also been raised as a performance issue) - a social/business/non-technical issue may persist regarding GNOME using or endorsing a Microsoft derived technology; some users/vendors may not appreciate that, to the point that they may choose to disassociate from the GNOME project You forgot Alvaro's feeling that GNOME is a platform and adding dependency on another platform might not make sense from a consistency point of view. (Point four is similar, but it's not the same.) We don't have to talk about the other items now. If we do, it'll just make yet another huge thread without real conclusions... 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: Putting the 'Mono debate' back on the rails
On lør, 2006-07-22 at 00:03 +1000, Jeff Waugh wrote: - a social/business/non-technical issue may persist regarding GNOME using or endorsing a Microsoft derived technology; some users/vendors may not appreciate that, to the point that they may choose to disassociate from the GNOME project (this shouldn't be dismissed out of hand) There are also those amongst the users who are getting royally tired of this debate, we want to contribute and we want to do it using Mono. I'm personally getting to the point where if a decision is not made as to whither or not I will be allowed the freedom to develop for my desktop of choice in my language of choice I'll go on a puppy killing spree. The point being the issue goes both ways, if we keep Mono as the bastard child of the platform a lot of upcoming developers will get tired of waiting and seek other pastures. - David Nielsen ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Putting the 'Mono debate' back on the rails
quote who=Vincent Untz - does it *need* to go in the Desktop suite at all? (genuine question, it may not be necessary to include Tomboy in the Desktop suite to achieve Tomboy's goals) I'm sorry, I'm not sure I understand this point. It might help to know what are Tomboy's (or Alex's) goals first :-) It's the same thing as does Inkscape *need* to go in the Desktop suite at all? - there are all kinds of reasons for and against this from both sides (maintainer and suite). - can we resolve the dissonance between delivering a coherent Desktop (a goal of the Desktop suite) and suggesting that vendors deliver multiple vm/language/binding/runtime platforms to satisfy it, and demand that users stomach it too? (this has also been raised as a performance issue) You forgot Alvaro's feeling that GNOME is a platform and adding dependency on another platform might not make sense from a consistency point of view. (Point four is similar, but it's not the same.) Yeah, I was attempting to summarise that in point 4, though understanding that it was heavily conflated with the long term platform story. Shipping something in the Desktop suite doesn't imply supporting the platform (cf. Aisleriot), so there's some flexibility here. - Jeff -- linux.conf.au 2007: Sydney, Australia http://lca2007.linux.org.au/ Basically my philosophy on release management is that it should be like police brutality. - Maciej Stachowiak ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Putting the 'Mono debate' back on the rails
Jeff Waugh wrote: Ni hao, (Wow, this took a long time to write. Sorry!) [...] Thanks, Please, could we (if possible) answer every point in a separate thread (like jdahlin began to do) to try and keep things clear ? Otherwise the new debate will be likely to turn into a nameless mess like the previous one. Thank you. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Putting the 'Mono debate' back on the rails
On Sat, 2006-07-22 at 00:03 +1000, Jeff Waugh wrote: * Should applications built with anything in the Bindings suite be accepted into the Desktop suite? - short to medium term - do we want the central components of our software to potentially be written in five to ten different languages and/or runtimes/platforms? - this leads very neatly into the next question * Is it time to redefine the suites and/or 'franchise' the release process? - medium term - this is not just about new suites, it's about redefining the current Desktop suite by its integration interfaces and central components; we need to make current suites serve us better before kicking off new stuff - http://perkypants.org/blog/2005/05/19/1116533413/ (last few paras) - start slow: don't even create new suites to begin with, just make sure the small number of apps that want to adopt our process and standards right now can do so - new/further governance of suites can come later Regarding just the above two issues: What if there is a bilateral subdivision of the desktop suite which helps *distributors* distinguish between applications that support being compiled AOT (C, C++, Mono AOT, Java GCJ, D?) and applications that run JIT'd/VM'd (Mono JIT, Java JRE, Python, Ruby, Perl). It seems to me that, at least conceptually if not technically, the division between the two camps above is one of AOT/native compilation versus JIT/VM'd/interpreted compilation. Notice that both Java and Mono could be in either camp depending on how the project's Makefiles are written ... in both the Mono AOT and Java GCJ cases, libraries in use are shared between processes. Execution performance is also (generally) higher. It would be interesting to get Miguel's take on whether or not Mono AOT usage should be encouraged. In the Java GCJ case, it is encouraged for use by its authors. 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: Putting the 'Mono debate' back on the rails
On Sat, 2006-07-22 at 00:03 +1000, Jeff Waugh wrote: * Should we include Gtk# in the Bindings suite? - the release management issues have largely been solved, aside from Gtk# not being split between Platform and Desktop (stable and unstable) APIs which is pretty important in terms of ISV/ISD communication and so on I have resisted this split, and I think the above statement gets to the heart of my issue. There is this idea that it is not possible to guarantee API stability for bindings of Desktop libraries. We (Gtk#) have made no stability exceptions for these APIs to our users. That may seem insane to some. It may make us jump through some additional hoops down the road, if the desktop developers choose to exercise their prerogative to break things. However, it has not been an issue for us to this point. We bind six libraries that fall in the desktop set currently. I cannot split out three of them because the APIs are included in gnome-sharp.dll currently, and to split them out would break API compat for my users. Those are libgnomeprint, libgnomeprintui, and libpanelapplet. The first two are unlikely to have API breakage, since they are basically deprecated by Gtk 2.10. libpanelapplet is a very small exposed API for us. If splitting these APIs out is a requirement, we can remove Gtk# from consideration now. The remaining three, rsvg, vte, and gtkhtml have not proven problematic. The small portion of gtkhtml that we bind has not changed since 3.10. We have not updated the version of rsvg or vte since Gtk# 1.0, and have had no reports of breakage against newer installed versions. We currently have a policy that only Gnome Platform libraries will be considered for inclusion going forward. Since I am already committed to maintaining API stability in the existing bindings, and that seems to be the crux of the No non-platform bindings rule, I still think it should be reasonable to allow Gtk# into the bindings release as is. Hopefully that helps explain why I resist when people continue to tell me I must split up the binding to remove these unstable libraries. The resulting split would provide users no additional guarantees, would require more work on my part and for packagers and users, and would theoretically break deployed applications if upgrading Gtk# started removing installed binaries. -- Mike Kestner [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Putting the 'Mono debate' back on the rails
On Fri, 21 Jul 2006, Jason D. Clinton wrote: On Sat, 2006-07-22 at 00:03 +1000, Jeff Waugh wrote: * Should applications built with anything in the Bindings suite be accepted into the Desktop suite? - short to medium term - do we want the central components of our software to potentially be written in five to ten different languages and/or runtimes/platforms? - this leads very neatly into the next question * Is it time to redefine the suites and/or 'franchise' the release process? - medium term - this is not just about new suites, it's about redefining the current Desktop suite by its integration interfaces and central components; we need to make current suites serve us better before kicking off new stuff - http://perkypants.org/blog/2005/05/19/1116533413/ (last few paras) - start slow: don't even create new suites to begin with, just make sure the small number of apps that want to adopt our process and standards right now can do so - new/further governance of suites can come later Regarding just the above two issues: What if there is a bilateral subdivision of the desktop suite which helps *distributors* distinguish between applications that support being compiled AOT (C, C++, Mono AOT, Java GCJ, D?) and applications that run JIT'd/VM'd (Mono JIT, Java JRE, Python, Ruby, Perl). It seems to me that, at least conceptually if not technically, the division between the two camps above is one of AOT/native compilation versus JIT/VM'd/interpreted compilation. I don't think this is an item worth dividing on. For languages like Mono (and Java with GCJ), the compile or JIT (for Mono) or interp (for GCJ) is purely a case-by-case performance decision. Notice that both Java and Mono could be in either camp depending on how the project's Makefiles are written ... in both the Mono AOT and Java GCJ cases, libraries in use are shared between processes. Execution performance is also (generally) higher. The statement that performance is generally higher isn't quite correct. However, it's completely besides the point for this discussion. It would be interesting to get Miguel's take on whether or not Mono AOT usage should be encouraged. In the Java GCJ case, it is encouraged for use by its authors. Again, completely besides the point. The decision to AOT would be based on measurements. It doesn't address any of the issues in Jeff's email. -- Ben ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Putting the 'Mono debate' back on the rails
On Fri, 2006-07-21 at 13:39 -0400, Ben Maurer wrote: I don't think this is an item worth dividing on. For languages like Mono (and Java with GCJ), the compile or JIT (for Mono) or interp (for GCJ) is purely a case-by-case performance decision. ... The statement that performance is generally higher isn't quite correct. However, it's completely besides the point for this discussion. ... Again, completely besides the point. The decision to AOT would be based on measurements. It doesn't address any of the issues in Jeff's email. Well I respectfully disagree and I find your statements that my statements don't address any issues raised by Jeff very puzzling as they were specifically influenced by the framing Jeff did in the issue directly above the two I quoted. Quoth Jeff: * Should Gtk#/Mono applications be accepted into the Desktop suite? ... - performance (memory and cpu) is a red herring here; we all *know* that ... - can we resolve the dissonance between delivering a coherent Desktop (a goal of the Desktop suite) and suggesting that vendors deliver multiple vm/language/binding/runtime platforms to satisfy it, and demand that users stomach it too? (this has also been raised as a performance issue) You are, of course, welcome to disagree with my suggestion. I have no idea if it's a good one or not but I thought it was worth bringing up. I think that inventivizing projects to push toward an AOT approach could be one way to help allay the people pounding their fists over the perceived performance of the desktop OOTB. 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: Putting the 'Mono debate' back on the rails
On Fri, 21 Jul 2006, Jason D. Clinton wrote: On Fri, 2006-07-21 at 13:39 -0400, Ben Maurer wrote: I don't think this is an item worth dividing on. For languages like Mono (and Java with GCJ), the compile or JIT (for Mono) or interp (for GCJ) is purely a case-by-case performance decision. ... The statement that performance is generally higher isn't quite correct. However, it's completely besides the point for this discussion. ... Again, completely besides the point. The decision to AOT would be based on measurements. It doesn't address any of the issues in Jeff's email. Well I respectfully disagree and I find your statements that my statements don't address any issues raised by Jeff very puzzling as they were specifically influenced by the framing Jeff did in the issue directly above the two I quoted. Quoth Jeff: * Should Gtk#/Mono applications be accepted into the Desktop suite? ... - performance (memory and cpu) is a red herring here; we all *know* that ... - can we resolve the dissonance between delivering a coherent Desktop (a goal of the Desktop suite) and suggesting that vendors deliver multiple vm/language/binding/runtime platforms to satisfy it, and demand that users stomach it too? (this has also been raised as a performance issue) You are, of course, welcome to disagree with my suggestion. I have no idea if it's a good one or not but I thought it was worth bringing up. I think that inventivizing projects to push toward an AOT approach could be one way to help allay the people pounding their fists over the perceived performance of the desktop OOTB. AOT is *not* always faster. There are lots of variables. For example, at JIT time, the compiler can make some assumptions that AOT can not (for example, if you have a static readonly field [static final in java], JITs can inline the constant value because it will never change. AOT can't do this because the value is computed in the static constructor). In some cases, AOT can incresae startup time becasue the assembly used by CPUs is generally larger than the IL in a JIT. In these cases, it can be *faster* to compile than it is to read more from the disk see: http://blogs.msdn.com/ricom/archive/2004/10/18/244242.aspx for a bit about this. We should encourage performance. However, making divisions based on specific optimization techniques is the wrong direction. Also, getting off track and talking about specific optimization techniques while making high level decisions isn't going to help. If you want to talk more about AOT in Mono (or other runtimes), this is simply not the list to do it. -- Ben ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Putting the 'Mono debate' back on the rails
On Fri, 2006-07-21 at 14:20 -0400, Ben Maurer wrote: AOT is *not* always faster. There are lots of variables. For example, at JIT time, the compiler can make some assumptions that AOT can not (for example, if you have a static readonly field [static final in java], JITs can inline the constant value because it will never change. AOT can't do this because the value is computed in the static constructor). We're goin' way off topic. Let me point you back to me first email: the project's Makefiles are written ... in both the Mono AOT and Java GCJ cases, libraries in use are shared between processes. Execution The benefit of AOT that I am emphasizing here is shared libraries and the amount of memory which would be saved - especially in the Java case. Any gains (or not) in execution speed would just be a nice side effect. 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
