On 11/26/2012 10:55 PM, Bruno Dilly wrote: > On Mon, Nov 26, 2012 at 12:16 PM, Lucas De Marchi > <[email protected]> wrote: >> On Mon, Nov 26, 2012 at 12:08 AM, Bruno Dilly <[email protected]> wrote: >>> On Sun, Nov 25, 2012 at 9:57 PM, Gustavo Sverzut Barbieri >>> <[email protected]> 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... > > 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). > So the list wouldn't be cleared and repopulated everytime. It should > make users life easier too.
You could do what nm-applet does. They usually have a submenu (like "More ->"), where they add new wifi while scanning, unless they find a wifi that you have connected to previously, which they add to the main list. The main list also contains a small number of other wifi that was found quickly. ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
