network-indicator should provide the "Please enter SIM PIN" text

[Albert Astals Cid]

We are showing the "Please enter SIM PIN" text ourselves but according to Saviq it should come from the indicator and not be in our code.

[Matthew Paul Thomas (mpt)]

Who's "We"?

Why does Saviq think it should be in the networking indicator code?

With the current design, on the PC a cellular modem might invoke a SIM PIN dialog from the networking menu or from System Settings. But on the phone, the only user-invoked SIM PIN UI is in System Settings.

[Albert Astals Cid (aacid)]

we is unity8 sorry.

[Michał Sawicz (saviq)]

"We" are unity8.

At least right now, the "Unlock SIM" menu entry is in the network indicator menu - and the network indicator service monitors the cellular connection - and it's that service that will trigger the SIM PIN dialog.

If it's the System Settings that will trigger the dialog, it's System Settings that needs to provide the labels - unity8 should have no knowledge of those strings.

[Antti Kaijanmäki (kaijanmaki)]

Where exactly is this "Please enter SIM PIN" shown in unity8 ATM?

I haven't looked at the design, so please bare with me if something below is wrongly stated.
(mpt, can you point me to the relevant design specs?)

There are multiple use cases where different apps/components need to be able to direct the user to the PIN dialog, as an example:
 - upon boot, some component (greeter?) needs to direct the user to enter the pin
 - dialer app needs to detect and inform the user that you can't place a call when SIM is locked
 - same for SMS app
 - indicator-network is also a logical place to show this information and access the pin dialog

In any case there should be just one service which takes care of the PIN handling and that service also must provide the means for other components to trigger the dialog for convenience. This one service can be indicator-network-service or it could be a standalone pin service. I need to check the specs, though.

[Michał Sawicz (saviq)]

It's shown... in the SIM PIN dialog, when you click the "Unlock SIM" entry in the network menu (temporary).

See the attached screenshot.

The one service that was supposed to handle this was meant to be indicator-network-service indeed. And that's how it is now. We don't have all the use cases yet (even in greeter the initial dialog should be triggered by the network indicator, only we need to wait for it to not show any other UI).

[Antti Kaijanmäki (kaijanmaki)]

saviq: thanks for the screenshots :)

indicator-network-service can't have any custom UI of it's own. It can only request some other component (be it the shell, greeter or some app) to show the pin dialog.
The dialog (UI) itself either
A) has to be part of the shell (or the greeter)
B) be an "standalone" application

The pin dialog it self needs to access information from the modem like which type of code is required (PIN, PIN2, PUK, PUK2, etc..) and how many attempts are available, etc.

AFAIK we don't have a requirement for a lock-code right now (think of password in a screensaver) but I would not be surprised that we need to implement it later and most probably it will look just like the PIN dialog. Therefore I would say the UI for the dialog can not be a standalone application as it might need to be modal for the lock-code case.

[Michał Sawicz (saviq)]

Yeah, the UI *is* part of unity8 already, and will remain so. Just the hardcoded string needs to be moved away into whoever invokes that dialog.

[Matthew Paul Thomas (mpt)]

Sorry for my mistake. I had forgotten that the network menu includes "Unlock SIM…" when the SIM is locked. <https://wiki.ubuntu.com/Networking#phone-indicator>

But the normal case is for the unlock dialog to appear on startup. <http://goo.gl/wtXjqx>

And as I mentioned, the dialog can also be invoked from System Settings if you turn on the PIN. <https://wiki.ubuntu.com/SecurityAndPrivacySettings#SIM_PIN>

I'm not an engineer, but it's a bit odd to me that two of those three bits of code should have to supply an identical "Enter SIM PIN" string. If you decided to improve the string later, you'd need to remember to change it in both places. Seems to me that the string belongs in the same place as the logic for the dialog -- the code that provides the "Incorrect PIN. %d attempts remaining." string, that makes the button insensitive when the PIN field contains an implausible number of digits, and so on. System Settings would then override the title and button text for its "Enter Previous PIN" dialog, but any other call-site would get the default text.

[Michael Zanetti (mzanetti)]

I tend to agree with Matthew here. The notification only opens that dialog if there is a x-canonical-simpin flag in the notification. So imho the text should be added there.

I don't see a point in changing it in a way where every caller needs to create a notification with the x-canonical-simpin flag AND the text.

[Michał Sawicz (saviq)]

