From: Doug B. <dou...@gm...> - 2010-11-21 16:22:36
|
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 |
From: jerome <rom...@ya...> - 2010-11-21 17:31:08
|
> 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 <dou...@gm...> a écrit : > De: Doug Blank <dou...@gm...> > Objet: [Gramps-devel] Proposal to remove topbar filter > À: "Gramps Development List" <gra...@li...> > 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 > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: Doug B. <dou...@gm...> - 2010-11-21 18:13:22
|
On Sun, Nov 21, 2010 at 12:31 PM, jerome <rom...@ya...> 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 <dou...@gm...> a écrit : > >> De: Doug Blank <dou...@gm...> >> Objet: [Gramps-devel] Proposal to remove topbar filter >> À: "Gramps Development List" <gra...@li...> >> 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 >> Gra...@li... >> https://lists.sourceforge.net/lists/listinfo/gramps-devel >> > > > > |
From: jerome <rom...@ya...> - 2010-11-21 20:19:06
|
> > * 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 <dou...@gm...> a écrit : > De: Doug Blank <dou...@gm...> > Objet: Re: Re : [Gramps-devel] Proposal to remove topbar filter > À: "jerome" <rom...@ya...> > Cc: "Gramps Development List" <gra...@li...> > Date: Dimanche 21 novembre 2010, 19h13 > On Sun, Nov 21, 2010 at 12:31 PM, > jerome <rom...@ya...> > 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 <dou...@gm...> > a écrit : > > > >> De: Doug Blank <dou...@gm...> > >> Objet: [Gramps-devel] Proposal to remove topbar > filter > >> À: "Gramps Development List" <gra...@li...> > >> 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 > >> Gra...@li... > >> https://lists.sourceforge.net/lists/listinfo/gramps-devel > >> > > > > > > > > > |
From: Tim L. <guy...@gm...> - 2010-11-21 21:40:01
|
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. |
From: Rob H. <rob...@gm...> - 2010-11-21 23:58:38
|
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...@gm...> 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 > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: Benny M. <ben...@gm...> - 2010-11-22 08:10:35
|
2010/11/21 Tim Lyons <guy...@gm...> > > 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 > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: Tim L. <guy...@gm...> - 2010-11-22 10:38:37
|
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. |
From: jerome <rom...@ya...> - 2010-11-22 11:20:41
|
> 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...@gm...> a écrit : > De: Tim Lyons <guy...@gm...> > Objet: Re: [Gramps-devel] Re : Proposal to remove topbar filter > À: gra...@li... > 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 > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: Doug B. <dou...@gm...> - 2010-11-22 12:04:17
|
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...@gm...> 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 > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: Benny M. <ben...@gm...> - 2010-11-22 12:51:34
|
2010/11/22 Doug Blank <dou...@gm...> > 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...@gm...> 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 > > Gra...@li... > > 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 > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: Serge N. <Ser...@fr...> - 2010-11-22 18:06:03
|
Benny Malengier a écrit : > > > 2010/11/22 Doug Blank <dou...@gm... <mailto:dou...@gm...>> > > 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...@gm... > <mailto:guy...@gm...>> 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. > |
From: Benny M. <ben...@gm...> - 2010-11-22 19:30:59
|
2010/11/22 Serge Noiraud <Ser...@fr...> > Benny Malengier a écrit : > >> >> >> 2010/11/22 Doug Blank <dou...@gm... <mailto:dou...@gm... >> >> >> >> >> 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 |
From: Rob H. <rob...@gm...> - 2010-11-22 20:07:12
|
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 <ben...@gm... > wrote: > > > 2010/11/22 Serge Noiraud <Ser...@fr...> > > Benny Malengier a écrit : >> >>> >>> >>> 2010/11/22 Doug Blank <dou...@gm... <mailto:dou...@gm... >>> >> >>> >>> >>> 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 > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > > |
From: Serge N. <Ser...@fr...> - 2010-11-22 22:40:50
|
Benny Malengier a écrit : > > > 2010/11/22 Serge Noiraud <Ser...@fr... > <mailto:Ser...@fr...>> > > Benny Malengier a écrit : > > > > 2010/11/22 Doug Blank <dou...@gm... > <mailto:dou...@gm...> <mailto:dou...@gm... > <mailto:dou...@gm...>>> > > > 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 |
From: Doug B. <dou...@gm...> - 2010-11-21 20:42:39
|
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 |
From: jerome <rom...@ya...> - 2010-11-25 14:07:43
|
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 <dou...@gm...> a écrit : > De: Doug Blank <dou...@gm...> > Objet: Re: [Gramps-devel] Proposal to remove topbar filter > À: "Gramps Development List" <gra...@li...> > 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 > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: Doug B. <dou...@gm...> - 2010-11-22 13:06:12
|
On Mon, Nov 22, 2010 at 7:51 AM, Benny Malengier <ben...@gm...> wrote: > > > 2010/11/22 Doug Blank <dou...@gm...> >> >> 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...@gm...> 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 >> > Gra...@li... >> > 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 >> Gra...@li... >> https://lists.sourceforge.net/lists/listinfo/gramps-devel > > |
From: Tim L. <guy...@gm...> - 2010-11-22 17:45:56
|
DS Blank wrote: > > On Mon, Nov 22, 2010 at 7:51 AM, Benny Malengier > <ben...@gm...> 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. |
From: Rob H. <rob...@gm...> - 2010-11-22 18:23:33
|
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...@gm...> 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 > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: Benny M. <ben...@gm...> - 2010-11-22 19:31:47
|
2010/11/22 Rob Healey <rob...@gm...> > 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...@gm...> 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 >> Gra...@li... >> 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 > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > > |
From: Rob H. <rob...@gm...> - 2010-11-22 20:04:34
|
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 <ben...@gm... > wrote: > > > 2010/11/22 Rob Healey <rob...@gm...> > > 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...@gm...> 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 >>> Gra...@li... >>> 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 >> Gra...@li... >> https://lists.sourceforge.net/lists/listinfo/gramps-devel >> >> > |
From: Martin S. <mar...@ma...> - 2010-11-22 19:35:00
|
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 |
From: Rob H. <rob...@gm...> - 2010-11-22 20:13:05
|
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 <mar...@ma...>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. > > 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 > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: Doug B. <dou...@gm...> - 2010-11-22 21:31:25
|
On Mon, Nov 22, 2010 at 2:11 PM, Martin Steer <mar...@ma...> 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 > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |