| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add enum type generation code to the gir sources. This fixes enum types
showing up as 'undefined' in gjs.
The change did not impact Python.
--✀--
const {Gio, GLib, GnomeBluetooth, GObject} = imports.gi;
client = new GnomeBluetooth.Client();
client.connect('notify', () => {
print(client.default_adapter_state);
});
ml = new GLib.MainLoop(null, false);
ml.run()
--✀--
|
|
|
|
|
|
|
|
|
| |
Unfortunately, powering on/off Bluetooth adapters has become longer,
and less reliable over time, so front-ends need more information to
be able to figure out what it happening.
As a first pass, export whether the adapter is in the process of being
turned on, or turned off, based on our own request.
|
| |
|
|
|
|
|
| |
Better explain what _connect_service() does, so it's not used for
devices which can't be "connected" to.
|
|
|
|
|
| |
Can't really explain the purpose of this variable by just naming it, so
document it in the structure that defines it.
|
|
|
|
|
|
|
|
|
|
| |
Reorganise functions called from
_bluetooth_client_set_default_adapter_discovering() so that we only call
StartDiscovery() if SetDiscoveryFilter() is successful, and we disable
the "in-flight" ->discovery_started variable so the next default-adapter
changes would try to enable discovery again if needed.
Closes: #100
|
|
|
|
|
| |
When somebody requests the "default-adapter-setup-mode" to be disabled
but there's no default adapter, consider that we're not in setup mode.
|
|
|
|
|
|
|
|
|
|
|
| |
As recommended in the BluetoothClient documentation:
"
Note that #BluetoothClient::device-removed will not be called
for each individual device as the model is cleared when the
#BluetoothClient:default-adapter property changes.
"
Closes: #116
|
|
|
|
|
|
| |
Escape the device name/alias before using it as a label.
Closes: #115
|
|
|
|
| |
As supported by bluez in its MIDI plugin.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When an adapter is removed while bluetoothd is still running (eg. not
crashing as we also want to handle), suppress the emission of
device-removed so that front-ends don't think that every device is
removed.
We implement this by queue device-removed signals until the next
mainloop iteration instead of sending it straight away.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/1426
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5058
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix possible race between UPower and Bluez when creating the
BluetoothClient.
Bluetooth-DEBUG: Successfully created UpClient
Bluetooth-DEBUG: Got initial list of 2 UPower devices
Bluetooth-DEBUG: Considering UPower device /org/freedesktop/UPower/devices/mouse_dev_11_22_33_44_55_66
Bluetooth-DEBUG: Could not find bluez device for upower device /org/bluez/hci0/dev_11_22_33_44_55_66
Bluetooth-DEBUG: Considering UPower device /org/freedesktop/UPower/devices/mouse_dev_11_22_33_44_55_67
Bluetooth-DEBUG: Could not find bluez device for upower device /org/bluez/hci0/dev_11_22_33_44_55_67
Bluetooth-DEBUG: Adding adapters from ObjectManager
Bluetooth-DEBUG: Inserting adapter :1.2 /org/bluez/hci0 org.bluez.Adapter1
Bluetooth-DEBUG: Setting '/org/bluez/hci0' as the new default adapter
Bluetooth-DEBUG: Emptying list store as default adapter changed
Bluetooth-DEBUG: Coldplugging devices for new default adapter
Bluetooth-DEBUG: Adding device '11:22:33:44:55:66' on adapter '/org/bluez/hci0' to list store
Bluetooth-DEBUG: Adding device '11:22:33:44:55:67' on adapter '/org/bluez/hci0' to list store
Bluetooth-DEBUG: New default adapter so invalidating all the default-adapter* properties
The UpDevices are enumerated before we've even enumerated the Bluetooth
adapters, so we don't have any BluetoothDevices to attach the UpDevices
to. Wait until we've at least run through setting a default adapter
before enumerating the UPower devices.
|
|
|
|
|
|
| |
We have a private property to keep track of this already, let's use it
and bail out of _bluetooth_client_set_default_adapter_discovering() if
we're already discovering.
|
|
|
|
|
|
|
|
|
| |
Add missing gtk4 and libadwaita deps to the gnome-bluetooth-ui
pkg-config file. In reality, this didn't impact any software as the only
consumer of the UI library is gnome-control-center which already depends
on those 2 libraries.
Closes: #105
|
|
|
|
|
|
|
|
|
|
| |
On gcc < 11 and any version of clang (tested up to 13),
the build would fail with the following error:
error: label at end of compound statement
GCC 11+ seems to only complain with -Werror -Wpedantic,
otherwise it tolerates even completely empty default: case.
|
|
|
|
|
|
| |
The pairing-dialog was not added to GtkWindowClass' global list of
windows as we didn't call up to gtk_window_constructed(), so couldn't be
closed by gtk_window_destroy().
|
|
|
|
|
|
| |
Right now the pairing dialog doesn't open because we're not specifying
the correct parent class when creating the GtkDialog subclass, so fix
that.
|
|
|
|
|
|
|
|
|
|
| |
Due to a reference leak, libupower-glib could still callback into our
BluetoothClient even if it was already finalized as the signal handlers
were not forcibly disconnected when the BluetoothClient was.
See https://gitlab.freedesktop.org/upower/upower/-/merge_requests/112
Fixes: 983838f1
|
|
|
|
|
|
|
|
|
| |
With gtk4 the widget also has to be shown now, so do that.
While at it also make the dialog GTK_DIALOG_DESTROY_WITH_PARENT so it
gets destroyed when the parent window closes, and get rid of the
GMainLoop that made show_confirm_dialog() behave like a synchronous
function.
|
|
|
|
|
|
|
| |
Apparently in gtk4 the spinner needs to be actually started to show it.
While at it move the exclusive showing/hiding of the status widget and
spinner into label_might_change() instead of the double BIDIRECTIONAL
property bind.
|
|
|
|
|
| |
When the alias changes, we don't need to say that the adapter changed
power status.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Connect and monitor UPower devices for devices reporting their battery
status.
This makes sure that we can show battery status for devices
that emit their battery status through bluez (via the BATT LE service,
or the org.bluez.BatteryProviderManager1 API, as well as devices for
which the kernel is the battery info provider.
Closes: #102
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Now that libadwaita has the header-suffix property,
we can use AdwPreferencesGroup's built-in header.
|
|
|
|
|
|
|
| |
The property was forgotten in commit 6f611a67, which made the
connect button in the settings panel not work properly.
Fixes: 6f611a67
|
|
|
|
|
|
|
|
|
|
| |
Panels in g-c-c should be using these widgets wherever
possible. These are the widgets meant to be used
for boxed list panels, and libadwaita provides a
single source of truth for the styling.
The UI file will be further reduced once https://gitlab.gnome.org/GNOME/libadwaita/-/merge_requests/433
is merged.
|
|
|
|
|
| |
Significantly reduces the size of the UI file
and gives us consistent margins and padding.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
This will figure out whether there are any connected input devices, so
that gnome-shell (or gnome-control-center) can show a confirmation
dialogue before really turning things off.
Closes: #101
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Both UI and non-UI libraries export a pkg-config file. Only the non-UI
library exports a Gir as it's the only one that gets to be used from a
non-native program (gnome-shell).
|
|
|
|
|
| |
Remove the adapter power-up when a new default adapter is added. This
should avoid unwanted power-up on the adapter.
|
|
|
|
|
| |
This will be used when enabling Bluetooth (eg. disabling the Bluetooth
rfkill).
|
| |
|
|
|
|
|
|
|
|
|
| |
This makes sure that whether, say, hci1 is plugged in before starting
the programme using gnome-bluetooth, or after it's been started, the
default adapter will still be hci1.
The old behaviour could have caused discrepancies in what gnome-shell
(long-running) and gnome-control-center saw as the default adapter.
|
|
|
|
|
| |
"replacement" wasn't really a replacement, we were swapping a proxy for
a new one attached to the correct D-Bus owner.
|
|
|
|
|
|
| |
This would prefer hci1 as the default adapter, but that's already the
order in which g_dbus_object_manager_get_objects() returns the objects,
so it's more complicated code for the sake of clarity.
|
| |
|
| |
|
| |
|
|
|
|
| |
Add debug output when enabling or disabling discovery.
|