GNOME Bugzilla – Bug 769114
Printer renaming feels extremely slow
Last modified: 2021-06-09 16:27:05 UTC
A bit but not completely similar to bug #751109 (because in my case it actually unfreezes and successfully renames the printer after 30-60 secs)... Renaming a printer is excruciatingly slow on my end, even if I use no spaces or special characters, be it a USB or networked (wired or wifi) printer. It takes what feels like 30-60 seconds for the UI to apply the changes and become responsive again, whereas during that time other apps (like Evince/GTK's print dialog) can already see the changes immediately, so I'm not sure why the control center is waiting longer than GTK itself on this.
The renaming works here the way that it adds the printer with the new name, sets its properties to the same as for the old one and removes the printer with the old name. So it can happen that other apps see the new printer before the rename call in g-c-c has finished. Now we use cups-pk-helper's PrinterRename method for this (if it is available, if it is not available then the old code is used). Could you try whether this call takes that much time as if renamed from g-c-c?: gdbus call --system --dest org.opensuse.CupsPkHelper.Mechanism --object-path / --method org.opensuse.CupsPkHelper.Mechanism.PrinterRename old-printer-name new-printer-name Which version of cups-pk-helper do you have installed?
Created attachment 345829 [details] [review] printers: Use async rename method pp_printer_rename_async is better than the old printer_rename utility. The PpDetailsDialog doesn't need to do anything in the callback since we are emiting the "printer-changed" signal when the dialog is closed.
Created attachment 345830 [details] [review] printers: Drop sync printer_rename utility function
Review of attachment 345829 [details] [review]: There is quite a lot of warnings when I rename a printer with this patch.
Review of attachment 345830 [details] [review]: A function still needs it. If it is only the sync fallback, remove it there too since we kept it around for quite some time.
Created attachment 346316 [details] [review] printers: Use async rename method pp_printer_rename_async is better than the old printer_rename utility. The PpDetailsDialog doesn't need to do anything in the callback since we are emiting the "printer-changed" signal when the dialog is closed.
Comment on attachment 345830 [details] [review] printers: Drop sync printer_rename utility function sure. I didn't see that pp-printer was encapsulating this sync method into a gtask. my bad. I'm making this patch obsolete.
Review of attachment 346316 [details] [review]: If I rename printer, press Tab and close the details dialog I get this: (gnome-control-center:30423): GLib-GObject-WARNING **: invalid unclassed pointer in cast to 'PpPrinterEntry' (gnome-control-center:30423): GLib-GObject-WARNING **: instance with invalid (NULL) class pointer (gnome-control-center:30423): GLib-GObject-CRITICAL **: g_signal_emit_by_name: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed (gnome-control-center:30423): printers-cc-panel-WARNING **: cups-pk-helper: renaming of printer test-print7 failed: client-error-not-found
Created attachment 346361 [details] [review] printers: Do not apply rename/location changes in focus-out-event Since we are already applying the changing in the PpDetailsDialog when it gets closed, there's no need to apply these changes in the focus-out-event of its respective GtkEntries.
Created attachment 346362 [details] [review] printers: Use async rename method pp_printer_rename_async is better than the old printer_rename utility. The PpDetailsDialog doesn't need to do anything in the callback since we are emiting the "printer-changed" signal when the dialog is closed.
I only see the warning when combining the focus-out-event and the dialog response changes. In doing so, I propose that we don't apply the changes for the entries until the dialog is closed (attachment 346361 [details] [review]). This way works flawless here.
Review of attachment 346361 [details] [review]: This makes sense. Merge those 2 functions to 1 so we don't need to tackle with order of the operations (what would happen if you ask for async rename of the printer and in between you would change its location in sync?) Also modify the function to match https://developer.gnome.org/gtk3/stable/GtkDialog.html#GtkDialog-response please.
Review of attachment 346362 [details] [review]: ::: panels/printers/pp-details-dialog.c @@ +84,3 @@ + new_name, + NULL, + (GAsyncReadyCallback) pp_printer_rename_finish, Create a new callback with correct type for this please. It should just call the finish function without accessing the possible-gone structures and unref the source object. ::: panels/printers/pp-printer.c @@ +235,3 @@ NULL); + if (printer_name == NULL) + return; Is this needed here?
Created attachment 346450 [details] [review] printers: Do not apply rename/location changes in focus-out-event Since we are already applying the changing in the PpDetailsDialog when it gets closed, there's no need to apply these changes in the focus-out-event of its respective GtkEntries.
Created attachment 346451 [details] [review] printers: Use async rename method pp_printer_rename_async is better than the old printer_rename utility. The PpDetailsDialog doesn't need to do anything in the callback since we are emiting the "printer-changed" signal when the dialog is closed.
Review of attachment 346450 [details] [review]: Thanks. Looks good to me.
Review of attachment 346451 [details] [review]: Looks good to me too. Thank you for the fixes!
Thanks for the reviews! Attachment 346450 [details] pushed as 5fa1ded - printers: Do not apply rename/location changes in focus-out-event Attachment 346451 [details] pushed as ca30e0e - printers: Use async rename method
Cause of the original problem was not discovered yet. So I'm reopening this bug.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new bug report at https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/ Thank you for your understanding and your help.