> > * intuitive use for new user ?
>
> Yes, the topbar is perhaps more intuitive than the sidebar.
> However,
> currently we have to explain the difference of when to use
> one versus
> the other, and we have to explain why it doesn't
> necessarily work
> correctly (because the topbar doesn't work always as
> expected and is
> limited in its ability). So, total confusion may be
> lessened by
> removing it.
2 examples I often use:
# List of spouses column on Person View, to search names matching four letters
# Dates column, to search a month on dates (letters)
Maybe to write a filter rule is also possible but less intuitive.
> > * maybe search is not to play with regex
>
> The only way to use regex is through the sidebar. Topbar
> doesn't allow regex.
Yes, sidebar cannot search some letters on strings without regex.
Topbar does not need regex for a quick match.
> > * to sort column is not the same as only display
> values (match).
>
> Sorting is independent of this issue. One still sorts by
> clicking on
> column name.
Without anymore search on date columns (topbar), a quick alternative will be to sort date columns and to look at date period. It is true that dates fields are already active (and more powerful) on sidebar, but this is the common sample of sort column as a search feature. Last modification, id, places columns are maybe a better samples on Person View.
> > * broken filter editor, means no more search.
>
> I'm not sure I understand this. If the filter editor is
> broken, then
> yes, it wouldn't work. Are you suggesting that we need the
> topbar as a
> backup? That doesn't seem like a good argument to keep it.
backup ... maybe just an alternative filter function !
But true, we do not need backup for custom_filter.xml
This works whatever Family Tree loaded.
Maybe we should re-enable system_filter.xml ?
http://www.gramps-project.org/bugs/view.php?id=2548
Jérôme
--- En date de : Dim 21.11.10, Doug Blank <doug.blank@...> a écrit :
> De: Doug Blank <doug.blank@...>
> Objet: Re: Re : [Gramps-devel] Proposal to remove topbar filter
> À: "jerome" <romjerome@...>
> Cc: "Gramps Development List" <gramps-devel@...>
> Date: Dimanche 21 novembre 2010, 19h13
> On Sun, Nov 21, 2010 at 12:31 PM,
> jerome <romjerome@...>
> wrote:
> >> Is there anything that would be lost by removing
> the topbar
> >> filter?
> >
> > * intuitive use for new user ?
>
> Yes, the topbar is perhaps more intuitive than the sidebar.
> However,
> currently we have to explain the difference of when to use
> one versus
> the other, and we have to explain why it doesn't
> necessarily work
> correctly (because the topbar doesn't work always as
> expected and is
> limited in its ability). So, total confusion may be
> lessened by
> removing it.
>
> > * maybe search is not to play with regex
>
> The only way to use regex is through the sidebar. Topbar
> doesn't allow regex.
>
> > * to sort column is not the same as only display
> values (match).
>
> Sorting is independent of this issue. One still sorts by
> clicking on
> column name.
>
> > * broken filter editor, means no more search.
>
> I'm not sure I understand this. If the filter editor is
> broken, then
> yes, it wouldn't work. Are you suggesting that we need the
> topbar as a
> backup? That doesn't seem like a good argument to keep it.
>
> > Do you plan to move search feature on sidebar ?
> > ie. instead of moving to filter framework, search bar
> could be like a simple search: Gramplet pane or Filter bar
> or Search bar into Sidebar ? User selects active one with
> the selector.
>
> No. One might create a Gramplet, but the proposal here is
> just to
> remove the topbar filter. The sidebar filter will act as it
> does in
> trunk.
>
> > http://www.gramps-project.org/wiki/index.php?title=Gramps_3.2_Wiki_Manual_-_Main_Window#Filters
>
> I hadn't read that section before. I suspect that the
> distinction
> between "search" and "filter" is completely arbitrary and
> invented to
> try to make sense of why we have two different, competing
> ways to do
> the same thing.
>
> Thanks for the clarifying questions,
>
> -Doug
>
> >
> >
> > Jérôme
> >
> >
> > --- En date de : Dim 21.11.10, Doug Blank <doug.blank@...>
> a écrit :
> >
> >> De: Doug Blank <doug.blank@...>
> >> Objet: [Gramps-devel] Proposal to remove topbar
> filter
> >> À: "Gramps Development List" <gramps-devel@...>
> >> Date: Dimanche 21 novembre 2010, 17h22
> >> Devs,
> >>
> >> Looking for some feedback on the following.
> >>
> >> Current situation: in each object view (Person,
> Family,
> >> Note, etc)
> >> there are two ways to do interactive filters: the
> topbar
> >> and the
> >> sidebar. These are mutually exclusive filters: you
> see
> >> either one or
> >> the other at all times.
> >>
> >> The topbar filter is the row above the columnar
> view, and
> >> allows you
> >> to select a current column, and enter text to
> search and
> >> match.
> >>
> >> The sidebar filter is activated when you check
> the
> >> "Sidebar" checkbox
> >> from menu -> "View". It is context-based,
> showing
> >> appropriate fields
> >> and filters given the active object view.
> >>
> >> One can filter on one filter method or the other,
> but not
> >> both
> >> together. More problematic, the two ways of
> filtering work
> >> slightly
> >> differently and each has things the other can't
> (currently)
> >> do.
> >>
> >> For example, the topbar filter only searches
> through the
> >> model
> >> attached to treeview. That probably makes this
> filter
> >> slightly faster
> >> (I didn't actually check, but it is reasonable to
> assume
> >> that it is
> >> slightly faster). On the other hand, it only uses
> >> text-based search.
> >> That means that "male" would match "female",
> unless we do
> >> some special
> >> handling (which we do). Also, the topbar filter
> doesn't do
> >> a proper
> >> date match, but only a date-text match. Finally,
> it doesn't
> >> search
> >> through all of a note, but only the "preview" (ie,
> the text
> >> that is
> >> actually showing).
> >>
> >> The sidebar filter doesn't provide "does not
> contain"
> >> filters.
> >> However, it uses the full power of the filter
> system, and
> >> in fact
> >> constructs a full Filter on the fly. This might be
> a bit
> >> slower as it
> >> runs through the database on disk, but it doesn't
> have any
> >> limitations
> >> (such as only search the first 80 characters of a
> note).
> >>
> >> The differences are subtle and hard to explain.
> >>
> >> I'm proposing to drop the topbar filter, and put
> some
> >> refinement on
> >> the sidebar filter. This would do a couple of
> things:
> >>
> >> 1) Make the codebase simpler. We could get rid of
> some
> >> code. It isn't
> >> a lot (as it is pretty general across all models).
> But
> >> there are some
> >> some special cases that have to be handled, and
> there might
> >> be some
> >> languages that don't work right.
> >>
> >> 2) Simplify the interface. By getting rid of the
> topbar
> >> filter, there
> >> becomes only one way to filter. That makes the
> interface,
> >> and the
> >> explanations, simpler. This is even more important
> as we
> >> move forward.
> >> Trunk has a new idea about the sidebar: not only
> will it
> >> hold the
> >> Sidebar Filter, but it could be switched to other
> sidebar
> >> plugins,
> >> such as a pane of Gramplets. I like this idea, and
> it seems
> >> to be
> >> about the best way that we have seen over the last
> year of
> >> experimentation of combining views. However,
> hiding the
> >> sidebar filter
> >> while a filter is active can make the interface
> even more
> >> confusing.
> >> We will need a way to clearly indicate that a
> filter is in
> >> use, even
> >> though the sidebar filter is not visible. Perhaps
> we could
> >> use the
> >> topbar location for a message "Filtered view.
> 23/1034
> >> records showing"
> >> (which we have a version of in the status bar, but
> could be
> >> missed).
> >>
> >> Is there anything that would be lost by removing
> the topbar
> >> filter?
> >> The "does not contain" option is (currently)
> harder to do
> >> via the
> >> sidebar filter (one has to create a filter and
> negate it).
> >> However,
> >> everything that the topbar filter does can be done
> with the
> >> sidebar.
> >> In addition, we could add a row to easily add the
> >> selection/text to
> >> the sidebar.
> >>
> >> Anything else to consider?
> >>
> >> -Doug
> >>
> >>
> ------------------------------------------------------------------------------
> >> Beautiful is writing same markup. Internet
> Explorer 9
> >> supports
> >> standards for HTML5, CSS3, SVG 1.1, ECMAScript5,
> and
> >> DOM L2 & L3.
> >> Spend less time writing and rewriting code and
> more
> >> time creating great
> >> experiences on the web. Be a part of the beta
> today
> >> http://p.sf.net/sfu/msIE9-sfdev2dev
> >> _______________________________________________
> >> Gramps-devel mailing list
> >> Gramps-devel@...
> >> https://lists.sourceforge.net/lists/listinfo/gramps-devel
> >>
> >
> >
> >
> >
>
|