[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