gramps

> Is there anything that would be lost by removing the topbar
> filter?

* intuitive use for new user ?
* maybe search is not to play with regex
* to sort column is not the same as only display values (match).
* broken filter editor, means no more search.

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.

http://www.gramps-project.org/wiki/index.php?title=Gramps_3.2_Wiki_Manual_-_Main_Window#Filters



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
>

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
>>
>
>
>
>

> > * 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
> >>
> >
> >
> >
> >
>

Another difference between topbar and sidebar filters:

When using topbar filter, the text must match the text in the column
as shown. In the sidebar filter, it more than likely uses the database
data without regard to how a field is currently displayed.

For example, if you use "Surname, G" in the topbar with "Name
contains:" selected, and the Name Display set appropriately, you'll
match "Surname, Given". However, in the sidebar filter, the text must
match either the given or the surname, but can't be used to match both
parts, and works in the same manner without regard to the Name
Display.

If we do get rid of the topbar filter, we should spend a bit of time
to make sure that the sidebar filters capture most of the uses of the
topbar.

-Doug

I think removing the topbar search facility would be a bad idea (TM). I
frequently use the search facility as a very quick way to narrow down a
large number of entries. In contrast, I didn't really know that the filter
sidebar existed (although now you mention it, I may have seen references to
it on gramps-devel), and I have certainly never used it. The filter sidebar
takes up a lot of space in the window, whereas the search is very compact. 

If you want to simplify the interface, then I would much prefer you removed
the filter sidebar instead! If it were to be removed then I seriously doubt
it would be noticed except by real power users like developers.

If you think it provides useful functionality that will be missed then what
about adding 'custom filter' to the bottom of the top filter drop-down, and
allowing the user to specify one of the filters he had defined in the filter
editor. After all, if you remove the top filter, and someone wanted to do a
negative filter, then the amount of work needed would be about the same.
[Presumably if you select custom filter, then the type-in box beside the
drop-down would contain the name of the selected filter].
-- 
View this message in context: http://gramps.1791082.n4.nabble.com/Proposal-to-remove-topbar-filter-tp3052501p3052818.html
Sent from the GRAMPS - Dev mailing list archive at Nabble.com.

Greetings All:

I know that the topbar filter is a quick and dirty example to narrow down
your records, but as you pointed out yourself, that it can NOT do multiple
field searches!  I am a , minor developer, who spends very little time in
coding and most of my time in searching and researching of my family tree!
Since I finally did turn on the sidebar/ filter, it has become such an
invaluable tool and resource for me.  I do NOT know how I got along without
it for so long...

*I totally disagree with removing the sidebar/ filter!!!*  I, do, support
the idea of removing the topbar filter though...

With the sidebar/ filter, I can complete a search in the events for example:

1) All Marriage events
2) bet 1908 and 1953
3) in Ohio state

and it is done!  This is not only an example, but it is one of the searches/
filtering that I wanted to do because of a website out that that provides
marriage certificates with that creiteria!

Example 2:
* I am looking for a particular person named Benjamin and he was born in
1829... I can do this in the PeopleView using the filter sidebar!

I would be COMPLETELY LOST if you removed the filter/ sidebar!  It is an
unmentionable idea!

As previously spoken to Doug and Nick, it does need to be upgraded though to
have more options than just one in the interface/ configuration settings!  I
do want the filter/ sidebar open at all times in PeopleView,FamilyView,
EventView, PlaceView, SourceView, MediaView, NoteView, and RepositoryView.
I do not want it open in GrampletView, RelationshipView, AncestryView,
Geoview, and HtmlView!

I would also love to see being able to have a place where I can attach/ dock
some of the most used gramplets too!  I do not know where they should go
though?  Doug says that they can go in the same space as the filter/ sidebar
though...

As ststed before, I am 100% agreeable to removing the topbar search!

Sincerely yours,
Rob G. Healey


On Sun, Nov 21, 2010 at 1:39 PM, Tim Lyons <guy.linton@...> wrote:

>
> I think removing the topbar search facility would be a bad idea (TM). I
> frequently use the search facility as a very quick way to narrow down a
> large number of entries. In contrast, I didn't really know that the filter
> sidebar existed (although now you mention it, I may have seen references to
> it on gramps-devel), and I have certainly never used it. The filter sidebar
> takes up a lot of space in the window, whereas the search is very compact.
>
> If you want to simplify the interface, then I would much prefer you removed
> the filter sidebar instead! If it were to be removed then I seriously doubt
> it would be noticed except by real power users like developers.
>
> If you think it provides useful functionality that will be missed then what
> about adding 'custom filter' to the bottom of the top filter drop-down, and
> allowing the user to specify one of the filters he had defined in the
> filter
> editor. After all, if you remove the top filter, and someone wanted to do a
> negative filter, then the amount of work needed would be about the same.
> [Presumably if you select custom filter, then the type-in box beside the
> drop-down would contain the name of the selected filter].
> --
> View this message in context:
> http://gramps.1791082.n4.nabble.com/Proposal-to-remove-topbar-filter-tp3052501p3052818.html
> Sent from the GRAMPS - Dev mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> 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
>

2010/11/21 Tim Lyons <guy.linton@...>

>
> I think removing the topbar search facility would be a bad idea (TM). I
> frequently use the search facility as a very quick way to narrow down a
> large number of entries. In contrast, I didn't really know that the filter
> sidebar existed (although now you mention it, I may have seen references to
> it on gramps-devel), and I have certainly never used it. The filter sidebar
> takes up a lot of space in the window, whereas the search is very compact.
>
> If you want to simplify the interface, then I would much prefer you removed
> the filter sidebar instead! If it were to be removed then I seriously doubt
> it would be noticed except by real power users like developers.
>
> If you think it provides useful functionality that will be missed then what
> about adding 'custom filter' to the bottom of the top filter drop-down, and
> allowing the user to specify one of the filters he had defined in the
> filter
> editor. After all, if you remove the top filter, and someone wanted to do a
> negative filter, then the amount of work needed would be about the same.
> [Presumably if you select custom filter, then the type-in box beside the
> drop-down would contain the name of the selected filter].
>

This shows a bit the current problem. Because there is a topbar, people
don't realize there is a much more powerful sidebar present.
Suggesting to remove it clearly shows you never used it :-)

Anyway, this question mainly comes down to: if people know about the
sidebar, would they still use the topbar?
In my case, I very, very, very rarely use the topbar, I always activate the
sidebar and do the search. This however also shows I normally remove the
sidebar again afterwards to have more things on the screen.
I don't like the idea of a dialog for search much. This is not a texteditor,
but search on a column view, no need to block the view somehow with a
dialog.

