Re: GMime as an external dependency
On Fri, 2009-07-24 at 08:01 -0700, Sandy Armstrong wrote: On Fri, Jul 24, 2009 at 7:15 AM, Frederic Petersfpet...@gnome.org wrote: Sandy Armstrong wrote: Talking to Jeff Stedfast, this is most likely caused by using gtk# trunk in jhbuild. Although this will surely be fixed, we recommend switching jhbuild to gtk# 2.12 (or building from the gtk-sharp-2-12 branch in SVN, which is still maintained). What about gnome-sharp ? Is it ok to follow trunk ? Yes, gtk-sharp-2-12-branch is the stable and probably final 2.x branch for gtk-sharp. The trunk branch will target gtk 3.0 when it is released. The 2.12 branch should be used for future 2.x builds. trunk is still 2.x for gnome-sharp and gnome-desktop-sharp. I'll send a message to d-d-l if/when they switch to 3.0. -- Mike Kestner mkest...@gmail.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Removing libgnomeprint* from the desktop set
On Mon, 2008-07-28 at 00:44 +0200, Vincent Untz wrote: Have you figured out a way to handle this? It looks like the only blocking issue to remove libgnomeprint* from the desktop set is gnome-sharp. We've decided to move the gnomeprint and panelapplet bindings to gnome-desktop-sharp as optional dependencies. I've done the work to remove them from gnome-sharp, but I can't really commit it and do any releases until I get the bindings ported to gnome-desktop-sharp. The ironic part is that since I was going through the effort, I decided to update all the gnome-sharp library APIs to the latest development versions and there will be zero API change for gnome-sharp users other than the removal of this API. It will be interesting to see if anything new has been added to the gnome-desktop-sharp libraries. I invested about 4 hours one night last week playing nanny to a garnome build for one of the 2.23 releases before getting frustrated enough to walk away from my computer. What's the drop-dead date for completing this? Mike ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Removing libgnomeprint* from the desktop set
On Fri, 2008-03-28 at 19:58 -0600, Elijah Newren wrote: On Fri, Mar 28, 2008 at 10:12 AM, Vincent Untz [EMAIL PROTECTED] wrote: I'd like us to finally stop shipping libgnomeprint/libgnomeprintui as part of the desktop set. As far as I can tell from the jhbuild moduleset, it's only used by: + anjuta, with the scintilla editor plugin (but there's the gtksourceview editor plugin) + tomboy: http://bugzilla.gnome.org/show_bug.cgi?id=512369 + gnome-python-desktop, for bindings + gnome-sharp, for bindings + gtksourceview 1.x, which I'd like to kill :-) see previous mail for this. Opinions? Sounds like a good idea to me. :-) I'm fairly confident that this post is a waste of electrons, but I'll go on record as saying I don't think it's a good idea. I know there are no stability guarantees in the desktop release. They are however the kind of general purpose APIs that many classes of applications could, and most likely did, take advantage of, and removing them just seems to be a potential pain causer for little benefit. Just because the desktop release can break stability doesn't necessarily mean it should. I understand the desktop library policy in the context of small limited-use libraries shared between desktop-only components. Putting a general-use library in the desktop release set and indiscriminately breaking its API or removing it from the set seems counterproductive to me. What exactly is the cost to GNOME of leaving a deprecated unmaintained library in the 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: Removing libgnomeprint* from the desktop set
On Mon, 2008-03-31 at 17:56 +0200, Matteo Settenvini wrote: I believe the point is exactly that it's deprecated and unmaintained. Putting it outside of GNOME gives a strong signal to developers. For the record, that wasn't a rhetorical question. I was looking for actual cost to the team or platform, as in effort or platform performance. Not theoretical signals sent to developers. I'm also not convinced that the signal hold on to your hats, cause GNOME is going to change under you at our whim is the optimal signal to send. Even for a desktop library. However, this doesn't mean that library can't continue living its own life outside of GNOME: it can still be packaged for a distro, or shipped along with a third-party application. It just means extra work, and confusion as to whether it should be done since it's not in GNOME any more, etc... If the application in question is still actively developed, porting the old code to the new one shouldn't be too much a hassle; it's not as if you're removing any functionality to the platform, just saying move on to the next version, it's better and more stable and people will work on it. It tells application developers who use GNOME that you _have_ to invest effort into your application to keep its current feature set with the current GNOME release. Effort that could otherwise be invested in potentially more worthwhile features. Instead of continuing this discussion I should probably have invested the time in figuring out how I can maintain stability for gnome-sharp's users in the face of this removal. Most people won't be worried about that, since it's my fault for depending on an unstable library, but it's effort I could be spending elsewhere to make GNOME more available to mono users. -- Mike Kestner [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.21.90 Development Release
On Fri, 2008-02-01 at 10:42 +0200, Lucas Rocha wrote: What does everyone else say? I see no problem with inclusing both. Just one question: you said gnome-desktop-sharp 2.20 will be ready when GNOME 2.22 ships. Does it mean it's not ready now? What's missing? We are still planning to merge our existing gtksourceview2-sharp binding from a standalone module into gnome-desktop-sharp, which is basically just make integration work. Other than that, bugfixing for any issues resulting from the preview release. Mike ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.21.90 Development Release
On Wed, 2008-01-30 at 21:49 -0700, Elijah Newren wrote: = GNOME 2.21.90 Development Release = Hey Elijah, I noticed that you folks picked up gnome-sharp-2.19.91 for this release. In our current development releases, we have split the existing gnome-sharp binding set into two packages: gnome-sharp and gnome-desktop-sharp. We have moved our rsvg, vte, and gtkhtml bindings from gnome-sharp to gnome-desktop-sharp in an attempt to clarify the stable/unstable status of the APIs. We also have added a few new bindings to gnome-desktop-sharp. I didn't officially pursue inclusion of gnome-desktop-sharp for 2.22 because of the timing of when all this started coming together, though at this point, I'm confident gnome-desktop-sharp 2.20 will be ready when GNOME 2.22 ships. It would be great if the gnome-desktop-sharp package can be included in 2.22. If it's too late or too controversial to do so at this point, I would suggest that you revert to gnome-sharp 2.16.x for 2.22, since shipping gnome-sharp 2.20 without gnome-desktop-sharp will remove functionality. Let me know if I can provide any more info. -- 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 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
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 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 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 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
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: focus!
On Wed, 2006-07-19 at 11:06 -0500, Federico Mena Quintero wrote: On Wed, 2006-07-19 at 11:38 +0100, Brian Nitz wrote: Do we know what level of accessibility is possible within the current mono framework? Do we know what level of accessibility is likely (e.g. with C# apps ported from other platforms?) Semi-informed reply (Mike Kestner, the gtk-sharp maintainer, will be able to inform you better): - Last I heard inside Novell, gtk-sharp was in the process of adding support for GObject interfaces, which are required to implement the a11y interfaces from C# itself --- you could always implement your accessible interfaces in straight C, but that's not fun :) GInterface registration for managed subclasses is our #1 feature request, other than perhaps Data Binding. GInterface reg will probably be the next substantial addition to Gtk#. Much of the work is already completed, but it won't be included in 2.10.x. 2.10.x looks to be an API tracking release only. -- Mike Kestner [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gtk# in 2.16
On Tue, 2006-04-25 at 07:16 +0200, Murray Cumming wrote: http://mail.gnome.org/archives/language-bindings/2003-November/msg00013.html The Java and Python maintainers seem to have grown to like it. If you say so. But I still have yet to hear a good reason for why it's necessary. Nothing I've heard so far outweighs the increased burden it places on the users, packagers, and on me. There is no independent release cycle. There have been no API stability issues. Do you plan to depend on GtkHtml for ever, or will you remove it from Gtk# when everybody has stopped using it? What effect will this have on existing applications? Our dependency on gtkhtml is optional. The small portion of the API we bind hasn't changed since 3.0. The only reason I can think of to remove it from Gtk# would be to integrate the bindings into gtkhtml itself, which was discussed at one time. I don't personally see the value of the split between Platform/Desktop in a language binding. Maybe if that rule is written in stone, Gtk# could be added to the Desktop release instead of the Bindings set. ;-) You obviously saw some value to this idea, because you already removed some of the more flaky stuff from Gtk#. We removed some stuff that people had added and abandoned, didn't work, and that I didn't feel like fixing/maintaining myself. Some of the removals were to integrate the bindings into the libraries that they bound, in the hopes they would get more love. It had nothing to do with whether it was platform or desktop. FWIW, we have more or less decided that no new libraries will be added to Gtk# that are not platform libraries, so we would only need an exemption on that rule for the existing binding set. Technically, gnomeprint is a show-stopper for us. We expose its API in gnome-sharp.dll and therefore could not split it out and still maintain our API stability guarantees. So, GtkHtml is in a different .dll? Yes, as are rsvg and vte. -- Mike Kestner [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Gtk# in 2.16
The discussion already seems to have started, but I'd like to formally propose Gtk# for inclusion in the 2.16 Gnome bindings release. Gtk# is a language binding for Gtk+ (and most of the Gnome platform libraries) for .net/mono supported languages including C#, VB.net, python, boo, nemerle and several others. We have stable releases for Gtk 2.2, 2.4, 2.6, and 2.8 now, with associated gnome platform libraries. We are prepared to release alongside the Gnome schedule moving forward. I have reviewed the Requirements page and I believe we can comply with all but 1 rule, the one that requires bindings for GnomePrint and other desktop libraries to be bound by a separate package. We already have bindings for gnomeprint and gtkhtml in Gtk#, for example, and would prefer not to remove them from the binding set, though gnomeprint is obviously headed for obsolescence. -- Mike Kestner [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gtk# in 2.16
On Mon, 2006-04-24 at 15:47 -0600, Elijah Newren wrote: To clarify, this means you're targetting Gtk+-2.10 for Gnome 2.16, right? Yes. Why are you unable to comply with that one -- what would be difficult about putting the API/ABI stable bindings into one package and putting the other bindings in a separate one? Wouldn't it just mean that people who want to use the extra bindings install both packages? I feel like I'm missing something because I would have assumed this was the easiest requirement to comply with (though I'm obviously no expert in the area...) In my opinion, it would just make more work for me to release Gtk# and more work for our users to download and build it, and more work for our packagers to package it, etc... My recollection of the initial process that defined the rules was that everyone who commented on that particular rule except for Murray thought this was not important. http://mail.gnome.org/archives/language-bindings/2003-November/msg00013.html Murray's primary argument seemed to be about the marketing aspects of guaranteeing API stability which a non-platform lib couldn't do. The reality is that we've been able to maintain our API stability guarantee despite the presence of Desktop libs in our set. I don't personally see the value of the split between Platform/Desktop in a language binding. Maybe if that rule is written in stone, Gtk# could be added to the Desktop release instead of the Bindings set. ;-) FWIW, we have more or less decided that no new libraries will be added to Gtk# that are not platform libraries, so we would only need an exemption on that rule for the existing binding set. Technically, gnomeprint is a show-stopper for us. We expose its API in gnome-sharp.dll and therefore could not split it out and still maintain our API stability guarantees. -- Mike Kestner [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
