I don't think that system-config-printer ought to depend on hplip, since there
are very many use-cases that don't require it and it is quite large.

We should add it to comps, though, wherever cups appears.

Sounds reasonable, as long as it gets installed by default. Also
system-config-printer should use and if nescesarry enable hplip for PSC (all in
one) devices if installed. When using hplip one can just startup xsane and
everything works.

I can get it to work myself, but we want tobe as much plug and play as possbile,
right?

That aspect is much harder to fix, as printconf-tui creates the queues that
kudzu/cups-config-daemon tell it to.

Should I file a bug against kudzu for this then?

My mother in law has such a printer and I have converted here over to Linux, no
for other mother in law scenarios it would be nice if this would work 100% out
of the box, and all the parts are there.

Yes please -- against hal I think.

Assigning it to hal.

This is a foomatics issue isn't it?

I should be cleared.  We just tell cups-config-printer what make and model and
printconf then looks up that make and model in foomatics and sets up the queue
with that info.  If foomatics points to the hplip drivers that is what it uses.

The problem is not the selected driver, the problem is that with hplip installed
and the daemons running there are 2 ways to get to the printer, through usblp
and through hplip, printconf should prefer / only use the hplip uri, as that way
other functions of the device work too.

Above (coment #9) should read clearer not cleared. 

So you are saying it is a cups backend?  Then we need to fix the hal backend to
dasy chain.

I think I'm saying that, I dunno what exactly makes up a cups-backend, what I
know / see is that if I:
-install hplip
-start the service
-start system-config-printer
-edit my printer
-select queue type tab

I see the following local-connected "queues":
/dev/lp0
/dev/usb/lp0
hp:/usb/psc_1300_series?serial=XXXXXXXXXXXXXXXXXX

By default system-config-printer uses /dev/usb/lp0, I changed this to
hp:/usb/psc_1300_series?serial=XXXXXXXXXXXXXXXXXX. I did this si that I can use
the scanner of the printer too. I assume that using /dev/usb/lp0 directly can
cause trouble when also using the scanner, I haven't tried though.

Note: both are the same printer.

Yes hp is a cups backend.  I can easily daisy chain it but I have to figure out
the logic for deciding when to do this.  Can I do it for all hp printers?  If
that is so then it is totaly easy.  It looks like the port format is just
hp:/usb/<product name>?serial=<serial #> which HAL exports.

If I can't do it for all hp printers I guess I am just going to have to frob the
hp backend to give me a list of printers attached to the system it supports and
grok that list to see if the serial #'s match up.

Actually I should point out what I am talking about and what Hans is talking
about are different issues but are related.  Hans you are setting it up by hand
and just noticed that the hp queue is listed last.  I'm guessing
system-config-printer should just pick the best queue to use.  I don't think
this will be fixed in the near term as we will be redesigning
system-config-printer and changes like this will get in then.

I'm talking about autodetecting printers which use the hal backend.  In my case
plugging in an HP printer should just work without going through
system-config-printer.  This bug report is very helpful in that respect.

I can fix up system-config-printer to automatically order 'hp'-provided devices
before any others.

J5: running the 'hp' backend with no parameters -- or alternatively, 'lpinfo -v
|grep " hp:"' -- will show you which attached devices the backend can drive.

I wish this weren't all so hacky. :-/

John, what is the status of this ? 
Do hp psc devices work out of the box in rawhide ?

Think I know how to fix this.

Fixed in update: hal-cups-utils-0.6.5-1.fc6