On 10.01.2014 11:47, Matthew Paul Thomas wrote:
> I'm not an engineer, but it's a bit odd to me that two of those three
> bits of code should have to supply an identical "Enter SIM PIN" string.
> If you decided to improve the string later, you'd need to remember to
> change it in both places. Seems to me that the string belongs in the
> same place as the logic for the dialog -- the code that provides the
> "Incorrect PIN. %d attempts remaining." string, that makes the button
> insensitive when the PIN field contains an implausible number of digits,
> and so on. System Settings would then override the title and button text
> for its "Enter Previous PIN" dialog, but any other call-site would get
> the default text.

Thing is "the logic" doesn't live with the UI, unity8 doesn't know what a SIM PIN is, nor how to supply it back to the SIM, nor how to query the SIM for how many remaining tries there are until you b0rk your SIM card. There needs to be a service (which right now is indicator-network) that deals with the SIM card. And System Settings will talk to that service when dealing with the SIM PIN. The "%d attempts remaining" string won't belong to unity8 either, but to the service that actually knows how to determine however many attempts are, in fact, remaining. The problem with unity8 holding the default text with domain knowledge (SIM) is that suddenly you have the translation for it spread between indicator-network and unity8. The fact alone that "Enter Previous PIN" needs to override the default string means that it needs to be *able* to come from the caller (which, right now, it cannot). Sure, we can have a default one (that IMO should not contain the word "SIM"), but services that use it can't rely on the fact that we won't change that default - they need to have control, and so should provide all the strings displayed in a dialog it controls.

On 10.01.2014 12:07, Michael Zanetti wrote:
> I tend to agree with Matthew here. The notification only opens that
> dialog if there is a x-canonical-simpin flag in the notification. So
> imho the text should be added there.
>
> I don't see a point in changing it in a way where every caller needs to
> create a notification with the x-canonical-simpin flag AND the text.

Well, IMO the hint shouldn't be named "-simpin", really, since it also allows for entering a PUK code, and generally unity8 should have no idea what kind of PIN is that. Let alone what a SIM is. See above also that that's not the only string that's meant to be displayed there.

[Michał Sawicz (saviq)]

There is also the "Emergency Call" label and button, which shouldn't even be there in the "I'm changing my PIN" scenario should it?

I'm fine with "Emergency Call" string being in unity8, because it holds no knowledge over what technology is used, and as long as the caller will be able to disable it, it's fine. I don't think there's need to change that string ever, either.

[Matthew Paul Thomas (mpt)]

Sure, this string does not belong in unity8. But that does not necessarily mean it belongs in indicator-network. For example, we might decide in future that the SIM unlock screen should have no indicators at all. When switching on your phone, it would be annoying if you still had to wait for indicator-network to start up, not because it was going to appear yet, but solely because it contained some of the SIM unlock UI!

This reminds me of update-notifier on PC, which has outlived its UI for five years now, because people inserted sundry unrelated code in there in the belief that it would always be running.

I'm surprised to learn of the existence of "x-canonical-simpin", and I have two followup questions.

1. After you enter the PUK code, you need to enter and then confirm a new SIM PIN. If we decided to put those two PIN fields in the same dialog, would that require code changes in unity8?

2. In the wi-fi prompt <https://wiki.ubuntu.com/Networking#wifi-connecting-prompted>, the "Connect" button should change to "Connect…" whenever the selected network is a secure one. Would that involve code in unity8?

If the answer to those questions is yes, the problem here isn't just a string.

[Michał Sawicz (saviq)]

On 13.01.2014 12:35, Matthew Paul Thomas wrote:
> Sure, this string does not belong in unity8. But that does not
> necessarily mean it belongs in indicator-network. For example, we might
> decide in future that the SIM unlock screen should have no indicators at
> all. When switching on your phone, it would be annoying if you still had
> to wait for indicator-network to start up, not because it was going to
> appear yet, but solely because it contained some of the SIM unlock UI!

Well, *some* service needs to start up that talks to the SIM card. It
might as well be indicator-network service (even if there's not going to
be any indicator UI on the screen).

--8<--

> 1. After you enter the PUK code, you need to enter and then confirm a
> new SIM PIN. If we decided to put those two PIN fields in the same
> dialog, would that require code changes in unity8?

Yes, it's unity8 that displays the UI, so it needs to support that use case.

> 2. In the wi-fi prompt <https://wiki.ubuntu.com/Networking#wifi-
> connecting-prompted>, the "Connect" button should change to "Connect…"
> whenever the selected network is a secure one. Would that involve code
> in unity8?

Yes, unity8 needs to support the caller of the snap decision changing
that label.

> If the answer to those questions is yes, the problem here isn't just a
> string.

Why is that?

[Matthew Paul Thomas (mpt)]

indicator-network will likely become, if it is not already, the most complex indicator code-wise. If it can integrate tethering, VPNs, Bluetooth connections, and anything else nm-applet handles that I don't know about yet, and still launch near-instantly and reliably, then my worry about it providing the SIM PIN UI may be unfounded.

Consider this scenario, though: A couple of years from now, a bug is discovered where a broadcast Wi-Fi network with a particular name crashes indicator-network. (Maybe it's extremely long, maybe it contains non-UTF8 bytes, whatever.) Even if an update was issued to fix the bug, whenever someone with a SIM PIN on their phone was in range of that network, they wouldn't even be able to unlock their phones to turn off Wi-Fi, let alone install the update! Hopefully it wouldn't be a city-wide network...

Anyway, just moving the string wouldn't alter the fact of code specific to the SIM PIN dialog being present in unity8. That's why I asked the followup questions: it seems that this is the case for every dialog that happens not to cover the screen. Is that right?

For example, the "Show password" checkbox in the full-screen "Other network" screen in System Settings can be implemented entirely in ubuntu-system-settings -- but implementing exactly the same checkbox in the dialog for authenticating to a broadcast network (as invoked from either indicator-network or System Settings) involves completely different code in unity8.

Similarly, the graph of battery charge is currently implemented entirely inside ubuntu-system-settings -- but if we wanted to replicate that graph, or anything like it, inside the "Battery Low" warning dialog, we'd need completely different code in unity8.

Is that right? If so, maybe we should fix that. Copying or moving some UI into a dialog should not involve rewriting part of it inside the OS shell code. Especially since whether something is a sheet or a dialog will depend on its screen size. Sometimes the same UI (like the Print UI, for example) will be a sheet on a phone, but a dialog on a tablet.

[Michał Sawicz (saviq)]

On 13.01.2014 18:05, Matthew Paul Thomas wrote:
> indicator-network will likely become, if it is not already, the most
> complex indicator code-wise. If it can integrate tethering, VPNs,
> Bluetooth connections, and anything else nm-applet handles that I don't
> know about yet, and still launch near-instantly and reliably, then my
> worry about it providing the SIM PIN UI may be unfounded.
>
> Consider this scenario, though: A couple of years from now, a bug is
> discovered where a broadcast Wi-Fi network with a particular name
> crashes indicator-network. (Maybe it's extremely long, maybe it contains
> non-UTF8 bytes, whatever.) Even if an update was issued to fix the bug,
> whenever someone with a SIM PIN on their phone was in range of that
> network, they wouldn't even be able to unlock their phones to turn off
> Wi-Fi, let alone install the update! Hopefully it wouldn't be a city-
> wide network...

That would be true regardless of *what* handled the SIM PIN, whether
it's the network indicator or anything else.

> Anyway, just moving the string wouldn't alter the fact of code specific
> to the SIM PIN dialog being present in unity8. That's why I asked the
> followup questions: it seems that this is the case for every dialog that
> happens not to cover the screen. Is that right?

System-wide dialogs / notifications / snap decisions are displayed by
the shell, yes - driven by whatever service needs them. That's because
the services themselves can't display anything on screen (or should not,
for that matter). If there's a dialog that's part of an application, it
will be displayed inside that application's surface (on Touch, that is).

> For example, the "Show password" checkbox in the full-screen "Other
> network" screen in System Settings can be implemented entirely in
> ubuntu-system-settings -- but implementing exactly the same checkbox in
> the dialog for authenticating to a broadcast network (as invoked from
> either indicator-network or System Settings) involves completely
> different code in unity8.
>
> Similarly, the graph of battery charge is currently implemented entirely
> inside ubuntu-system-settings -- but if we wanted to replicate that
> graph, or anything like it, inside the "Battery Low" warning dialog,
> we'd need completely different code in unity8.
>
> Is that right? If so, maybe we should fix that. Copying or moving some
> UI into a dialog should not involve rewriting part of it inside the OS
> shell code. Especially since whether something is a sheet or a dialog
> will depend on its screen size. Sometimes the same UI (like the Print
> UI, for example) will be a sheet on a phone, but a dialog on a tablet.

We already have a place that shares UI code between unity8 and
ubuntu-system-settings: lp:ubuntu-settings-components [1]. We might
still need to move more components there, but we're using that - and are
ready for more, already.

[1] https://code.launchpad.net/ubuntu-settings-components
--
Michał (Saviq) Sawicz <email address hidden>
Canonical Services Ltd.

[Michał Sawicz (saviq)]

