Those are not always present in the device string.
Guidance was taken from the usage on vendor websites.
NVIDIA actually has the rights to GTX™ but doesn’t seem to use it,
in contrast to RTX™.
This made everything AMD lower case after the second word
and is likely unintentional for something like EPYC™.
e.g. was
AMD Ryzen threadripper 1950x 16-core processor
AMD Radeon rx 580 series
The hostname/device name dialog has only a GtkEntry. So a user
navigating with only a keyboard should be able to apply their
changes by pressing "Enter".
It was apparent when selecting the text, as the text is right aligned.
»AMD® Ryzen threadripper 1950x 16-core processor × 32 «
↓
»AMD® Ryzen threadripper 1950x 16-core processor × 32«
libgtop gets the RAM size as is visible to the OS, so the physical RAM
size minus all the reserved areas listed at the top of your usual Linux
dmesg output.
Use systemd 248's MEMORY_ARRAY_* properties attached to the pseudo-DMI
device to get the size of the RAM sticks/chips as the user expects.
Closes: #1540
Ignored in Meson < 0.60.0, deprecated since 0.60.1 and fatal since 0.61.0.
panels/applications/meson.build:10:5: ERROR: Function does not take positional arguments.
panels/background/meson.build:10:5: ERROR: Function does not take positional arguments.
panels/camera/meson.build:10:5: ERROR: Function does not take positional arguments.
[...]
AdwActionRow handles many of the properties we use
CcListRow for. We can re-use it instead of re-creating it.
CcListRow is now an AdwActionRow with three suffixes.
The `activatable-widget` is set when the switch is visible.
Since our `icon-name` property was only used for the arrow
icon, it has been replaced with a `show-arrow` property.
The `bold` property has been removed - it was only used in
one place, and it's not a pattern used in other apps.
I decided to go this route because replacing all the
instances of CcListRow with AdwActionRow directly would
end up being more code.
- Remove visible=True properties from the UI file
- Use GtkPicture for the OS logo
- Drop gtk_dialog_run()
- Port gnome-control-center-print-renderer to GTK4
by using GdkSurface to create the GL context
gtk_image_set_from_icon_name() would fallback from $LOGO-text-dark to
$LOGO-text to $LOGO, leaving out $LOGO-dark which might be available.
Make sure it's in the list of possibilities by using
g_themed_icon_new_from_names() and listing it explicitly as a possible
icon name instead.
Fixes: a3b8964a19Closes: #1415
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
Make the logo non-square by setting its pixel size to -1. If (or when)
scaling the logo down is needed, we should instead use GtkIconTheme to
load the backing pixbuf, and use it to populate the GtkImage.
When loading the LOGO icon name from /etc/os-release, append -text to
prefer a textual variant of the logo if it exists, and -dark if the
theme variant is dark.
This allows distributors to ship textual and dark variants of their
logos without adding more fields to /etc/os-release, or more code
specific to logo handling for specific distributions.
$LOGO: default icon
$LOGO-dark: default icon when dark theme is used
$LOGO-text: icon with text
$LOGO-text-dark: icon with text when dark theme is used
With the new versioning scheme, GNOME just has major.minor versions
(e.g. 40.rc, 40.0) and micro versions are no longer used. Even if
gnome-desktop happens to get a micro version to fix a bug, it's not
something we should show in the UI.
By default info-overview panel shows the Gnome logo from a static
resource, currently every distro patches this component to show their logos
info-overview panel could use `/etc/os-release` file to fetch the OS logo
instead this static resource
Causes build errors linking against the builtin libhandy:
ninja: error: '/home/hadess/Projects/gnome-install/lib/libhandy-1.so', needed by 'panels/info-overview/gnome-control-center-print-renderer', missing and no known rule to make it
Not that it makes that much of a difference, but none of the GPUs we
listed were marked as the default one. The variable that holds the
boolean variant was also changed to make it clearer that it held the
value rather than was a value.
