On Wed, 2009-07-08 at 16:39 -0700, Xu, Martin wrote:
> >I have to agree here. That is not what we want. When the user connects
> >successfully to a network/service then this just means that this becomes
> >one of the services the others wants us to use. If that service is for
> I do not agree with it.
>
> If user clicks connect button of one service, normally, what he want is just
> to connect it BUT make it favorite. If ConnMan auto-connect to other service
> it will puzzle user, if user does not know ConnMan is in auto-mode.
If you click on a given network, like an open network called 'Guest',
then that network is now marked as a favorite, right? Why would the
auto-connection logic attempt to break that connection and connect to
some other network? Auto-connect would never break a working connection
just because some other network shows up, would it?
Also... wouldn't that new favorite network start out life at the top of
the favorite's list? Basically, all new friends start out as my best
friend.
> Think of Guest network, if user connect to Guest network at office, that
> means he/she just want to use this network to get http services outof intel.
> But if there is a higher order service existing, he/she can never
> successfully connect to Guest.
Selecting a specific network should attempt to connect to that network.
If the auto-connect logic trumps this then it's broken.
> You may say use DD to drag the Guset to the highest order, but with higher
> order service exist we even can not let Guest connected and be the favorite
> one.
If the auto-connection logic trumping my every move, regardless of what
I ask my device to do, then that would really suck. Please don't do
that.
> That really make user confusing.
>
> >one reason or another no longer available we have to go ahead and
> >connect to different one.
> >
> >So there is a difference with disconnect and remove. When calling remove
> >the user clearly has no longer interest in that service and we don't
> >care about it anymore. When calling disconnect, it means that the user
> >doesn't wanna use it right now. However it is okay to auto-connect it
> >again next time. For example if the default service gets disconnected.
> >
> >We don't wanna have the user to switch modes. We have to make this
> >decision for the user. Exposing the user to a concept of manual and
> But that decision is not easy and makes ConnMan complicated user confusing.
>
> >automatic mode is a bad idea from an experience point of view. It is
> >just way too complex and the user should not be bothered with these
> >details anyway.
>
> I really do not think manual and auto mode is a bad idea.
> 1. auto/manual mode is quite quit easy to be understood by user.
We will just have to agree to disagree on this one. The UI design for
carrick also doesn't expose this type of concept, which would make the
implementation rather interesting.
> 2. We can show the manual/auto mode at UI, let user know which mode it is in
I'm sure it's possible to design a UI to expose this, but its not the UI
design we are targeting for Moblin v2.
> 3. If user know it is at auto mode she/he will not confusing that system will
> helped to switch automatically
> 4. If user know switch to manual mode she/he will know that he/she can
> control connecting totally. In many case we can not and quite difficult to
> help user to chose the manual/auto mode. And sometimes user just want manual
> mode.
>
> Marcel/Rusty:
> Please carefully think about it again. Whether we really can not add the two
> modes?
> In fact, I have created several patches to resolve the new find issues
> without importing manual auto mode. But I am not sure that is really what we
> wanted.
> If you stick to your opinions, I will send it out, and let you review, I am
> just afraid that it will make ConnMan too complicated.
Marcel is the maintainer for Connman. I'm just providing feedback...
but, I'm not convinced.
--rusty
_______________________________________________
connman mailing list
[email protected]
http://lists.connman.net/listinfo/connman