Benny

--
> View this message in context:
> http://gramps.1791082.n4.nabble.com/Proposal-to-remove-topbar-filter-tp3052501p3052818.html
> Sent from the GRAMPS - Dev mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> 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
>

Benny Malengier wrote:
> 
> I don't like the idea of a dialog for search much. This is not a
> texteditor,
> but search on a column view, no need to block the view somehow with a
> dialog.
> 

Sorry, my fault, I confused things by the way I mentioned top filter in my
argument. I think you have misunderstood.

Personally I don't think there is much needing a change. Even though I know
about the sidebar, I will still use the topbar.

What I meant was, If you want to make a change, then:
(a) remove the side filter,
(b) leave the top filter exactly as it is, except
(c) add 'custom filter' to the bottom of the top filter drop-down, and
allowing the user to specify one of the filters he had defined in the filter
editor
(d) if the user selects the custom filter, then the filter name he selects
could be displayed in the top filter where the filter criterion is normally
displayed.


-- 
View this message in context: http://gramps.1791082.n4.nabble.com/Proposal-to-remove-topbar-filter-tp3052501p3053387.html
Sent from the GRAMPS - Dev mailing list archive at Nabble.com.

> I don't like the idea of a dialog for search much.
> This is not a texteditor, but search on a column view, no need to block the view somehow with a dialog.

Then maybe, to move fields and buttons from topbar to ToolBar ? which is more a View bar because it is rebuild when we switch from one view to an other one! And to rename Toolbar to View bar (also for GeoView).


Jérôme

--- En date de : Lun 22.11.10, Tim Lyons <guy.linton@...> a écrit :

> De: Tim Lyons <guy.linton@...>
> Objet: Re: [Gramps-devel] Re : Proposal to remove topbar filter
> À: gramps-devel@...
> Date: Lundi 22 novembre 2010, 11h38
> 
> 
> Benny Malengier wrote:
> > 
> > I don't like the idea of a dialog for search much.
> This is not a
> > texteditor,
> > but search on a column view, no need to block the view
> somehow with a
> > dialog.
> > 
> 
> Sorry, my fault, I confused things by the way I mentioned
> top filter in my
> argument. I think you have misunderstood.
> 
> Personally I don't think there is much needing a change.
> Even though I know
> about the sidebar, I will still use the topbar.
> 
> What I meant was, If you want to make a change, then:
> (a) remove the side filter,
> (b) leave the top filter exactly as it is, except
> (c) add 'custom filter' to the bottom of the top filter
> drop-down, and
> allowing the user to specify one of the filters he had
> defined in the filter
> editor
> (d) if the user selects the custom filter, then the filter
> name he selects
> could be displayed in the top filter where the filter
> criterion is normally
> displayed.
> 
> 
> -- 
> View this message in context: http://gramps.1791082.n4.nabble.com/Proposal-to-remove-topbar-filter-tp3052501p3053387.html
> Sent from the GRAMPS - Dev mailing list archive at
> Nabble.com.
> 
> ------------------------------------------------------------------------------
> 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
>

Thanks for all of the feedback!

It seems all of the arguments so far have been about the UI, which is
fine. That suggests that we can get rid of the two different ways of
functioning and collapse that down to just one (the way that sidebar
works, perhaps with some niceties added). That would get rid of having
to explain differences.

The problem remaining, then, is how to make a consistent UI that could
use either a simple, topbar filter, or something more (and even
suggest to users that there is something more powerful available).

Some ideas:

1) Have a simplified topbar available for single entry, simple filters
(either a single column, or a single custom filter).
2) This might require that every field have associated with it a
filter (so that date columns would be searched by the date logic,
"male" would not match "female", note would search the entire text,
etc)
3) More complex filters could be available by having a "+" button in
the topbar, which would bring up a dialog (not sidebar). That would
prevent real estate from being eaten up. The topbar would become a
button indicating that a more complex filter is in effect. Clicking it
would bring up the dialog (which used to be the sidebar filter).
4) This would integrate the topbar/sidebar as the topbar would be a
simplified version of the full dialog, and only shown when the dialog
isn't.
5) This also removes some of the complexity by just making the sidebar
a dialog, which is either opened or closed, and makes it so that its
showing is independent of the gramplet pane. (As an aside, the full
filter dialog could be dockable in the gramplet pane, which would give
nearly the current appearance of the sidebar filter).

Does anyone see any issue with that type of strategy?

-Doug

On Mon, Nov 22, 2010 at 5:38 AM, Tim Lyons <guy.linton@...> wrote:
>
>
> Benny Malengier wrote:
>>
>> I don't like the idea of a dialog for search much. This is not a
>> texteditor,
>> but search on a column view, no need to block the view somehow with a
>> dialog.
>>
>
> Sorry, my fault, I confused things by the way I mentioned top filter in my
> argument. I think you have misunderstood.
>
> Personally I don't think there is much needing a change. Even though I know
> about the sidebar, I will still use the topbar.
>
> What I meant was, If you want to make a change, then:
> (a) remove the side filter,
> (b) leave the top filter exactly as it is, except
> (c) add 'custom filter' to the bottom of the top filter drop-down, and
> allowing the user to specify one of the filters he had defined in the filter
> editor
> (d) if the user selects the custom filter, then the filter name he selects
> could be displayed in the top filter where the filter criterion is normally
> displayed.
>
>
> --
> View this message in context: http://gramps.1791082.n4.nabble.com/Proposal-to-remove-topbar-filter-tp3052501p3053387.html
> Sent from the GRAMPS - Dev mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> 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
>

2010/11/22 Doug Blank <doug.blank@...>

> Thanks for all of the feedback!
>
> It seems all of the arguments so far have been about the UI, which is
> fine. That suggests that we can get rid of the two different ways of
> functioning and collapse that down to just one (the way that sidebar
> works, perhaps with some niceties added). That would get rid of having
> to explain differences.
>
> The problem remaining, then, is how to make a consistent UI that could
> use either a simple, topbar filter, or something more (and even
> suggest to users that there is something more powerful available).
>
> Some ideas:
>
> 1) Have a simplified topbar available for single entry, simple filters
> (either a single column, or a single custom filter).
> 2) This might require that every field have associated with it a
> filter (so that date columns would be searched by the date logic,
> "male" would not match "female", note would search the entire text,
> etc)
> 3) More complex filters could be available by having a "+" button in
> the topbar, which would bring up a dialog (not sidebar). That would
> prevent real estate from being eaten up. The topbar would become a
> button indicating that a more complex filter is in effect. Clicking it
> would bring up the dialog (which used to be the sidebar filter).
> 4) This would integrate the topbar/sidebar as the topbar would be a
> simplified version of the full dialog, and only shown when the dialog
> isn't.
> 5) This also removes some of the complexity by just making the sidebar
> a dialog, which is either opened or closed, and makes it so that its
> showing is independent of the gramplet pane. (As an aside, the full
> filter dialog could be dockable in the gramplet pane, which would give
> nearly the current appearance of the sidebar filter).
>
> Does anyone see any issue with that type of strategy?
>

