On Mo, 2008-03-31 at 14:05 -0500, Mike Kestner wrote: > Those who follow desktop-devel-list have probably seen that GNOME is > currently discussion the removal of libgnomeprint* from the desktop > release. This has consequences to gnome-sharp. > > I'd like to start a discussion about possible methods of going forward > in the light of this change. We currently have a dependency on > libgnomeprint* for gnome-sharp.dll, since it exposes Gnome printing API. > I can see a few possible approaches, all of which stink in one way or > another. ;-) > > 1) We remove the gnomeprint bindings from gnome-sharp.dll, breaking > stability for the assembly, but allowing it to build with its GNOME > platform library dependencies still in place. This would require > dropping of existing policy assemblies and starting over fresh with the > upcoming release of gnome-sharp.dll, version 2.24.0.0. > > The existing Gnome.Print* bindings would be spun out into a new > gnome-print-sharp.dll in a standalone module with its own .pc file. > While this would break runtime compat, the only change required to get > apps building again would probably be the addition of a > gnome-print-sharp-2.0 entry to configure.in files or -pkg: switches, and > of course, the installation of the new module. This is the "bite the > bullet" solution. > > 2) Maintain stability by leaving the gnomeprint* dependency in > gnome-sharp.dll. I don't think this choice will be appreciated by the > GNOME folks, and would put pressure on Tomboy, because it depends on > gnome-sharp.dll. Any gnome build which included Tomboy would therefore > still require libgnomeprint* and I doubt the gnome folks will be pleased > with us. This is probably a non-starter, but I mention it for > completeness. This is the "bury our heads in the sand" solution. > > 3) Maintain stability by importing libgnomeprint* into gnome-sharp and > producing "glue" libraries from the sources. This could be a pain in > the rear to pull off, especially if name mangling is required to avoid > potential type clashes from ld. We also probably pick up an ongoing > maintenance headache for bugs in the underlying C code, and we all know > us C# hackers aren't excited about hacking C code. ;-) This is the > "Mike you screwed up so you should be flogged, then drawn and quartered" > solution. > > I see option 1 and 3 as being the most likely approaches. Gnome.Print's > inclusion in gnome-sharp.dll was a mistake in the first place, and I'm > willing to go through the pain of option 3 in order to maintain the > compatibility that we've advertised. On the other hand, I'd rather not > take on that burden if the users are willing to accept option 1. I > think option 1 is probably the "cleanest" solution of the 3 within the > context of the underlying GNOME API guarantees, though the stability > break to gnome-sharp.dll is embarrassing to me as a maintainer. > > I would appreciate any feedback. We have a little time to make a > decision, since we are early in this GNOME cycle. But based on the > feedback to my posts on d-d-l, I think we're most likely going to have > to fix this lurking dependency bug in this upcoming release.
I'd go with 1) and provide gnome-print bindings in gnome-desktop-sharp until every user (i.e. tomboy and...?) finally have ported and then remove it from gnome-desktop-sharp too. Also, while you're breaking API anyway please remove all other desktop components from gnome-sharp if there are still any and move them to gnome-desktop-sharp :) Breaking API is not nice but in this case makes sense IMHO... and afterwards we can guarantuee API stability until 3.0 next decade or next century :)
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
_______________________________________________ Gtk-sharp-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/gtk-sharp-list
