Our UI doesn't expose the Delete button when the current logged user
is the one viewing its account settings. So there's no need to have
this dialog since it never gets shown.
The output test wheel is fixed size with a size of 300px
and a margin of 60px on both sides. Decreasing each value
by 20px, makes it fit a width (and height) of 360px.
see: !1563
Signed-off-by: Markus Göllnitz <camelcasenick@bewares.it>
While the combo box for devices can get ellipsized labels,
the one for the profile cannot. For Bluetooth profiles
with long descriptive names, this can lead to large
minimal widths for the combo box, the row, and the panel.
Signed-off-by: Markus Göllnitz <camelcasenick@bewares.it>
This reverts commit 4a0d924afd.
There are some rough edges to be polished before this is ready for
prime time.
UPower battery health capacity reporting can often be inconsistent
across vendors, and we don't want to expose unreliable information
on the UI without proper sanitization.
As described in #2554, it would be useful to be able to see battery health information
such as charge capacity in Settings. This commit implements the proposed design for
battery health information, adding this functionality to the power panel.
Closes#2554
Use a GtkStack instead of a AdwLeaflet in the security and heavily
simplify the security dialog, because it contained a lot of misued
widgets and also a page that was never made visible.
The method gtk_widget_translate_coordinates is deprecated in gtk 4.12.
Use a new method gtk_widget_compute_point instead.
general: Apply suggestions graphene point
The homogeneous on their boxes has no visible effect, as
the buttons lack hexpand. It, however, still influences
the box's minimal width unnecessarily. Thus, removing it
decreases the panel's minimal and natural width without a
visible change otherwise.
Making those buttons can-shrink also decreases their and
henceforth the panel's minimal width. With this change,
the panel can shrink to a width of 360px, with a natural
width not far from it.
Signed-off-by: Markus Göllnitz <camelcasenick@bewares.it>
The copy button now generates a system information report with all the system information.
The information is generated by calling the same methods used when populating the System Information window.
get_gnome_version() relies on shell_proxy_ready() to provide it with shell proxy.
This means that we cant call get_gnome_version() without providing proxy as an argument which is fine normally but becomes tedious if we want to call this function multiple times in different scopes.
Fix this by creating the shell proxy inside get_gnome_version() function instead.
Since we're no longer processing the list of graphics devices inside of get_renderer_from_switcheroo, there's no need for this function
as the the list now gets passed around to a different function and automatically freed once it goes out of scope.
Default and non default GPUs were associated with a weight of 1 and -1 respectively which meant default gpus were treated
as a "bigger" entity than non default ones. It meant that when sorting a list of GpuData, the default gpu would end up
at the end of the list since it was treated as the biggest. The resultant list after sorting would end up something like
our pointer
|
|
<gpu>, <gpu>, <gpu>, <gpu>, <default gpu>
With this change the weights of these gpus have been exchanged, making the default gpu to be treated as "smaller" this
changing the order of the sorted list into something like
our pointer
|
|
<default gpu>, <gpu>, <gpu>, <gpu>, <gpu>
This is pretty useful because when creating the gpu information row entries in create_graphics_rows, the default gpu is processed first so it becomes the first element added to the gpu entry list which is how we would expect it to be.
This change brings it more inline with the mockup and it makes sense to not have a number for the default graphics device as that
s always going to be the first device.
Part 1:
Currently all graphics devices have to share a single row for their names, this method doesn't pretty well for devices with long names or computers that may have multiple GPUs.
The new mockup fixes this by having a separate entry for each graphics device.
This commit turns graphics_row into a GtkBox, graphics_row is going to act like a space where gpu entries will be placed.
graphics_row will be populated in the code using create_graphics_row() to have separate entries for each graphics device
Part 2:
Currently all graphics devices have to share a single row for their names, this method doesn't pretty well for devices with l>
The new mockup fixes this by having a separate entry for each graphics device.
This commit adds a method to popuplate graphics_row with GPU information entries.
It uses the existing logic from get_renderer_from_switcheroo to iterate over a list of graphics devices and build a CcInfoEntry for each device.
It finally appends the widget to graphics_row
Part 3:
Currently all graphics devices have to share a single row for their names, this method doesn't pretty well for devices with l>
The new mockup fixes this by having a separate entry for each graphics device.
The list of graphics devices is now processed in create_graphics_rows function, so remove that logic from get_renderer_from_switcheroo () and return a GSList instead of a string.
graphics_hardware_string has been renamed to graphics_hardware_list to imply the change.
Since create_graphics_rows expects a list, get_graphics_hardware method has been modified to create a renderer list from the outputs of get_renderer_from_session or get_renderer_from_helper in case that get_renderer_from_switcheroo fails.