It is hard to envisage what you mean.
I suppose the gramplet pane can be closed also.

Technically I know very good how topbar/sidebar relates to the view as I
rewrote that with Nick for 3.2. The changes you want to do go deep in the
core code and are not that simple.

What is the global strategy?

1. We still have the problem in trunk that Geoview is broken with panes.
That needs a solution, meaning several of us will have to try and fix that.
Serge thinks it is a Gtk bug...
2. We want the navigation bar to the left, view center, and a general
docking area to the right. Correct?
3. Listviews have a search option shown via topbar or filter bar, geoview a
sidebar search possible.
4. Topbar search remains but uses the filter infrastructure instead of the
view model/column data
5. Sidebar search becomes a dialog that is dockable in the general docking
area?

Note that above can be done without having to do 4., that is, it remains
possible to keep searching in the columns. Tim's remark gives a hint quite
some people are using it.

If above is done, best would be to do it in parts. So first 1, the 2/5, ..

Benny

>
> -Doug
>
> On Mon, Nov 22, 2010 at 5:38 AM, Tim Lyons <guy.linton@...> wrote:
> >
> >
> > Benny Malengier wrote:
> >>
> >> I don't like the idea of a dialog for search much. This is not a
> >> texteditor,
> >> but search on a column view, no need to block the view somehow with a
> >> dialog.
> >>
> >
> > Sorry, my fault, I confused things by the way I mentioned top filter in
> my
> > argument. I think you have misunderstood.
> >
> > Personally I don't think there is much needing a change. Even though I
> know
> > about the sidebar, I will still use the topbar.
> >
> > What I meant was, If you want to make a change, then:
> > (a) remove the side filter,
> > (b) leave the top filter exactly as it is, except
> > (c) add 'custom filter' to the bottom of the top filter drop-down, and
> > allowing the user to specify one of the filters he had defined in the
> filter
> > editor
> > (d) if the user selects the custom filter, then the filter name he
> selects
> > could be displayed in the top filter where the filter criterion is
> normally
> > displayed.
> >
> >
> > --
> > View this message in context:
> http://gramps.1791082.n4.nabble.com/Proposal-to-remove-topbar-filter-tp3052501p3053387.html
> > Sent from the GRAMPS - Dev mailing list archive at Nabble.com.
> >
> >
> ------------------------------------------------------------------------------
> > 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
> >
>
>
> ------------------------------------------------------------------------------
> 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
>

On Mon, Nov 22, 2010 at 7:51 AM, Benny Malengier
<benny.malengier@...> wrote:
>
>
> 2010/11/22 Doug Blank <doug.blank@...>
>>
>> Thanks for all of the feedback!
>>
>> It seems all of the arguments so far have been about the UI, which is
>> fine. That suggests that we can get rid of the two different ways of
>> functioning and collapse that down to just one (the way that sidebar
>> works, perhaps with some niceties added). That would get rid of having
>> to explain differences.
>>
>> The problem remaining, then, is how to make a consistent UI that could
>> use either a simple, topbar filter, or something more (and even
>> suggest to users that there is something more powerful available).
>>
>> Some ideas:
>>
>> 1) Have a simplified topbar available for single entry, simple filters
>> (either a single column, or a single custom filter).
>> 2) This might require that every field have associated with it a
>> filter (so that date columns would be searched by the date logic,
>> "male" would not match "female", note would search the entire text,
>> etc)
>> 3) More complex filters could be available by having a "+" button in
>> the topbar, which would bring up a dialog (not sidebar). That would
>> prevent real estate from being eaten up. The topbar would become a
>> button indicating that a more complex filter is in effect. Clicking it
>> would bring up the dialog (which used to be the sidebar filter).
>> 4) This would integrate the topbar/sidebar as the topbar would be a
>> simplified version of the full dialog, and only shown when the dialog
>> isn't.
>> 5) This also removes some of the complexity by just making the sidebar
>> a dialog, which is either opened or closed, and makes it so that its
>> showing is independent of the gramplet pane. (As an aside, the full
>> filter dialog could be dockable in the gramplet pane, which would give
>> nearly the current appearance of the sidebar filter).
>>
>> Does anyone see any issue with that type of strategy?
>
> It is hard to envisage what you mean.
> I suppose the gramplet pane can be closed also.

(That part about docking in the gramplet pane was an aside, and not
meant to distract from the main issues.)

> Technically I know very good how topbar/sidebar relates to the view as I
> rewrote that with Nick for 3.2. The changes you want to do go deep in the
> core code and are not that simple.

I know. But the current situation (two different working systems) is
caused by not working this down to a single, consistent system. That
is really the main goal, with a consistent UI.

> What is the global strategy?

Single filter system, with easy-to-understand UI.

> 1. We still have the problem in trunk that Geoview is broken with panes.
> That needs a solution, meaning several of us will have to try and fix that.
> Serge thinks it is a Gtk bug...

I don't know anything about that. I consider that a separate issue.

> 2. We want the navigation bar to the left, view center, and a general
> docking area to the right. Correct?

Yes. Currently in trunk the "docking area" is serving two purposes: a
place to hold the sidebar filter (which is itself toggled with topbar
filter) and the gramplet dock area. This is too complicated.
Suggestion is to remove sidebar filter from this functionality, and
make sidebar filter it a dialog, when needed.

> 3. Listviews have a search option shown via topbar or filter bar, geoview a
> sidebar search possible.

Yes. One possibility is to make topbar the minimized sidebar dialog.

> 4. Topbar search remains but uses the filter infrastructure instead of the
> view model/column data

Yes, when possible. Multi-column searches cannot be completely seen in
a topbar, single-line row.

> 5. Sidebar search becomes a dialog that is dockable in the general docking
> area?

Perhaps. Maybe just opened or closed.

> Note that above can be done without having to do 4., that is, it remains
> possible to keep searching in the columns. Tim's remark gives a hint quite
> some people are using it.

Yes, noted. But I'd like to integrate them so that Tim (and others)
would see a "+" in the topbar to suggest that there are more options
and power in the full dialog.

-Doug

