Increasing width of a column makes column in each row to have the same
width. So it is unnecessary to set 3rd column of each row separately to
have the same width. Let's do it just once.
https://bugzilla.gnome.org/show_bug.cgi?id=779216
The chooser ignores EXIF orientations embedded in the pictures when the
thumbnails are generated.
Because the EXIF informations are available after the file has been
loaded, it has to be reloaded if the transformed dimensions don't
match the thumbnails constraints.
The transformations are directly applied for EXIF orientations 1, 2,
3 and 4. For EXIF orientations 5, 6, 7 and 8, the pictures are reloaded
with swapped dimensions before the transformations are applied.
https://bugzilla.gnome.org/show_bug.cgi?id=783200
In some cases we end up getting an input source row activated without
it being selected. This seems like a GtkListBox bug but we can easily
avoid it.
https://bugzilla.gnome.org/show_bug.cgi?id=783058
The expired credentials GtkButton is going to be replaced with a
GtkInfoBar touching the top, start and end edges of the GtkDialog.
Therefore, the margins around the account details and GtkSwitches
cannot be set on the higher level GtkBoxes. Instead, they need to be
set lower down the hierarchy closer to the actual widgets that need
them.
Bump required GOA version for the new goa_provider_show_account
behaviour.
https://bugzilla.gnome.org/show_bug.cgi?id=779368
For an infinitesimal amount of time after opening the options dialog, a
spinner is displayed at the start of the action area while the dialog
loads asynchronously. Display the spinner in the center of the dialog
instead, using a GtkStack to switch between spinner mode and normal
mode. Test by removing the calls to printer_get_ppd_async(),
get_named_dest_async(), and get_ipp_attributes_async() from the bottom
of populate_options().
Why? (1) It looks better this way. (2) Need to stop using the action
area in order to switch to a header bar.
https://bugzilla.gnome.org/show_bug.cgi?id=755713https://bugzilla.gnome.org/show_bug.cgi?id=779708
In scenarios with a long list of printers, it might be difficult
to find a newly added printer.
This patch make the view scroll to the allocated position of the
printer entry.
https://bugzilla.gnome.org/show_bug.cgi?id=779506
The select_new_printer property used to be an indicator whether
the view should change to present the newly added printer.
With the Printers presented as a list in the new design, there's
no need for this flag.
https://bugzilla.gnome.org/show_bug.cgi?id=779506
Dismisses the Printer removal notification after 10 seconds,
removing the printer permanently.
The 10 seconds value is taken from the online-accounts panel.
https://bugzilla.gnome.org/show_bug.cgi?id=693187
Instead of directly applying the deletion of a printer, we should
follow the GNOME in-app notification deletion guidelines.
This patch introduces the in-app notification following the HIG[0]
for the deletion of a printer. It allows to "undo" the deletion.
The default behavior for these notification is to dismiss a previous
notification. In doing so, when deleting multiple printers, the
"Undo" button only restores the last deleted one. We don't do batch/
bulk removal in the printers panel.
[0] https://developer.gnome.org/hig/stable/in-app-notifications.html.enhttps://bugzilla.gnome.org/show_bug.cgi?id=693187
Mutter's new display configuration API allows configurable per-monitor
scales within a finite set determined by mutter. We expose the
available values in a simple slider widget for each monitor.
https://bugzilla.gnome.org/show_bug.cgi?id=782785
The new API checks with mutter every time update_apply_button() is
called and mutter is very strict about this so it already does these
adjustments internally.
https://bugzilla.gnome.org/show_bug.cgi?id=782785
When setting the primary monitor off we were setting all other
monitors as non-primary which is clearly wrong. It only worked
correctly because the backend code in GnomeRR would implicitly
select a primary for us.
https://bugzilla.gnome.org/show_bug.cgi?id=782785
Use mutter's new display configuration API if it's available or
fallback to the old API via GnomeRR. The new API requires a new way to
identify outputs so we also need to use an alternative monitor labeler
API.
https://bugzilla.gnome.org/show_bug.cgi?id=782785
This adapts as much as possible mutter's new display config API to the
current display panel's expectations. In particular we keep the
concept of logical monitors hidden from the panel. They will later be
exposed when we re-design the panel to make full use of the new API.
https://bugzilla.gnome.org/show_bug.cgi?id=782785
This removes the direct dependency on GnomeRR while keeping the
existing functionality.
All the tiled monitor special casing was removed since the new API
doesn't expose tiled monitors in the first place.
A check for virtual size limits was removed but it wasn't being
enforced anyway.
We also introduce a blank error state for when the backend API isn't
available.
https://bugzilla.gnome.org/show_bug.cgi?id=782785
