[Gtk-sharp-list] Gnome.Print

Mike Kestner mkestner at gmail.com
Mon Mar 31 15:05:08 EDT 2008


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.

-- 
Mike Kestner <mkestner at gmail.com>



More information about the Gtk-sharp-list mailing list