hi,
On Mon, Oct 1, 2012 at 11:03 AM, Tomasz Bursztyka <
[email protected]> wrote:
> 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.
>
Cant we just return an different error for hard blocked ? the UI can
interpret the state acc to the error then.
>
> #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
Cheers,
Alok.
>
> ______________________________**_________________
> connman mailing list
> [email protected]
> http://lists.connman.net/**listinfo/connman<http://lists.connman.net/listinfo/connman>
>
_______________________________________________
connman mailing list
[email protected]
http://lists.connman.net/listinfo/connman
