Comment 18 for bug 1267135

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.