After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 382676 - PAPI backend is required
PAPI backend is required
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Printing
2.10.x
Other All
: Normal enhancement
: ---
Assigned To: gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2006-12-05 17:58 UTC by Ghee Teo
Modified: 2009-05-23 04:32 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement


Attachments
PAPI print backend patch (37.03 KB, patch)
2009-04-15 13:18 UTC, Ghee Teo
needs-work Details | Review
updated patch based on comments. (37.31 KB, patch)
2009-05-07 14:53 UTC, Ghee Teo
committed Details | Review

Description Ghee Teo 2006-12-05 17:58:41 UTC
Currently GTK+ Printing supports provides the following backends:
- CUPS
- FILE
- LPR

On Solaris, we have Solaris Print Server access through PAPI backend by default.
Even though Solaris does provide a CUPS implemnetation but it is not installed 
nor run by default.

We need a PAPI backend. I have a implementation for the PAPI backend which is currently being soaked in Solaris release, of which I should attach to this bug as soon as I can.
Comment 1 Matthias Clasen 2009-04-12 23:19:11 UTC
Well-soaked by now ?
Comment 2 Ghee Teo 2009-04-14 11:21:39 UTC
My bad me! Too shame to give any excuse.
I will attach it as soon I apply to head. No later than end of the week :)
Comment 3 Ghee Teo 2009-04-15 13:18:15 UTC
Created attachment 132689 [details] [review]
PAPI print backend patch
Comment 4 Ghee Teo 2009-04-15 13:19:04 UTC
Attached patch against trunk code.
Please review Matthias.
Thanks.
Comment 5 Matthias Clasen 2009-05-07 06:17:17 UTC
+if HAVE_PAPI
+GTK_PRINT_BACKENDS=file,lpr,papi
+else

Does it make sense to have lpr and papi on by default ? 
I would have expected just file,papi. 



+# Checks to see if we should compile with PAPI backend for GTK+
+#

I'd prefer to have an explicit option to control this, like the 
AC_ARG_ENABLE(cups ... we have for cups.


+AM_CONDITIONAL(HAVE_PAPI_CUPS, test $have_papi = yes && test "x$CUPS_CONFIG" != "xno")

This seems to be unused ?


Other than these things, looks ok
Comment 6 Ghee Teo 2009-05-07 14:42:59 UTC
(In reply to comment #5)
> +if HAVE_PAPI
> +GTK_PRINT_BACKENDS=file,lpr,papi
> +else
> 
> Does it make sense to have lpr and papi on by default ? 
> I would have expected just file,papi. 

Fair point. I took it out now.

> 
> 
> 
> +# Checks to see if we should compile with PAPI backend for GTK+
> +#
> 
> I'd prefer to have an explicit option to control this, like the 
> AC_ARG_ENABLE(cups ... we have for cups.

I have created a new patch using this macro. Now the configure script also take
--disable-papi.

> 
> 
> +AM_CONDITIONAL(HAVE_PAPI_CUPS, test $have_papi = yes && test "x$CUPS_CONFIG"
> != "xno")
> 
> This seems to be unused ?

  My mistake. I have another patch which is also to build a cups backend. Since on OpenSolaris, we can have either PAPI backend or CUPS backend depend on the print system user set to. We need to build both, though only one of them can be active at any one time.

  I have now also include that changes in this new patch. Essentially, the new changes between the previous patch and the current patch are:



bash-3.2$ svn diff configure.in gtk/Makefile.am
Index: configure.in
===================================================================
--- configure.in	(revision 22596)
+++ configure.in	(working copy)
@@ -1879,6 +1879,28 @@
   AM_CONDITIONAL(HAVE_CUPS, false)
 fi
 
+# Checks to see if we should compile with PAPI backend for GTK+
+#
+
+AC_ARG_ENABLE(papi,
+              [AC_HELP_STRING([--disable-papi]
+                              [disable papi print backend])],,
+	      [enable_papi=auto])
+
+if test "x$enable_papi" = "xauto"
+then
+  AC_MSG_CHECKING(libpapi)
+  AC_CHECK_LIB(papi, papiServiceCreate, have_papi=yes, have_papi=no)
+  if test $have_papi = yes; then
+    AC_DEFINE([HAVE_PAPI], [], [Define to 1 if libpapi available])
+  fi
+  AM_CONDITIONAL(HAVE_PAPI, test $have_papi = yes)
+else
+  AM_CONDITIONAL(HAVE_PAPI, false)
+fi
+
+AM_CONDITIONAL(HAVE_PAPI_CUPS, test $have_papi = yes && test "x$CUPS_CONFIG" != "xno")
+
 gtk_save_cppflags="$CPPFLAGS"
 CPPFLAGS="$CPPFLAGS $GTK_DEP_CFLAGS"
 			  
@@ -2107,6 +2129,7 @@
 modules/printbackends/cups/Makefile
 modules/printbackends/lpr/Makefile
 modules/printbackends/file/Makefile
+modules/printbackends/papi/Makefile
 modules/printbackends/test/Makefile
 perf/Makefile
 contrib/Makefile
Index: gtk/Makefile.am
===================================================================
--- gtk/Makefile.am	(revision 22596)
+++ gtk/Makefile.am	(working copy)
@@ -10,11 +10,19 @@
 SUBDIRS = theme-bits . tests
 DIST_SUBDIRS=theme-bits tests
 
+if HAVE_PAPI_CUPS
+GTK_PRINT_BACKENDS=file,papi,cups
+else
 if HAVE_CUPS
 GTK_PRINT_BACKENDS=file,cups
 else
+if HAVE_PAPI
+GTK_PRINT_BACKENDS=file,papi
+else
 GTK_PRINT_BACKENDS=file,lpr
 endif
+endif
+endif
 
 INCLUDES =						\
 	-DG_LOG_DOMAIN=\"Gtk\"				\



> 
> 
> Other than these things, looks ok
> 

Comment 7 Ghee Teo 2009-05-07 14:53:04 UTC
Created attachment 134198 [details] [review]
updated patch based on comments.
Comment 8 Matthias Clasen 2009-05-07 16:17:48 UTC
Thanks, looks good now.
Comment 9 Ghee Teo 2009-05-11 13:44:31 UTC
Should I try to put back?
Comment 10 Matthias Clasen 2009-05-11 14:14:41 UTC
To the 2.16 branch, you mean ? 

Up to you, I'd say. We don't normally add new features to the stable branch, but since this is a totally self-contained new print backend, I don't have objections if you want to do the work...
Comment 11 Ghee Teo 2009-05-11 16:01:21 UTC
Thanks! I will do the put back to trunk first and then to branch. Saved me the possibility of re-visit this again later. Now need to work the patch against git trunk :)
Comment 12 Ghee Teo 2009-05-11 17:39:36 UTC
Just push to HEAD,
 git push origin HEAD
Will try out branch tomorrow.
-Ghee
Comment 13 Ghee Teo 2009-05-13 19:18:54 UTC
Push to gtk+-2-16 branch as well. Thanks. Matthias!