slomo at circular-chaos.org
Mon Mar 31 15:25:42 EDT 2008
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 184.108.40.206.
> 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"
> 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
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : http://lists.ximian.com/pipermail/gtk-sharp-list/attachments/20080331/a48bd94b/attachment-0001.bin
More information about the Gtk-sharp-list