ubuntu-phone team mailing list archive
-
ubuntu-phone team
-
Mailing list archive
-
Message #14887
Re: RFC- Having a bluetooth service to handle pairing
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Michael Zanetti wrote on 13/08/15 13:07:
>
> On 03.08.2015 11:30, Matthew Paul Thomas wrote:
>
> ...
>>
>> That incoming calls and wi-fi password entry are handled through
>> the notification system is a mistake. It means that without
>> changing the notification system itself, the incoming call
>> dialog can't be full-screen, or display the stored photo of the
>> contact calling you[1]; that third-party VoIP apps, if they
>> existed, couldn't do anything equivalent to the incoming call
>> dialog; that the wi-fi auth dialog can't do anything to prevent
>> you from submitting a password that can't possibly be correct[2];
>> that the dialog is incapable of showing connection progress, and
>> instead just disappears only to reappear seconds later if there
>> was an error[3]; that even then, it doesn't display an error
>> message[4]; and that you can't connect to an enterprise network
>> without opening System Settings[5], because the notification
>> system can't show dialogs that contain multiple text fields
>> and/or certificate pickers.
>
> I'm not saying that "abusing" the notification system is a good
> thing, but it is not correct that those things are not supported.
> Check out the unlock SIM PIN dialog. That's a notification too. It
> is full-screen, it has multiple text fields (retry count, SIM1/2
> indication) and it even supports additional signals to trigger
> warning dialogs on top of that notification.
>
> ...
I didn't say they are not "supported" (I avoid that word), but that
they require "changing the notification system itself".
Your example of SIM PIN unlocking demonstrates this: it is handled by
a hundred lines of code in the UI shell, devoted to the specific
notification type "com.canonical.snapdecision.pinlock".
<https://bazaar.launchpad.net/~unity-team/unity8/trunk/view/head:/qml/Notifications/NotificationMenuItemFactory.qml#L140>
For example, fixing "SIM PIN + passcode screens too similar"
<http://launchpad.net/bugs/1397963> would require changes to that code
in the notification system.
Since it involves unlocking the session itself, it's perhaps
reasonable for a UI shell to have code for handling passcodes and
passphrases. But not for declining a phone call with a text message,
or warning you that WEP is easily snooped on, or selecting a WPA
Enterprise FAST PAC file, or letting you choose which app to open a
particular URL with ... or validating Bluetooth device PINs.
- --
mpt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iEYEARECAAYFAlXMn3EACgkQ6PUxNfU6ecozsQCfdXzvdsEVfiCfhGIPYA7BKILf
jCgAoLhUt8/4yp5HtZjsT9sMDsiRUw56
=Zq6P
-----END PGP SIGNATURE-----
References
-
RFC- Having a bluetooth service to handle pairing
From: Sebastien Bacher, 2015-07-28
-
Re: RFC- Having a bluetooth service to handle pairing
From: Tony Espy, 2015-07-28
-
Re: RFC- Having a bluetooth service to handle pairing
From: Simon Busch, 2015-07-28
-
Re: RFC- Having a bluetooth service to handle pairing
From: Sebastien Bacher, 2015-07-28
-
Re: RFC- Having a bluetooth service to handle pairing
From: Simon Busch, 2015-07-28
-
Re: RFC- Having a bluetooth service to handle pairing
From: Sebastien Bacher, 2015-07-28
-
Re: RFC- Having a bluetooth service to handle pairing
From: Simon Busch, 2015-07-28
-
Re: RFC- Having a bluetooth service to handle pairing
From: Michael Zanetti, 2015-07-28
-
Re: RFC- Having a bluetooth service to handle pairing
From: Matthew Paul Thomas, 2015-08-03
-
Re: RFC- Having a bluetooth service to handle pairing
From: Michael Zanetti, 2015-08-13