On 13.01.2014 18:05, Matthew Paul Thomas wrote:
> indicator-network will likely become, if it is not already, the most
> complex indicator code-wise. If it can integrate tethering, VPNs,
> Bluetooth connections, and anything else nm-applet handles that I don't
> know about yet, and still launch near-instantly and reliably, then my
> worry about it providing the SIM PIN UI may be unfounded.
>
> Consider this scenario, though: A couple of years from now, a bug is
> discovered where a broadcast Wi-Fi network with a particular name
> crashes indicator-network. (Maybe it's extremely long, maybe it contains
> non-UTF8 bytes, whatever.) Even if an update was issued to fix the bug,
> whenever someone with a SIM PIN on their phone was in range of that
> network, they wouldn't even be able to unlock their phones to turn off
> Wi-Fi, let alone install the update! Hopefully it wouldn't be a city-
> wide network...

That would be true regardless of *what* handled the SIM PIN, whether
it's the network indicator or anything else.

> Anyway, just moving the string wouldn't alter the fact of code specific
> to the SIM PIN dialog being present in unity8. That's why I asked the
> followup questions: it seems that this is the case for every dialog that
> happens not to cover the screen. Is that right?

System-wide dialogs / notifications / snap decisions are displayed by
the shell, yes - driven by whatever service needs them. That's because
the services themselves can't display any

> For example, the "Show password" checkbox in the full-screen "Other
> network" screen in System Settings can be implemented entirely in
> ubuntu-system-settings -- but implementing exactly the same checkbox in
> the dialog for authenticating to a broadcast network (as invoked from
> either indicator-network or System Settings) involves completely
> different code in unity8.
>
> Similarly, the graph of battery charge is currently implemented entirely
> inside ubuntu-system-settings -- but if we wanted to replicate that
> graph, or anything like it, inside the "Battery Low" warning dialog,
> we'd need completely different code in unity8.
>
> Is that right? If so, maybe we should fix that. Copying or moving some
> UI into a dialog should not involve rewriting part of it inside the OS
> shell code. Especially since whether something is a sheet or a dialog
> will depend on its screen size. Sometimes the same UI (like the Print
> UI, for example) will be a sheet on a phone, but a dialog on a tablet.

We already have a place that shares UI code between unity8 and
ubuntu-system-settings: lp:ubuntu-settings-components [1].

[1] https://code.launchpad.net/ubuntu-settings-components
--
Michał (Saviq) Sawicz <email address hidden>
Canonical Services Ltd.

[Matthew Paul Thomas (mpt)]

> That would be true regardless of *what* handled the SIM PIN, whether
> it's the network indicator or anything else.

If anything else handled the SIM PIN, I could enter it without the network indicator running, then I could turn off wi-fi in System Settings again without the network indicator running.

To summarize, I think:
1) unity8 should not contain any specific code for the SIM PIN dialog, because it has nothing to do with the shell in particular, and dialogs in general belong in the toolkit rather than the shell;
2) indicator-network should not contain any specific code for the SIM PIN dialog (even though it is one of the access points for the dialog), because indicator-network should not need to be running when the dialog is shown;
3) therefore, the code should be in a separate SIM service.

This SIM service might also be responsible in future for displaying appropriate UI when a SIM is inserted, removed, or remotely locked.

[Antti Kaijanmäki (kaijanmaki)]

Matthew Paul Thomas (mpt) wrote on 2014-01-17:
> 1) unity8 should not contain any specific code for the SIM PIN dialog...
> 2) indicator-network should not contain any specific code for the SIM PIN dialog...

https://bugs.launchpad.net/indicator-network/+bug/1302049
https://bugs.launchpad.net/unity-notifications/+bug/1306769

unity8 needs to have some specific code as PIN dialog and greeter lock screen are special. Unity8 does not need to know about the specific dialogs, but it has to offer a way for doing hard modal dialogs.

> 3) therefore, the code should be in a separate SIM service.

Yep. That's the plan.

[Antti Kaijanmäki (kaijanmaki)]

Now, just concentrating on the original bug, I'm working on getting rid of the hard coded string in unity8/qml/Notifications/NotificationMenuItemFactory.qml

[Launchpad Janitor (janitor)]

This bug was fixed in the package unity8 - 8.00+14.10.20141008-0ubuntu1

---------------
unity8 (8.00+14.10.20141008-0ubuntu1) utopic; urgency=low

  [ Michael Zanetti ]
  * Dual SIM pin unlocking. Hook up the UI to the backend. (LP:
    #1267135)

  [ Antti Kaijanmäki ]
  * Dual SIM pin unlocking. Hook up the UI to the backend. (LP:
    #1267135)

  [ Ubuntu daily release ]
  * New rebuild forced
 -- Ubuntu daily release <email address hidden> Wed, 08 Oct 2014 09:41:32 +0000