Bug 658550

The printer queue name may contain any printable characters except "/", "#", and space. That's the reason why are these characters automatically removed.

Thank you for the report but I'm closing it as notabug.

Re-opening it since it's still valid bug there is nothing that indicates to the end user that he cant write "/", "#" Neither when he types in the short name for the printer in the Describe Printer widget when he's adding it nor when he renames the printer when he already has added it...

(In reply to comment #2)
> Re-opening it since it's still valid bug there is nothing that indicates to the
> end user that he cant write "/", "#" Neither when he types in the short name
> for the printer in the Describe Printer widget when he's adding it
From my point of view the fact that the user can't type these characters into the text box (when adding new queue) is sufficient indicator.

Cups web interface (http://localhost:631/admin) doesn't check the queue name during typing so it shows this label next to text entry for the queue name:
"(May contain any printable characters except "/", "#", and space)"

Maybe we could add something like that on the 'Describe Printer' page.
Tim, what do you think ?

> nor when he renames the printer when he already has added it...
bug #612315, comment #8

I've done some digging and I think the way to do it is this:

Connect to the cell renderer's 'editing-started' signal, which will provide the gtk.Entry (or, technically, it could be another gtk.Editable-compatible object).  There we can connect to the 'changed' signal of this gtk.Entry (or whatever it is) -- and then we can prevent " " being entered as with any other gtk.Entry.

Cant the name name presented to the end user in s-c-p be "my printer" but in cups backend it would be saved as my-printer or my_printer? 

swapping out '-' or '_' for whitespace when the name is presented to the end user
and visa versa for cups back end when user (re)names his printer

(In reply to comment #5)
> Cant the name name presented to the end user in s-c-p be "my printer" but in
> cups backend it would be saved as my-printer or my_printer? 
> 
> swapping out '-' or '_' for whitespace when the name is presented to the end
> user
> and visa versa for cups back end when user (re)names his printer

I can't really go along with you there, Jóhann.
If I understand your suggestion right,
then when the user gives the queue "my-printer" name, we save it as "my-printer" and then present it as "my printer" which is different name than the user gave to the queue.

I agree with Jiri -- we won't go down that route.  We did actually try something like that a long time ago and I ended up having to apply bug fixes about it for years.

The queue names are what they are.  If you want to put special characters in there somewhere, use printer-info (the 'Description') for that.

I do think it might be nice to automatically block unwanted characters at the edit stage though.

True it could be a headache to maintain but then why not use the "Description:" or Location: field as the name of the printer shown to the end user instead of using the queue name which does have this limit?

This is akin to "package names" vs "package summaries" in PackageKit and in desktop menus.  You'd need to have the GTK+ print dialog, the KDE print dialog, as well as any other print dialogs lying around, all to agree to do that.

If that's something you think would be of value, please raise the topic in, say, the Fedora development mailing list so that agreement can be sought. (I personally don't think this is a worth-while change.)

Yeah right that would be like trying to reach agreement over defaulting to A4 papersize over Letter honestly you would have better chance achieving world piece than that happening...

and by piece I mean peace...

(In reply to comment #4)
> I've done some digging and I think the way to do it is this:
> 
> Connect to the cell renderer's 'editing-started' signal, which will provide the
> gtk.Entry (or, technically, it could be another gtk.Editable-compatible
> object).  There we can connect to the 'changed' signal of this gtk.Entry (or
> whatever it is) -- and then we can prevent " " being entered as with any other
> gtk.Entry.

Thanks Tim, fixed upstream
http://git.fedorahosted.org/git/?p=system-config-printer.git;a=commitdiff;h=d12cb0dd0a696a6b40f0fad9d4f553ba9548bca2

system-config-printer-1.2.6-1.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/system-config-printer-1.2.6-1.fc14

system-config-printer-1.2.6-1.fc13 has been submitted as an update for Fedora 13.
https://admin.fedoraproject.org/updates/system-config-printer-1.2.6-1.fc13

system-config-printer-1.2.6-2.fc13 has been pushed to the Fedora 13 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update system-config-printer'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/system-config-printer-1.2.6-2.fc13

system-config-printer-1.2.6-3.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.

system-config-printer-1.2.7-2.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.