On Fri, Sep 28, 2012 at 3:35 PM, Tomasz Bursztyka
<[email protected]> wrote:
> Hi,
>
> While playing around with enabling/disabling technology I found out that if a
> technology is hardblocked through the physical switch,
> first the technology is still listed in GetTechnologies, but of course
> enabling it
> from dbus API will lead to nothing. User HAS to play with the physical switch.
>
> In order not to mess up the user with it, patch 1 and 2 make so a technology
> is not given to the user if it's hardblocked.
> So if a technology is shown and disabled: it's just soft block. user can
> change that through dbus api.
>
> Technically, this means not registering the technology as a dbus object. And
> hardblock on will throw TechnologyRemoved(), and
> hardblock off a TechnologyAdded().
I've not followed connman that closely recently, so it's entirely
possible I'm missing something. Anyway, previous UX requirements in
this area were:
1. list the technologies that we have the hardware for
2. allow enabling/disabling (blocking/unblocking) by user if possible
3. if unblocking is not possible in SW, let the user know ("Wifi is
disabled, please check the 'Wifi' or 'Airplane mode' button on your
computer")
These still seem like reasonable requests and it looks like your
proposal would prevent #1 and #3 (I cannot remember if #3 was possible
previously with connman). I think removing a Technology in particular
sounds very wrong. How do you make a consistent UI when Wifi can just
stop existing if the user happens to accidentally move a HW switch?
- Jussi
_______________________________________________
connman mailing list
[email protected]
http://lists.connman.net/listinfo/connman