> If above is done, best would be to do it in parts. So first 1, the 2/5, ..
>
> Benny
>>
>> -Doug
>>
>> On Mon, Nov 22, 2010 at 5:38 AM, Tim Lyons <guy.linton@...> wrote:
>> >
>> >
>> > Benny Malengier wrote:
>> >>
>> >> I don't like the idea of a dialog for search much. This is not a
>> >> texteditor,
>> >> but search on a column view, no need to block the view somehow with a
>> >> dialog.
>> >>
>> >
>> > Sorry, my fault, I confused things by the way I mentioned top filter in
>> > my
>> > argument. I think you have misunderstood.
>> >
>> > Personally I don't think there is much needing a change. Even though I
>> > know
>> > about the sidebar, I will still use the topbar.
>> >
>> > What I meant was, If you want to make a change, then:
>> > (a) remove the side filter,
>> > (b) leave the top filter exactly as it is, except
>> > (c) add 'custom filter' to the bottom of the top filter drop-down, and
>> > allowing the user to specify one of the filters he had defined in the
>> > filter
>> > editor
>> > (d) if the user selects the custom filter, then the filter name he
>> > selects
>> > could be displayed in the top filter where the filter criterion is
>> > normally
>> > displayed.
>> >
>> >
>> > --
>> > View this message in context:
>> > http://gramps.1791082.n4.nabble.com/Proposal-to-remove-topbar-filter-tp3052501p3053387.html
>> > Sent from the GRAMPS - Dev mailing list archive at Nabble.com.
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > 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
>> >
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>
>

DS Blank wrote:
> 
> On Mon, Nov 22, 2010 at 7:51 AM, Benny Malengier
> <benny.malengier@...> wrote:
> I know. But the current situation (two different working systems) is
> caused by not working this down to a single, consistent system. That
> is really the main goal, with a consistent UI.
> 
>> What is the global strategy?
> 
> Single filter system, with easy-to-understand UI.
> 
I agree

DS Blank wrote:
> 
> Yes. Currently in trunk the "docking area" is serving two purposes: a
> place to hold the sidebar filter (which is itself toggled with topbar
> filter) and the gramplet dock area. This is too complicated.
> 
I agree. I haven't actually seen the current trunk arrangement, but from
what I have heard it does sound complicated.

DS Blank wrote:
> 
> 
> Suggestion is to remove sidebar filter from this functionality, and
> make sidebar filter it a dialog, when needed.
> 
Sounds a good strategy

DS Blank wrote:
> 
> Yes, noted. But I'd like to integrate them so that Tim (and others)
> would see a "+" in the topbar to suggest that there are more options
> and power in the full dialog.
> 
That sounds good. As I said before, that could possibly be another option at
the bottom of the simple dropdown menu which pointed to the dialogue for
more functionality.

-- 
View this message in context: http://gramps.1791082.n4.nabble.com/Proposal-to-remove-topbar-filter-tp3052501p3054096.html
Sent from the GRAMPS - Dev mailing list archive at Nabble.com.

Benny Malengier a écrit :
>
>
> 2010/11/22 Doug Blank <doug.blank@... <mailto:doug.blank@...>>
>
>     Thanks for all of the feedback!
>
>     It seems all of the arguments so far have been about the UI, which is
>     fine. That suggests that we can get rid of the two different ways of
>     functioning and collapse that down to just one (the way that sidebar
>     works, perhaps with some niceties added). That would get rid of having
>     to explain differences.
>
>     The problem remaining, then, is how to make a consistent UI that could
>     use either a simple, topbar filter, or something more (and even
>     suggest to users that there is something more powerful available).
>
>     Some ideas:
>
>     1) Have a simplified topbar available for single entry, simple filters
>     (either a single column, or a single custom filter).
>     2) This might require that every field have associated with it a
>     filter (so that date columns would be searched by the date logic,
>     "male" would not match "female", note would search the entire text,
>     etc)
>     3) More complex filters could be available by having a "+" button in
>     the topbar, which would bring up a dialog (not sidebar). That would
>     prevent real estate from being eaten up. The topbar would become a
>     button indicating that a more complex filter is in effect. Clicking it
>     would bring up the dialog (which used to be the sidebar filter).
>     4) This would integrate the topbar/sidebar as the topbar would be a
>     simplified version of the full dialog, and only shown when the dialog
>     isn't.
>     5) This also removes some of the complexity by just making the sidebar
>     a dialog, which is either opened or closed, and makes it so that its
>     showing is independent of the gramplet pane. (As an aside, the full
>     filter dialog could be dockable in the gramplet pane, which would give
>     nearly the current appearance of the sidebar filter).
>
>     Does anyone see any issue with that type of strategy?
>
>
> It is hard to envisage what you mean.
> I suppose the gramplet pane can be closed also.
>
> Technically I know very good how topbar/sidebar relates to the view as 
> I rewrote that with Nick for 3.2. The changes you want to do go deep 
> in the core code and are not that simple. 
>
> What is the global strategy?
>
> 1. We still have the problem in trunk that Geoview is broken with 
> panes. That needs a solution, meaning several of us will have to try 
> and fix that. Serge thinks it is a Gtk bug...
NO. it's not a gtk but a gtk-webkit bug or a not implemented 
functionality for webkit in a paned window.

I'm interested too in this new filter as I incorporated navigation and 
filters into geoview.
I'm actually trying to break geoview in several modules and classes.
The navigation an filters will be some of them.
> 2. We want the navigation bar to the left, view center, and a general 
> docking area to the right. Correct?
> 3. Listviews have a search option shown via topbar or filter bar, 
> geoview a sidebar search possible.
> 4. Topbar search remains but uses the filter infrastructure instead of 
> the view model/column data
> 5. Sidebar search becomes a dialog that is dockable in the general 
> docking area?
>
> Note that above can be done without having to do 4., that is, it 
> remains possible to keep searching in the columns. Tim's remark gives 
> a hint quite some people are using it.
>
> If above is done, best would be to do it in parts. So first 1, the 2/5, ..
>
> Benny
>
>
>     -Doug
>
>     On Mon, Nov 22, 2010 at 5:38 AM, Tim Lyons <guy.linton@...
>     <mailto:guy.linton@...>> wrote:
>     >
>     >
>     > Benny Malengier wrote:
>     >>
>     >> I don't like the idea of a dialog for search much. This is not a
>     >> texteditor,
>     >> but search on a column view, no need to block the view somehow
>     with a
>     >> dialog.
>     >>
>     >
>     > Sorry, my fault, I confused things by the way I mentioned top
>     filter in my
>     > argument. I think you have misunderstood.
>     >
>     > Personally I don't think there is much needing a change. Even
>     though I know
>     > about the sidebar, I will still use the topbar.
>     >
>     > What I meant was, If you want to make a change, then:
>     > (a) remove the side filter,
>     > (b) leave the top filter exactly as it is, except
>     > (c) add 'custom filter' to the bottom of the top filter
>     drop-down, and
>     > allowing the user to specify one of the filters he had defined
>     in the filter
>     > editor
>     > (d) if the user selects the custom filter, then the filter name
>     he selects
>     > could be displayed in the top filter where the filter criterion
>     is normally
>     > displayed.
>

