So you essentially encountered the same issues as I have. You want a "freeze list" button, I argue that the freezing should be the default. Not the entire list appeared: sounds like a bug and I hope such things will get fixed, but I don't think they should stop us from planning on doing the right thing.
On Tue, Nov 27, 2012 at 12:25 PM, Zoffix Znet <[email protected]> wrote: > > Just wanted to add my experience with this exact problem: > > It wasn't in a train, but in a mall's parking lot. I haven't counted the > number of access points, but it looked like enough to have a couple of > screens to scroll through. > > I was trying to find an open access point, but the list kept refreshing. > I forget now whether the list would scroll to the top, or just rearrange > all the access points (or add new ones it found), but I do remember > every time it refreshed, I was lost in the list. > > Not the entire list appeared in the popup right away (not sure why—I > wasn't moving), so disabling update when popup is open might not be > feasible. > > At the time, I wished there were a "freeze list" button somewhere, so > once it updated with something you wish to browse through, you could > just stop the list from updating until you unfreeze the list by clicking > that button again. > > My two cents. > > ZZ > > > > > On Tue, 2012-11-27 at 10:34 +0000, Tom Hacohen wrote: > > Sounds like a good suggestion, and that will surely be nice, but I don't > > think it solves our issue for people who just want to run through the > list > > finding an open wifi. As for everyone who said 30 wifis are too much > anyway > > and etc., maybe I was wrong and it was 20, I was just assessing, but the > > list was long, too long. > > I don't understand why you are against having a list that doesn't refresh > > while it's open (and possibly has an indication that shows that it's no > > longer up to date or whatever. The only case where this will actually be > a > > problem is when you are on a train/car/whatever that wifis actually > > significantly change, because if wifis just disappear because of low > > reception they are not relevant anyway and refreshing the list or not > would > > not matter. > > > > > > On Mon, Nov 26, 2012 at 5:00 PM, Bruno Dilly <[email protected]> > wrote: > > > > > 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 > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > 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 > -- Tom. ------------------------------------------------------------------------------ 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
