Hi Simon, On 29 Aug 2012, at 12:41, Simon Schampijer <si...@schampijer.de> wrote:
> On 08/28/2012 05:53 PM, Gary Martin wrote: >> Hi Simon, >> >> On 28 Aug 2012, at 14:12, Simon Schampijer <si...@schampijer.de> wrote: >> >>> On 08/28/2012 02:14 PM, Manuel Quiñones wrote: >>>> So now the filtering is shared between the three views. I think this >>>> is worth noting in the commit message. >>> >>> Thanks for the review and catching this! I did note it in the commit >>> message before pushing. >>> >>> Gary, we did discuss the following: >>> >>> There seem to be three options how the search now that we have a search >>> entry in each view could work: >>> >>> - if you did a search in View A and then switch to View B the entry will be >>> cleared leaving you with no search applied in B >>> >>> - if you did a search in View A and then switch to View B the search from A >>> will be applied to B (behavior which landed in 0.97.2) >>> >>> - if you did a search in View A and then switch to View B the search from A >>> will not be applied in B, if you switch back to A the search you did before >>> in A has been cached and is still applied (behavior before 0.97.2) >> >> Thanks for raising this change! I'll need to give it some more though and >> test the patches. >> >> My gut reaction so far would be for the clearing behaviour, > > You can use the attached patch to test that behavior. I think I like that > behavior as well. Preferred over caching, as you say it may lead to > unexpected behaviors. > > second choice would be the caching behaviour. My reasons against the 0.97.2 > behaviour change would be that different views contain dissimilar enough > objects that a search in one is not often useful in another (e.g. searching > for a buddy or access point, and switching to home), and that will drop the > user in an unexpected UI state. A reason for clearing the search when > switching views is that it prevents issues for novice users who leave a query > in place unintentionally, and return to find a view in an unexpected state > without realising they need to clear the old search query manually. Though so > far, caching previous search queries in a view is just what we've been doing > in the shell. FWIW: home list view is the worst offender as it shows a blank > white canvas when a query has no matches, should really behave like the > Journal with the 'No matching entries' UI. The 0.97.2 change may well lead to > an increase in "my icons are all grey/gone" type support reports, especially > from young users who may randomly press keys and generate a shel query > without realising it. >> > > Thanks Gary, good catch about the needed feedback in the list view, filed as > [1] (feel free to add there wordings/icon to use etc). Once the shell port is > done, it should be straight forward to add. Fab. Done. Have added a mockup screen shot and comment to the ticket. Regards, --Gary > Btw, re Activity list view. We said at one point that the date displayed in > the list has not much meaning (at least at the moment). Did we have an idea > for a replacement? > > Thanks, > Simon > > [1] http://bugs.sugarlabs.org/ticket/3838 > <view_toolbar_search_behavior.patch> _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
