On Mon, Oct 1, 2012 at 1:03 PM, Tomasz Bursztyka
<tomasz.burszt...@linux.intel.com> wrote:
>> 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).
Yes, this sounds sane, and pretty much what I actually meant when I
inaccurately said "if we have the HW for it": I meant "list the
technologies that could realistically at some point be used with
current hardware".
> 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?
Consistency. Removing any evidence that the device is wifi-capable is
just wrong. Not exposing the hw-block state to UI is wrong as well and
now that you mention it, I think I've complained about it before :)
If you can't make #3 happen, then I (assuming I was a UI developer)
would much more appreciate keeping #1 working and making sure the call
to enable hw-rfkilled technologies fail as early as possible, and
documenting that. At least then it's possible to make a UI that
suggest checking if there's a HW switch in case of enable failing.
> 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?
>From this comment I assume you've not seen user tests... People just
don't understand the connections between these things. They may find
the rfkill HW switch and be able to put the machine in flight mode,
and later they may be absolutely dumbfounded when they can't enable
wifi via the UI (or in your suggested version, they'd be totally
surprised to not find Wifi anywhere in the UI).
It's happened to me as well. Thinkpad X61 had the rfkill switch hidden
underneath the front of the laptop and it was quite easy to switch it
on by accident. The first time that happened I spent a long while
trying to figure out why the wifi was no longer working. I wish the UI
would have told me about the switch.
Jussi
_______________________________________________
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman
