[Gtk-sharp-list] Gnome.Print

[Sebastian Dröge]

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 :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
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