Samba 4.12 complains loudly about a perl yapp driver module. Some
fiddling with the PERL5LIB and PRL_MM_OPT was required in order
to get perl to look into the /app prefix after bundling the module.
A logic error meant that the power profiles info boxes container
would not be shown if there wasn't a "degraded" performance as well.
Spotted by Allan Day
Both consumers of PpPPDSelectionDialog (PpNewPrinterDialog,
PpDetailsDialog) free the PPDList they pass to
pp_ppd_selection_dialog_set_ppd_list and they do not pass a copy, so
PpPPDSelectionDialog should not free the pointer on dispose.
This fixes a racy segfault when closing a PpDetailsDialog after PPD
selection (introduced with this series), did not appear with
PpNewPrinterDialog for some reason.
pp_new_printer_dialog_get_new_print_device is replaced with
pp_new_printer_dialog_get_new_printer which returns a PpNewPrinter.
gtk_show_all is used instead of gtk_dialog_run for PpNewPrinterDialog
and PpPPDSelectionDialog.
This is in response to feedback:
https://gitlab.gnome.org/GNOME/gnome-control-center/-/merge_requests/930#note_1202114
This is accomplished by moving the calls to pp_printer_add_async
directly to CcPrintersPanel. pp_printer_delete_async calls are already
done directly in the CcPrintersPanel so there is consistency gained by
this implementation in addition to PpNewPrinterDialog actually being a
GtkDialog.
A pp_new_printer_dialog_get_new_print_device method has been added to
PpNewPrinterDialog to allow getting the PpPrintDevice selected by the
user to add. This can be called anytime after a response callback
with a GTK_RESPONSE_OK reponse_id.
PpNewPrinterDialog still does asynchronous operations to populate the
dialog, but the create dialog -> receive signal -> destroy dialog flow
can all be handled like a traditional GtkDialog without additional
callbacks or signalling.
Reword the lap mode info message slightly as the performance mode might
not have been what the user requested, but the warning should stay until
cleared nonetheless.
Applications can request that power-profiles-daemon "hold" a particular
power profile for the duration of a task or event, such as launching a
taxing application, or saving power because of low battery.
Show those holds in the same type of info boxes we already use to show
"degraded" performance.
See https://gitlab.freedesktop.org/hadess/power-profiles-daemon/-/merge_requests/46
gnome-control-center/panels/power/cc-power-panel.c: In function ‘keynav_failed_cb’:
gnome-control-center/panels/power/cc-power-panel.c:892:50: warning: statement with no effect [-Wunused-value]
892 | direction == GTK_DIR_UP ? GTK_DIR_TAB_BACKWARD : GTK_DIR_TAB_FORWARD;
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~
As described in #1346, GLib 2.64 includes a g_get_os_info() function,
providing access to keys from /etc/os-release. This commit replaces calls to
gnome-control-center's custom parser (in panels/common/cc-os-release.c)
with calls to this new function, and deletes the custom parser code.
Closes#1346
In case fractional scaling is enabled, depending on the resolution,
mutter may advertise many fractional scaling values which are way more
than MAX_SCALE_BUTTONS, making impossible to use higher fractional
scaling values in high dpi setups.
So, in case scaling is possible, show them as buttons if they fit the
buttons limit, otherwise fallback to a combo box that is consistent with
the rest of the UI and will allow to use any valid scaling value.
In the front-end we define a minimum size and then we check every time
we iterate through resolutions or scales if such mode is valid.
Since the configuration won't change, we can just filter the invalid
values once when the minimum allowed size is set, so that we can be sure
that the returned scales list is always matching the ones appliable for
the current mode.
The only edge case is when using a cloned configuration, as in this case
the values need to be applied to all the monitors.
However, since we already return a reffed GArray we can just create a
temporary one in this case where unappliable scales are skipped.
As per this we can just use around the scales array length as the number
of visible buttons.
It's just a nicer api and allows us to avoid having to count all the
elements around or to expose the size via an out value.
Given this is a private API anyway there's no risk for modifying the
array, so it's something safe to use anyways.