Tim:

If I am still misunderstanding what you have said is, REMOVE the sidebar/
filter?  If yes, then NEVER let that happen!!!

Sincerely yours,
Rob G. Healey


On Mon, Nov 22, 2010 at 2:38 AM, Tim Lyons <guy.linton@...> wrote:

>
>
> Benny Malengier wrote:
> >
> > I don't like the idea of a dialog for search much. This is not a
> > texteditor,
> > but search on a column view, no need to block the view somehow with a
> > dialog.
> >
>
> Sorry, my fault, I confused things by the way I mentioned top filter in my
> argument. I think you have misunderstood.
>
> Personally I don't think there is much needing a change. Even though I know
> about the sidebar, I will still use the topbar.
>
> What I meant was, If you want to make a change, then:
> (a) remove the side filter,
> (b) leave the top filter exactly as it is, except
> (c) add 'custom filter' to the bottom of the top filter drop-down, and
> allowing the user to specify one of the filters he had defined in the
> filter
> editor
> (d) if the user selects the custom filter, then the filter name he selects
> could be displayed in the top filter where the filter criterion is normally
> displayed.
>
>
> --
> View this message in context:
> http://gramps.1791082.n4.nabble.com/Proposal-to-remove-topbar-filter-tp3052501p3053387.html
> Sent from the GRAMPS - Dev mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> 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
>

2010/11/22 Serge Noiraud <Serge.Noiraud@...>

> Benny Malengier a écrit :
>
>>
>>
>> 2010/11/22 Doug Blank <doug.blank@... <mailto:doug.blank@...
>> >>
>>
>>
>>    Thanks for all of the feedback!
>>
>>    It seems all of the arguments so far have been about the UI, which is
>>    fine. That suggests that we can get rid of the two different ways of
>>    functioning and collapse that down to just one (the way that sidebar
>>    works, perhaps with some niceties added). That would get rid of having
>>    to explain differences.
>>
>>    The problem remaining, then, is how to make a consistent UI that could
>>    use either a simple, topbar filter, or something more (and even
>>    suggest to users that there is something more powerful available).
>>
>>    Some ideas:
>>
>>    1) Have a simplified topbar available for single entry, simple filters
>>    (either a single column, or a single custom filter).
>>    2) This might require that every field have associated with it a
>>    filter (so that date columns would be searched by the date logic,
>>    "male" would not match "female", note would search the entire text,
>>    etc)
>>    3) More complex filters could be available by having a "+" button in
>>    the topbar, which would bring up a dialog (not sidebar). That would
>>    prevent real estate from being eaten up. The topbar would become a
>>    button indicating that a more complex filter is in effect. Clicking it
>>    would bring up the dialog (which used to be the sidebar filter).
>>    4) This would integrate the topbar/sidebar as the topbar would be a
>>    simplified version of the full dialog, and only shown when the dialog
>>    isn't.
>>    5) This also removes some of the complexity by just making the sidebar
>>    a dialog, which is either opened or closed, and makes it so that its
>>    showing is independent of the gramplet pane. (As an aside, the full
>>    filter dialog could be dockable in the gramplet pane, which would give
>>    nearly the current appearance of the sidebar filter).
>>
>>    Does anyone see any issue with that type of strategy?
>>
>>
>> It is hard to envisage what you mean.
>> I suppose the gramplet pane can be closed also.
>>
>> Technically I know very good how topbar/sidebar relates to the view as I
>> rewrote that with Nick for 3.2. The changes you want to do go deep in the
>> core code and are not that simple.
>> What is the global strategy?
>>
>> 1. We still have the problem in trunk that Geoview is broken with panes.
>> That needs a solution, meaning several of us will have to try and fix that.
>> Serge thinks it is a Gtk bug...
>>
> NO. it's not a gtk but a gtk-webkit bug or a not implemented functionality
> for webkit in a paned window.
>
> I'm interested too in this new filter as I incorporated navigation and
> filters into geoview.
> I'm actually trying to break geoview in several modules and classes.
> The navigation an filters will be some of them.
>

Yes, Geoview must be broken up in smaller pieces.
Can you do that work in a new branch which we merge back in later. Or do you
expect this to be finished in 1 or 2 weeks?

Benny

2010/11/22 Rob Healey <robhealey1@...>

> Tim:
>
> If I am still misunderstanding what you have said is, REMOVE the sidebar/
> filter?  If yes, then NEVER let that happen!!!


What they say is to remove it from the sidebar, not to remove the
functionality.

Benny

>
>
> Sincerely yours,
> Rob G. Healey
>
>
> On Mon, Nov 22, 2010 at 2:38 AM, Tim Lyons <guy.linton@...> wrote:
>
>>
>>
>> Benny Malengier wrote:
>> >
>> > I don't like the idea of a dialog for search much. This is not a
>> > texteditor,
>> > but search on a column view, no need to block the view somehow with a
>> > dialog.
>> >
>>
>> Sorry, my fault, I confused things by the way I mentioned top filter in my
>> argument. I think you have misunderstood.
>>
>> Personally I don't think there is much needing a change. Even though I
>> know
>> about the sidebar, I will still use the topbar.
>>
>> What I meant was, If you want to make a change, then:
>> (a) remove the side filter,
>> (b) leave the top filter exactly as it is, except
>> (c) add 'custom filter' to the bottom of the top filter drop-down, and
>> allowing the user to specify one of the filters he had defined in the
>> filter
>> editor
>> (d) if the user selects the custom filter, then the filter name he selects
>> could be displayed in the top filter where the filter criterion is
>> normally
>> displayed.
>>
>>
>> --
>> View this message in context:
>> http://gramps.1791082.n4.nabble.com/Proposal-to-remove-topbar-filter-tp3052501p3053387.html
>> Sent from the GRAMPS - Dev mailing list archive at Nabble.com.
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>>
>
>
>
> ------------------------------------------------------------------------------
> Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
> Tap into the largest installed PC base & get more eyes on your game by
> optimizing for Intel(R) Graphics Technology. Get started today with the
> Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
> http://p.sf.net/sfu/intelisp-dev2dev
> _______________________________________________
> Gramps-devel mailing list
> Gramps-devel@...
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>
>

