In the async version of the client creation, i.e. when a new client
is created via bolt_client_new_async and an error happens it will be
passed to g_task_return_error which takes ownership of it but the very
same error will also be free'd via g_autoptr; remove the latter.
This is a port of bolt commit e96f8bd47587b167ae46c8ac9347003f69f931dd
This reverts commit d2c759fcae.
The commit caused the Applications panel to crash with
Unhandled tag: <attributes>
Apparently CInfoRow doesn't know how to handle attributes.
Looks more natural this way. All buttons and links have been moved
into the main grid so this is possible. The links additionally had
to be removed all the padding so they actually align visually.
Closes: https://gitlab.gnome.org/GNOME/gnome-control-center/issues/238
Note that this also changes the way to detect that the connection is
currently active. This change is not required but but does simplify the
code a little bit.
In almost all cases, the SSID will be identical with the connection name
(in fact, we do not even allow modifying the connection name). However,
as it is now, we can end up with multiple connections with the same name
in the list.
Change the list to indicate the SSID separately in a way that will not
result in any changes in the usual case.
The code tries to establish a connect by using an existing connection.
However, if that is possible the function will not even be called.
Remove the code in question.
This adds a scale to change the color temperature from 3000K to
6000K. A mark is added to the default value and a second one for
aesthetics.
Initial implementation by Benjamin Berg
Color choices by Daniel Foré and elementary OS
Closes#147
Presumably, they are nonwritable because a system administrator has locked
these settings down.
https://help.gnome.org/admin/system-admin-guide/stable/dconf-lockdown.html
If Night Light is locked on, don't show the Off button.
If Night Light is locked off, don't show the Manual or "Sunset to Sunrise" buttons.
If Manual is force-enabled, don't show "Sunset to Sunrise" or the other way around.
The location support in flatpak is changing with the
next releases of geoclue and xdg-desktop-portal, and
the permission table is changing as well. Adapt to these
changes.
This may need some version check, or migration.
This is an initial implementation of most of the
intended functionality for this panel. Flatpak
integration itself is implemented by spawning
"flatpak info -m $appid", which gives us the
metadata in key file format, and allows flatpak
to be a runtime dependency.
Even after removing the .desktop suffix, there can
still be a difference between the app ID generated
in this way and the flatpak ID, since flatpaks are
allowed to export files whose prefix is the flatpak
ID. Fix this by pulling the X-Flatpak key out of
the desktop file. This would cause trouble for
org.libreoffice.LibreOffice-math.
gnome-user-accounts-panel.desktop has some differences in "Categories" in
comparison to other desktop files provided by gnome-control-center for no
obvious reason.
Add "GNOME" and "GTK" categories, which are used in all other desktop files.
Remove "System" and use just "Settings" main category. This among others
prevents the following output from desktop-file-validate:
/usr/share/applications/gnome-user-accounts-panel.desktop: hint: value
"System;Settings;X-GNOME-Settings-Panel;X-GNOME-DetailsSettings;" for key
"Categories" in group "Desktop Entry" contains more than one main
category; application might appear more than once in the application menu
All other desktop files uses just the "Settings" main category.
But maybe this is totally useless patch, because it seems that GNOME Shell
do not care about the most of categories and GNOME Classic do not show those
desktop files in menus at all.
In my testing, default orca didn't seem to read the "Hour" or "Minute"
words when we used accessible-name but it does work with
accessible-description.
This is the only place we used accessible-name in gnome-control-center
but we use accessible-description in a few other places.
This used to be done only if the stylus was "brand new", because pages for
previously known styli are added when the tablet is detected/plugged. There
are however situations where this may break: eg. the stylus was previously
known through a tablet that is not plugged ATM. The tool is however "not
new" so no UI is added for it.
We should try to add the stylus invariably on proximity, add_stylus_page()
ensures there is only one page per tool anyway.
Closes: https://gitlab.gnome.org/GNOME/gnome-control-center/issues/315
When the wacom driver handles the touch device, we get a tool id of 0x3. Let's
ignore that because we don't need a tool for the touch node.
Ideally we should be able to rely on the GDK tool type but that one is always
GDK_DEVICE_TOOL_TYPE_UNKNOWN see
https://gitlab.gnome.org/GNOME/gtk/merge_requests/453
A GTK bug (also fixed in that MR) prevents the tool id from updating.
Until that GTK bug is fixed the pen will only be detected if it is the first
event from this physical device. If the touch node sends an event before the
pen, the pen won't be detected.
When we bring a generic pen (serial 0) into proximity, the tool is initialized
as "generic" and mapped to the current tablet. This is then written out into
the keyfile, so we end up with something like:
[056a:00d1]
Styli=generic;
On the next g-c-c start the generic pen is pre-loaded from the keyfile but not
yet associated with the tablet. When the pen gets into proximity the
association was handled like a completely new pen, thus triggering a key file
entry again. Eventually, our styli list looked like this:
[056a:00d1]
Styli=generic;generic;generic;generic;generic;generic;
Fix this by remembering whether we freshly initialized the tool or whether it
was already known. Since we can only have one generic tool per tablet (because
we wouldn't notice the difference between two physical tools) we just skip the
write of the keyfile.
Fixes#313
The xf86-input-wacom driver doesn't use 0 for tools that do not have an id or
serials. Serials default to 1, and the tool id is either 0x2 for stylus or 0xa
for eraser, see xf86WacomDefs.h, the defines for STYLUS_DEVICE_ID and
ERASER_DEVICE_ID.
libwacom uses 0xfffff and 0xffffe for the generic pens and all the lookup code
we have in the panel is designed for a serial/tool id of 0. So let's just map
the wacom driver IDs to 0 at the only transition point between Gdk and our
panel.
No devices with serials 0 or hw ids 2/10 exist, so this shouldn't have side
effects. This only affects X + xf86-input-wacom.
