Marcel Holtmann <mar...@holtmann.org> writes: > Hi Kalle,
Hi Marcel, >> When I experimented this on my laptop, it took few seconds to get the >> association state from the connect call. So from user's point of view it >> there was an annoying delay between selecting a connection and starting >> animation. > > I think your UI is broken. The Connect() method will not return until > connected. Yeah, maybe my code was still using synchronous calls at that and hence broken. I tried to reproduce it now with two different processes and I got the event almost instantly, just like everyone said. >> > I did mention that these *Technology properties might go away in favor >> > of technology object paths. In there we could have potentially (I am >> > still no 100% convinced) a State property that combines this and is >> > similar to what we have on a per service level. >> >> Oh, I hope you will still keep the technology properties around for a >> while (at least for our 10.10 release), because we are now relying on >> these interfaces. > > They most likely stay, but in the end you get proper object path with > Technology interface. Oh, that sounds good. >> > The State property of the manager stays online/offline since that is >> > suppose to be used be 3rd party applications and not the main connection >> > manager UI. >> >> I just think that the application interface should be separated from the >> UI interface. The needs are different between the two. >> >> And besides, having offline/connecting/online would not be a disaster >> from application point of view. They should just ignore the connecting >> state, unless they are interested about it. > > Once you are done with your UI then you will see that this is pointless > and will not make any UI simpler. Been there, done it, got a t-shirt for > it. Really look at the ConnMan history and you will see that at some > point of time we had exactly this. I thought it was a good idea in the > beginning, but it is rather pointless. I trust you on this one :) > Basically if you need it, then your UI is broken. I don't need the connecting signal, I just think that it would make it simpler for UI. No need to go through all services and check theirs state etc. But let's forget this, at least for now. >> > Btw. there is some magic in ConnMan when it comes to default SSIDs like >> > linksys etc. We treat them individual. So they are per BSSID actually to >> > not accidentally roam with your neighbor. For everything else we expect >> > that roaming is wanted. No exceptions. If you don't want roaming then >> > name your AP accordingly. >> >> Oh, I had totally missed functionaly, which is pretty wicked IMHO. Is >> this really needed? And how user differentiate between the similar named >> networks when choosing the connection? > > Mainly it is signal strength and luck. And hopefully at some point users > realize to name their access point properly and also encrypt them. > > However there is no different to just allow the user to do roaming > between these vendor default SSID. You still might accidentally get your > neighbors without knowing. My worry is that there is no way for the user to know about this. Some kind of warning would be nice, or somehow show in the UI that specific bssid is used or something. -- Kalle Valo _______________________________________________ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
