GNOME Bugzilla – Bug 126046
CUPS blocks out other 'Location:' options
Last modified: 2004-12-22 21:47:04 UTC
Background: http://bugs.debian.org/212264 and http://bugs.debian.org/217797 . Versions: libgnomeprint2.2-0 2.4.0-1 libgnomeprint2.2-data 2.4.0-1 libgnomeprintui2.2-0 2.4.0-1 libgnomeprintui2.2-common 2.4.0-1 cupsys 1.1.19final-1.4 gnumeric 1.2.1-3 When /usr/sbin/cupsd is not running, gnumeric's File -> Print -> Printer -> Location has the following options: "lpr", "File", "Custom". When cupsd is running prior to starting gnumeric, the only option becomes "CUPS". The others are no longer listed, thus e.g. blocking the possibility of printing to a file. For me, this is reproducible with all other libgnomeprintui using applications I've tried so far: mrproject, gedit, evolution, abiword-gnome. Christian Surchi used to be able to reproduce it with other applications as well, but reports he can now only reproduce it with gnumeric.
I can replicate this with gnumeric. strangely enough gedit semes to be fine but I can't find a hint that it even ends up using cups.
With gnome-print HEAD this seems to work just fine with dedit and example_06 of gnome-print. I am seeing the problem with gnumeric. Since gnumeric is just using gtk_dialog_run (and example_06 is essentially doing the same) I have no clue where the difference comes from.
I can only replicate with gnumeric. Things work fine with gedit and evolution in debian sid. Ray, when you select "Generic Postscript", do you still have only CUPS in the transport menu?
With gnumeric, it doesn't matter if Printer is set to "Generic Postscript", "Create a PDF document" or "Dummy" (the dummy printer I configured with CUPS), the list for Location always contains just the single item "CUPS". With gedit, "Generic Postscript" allows me to choose between "File", "lpr" and "Custom"; "Create a PDF document" just "File" and "Dummy" just "CUPS". With mrproject and abiword the behaviour is as with gedit.
The behaviour in all applications except gnumeric appears to be the desired one. In the case of gnumeric, changing the content of the config does not invoke the required signal handler. I don't see how this could be a gnumeric bug, but since it works every where else...
Andreas: do you have more than one gnome-print installed?
"More than one libgnomeprint installed..."? That was one of my first thoughts. I don't think that is the case. To be sure I inserted various g_warnings in libgnome print. Recompiled, reinstalled etc and they do print as expected except for all apps I tried, except that with gnumeric one handler that rebiuilds the location menu is not being invoked...
Well, if we comment out the lines: /* gnome_print_config_unref (dst_pi->print_config); */ /* dst_pi->print_config = gnome_print_config_dup (src_pi->print_config); */ in print_info_dup of gnumeric, ie. rather than duplicating a gnome_print_config we would be nusing a new one. THen the problem disappears. It seems that the gnome_print_config_dup does not duplicate the config correctly: if the Printer node is being modified, normally a `modified' signal is emitted both by the Printer node and by its parent, but after duplication only the Printer node emits that signal.
Th eproblem was in gpa_config_duplicate which was called by gnome_print_config_dup. Fixed in cvs HEAD (post 2.5.0 release)