[RFC] Changes to Bluetooth device selection dialog
Berthold Stoeger
bstoeger at mail.tuwien.ac.at
Sun Nov 5 13:59:07 PST 2017
Dear all,
I tried to modify the behavior of the Bluetooth (BT) device selection dialog
and would need some feedback. Unfortunately, BT is highly platform dependent
and I have no idea how this behaves with non-Bluez 5 backends.
The idea was that when I activate the BT device selection dialog I certainly
don't want an empty list of devices. Because that means that I have to click
"Scan" in all cases. Ideally, I'd immediately get the BT devices known to the
OS (especially the paired ones). It seems that Qt does not provide such a list
(an API defect?). But looking into the Qt Bluez5 backend of
QBluetoothDeviceDiscoveryAgent, these devices are collected synchronously in
the start() method.
The first patch therefore simply does a start()/stop() pair, which is of course
horrible because it uses undocumented behavior, but has precisely the intended
effect. I didn't bother to figure out the Objective-C MacOS code - perhaps
there you would get the same effect with a short BLE timeout?
The second patch is a trivial code clean up and independent of the others.
The third patch adds "Aladin" to the list of recognized BT names and exports
the getDeviceType() function. This is a preparation for the next patch.
The fourth patch came from the idea that I'd want the previous selection
retained. So what it does is preselecting a device according to priority:
1st: previously selected device
2nd: a known dive computer name
3rd: paired device
Non-paired devices are never selected.
I'm not really happy about the code. It has also to be noted that this patch
might lead to the undesired behavior that a user selects a device and the UI
overrules the user's selection if a higher-priority device is detected later
on. This situation seems quite unlikely but nevertheless the patch might need
some refinement.
The fifth patch makes the Save button the "default button" of the dialog. This
has the effect that pressing enter does not discard the selection of the user.
This patch might also be done with QDialogButtonBox(?), but here I opt for the
less intrusive change.
Thank you,
Berthold
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Initialize-Bluetooth-device-list.patch
Type: text/x-patch
Size: 1570 bytes
Desc: not available
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20171105/fb009abe/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-Remove-unnecessary-NULL-test.patch
Type: text/x-patch
Size: 1260 bytes
Desc: not available
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20171105/fb009abe/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-Add-Aladin-to-the-list-of-recognized-BT-names.patch
Type: text/x-patch
Size: 1976 bytes
Desc: not available
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20171105/fb009abe/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0004-Automatically-select-item-in-Bluetooth-device-select.patch
Type: text/x-patch
Size: 8415 bytes
Desc: not available
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20171105/fb009abe/attachment-0003.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0005-BT-device-selection-dialog-make-Save-the-default-but.patch
Type: text/x-patch
Size: 1051 bytes
Desc: not available
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20171105/fb009abe/attachment-0004.bin>
More information about the subsurface
mailing list