Bug 133915 - Desktop-printing in devel tree no longer pulls in printman as a dependancy
Desktop-printing in devel tree no longer pulls in printman as a dependancy
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: desktop-printing (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Colin Walters
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-09-28 10:07 EDT by Jef Spaleta
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version: 0.15-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-29 00:26:16 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jef Spaleta 2004-09-28 10:07:51 EDT
Description of problem:
In fc2 desktop-printing-0.1.10-26  requires printman
In fc3t2 and the development tree desktop-printing no longer
requires printman, and the default desktop and workstation installs
do not explicit list printman as a package to be installed. Nor is
printman explicitly defined in a group in comps.xml at all.

Afaict printman provides the only gnome menu exposed way for a
non-privledged user to set the which printer to use.
rpm -qf /usr/bin/gnome-print-manager
printman-0.0.2-4

Surely the intention is to make sure gnome-print-manager is available
in the gnome menus for default desktop and workstation installs.

Either the explicit dependancy on printman needs to be added back into
desktop-printing to make sure printman is pulled in. Or comps.xml
needs to be updated to explicitly list printman as a package to
install. I'm filing this against desktop-printing since the fc2
behavior was to require printman.

-jef
Comment 1 Colin Walters 2004-09-28 11:52:22 EDT
We actually decided g-p-m wasn't really needed since the print dialog
now provides printer status.  

As for setting the default - right now that's saved per-application. 
Is that not sufficient?
Comment 2 Jef Spaleta 2004-09-28 12:57:22 EDT
Really? All applications let me define a default printer from the
available system printers? or do you mean all the modern toolkit
applications? I take it you dont include things like xpdf when you
speak of "per application"

So all the default installed applications should all have a "per
appliction" way of choosing which system-wide configured printer to
use is what your telling me. So if I find a application that allows me
to print but not select a printer is that a filable bug against that
application?

As for non-default installed graphical applications like xpdf that do
not let me choose a default printer in a sane dialog manner.. is that
a fileable bug? Or do we finally get to use this printer choosing
issue as a means to punt applications like that out of Core? 

So assuming that all graphical applications in a desktop/workstation
install let me choose a printer via a sane dialog... does this mean
printman needs to be exposed in comps.xml as an custom installable
package? Or is printman going to be punted along with applications
that don't allow of a sane printer dialog experience?

-jef



Comment 3 Jef Spaleta 2004-09-28 13:03:42 EDT
ggv for example, which im pretty sure is a default installed
application.  Its printing preferences dialog SUCKS... is nothing but
a commandline lpr statement.  Maybe I misunderstand your "per
application" comment. So I'll phrase my concern in the form of a question.

On a default Desktop install of fc3t2, after configuring available
system printers as a privledged user, how does a user select which
printer to use when trying to print to ggv?  

Afaict printman is the only thing that exposes a sane graphical
interface to select the default printer ggv is going to use.
Reconfiguring ggv to use /usr/bin/lpr -Pveryslowlaser2 seems wrong to me.

-jef
Comment 4 Colin Walters 2004-09-28 15:36:50 EDT
Ugggh.  ggv is basically just broken.  It needs to use libgnomeprint.

Comment 5 Colin Walters 2004-09-28 15:50:25 EDT
The issue here is that a lot of our printing work was predicated on
getting a consistent print dialog in different applications, including
Mozilla and OpenOffice (I didn't realize how broken ggv was until now).

Unfortunately due to our Mozilla guy getting swamped by security
errata we don't have that in Mozilla, and not sure about OpenOffice
either.

But as for this particular bug, I'm not going to resuscitate printman
just for ggv.  I'll take a look at how hard it is to fix ggv.
Comment 6 Jef Spaleta 2004-09-28 16:06:46 EDT
Sure ggv certaintly does need to use libgnomeprint. Shall i suggest to
someone that ggv should NOT be installed by default then if its
printing behavior is considered broken. :->
 
And i can appreciate that fact that any modern toolkit application or
application installed by default should be considered broken if its
not using something sane as a printer chooser. Thats a very good
reason to not include printman by default, totally acceptible.

But its also a reality that broken and non-modern toolkit applications
exist in Core (not to mention Fedora Extras), and printman provides
the only sane way to set a default printer for those applications,
that relying on lpr directly such as xpdf and ggv. It makes sense to
me that printman should be exposed in comps.xml as a selectable Extra
in something like the Gnome Desktop Grome as long as printman is still
in Core.

I'm not sure what you mean by "resuyscitate". If printman is totally
dead...drop it. Don't leave it hanging around as part of Core taking
up space if the intent is to get rid of it completely. But if its not
going to drop out of Core, then it would make sense to me to expose
printman as a selectable extra package of which every group seems most
appropriate in comps.xml. Since right now you have to know that
printman exists or do an everything install to get access to it.

So tell me which way to refile this bug. Do i refile asking for
printman to be dropped from Core or do I refile asking printman to be
exposed in comps.xml so it can be installed via Add/Remove Software by
a user who wants to use printman with something like xpdf of xdvi to
set a default printer?

-jef
Comment 7 Colin Walters 2004-09-28 16:13:35 EDT
I have no problem keeping it in Core and putting it in comps.xml. 
However I think comps is frozen for FC3, you'll have to get it past
notting.
Comment 9 Colin Walters 2004-09-29 00:26:16 EDT
We discussed this in the office a bit and the final answer is that
neither Mozilla nor OpenOffice are going to use the native print
dialog for FC3.

So we need a way to set the default printer.  We came to the
conclusion that the best way to do this is to have a little capplet
Preferences->Default Printer.  I've implemented this in
desktop-printing-0.15-1.  

Let me know if that works for you.
Comment 10 Jef Spaleta 2004-09-30 10:40:30 EDT
looks like it works as expected.
I see the local printers in the list.
And when iptables is configured (ie turned-off) to see other available
cups printers on the network i see them included as well.

I've tested it with the local printer, I haven't tested it with the
remote cups printers on the network.

So this definitely meets the basic needs i see. I thank you.

Now to start filing RFE's to add functionality to the dialog :->

Note You need to log in before you can comment on or make changes to this bug.