On Sun, Nov 21, 2010 at 01:39:54PM -0800, Tim Lyons wrote:
>
>I think removing the topbar search facility would be a bad idea (TM). I
>frequently use the search facility as a very quick way to narrow down a
>large number of entries. In contrast, I didn't really know that the filter
>sidebar existed (although now you mention it, I may have seen references to
>it on gramps-devel), and I have certainly never used it. The filter sidebar
>takes up a lot of space in the window, whereas the search is very compact.
>
>If you want to simplify the interface, then I would much prefer you removed
>the filter sidebar instead!

I agree with all of the above. As a fairly longterm user, I'm not very
interested in filters, but I do want quick access to data. (For what is,
to my mind, a brilliant search interface, try Lifelines.) Screen space
is also important to me. The current sidebar steals a quarter of my
screen.

Martin

Dear Benny:

Thanks for clarifying the idea of removing the filters from the sidebar not
completely from Gramps in its entirety!

Sincerely yours,
Rob G. Healey

On Mon, Nov 22, 2010 at 11:31 AM, Benny Malengier <benny.malengier@...
> wrote:

>
>
> 2010/11/22 Rob Healey <robhealey1@...>
>
> Tim:
>>
>> If I am still misunderstanding what you have said is, REMOVE the sidebar/
>> filter?  If yes, then NEVER let that happen!!!
>
>
> What they say is to remove it from the sidebar, not to remove the
> functionality.
>
> Benny
>
>>
>>
>> Sincerely yours,
>> Rob G. Healey
>>
>>
>> On Mon, Nov 22, 2010 at 2:38 AM, Tim Lyons <guy.linton@...> wrote:
>>
>>>
>>>
>>> Benny Malengier wrote:
>>> >
>>> > I don't like the idea of a dialog for search much. This is not a
>>> > texteditor,
>>> > but search on a column view, no need to block the view somehow with a
>>> > dialog.
>>> >
>>>
>>> Sorry, my fault, I confused things by the way I mentioned top filter in
>>> my
>>> argument. I think you have misunderstood.
>>>
>>> Personally I don't think there is much needing a change. Even though I
>>> know
>>> about the sidebar, I will still use the topbar.
>>>
>>> What I meant was, If you want to make a change, then:
>>> (a) remove the side filter,
>>> (b) leave the top filter exactly as it is, except
>>> (c) add 'custom filter' to the bottom of the top filter drop-down, and
>>> allowing the user to specify one of the filters he had defined in the
>>> filter
>>> editor
>>> (d) if the user selects the custom filter, then the filter name he
>>> selects
>>> could be displayed in the top filter where the filter criterion is
>>> normally
>>> displayed.
>>>
>>>
>>> --
>>> View this message in context:
>>> http://gramps.1791082.n4.nabble.com/Proposal-to-remove-topbar-filter-tp3052501p3053387.html
>>> Sent from the GRAMPS - Dev mailing list archive at Nabble.com.
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> 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
>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
>> Tap into the largest installed PC base & get more eyes on your game by
>> optimizing for Intel(R) Graphics Technology. Get started today with the
>> Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
>> http://p.sf.net/sfu/intelisp-dev2dev
>>
>> _______________________________________________
>> Gramps-devel mailing list
>> Gramps-devel@...
>> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>>
>>
>

Dear Benny and Serge:

I know that some of the same functionality that I use in NarrativeWeb is
close or similar to what is being used in GeoView too!  Or at least I could
use some of the same code that is in Geoview for NarWeb if it was broken
down into pieces...

Sincerely yours,
Rob G. Healey


On Mon, Nov 22, 2010 at 11:30 AM, Benny Malengier <benny.malengier@...
> wrote:

>
>
> 2010/11/22 Serge Noiraud <Serge.Noiraud@...>
>
> Benny Malengier a écrit :
>>
>>>
>>>
>>> 2010/11/22 Doug Blank <doug.blank@... <mailto:doug.blank@...
>>> >>
>>>
>>>
>>>    Thanks for all of the feedback!
>>>
>>>    It seems all of the arguments so far have been about the UI, which is
>>>    fine. That suggests that we can get rid of the two different ways of
>>>    functioning and collapse that down to just one (the way that sidebar
>>>    works, perhaps with some niceties added). That would get rid of having
>>>    to explain differences.
>>>
>>>    The problem remaining, then, is how to make a consistent UI that could
>>>    use either a simple, topbar filter, or something more (and even
>>>    suggest to users that there is something more powerful available).
>>>
>>>    Some ideas:
>>>
>>>    1) Have a simplified topbar available for single entry, simple filters
>>>    (either a single column, or a single custom filter).
>>>    2) This might require that every field have associated with it a
>>>    filter (so that date columns would be searched by the date logic,
>>>    "male" would not match "female", note would search the entire text,
>>>    etc)
>>>    3) More complex filters could be available by having a "+" button in
>>>    the topbar, which would bring up a dialog (not sidebar). That would
>>>    prevent real estate from being eaten up. The topbar would become a
>>>    button indicating that a more complex filter is in effect. Clicking it
>>>    would bring up the dialog (which used to be the sidebar filter).
>>>    4) This would integrate the topbar/sidebar as the topbar would be a
>>>    simplified version of the full dialog, and only shown when the dialog
>>>    isn't.
>>>    5) This also removes some of the complexity by just making the sidebar
>>>    a dialog, which is either opened or closed, and makes it so that its
>>>    showing is independent of the gramplet pane. (As an aside, the full
>>>    filter dialog could be dockable in the gramplet pane, which would give
>>>    nearly the current appearance of the sidebar filter).
>>>
>>>    Does anyone see any issue with that type of strategy?
>>>
>>>
>>> It is hard to envisage what you mean.
>>> I suppose the gramplet pane can be closed also.
>>>
>>> Technically I know very good how topbar/sidebar relates to the view as I
>>> rewrote that with Nick for 3.2. The changes you want to do go deep in the
>>> core code and are not that simple.
>>> What is the global strategy?
>>>
>>> 1. We still have the problem in trunk that Geoview is broken with panes.
>>> That needs a solution, meaning several of us will have to try and fix that.
>>> Serge thinks it is a Gtk bug...
>>>
>> NO. it's not a gtk but a gtk-webkit bug or a not implemented functionality
>> for webkit in a paned window.
>>
>> I'm interested too in this new filter as I incorporated navigation and
>> filters into geoview.
>> I'm actually trying to break geoview in several modules and classes.
>> The navigation an filters will be some of them.
>>
>
> Yes, Geoview must be broken up in smaller pieces.
> Can you do that work in a new branch which we merge back in later. Or do
> you expect this to be finished in 1 or 2 weeks?
>
> Benny
>
>
>
> ------------------------------------------------------------------------------
> Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
> Tap into the largest installed PC base & get more eyes on your game by
> optimizing for Intel(R) Graphics Technology. Get started today with the
> Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
> http://p.sf.net/sfu/intelisp-dev2dev
> _______________________________________________
> Gramps-devel mailing list
> Gramps-devel@...
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>
>

