GNOME Bugzilla – Bug 690494
Use a shell dialog for printer authentication
Last modified: 2018-04-15 00:18:07 UTC
Created attachment 231873 [details] mockup If a printer requires a password (such as for samba printers on authenticated servers), we show this dialog: http://bugzilla-attachments.gnome.org/attachment.cgi?id=223224 Ideally we should use a GNOME Shell dialog for this, and not a Gtk+ one. Shell dialogs are used for other authentication operations, such as VPN. Printers should be consistent with this. See the attached mockup for how to do the shell authentication dialog. A few other notes here: * The dialog should only ever be displayed straight after the user has started a print job. It should not pop up after a long delay, or pop up on its own. * If we are unable to save the password, the Remember Password check box should not be included in the dialog. * Do not show the password dialog when the printer is being added or installed. The first time someone sees it should be when they print for the first time. * It would be good to have a section in the printer options dialog for authentication details. This would allow the user to update their password if it changes, for example.
I'm changing component of this bug, because it is targeted to actual printing not to configuration of new printer.
Created attachment 231879 [details] current samba authentication dialog This is actual authentication dialog used when printing to an authenticated printer in Gtk+. There can be also one another entry for "Domain:" (e.g. "WORKGROUP").
Allan, do we still want this ? There's been a general trend away from shell modals...
(In reply to comment #3) > Allan, do we still want this ? If a password is requested from a print dialog, then yes - we do. It is the system that is going to store the password, not the app that spawned the print dialog. This communicates that. Also, it avoids having dialog windows stacked on top of one another.
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla. If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab: https://gitlab.gnome.org/GNOME/gtk/issues/new