On Mon, Nov 26, 2012 at 2:28 PM, Robert Krambovitis <[email protected]> wrote: >> From: "Lucas De Marchi" <[email protected]> >> To: "Enlightenment developer list" >> <[email protected]> >> 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 <[email protected]> >> 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... >> >> 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 :)
Sounds like a valid proposal for me as well. > > ------------------------------------------------------------------------------ > 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 -- Bruno Dilly Lead Developer ProFUSION embedded systems http://profusion.mobi ------------------------------------------------------------------------------ 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