Dear Martin:

I, too, have been using Gramps for a very long time and for a little period
of time, I have been working with NarrativeWeb and WebCal!  I am NOT trying
to preach or convert you, but I had never even looked at how much power and
functionality there is in being able to use the filter/ sidebar!

I know that it can take a lot of real estate in the screen, but it can be
added/ removed with ease too!

Sincerely yours,
Rob G. Healey



On Mon, Nov 22, 2010 at 11:11 AM, Martin Steer <martinsteer@...:

> On Sun, Nov 21, 2010 at 01:39:54PM -0800, Tim Lyons wrote:
> >
> >I think removing the topbar search facility would be a bad idea (TM). I
> >frequently use the search facility as a very quick way to narrow down a
> >large number of entries. In contrast, I didn't really know that the filter
> >sidebar existed (although now you mention it, I may have seen references
> to
> >it on gramps-devel), and I have certainly never used it. The filter
> sidebar
> >takes up a lot of space in the window, whereas the search is very compact.
> >
> >If you want to simplify the interface, then I would much prefer you
> removed
> >the filter sidebar instead!
>
> I agree with all of the above. As a fairly longterm user, I'm not very
> interested in filters, but I do want quick access to data. (For what is,
> to my mind, a brilliant search interface, try Lifelines.) Screen space
> is also important to me. The current sidebar steals a quarter of my
> screen.
>
> Martin
>
>
>
> ------------------------------------------------------------------------------
> Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
> Tap into the largest installed PC base & get more eyes on your game by
> optimizing for Intel(R) Graphics Technology. Get started today with the
> Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
> http://p.sf.net/sfu/intelisp-dev2dev
> _______________________________________________
> Gramps-devel mailing list
> Gramps-devel@...
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>

On Mon, Nov 22, 2010 at 2:11 PM, Martin Steer <martinsteer@...> wrote:
> On Sun, Nov 21, 2010 at 01:39:54PM -0800, Tim Lyons wrote:
>>
>>I think removing the topbar search facility would be a bad idea (TM). I
>>frequently use the search facility as a very quick way to narrow down a
>>large number of entries. In contrast, I didn't really know that the filter
>>sidebar existed (although now you mention it, I may have seen references to
>>it on gramps-devel), and I have certainly never used it. The filter sidebar
>>takes up a lot of space in the window, whereas the search is very compact.
>>
>>If you want to simplify the interface, then I would much prefer you removed
>>the filter sidebar instead!
>
> I agree with all of the above. As a fairly longterm user, I'm not very
> interested in filters, but I do want quick access to data. (For what is,
> to my mind, a brilliant search interface, try Lifelines.) Screen space
> is also important to me. The current sidebar steals a quarter of my
> screen.

I think we are headed to a consensus on UI issues:

- keep an easy-to-use topbar version
- make access to a more powerful dialog handy
- keep the more powerful version from taking up so much space
- make it so that one can understand how these work
- make it so the way they work matches expectations

I think we can do all of this. If someone has screen captures of
LifeLines (or any other software) doing filtering/searching, that
might be useful.

-Doug

> Martin
>
>
> ------------------------------------------------------------------------------
> Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
> Tap into the largest installed PC base & get more eyes on your game by
> optimizing for Intel(R) Graphics Technology. Get started today with the
> Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
> http://p.sf.net/sfu/intelisp-dev2dev
> _______________________________________________
> Gramps-devel mailing list
> Gramps-devel@...
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>

2010/11/22 Doug Blank <doug.blank@...>

> On Mon, Nov 22, 2010 at 2:11 PM, Martin Steer <martinsteer@...>
> wrote:
> > On Sun, Nov 21, 2010 at 01:39:54PM -0800, Tim Lyons wrote:
> >>
> >>I think removing the topbar search facility would be a bad idea (TM). I
> >>frequently use the search facility as a very quick way to narrow down a
> >>large number of entries. In contrast, I didn't really know that the
> filter
> >>sidebar existed (although now you mention it, I may have seen references
> to
> >>it on gramps-devel), and I have certainly never used it. The filter
> sidebar
> >>takes up a lot of space in the window, whereas the search is very
> compact.
> >>
> >>If you want to simplify the interface, then I would much prefer you
> removed
> >>the filter sidebar instead!
> >
> > I agree with all of the above. As a fairly longterm user, I'm not very
> > interested in filters, but I do want quick access to data. (For what is,
> > to my mind, a brilliant search interface, try Lifelines.) Screen space
> > is also important to me. The current sidebar steals a quarter of my
> > screen.
>
> I think we are headed to a consensus on UI issues:
>
> - keep an easy-to-use topbar version
> - make access to a more powerful dialog handy
> - keep the more powerful version from taking up so much space
> - make it so that one can understand how these work
> - make it so the way they work matches expectations
>
> I think we can do all of this. If someone has screen captures of
> LifeLines (or any other software) doing filtering/searching, that
>


Hmm, http://sourceforge.net/project/screenshots.php?group_id=852&ssid=4897
Press s to search ;-)

might be useful.
>

very.
Perhaps Martin meant something else, or meant the speed?

Benny

