Merge lp://staging/~ken-vandine/ubuntu-system-settings/bluetooth_lp1535660 into lp://staging/ubuntu-system-settings

:)

FAILED: Continuous integration, rev:1584
http://jenkins.qa.ubuntu.com/job/ubuntu-system-settings-ci/2578/
Executed test runs:
    UNSTABLE: http://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-vivid-touch/6087
    SUCCESS: http://jenkins.qa.ubuntu.com/job/ubuntu-system-settings-vivid-amd64-ci/352
    SUCCESS: http://jenkins.qa.ubuntu.com/job/ubuntu-system-settings-vivid-i386-ci/761
    UNSTABLE: http://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-runner-vivid-touch/4698
    SUCCESS: http://jenkins.qa.ubuntu.com/job/generic-mediumtests-builder-vivid-armhf/6098
        deb: http://jenkins.qa.ubuntu.com/job/generic-mediumtests-builder-vivid-armhf/6098/artifact/work/output/*zip*/output.zip
    SUCCESS: http://s-jenkins.ubuntu-ci:8080/job/touch-flash-device/26822

Click here to trigger a rebuild:
http://s-jenkins.ubuntu-ci:8080/job/ubuntu-system-settings-ci/2578/rebuild

thanks but the spec states

"If a device is of a type that Ubuntu Touch does not currently work with, it should be present (so that you don’t think there’s a problem with the hardware) but greyed out and with a ⛔ no entry icon (bug 1419866)."

don't we need that enum to define what devices are working or not?

Sorry, this isn't meant to be merged yet, just getting debs.

Although we've been talking about dropping isSupportedType completely, with new LE devices we never know the type before they are connected. We won't be able to support those as we have things now.

FAILED: Continuous integration, rev:1585
http://jenkins.qa.ubuntu.com/job/ubuntu-system-settings-ci/2579/
Executed test runs:
    UNSTABLE: http://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-vivid-touch/6104
    SUCCESS: http://jenkins.qa.ubuntu.com/job/ubuntu-system-settings-vivid-amd64-ci/353
    SUCCESS: http://jenkins.qa.ubuntu.com/job/ubuntu-system-settings-vivid-i386-ci/762
    UNSTABLE: http://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-runner-vivid-touch/4712
    SUCCESS: http://jenkins.qa.ubuntu.com/job/generic-mediumtests-builder-vivid-armhf/6115
        deb: http://jenkins.qa.ubuntu.com/job/generic-mediumtests-builder-vivid-armhf/6115/artifact/work/output/*zip*/output.zip
    SUCCESS: http://s-jenkins.ubuntu-ci:8080/job/touch-flash-device/26851

Click here to trigger a rebuild:
http://s-jenkins.ubuntu-ci:8080/job/ubuntu-system-settings-ci/2579/rebuild

Who is "we"? I haven't seen anything about needing to change the design of Bluetooth settings, or anything about devices being misidentified other than bug 1521518.

What is it about Bluetooth LE that makes a device unidentifiable?

If we don't know what type a device is, how can we do anything useful with it? How do we decide whether to use it as a mouse, a storage device, or a loudspeaker?

In the meantime, I'm disapproving of this (however much that counts) because it would lead to more bugs like bug 1419866.

Approved per discussion today.

it's a bit frustrating that this mp got a good explanation of issues with the change and then is changed to "approved" because some private discussion happened somewhere, could you at least update the public record explaining what changed the status compared to the previous rejected comment?
meanwhile I'm not convinced it's a good move so marking the change as disapproved

> it's a bit frustrating that this mp got a good explanation of issues with the
> change and then is changed to "approved" because some private discussion
> happened somewhere, could you at least update the public record explaining
> what changed the status compared to the previous rejected comment?
> meanwhile I'm not convinced it's a good move so marking the change as
> disapproved

Sorry about that, it was discussed in our settings weekly meeting today. There are two arguments in favor of this change:

1) New BTLE devices appear to be of type Network until after they are paired, once paired we know the specific type. Specifically we have people with new mice and keyboards that they can't pair.

2) Our criteria for what is supported is really based on what we have a profile for and can be used with our existing stack. However, who's to say in the future there might not be third party apps that can make use of some of these other types? Allowing these types to be paired should work fine, even if there is no app or backend that uses the device yet.

thanks for the update, that makes sense, it still feels suboptimal that we can't know the type before pairing and so display the right icon, but if that's what the bluetooth stack provides us then it is what it is...

While researching this I had a quick browse through the Bluetooth LE HID spec. Those devices, at least, can provide an icon specific to the device. I don't know how many of them do, and whether they're high-quality enough to bother with. But if the answers are "most" and "usually", we might end up rarely showing the device type icon anyway.