From: Robert K. <ro...@sp...> - 2012-11-26 16:28:41
|
> From: "Lucas De Marchi" <luc...@pr...> > To: "Enlightenment developer list" <enl...@li...> > Sent: Monday, November 26, 2012 6:16:17 PM > Subject: Re: [E-devel] Connman module suggestion > > On Mon, Nov 26, 2012 at 12:55 PM, Bruno Dilly <bd...@pr...> > wrote: > > On Mon, Nov 26, 2012 at 12:16 PM, Lucas De Marchi > > <luc...@pr...> wrote: > >> On Mon, Nov 26, 2012 at 12:08 AM, Bruno Dilly > >> <bd...@pr...> wrote: > >>> On Sun, Nov 25, 2012 at 9:57 PM, Gustavo Sverzut Barbieri > >>> <bar...@pr...> wrote: > >>>> On Sunday, November 25, 2012, Tom Hacohen wrote: > >>>> > >>>>> Not when you have 30 wifis in the same area. This makes things > >>>>> just > >>>>> impossible. If there's a bug in connman/the module, it should > >>>>> be fixed, but > >>>>> usability ATM is just crap. > >>>> > >>>> > >>>> > >>>> It's in wpa_supplicant that scans, emits a signal and connman > >>>> sends another > >>>> and we show it > >>> > >>> It's right, but... it's possible to handle that in our module, > >>> setting > >>> a timer while the popup is open. Something like: > >>> > >>> popup_open_cb() > >>> ... > >>> module_data->allow_list_update = EINA_FALSE > >>> ecore_timer_add(config_time, _allow_update, module_data) > >>> > >>> > >>> _allow_update(module_data) > >>> module->allow_list_update = EINA_TRUE > >>> return EINA_FALSE > >>> > >>> > >>> _connman_update_cb(module_data) > >>> if (!module_data->allow_list_update) > >>> return /* bad */ > >>> update_popup_list(module_data) > >>> module_data->allow_list_update = EINA_FALSE > >>> ecore_timer_add(config_time, _allow_update, module_data) > >>> > >>> > >>> The line tagged as bad is bad because if I remember correctly, > >>> connman > >>> will just send us a signal after something changes (network is > >>> removed > >>> / added / list sorted), > >>> so we can be discarding a change that happened between a > >>> config_time > >>> frametime and the outdate information will > >>> persist in our list for a long time. > >> > >> No.... don't do this. We could maintain the popup list not > >> synchronized with connman's list. However discarding updates to > >> the > >> *connman* list will open cans of worms. > > > > OK, that's exactly what the second version does =) > >> > >> So, if we are going to implement this delay, it should be only in > >> the > >> update_popup_list() function, not in econnman.c. > >> > > > > Right, that's what is done just below: > > > >>> > >>> So maybe a better would be: > >>> popup_open_cb() > >>> ... > >>> module_data->allow_list_update = EINA_FALSE > >>> module_data->popup_list_outdated = EINA_FALSE > >>> ecore_timer_add(config_time, _allow_update, module_data) > >>> > >>> > >>> _allow_update(module_data) > >>> if (module_data->popup_list_outdated) > >>> update_popup_list(module_data) > >>> module_data->popup_list_outdated = EINA_FALSE > >>> return EINA_TRUE > >>> module->allow_list_update = EINA_TRUE > >>> return EINA_FALSE > >>> > >>> > >>> _connman_update_cb(module_data) > >>> update_module_data_list(module_data) /* update internal list, > >>> not > >>> the popup list*/ > >>> if (!module_data->allow_list_update) > >>> module_data->popup_list_outdated = EINA_TRUE > >>> return > >>> update_popup_list(module_data) > >>> module_data->allow_list_update = EINA_FALSE > >>> ecore_timer_add(config_time, _allow_update, module_data) > >>> > >>> > >>> And we would need to make sure everything would work fine with > >>> this lists > >>> out of sync. Also timer should be properly deleted when popup is > >>> closed, etc. > >>> > >>> But I definitely don't like the proposal of not updating the list > >>> while the popup is open. > >> > >> I don't either. However if you have 30+ services, you'll have a > >> hard > >> time finding the service you want because: > >> > >> 1) If signal strengths change in such a way that services are > >> reordered, the popup list will be deleted and recreated > >> 2) If networks are added/removed, the popup list will be deleted > >> and recreated. > >> > >> And this (I think) implies that the list will scroll back to the > >> initial position. It's not a problem for simpler cases, but it > >> really > >> is when you are in a public place with lots of wifi APs. > >> > >> So, IMO what needs to be done is to either delay updates *to popup > >> list* when popup is open. Or even doesn't allow it at all. However > >> the > >> second approach seems bad for my daily use of opening the popup > >> and > >> waiting for the service to show up. > > > > This second approach is crappy. You would need to open / close the > > popup list > > many times until you see the service you want... > > this is what is being currently done. not something I'm proposing to > do. > > We have a list of services deleted, but we don't have a list of > services addded. They are mixed with the current ones. Of course we > could compare the current list with the new one to check if there > were > services added or if it was only a reordering update. > > > > > > Actually there are other ways to handle this situation. > > Like just removing / adding networks, not sorting them again. > > I believe just removing / adding items to a list widget wouldn't > > mess > > with its scroll (not 100% sure about it). > > AFAIR, we did this in the previous connman module, comparing the > lists.... and it suffered the same problem. > > > > So the list wouldn't be cleared and repopulated everytime. It > > should > > make users life easier too. > > > > But I would go with the second version of the solution I've > > proposed. > > agreed, > > Lucas De Marchi > Sorry to butt in, but how bout filtering the huge list of networks based on entry text ? Chances are that you will know what the network you are looking for is called, or have an idea, so typing the 1st few chars should be enough to limit any kind of chaos into a few potential networks. Something in the lines of everything module, or even a plugin for the everything module. Just a thought, feel free to ignore :) |