Benny Malengier a écrit :
>
>
> 2010/11/22 Serge Noiraud <Serge.Noiraud@... 
> <mailto:Serge.Noiraud@...>>
>
>     Benny Malengier a écrit :
>
>
>
>         2010/11/22 Doug Blank <doug.blank@...
>         <mailto:doug.blank@...> <mailto:doug.blank@...
>         <mailto:doug.blank@...>>>
>
>
>            Thanks for all of the feedback!
>
>            It seems all of the arguments so far have been about the
>         UI, which is
>            fine. That suggests that we can get rid of the two
>         different ways of
>            functioning and collapse that down to just one (the way
>         that sidebar
>            works, perhaps with some niceties added). That would get
>         rid of having
>            to explain differences.
>
>            The problem remaining, then, is how to make a consistent UI
>         that could
>            use either a simple, topbar filter, or something more (and even
>            suggest to users that there is something more powerful
>         available).
>
>            Some ideas:
>
>            1) Have a simplified topbar available for single entry,
>         simple filters
>            (either a single column, or a single custom filter).
>            2) This might require that every field have associated with
>         it a
>            filter (so that date columns would be searched by the date
>         logic,
>            "male" would not match "female", note would search the
>         entire text,
>            etc)
>            3) More complex filters could be available by having a "+"
>         button in
>            the topbar, which would bring up a dialog (not sidebar).
>         That would
>            prevent real estate from being eaten up. The topbar would
>         become a
>            button indicating that a more complex filter is in effect.
>         Clicking it
>            would bring up the dialog (which used to be the sidebar
>         filter).
>            4) This would integrate the topbar/sidebar as the topbar
>         would be a
>            simplified version of the full dialog, and only shown when
>         the dialog
>            isn't.
>            5) This also removes some of the complexity by just making
>         the sidebar
>            a dialog, which is either opened or closed, and makes it so
>         that its
>            showing is independent of the gramplet pane. (As an aside,
>         the full
>            filter dialog could be dockable in the gramplet pane, which
>         would give
>            nearly the current appearance of the sidebar filter).
>
>            Does anyone see any issue with that type of strategy?
>
>
>         It is hard to envisage what you mean.
>         I suppose the gramplet pane can be closed also.
>
>         Technically I know very good how topbar/sidebar relates to the
>         view as I rewrote that with Nick for 3.2. The changes you want
>         to do go deep in the core code and are not that simple.
>         What is the global strategy?
>
>         1. We still have the problem in trunk that Geoview is broken
>         with panes. That needs a solution, meaning several of us will
>         have to try and fix that. Serge thinks it is a Gtk bug...
>
>     NO. it's not a gtk but a gtk-webkit bug or a not implemented
>     functionality for webkit in a paned window.
>
>     I'm interested too in this new filter as I incorporated navigation
>     and filters into geoview.
>     I'm actually trying to break geoview in several modules and classes.
>     The navigation an filters will be some of them.
>
>
> Yes, Geoview must be broken up in smaller pieces.
> Can you do that work in a new branch which we merge back in later. Or 
> do you expect this to be finished in 1 or 2 weeks?
It will never be finished in two weeks.
I have a lot of work to do at home and only a few for genealogy ( and 
gramps ) at this moment.

This is the beginning as I want to suppress webkit and gtkmozembed and do
all the work in python.
1 - It will be easier to manage.
2 - We could interact with the map as we want.
3 - We'll have a local map
4 - Avoid an internet connexion except when we want to update the local map.
5 - Reduce gramps dependencies
5 - Many, many work ...

Perhaps the best could be to create a GEPS for this new geoview.
I don't know how to do this and how to manage it.
>
> Benny

I had in mind 'browsing for persons' in lifelines, rather than
searching. Essentially this amounts to 1) entering search with a
keypress (no mousing, no dialogs, no menus), 2) being able to search on
a string or part of a string. What I want to do in gramps is to reduce a
long list of potential targets to just a few. Names are usually enough
for this; I usually don't need dates, sexes, etc., but it has to be
quick.

In a selection dialog in gramps, you can initiate a search just by
typing your string, but this has never worked well for me in the main
views. There the list of targets doesn't automatically have focus, so
it's not a matter of just typing; and the search isn't flexible enough,
as it requires that you match from the beginning of the string. I also
find that I have to type slowly.

Martin

An arrangement which would be 'intuitive' for most users would be to
launch a simple search with control-f or control-s, with an entry also
under the edit menu. There should also be a way to repeat the search,
i.e. to move to the next result. Maybe then you could lose the topbar.

Martin

Hi,


As you also used LifeLines, maybe I can send you some tries for re-writting some LifeLines' report/plugins into python !!!

Some years ago, I had used:
http://sourceforge.net/projects/hrreportmaker/

My goal was to see reports/plugins written in python and not to use them into Gramps.


Regards,
Jerome


--- En date de : Mar 23.11.10, Martin Steer <martinsteer@...> a écrit :

> De: Martin Steer <martinsteer@...>
> Objet: Re: [Gramps-devel] Re :  Proposal to remove topbar filter
> À: gramps-devel@...
> Date: Mardi 23 novembre 2010, 1h01
> I had in mind 'browsing for persons'
> in lifelines, rather than
> searching. Essentially this amounts to 1) entering search
> with a
> keypress (no mousing, no dialogs, no menus), 2) being able
> to search on
> a string or part of a string. What I want to do in gramps
> is to reduce a
> long list of potential targets to just a few. Names are
> usually enough
> for this; I usually don't need dates, sexes, etc., but it
> has to be
> quick.
> 
> In a selection dialog in gramps, you can initiate a search
> just by
> typing your string, but this has never worked well for me
> in the main
> views. There the list of targets doesn't automatically have
> focus, so
> it's not a matter of just typing; and the search isn't
> flexible enough,
> as it requires that you match from the beginning of the
> string. I also
> find that I have to type slowly.
> 
> Martin
> 
> ------------------------------------------------------------------------------
> Increase Visibility of Your 3D Game App & Earn a Chance
> To Win $500!
> Tap into the largest installed PC base & get more eyes
> on your game by
> optimizing for Intel(R) Graphics Technology. Get started
> today with the
> Intel(R) Software Partner Program. Five $500 cash prizes
> are up for grabs.
> http://p.sf.net/sfu/intelisp-dev2dev
> _______________________________________________
> Gramps-devel mailing list
> Gramps-devel@...
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>

Yes and to work like on spreadsheet[1] could be also harder without top bar features.

Some specific columns displaying data like: description on event[2], spouses list, main persons on event, marriage data on family, etc ... are not "string only". The ability to match entries with few letters is a good search tool.


[1] http://gramps-project.org/wiki/index.php?title=Events_manager#Gramps_as_spreadsheet
[2] http://gramps-project.org/wiki/images/6/62/Tab4.png


Jérôme

--- En date de : Dim 21.11.10, Doug Blank <doug.blank@...> a écrit :

> De: Doug Blank <doug.blank@...>
> Objet: Re: [Gramps-devel] Proposal to remove topbar filter
> À: "Gramps Development List" <gramps-devel@...>
> Date: Dimanche 21 novembre 2010, 21h42
> Another difference between topbar and
> sidebar filters:
> 
> When using topbar filter, the text must match the text in
> the column
> as shown. In the sidebar filter, it more than likely uses
> the database
> data without regard to how a field is currently displayed.
> 
> For example, if you use "Surname, G" in the topbar with
> "Name
> contains:" selected, and the Name Display set
> appropriately, you'll
> match "Surname, Given". However, in the sidebar filter, the
> text must
> match either the given or the surname, but can't be used to
> match both
> parts, and works in the same manner without regard to the
> Name
> Display.
> 
> If we do get rid of the topbar filter, we should spend a
> bit of time
> to make sure that the sidebar filters capture most of the
> uses of the
> topbar.
> 
> -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
>