Bug 388575

No longer a major bug because it is only the
wording which totally confused me.

Furthermore the CUPS UTF-8 issue (see bug #387130) hit me
because I run yast2-printer in a "en_GB.iso885915" locale
which is probably the reason that yast2-printer didn't get
any possible DeviceURI from the cupsd so that the list was
empty.

When running yast2-printer in a UTF-8 or 7-bit ASCII locale
the "New Queue for Existing Printer" popup
shows a list of possible DeviceURIs.

Because of the YaST2 'text freeze' I suggest to simply
omit the "New Queue for Existing Printer" text at all
because it is plain wrong here.

What is missing is a way to set an arbitrary DeviceURI.

Could perhaps the [Connection Wizard] button lead to
the usual workflow to choose the connection manually
(locally connected, network, ...), see bug #388574.

Now a critical bug because of "corruption of data"
(corruption of config data in this particular case), see
https://bugzilla.novell.com/page.cgi?id=fields.html#bug_severity

The [Change Connection] stuff it broken to the core!

Have two locally connected printers to have
two DeviceURIs avialable so that you can
actually change the DeviceURI via [Change Connection].
Perhaps it works also with one real USB printer
and then change its DeviceURI to "parallel...".

Initially have no queues.
Start yast2-printer.
Set up a new queue only for one printer with yast2-printer.
Finish yast2-printer.

Start yast2-printer.
Select the queue to change it.
Select [Change Connection].
Choose another DeviceURI (e.g. the one for the other printer).

Normal bug:
yast2-printer automatically changes also the driver
without any user notification.
But this is not what I did.
I did only [Change Connection].
I didn't do [Change Driver].
If the model for the new DeviceURI looks different,
a user information that probably the driver should
also be changed is of course nice to have.
But a silent change is a bug.
If I replace a model completely, I would usually
just remove to old queue and set up a new one
(in particular to get a new matching queue name).

To reproduce the next bug, leave it as is
and just finish yast2-printer.

Critical bug:
Now there is a new queue with a meaningless
autogenerated name "printer" which has the
new DeviceUri and the new driver (PPD file)
but the original queue was not changed at all.

This is plain totally broken to the core.
Did you ever test it on your own?

If there is no time to fix it for 11.0
remove the [Change Connection] stuff completely
to avoid its descructive results.
Under the current circumstances it would be much better
to let the user delete and re-create the queue if the
connevtion is to be changed than the current mess.

I do not want to know what happens if I try to do
a lot of changes for a lot of different queues
in one single yast2-printer run...

When I have a queue for a USB printer
and change its connection to "parallel..."
there is no automated selection of a new driver.

When I have a queue for a parallel port printer
and change its connection to one for a USB printer
there is an automated selection of a new driver
but the selected driver does not always match to
the model to which the USB printer DeviceURI belongs.

I have in particular plain wrong automated drivers
if I use a DeviceURI for a HP network printer like
hp:/net/Officejet_7200_series?ip=10.10.100.100

I.e. the results are inconsistent and sometimes
plain wrong depending on whatever obscure magic!

The more I test it the worse it becomes.

fixed in yast2-printer-2.16.26
widget changed to editable ComboBox and it will edit only current URI

Some good news after the many bug reports:

I installed openSUSE 11.0 beta3 from scratch
on i386 hardware
but
I updated yast2-printer from what is in beta-3
to yast2-printer-2.16.26 which I built from
what was in /work/src/done/STABLE/yast2-printer/

I can confirm that now "Change Connection" works well.

It changes only the DeviceURI and it does it regardless
which strange new URI I choose or which strange URI
I enter manually (e.g. it works for "parallel:/tmp/foobar")
which is excatly correct (provide reasonable predefined
values but nevertheless let the user the freedom to
configure it as he insists).

There is only one tiny issue left:
CUPS rejects to set up a DeviceURI if the URI scheme
(the first word in the URI, see "man backend")
is unknown to the cupsd.
Therefore it fails when I enter manually "paralel:/dev/lp0"
(note the missing 'l' - the correct URI scheme is "parallel").
It is perfectly correct that it fails
but

1.
There is only an error message when [Finish]
so that the user cannot correct it at this stage.
Compare
http://en.opensuse.org/YaST/Development/Printer_Enhancement
"Transaction Semantics For Each One Setup"

2.
The error popup reads
  "Queue <queuename> cannot be saved because
   the selected spooler does not support it"
which is misleading.

3.
The error popup does not show the original error message
from the system which mentions exactly what is actually wrong:
---------------------------------------------------------------
nelson:~ # lpadmin -p printer -v paralel:/dev/lp0
lpadmin: Bad device-uri "paralel:/dev/lp0"!
---------------------------------------------------------------
Compare this bug from the stone age:
https://bugzilla.novell.com/show_bug.cgi?id=suse10048

Therefore I reopened it as enhancement for openSUSE 11.1

No, that message is shown only when valid variable is set to false (by YaST, not by CUPS) - YaST don't try to add this queue. 
What about to check just first part of URI string if it's one of "ls /usr/lib/cups/backend/*"?

What about x86_64 (i.e. /usr/lib64/cups/backend/)?

What about architectures which may have /usr/lib32/?
(read the FHS!)

What about files in /usr/lib[64]/cups/backend/ which
are not exectutable (e.g. intentionally disabled backends)?

What about exectuable backends which fail on the
particular user's system?

Read
http://en.opensuse.org/SDB:CUPS_in_a_Nutshell
"The Backends"!

Why do you always prefer to inspect the file system
when it is the local running cupsd and only this cupsd
which has the currently actually correct information?

I explained it already so many many times to you!

Use "lpinfo -h localhost ..." and nothing else!

Get rid of all this crap in yast2-printer which
leads only to more and more problems!

Start to implement it in compliance with CUPS!

Stop re-implementing stuff as YaST-specific ditry-hacks!

Only

lpinfo -h localhost -v | cut -s -d ' ' -f2 | cut -d ':' -f1 | sort -u

(or equivalent CUPS library calls) results what you need!

If this command results nothing, there is a severe reason,
e.g. no local running cupsd and then it is exactly correct
that the command fails in contrast to your dirty hack
which works even without a local running cupsd!

fixed in yast2-printer-2.17.1