On 08/28/2012 05:53 PM, Gary Martin wrote:
Hi Simon,
On 28 Aug 2012, at 14:12, Simon Schampijer <[email protected]> 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.
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
diff --git a/src/jarabe/desktop/homewindow.py b/src/jarabe/desktop/homewindow.py
index c4f1401..840f19c 100644
--- a/src/jarabe/desktop/homewindow.py
+++ b/src/jarabe/desktop/homewindow.py
@@ -192,16 +192,19 @@ class HomeWindow(gtk.Window):
if level == ShellModel.ZOOM_HOME:
self._box.pack_start(self._home_box)
self._home_box.show()
+ self._toolbar.search_entry.set_text('')
self._toolbar.search_entry.grab_focus()
self._toolbar.show_view_buttons()
elif level == ShellModel.ZOOM_GROUP:
self._box.pack_start(self._group_box)
self._group_box.show()
+ self._toolbar.search_entry.set_text('')
self._toolbar.search_entry.grab_focus()
self._toolbar.hide_view_buttons()
elif level == ShellModel.ZOOM_MESH:
self._box.pack_start(self._mesh_box)
self._mesh_box.show()
+ self._toolbar.search_entry.set_text('')
self._toolbar.search_entry.grab_focus()
self._toolbar.hide_view_buttons()
_______________________________________________
Sugar-devel mailing list
[email protected]
http://lists.sugarlabs.org/listinfo/sugar-devel
