Hi Jussi,
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?
#1 and #3 does not even work right now. Actually #1 works so it lists
the hw supported by connman (builtin or plugin).
But you might not even have drivers for it, so it won't be possible to
get it enabled (my patches does not fix that issue anyway, there is an
issue to solve here)
And #3 because API 1.0 does not propose anything about that.
#2 the problem is that, if hw rfkilled, there is a bug (which is fixed
in this patch then) that you "can" enable the technology (soft unblock)
and connman
thinks everything is fine, can start scanning (if wifi) or else...
completely bogus behavior.
Same thing if no backend is running (wpa_s for wifi or bluez for bt):
the technology is present but can't be enabled (of course) and the api
does not help much, again.
So what's the point of displaying a technology that you can't play with
anyway?
In 1.0, I don't see why we should expose technologies hw rfkilled if
nothing is made in the API to tell about this hw switch.
At least, for now, my fix makes it "more sane", for this version of the API.
In the scope of API 1.0, your proposal is impossible to get. It could be
relevant for the 2.0 though.
But I would then go for a technology property (boolean HardBlocked or
about) instead of an error,
so you could disable the widget and tell to the user (through an info
bullet for instance) what he is required to do.
You don't want an error, it's not really an error, just a configuration
issue (hw switch).
For the rest: no driver, no backend, yes I would go for an error maybe.
However, being too careful with the user, from UI point of view is
something that can be argued. I mean, how come the user does not know
about his machine hw switch?
At least if he does not see any wifi technology, he will look around his
laptop and learn by himself that
"hey, turning this switch on/off makes it available or not, nice".
(plus: he will think he is smart! bonus).
No, seriously we need to discuss about that, but it's about API 2.0 then.
Tomasz
_______________________________________________
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman
