From: Douglas S. B. <db...@cs...> - 2007-02-09 03:08:17
|
As I was working toward making estimates of birth dates, death dates, and marriage dates better, I realized that gramps first needs to better use the dates that we know for certain. For example, it is very difficult to find someone in the database that died at a particular age, say at 114. This was made apparent when running either Eero's StatisticsChart or the temporary Lifespan Distribution view that I sent around yesterday. Trying to locate the anomalies that appear in these reports is basically impossible. Also, it is not easy to find those people that would have been about 55 years old in the year 1851. This is something that I find myself doing quite often, for example, when looking at census reports. This is possible using the event comparison, sorting on birth dates, and doing some addition, but isn't easy. So, I have two new columns for the Person view: "Age at Death", and "Age on Date". I think these are very useful; I suspect that people might like to have them in the official gramps. If so, this brings up some questions: 1) Don and Richard both indicated that the model/view code may change soon. These two columns are pretty simple code (except for the date, see next), so shouldn't have a large impact. Should we add them to 2.2 and/or 2.3, or wait till the new model/view is implemented? 2) The "Age on Date" requires a date. I imagine that the column heading should be "Age on December 31, 1851", or "Age in 1851". Of course, that date should be easy to change. Where should this date be stored? How should it be set? Some ideas: - don't store it. keep it in memory, and let it default to today's date on startup - keep it and set in Preferences (clumsy, but easy to do) - set it via a dialog by right-clicking on that column 3) Is the plan to have gramps support sortable person-view columns? If so, that would be great. If not, then we may need to figure out how to get these ages in a sorted fashion. 4) Do you think that both of these virtual columns would make good values to filter on? 5) Are there other age-related values that you would like to see in the person view, or in other places? Thanks for any and all feedback, -Doug |
From: <ben...@ug...> - 2007-02-09 08:45:41
|
I think adding some calculated fields to the dialogs of gramps is a good idea. Adding it to the person view is in my view not good, and is actually a workaround for the not so good working filter search in GRAMPS. Let me explain: You can let users do these searches without columns, with more flexebility with filters. You could make a filter now to add this functionality to 2.2.7, independent if dialog or view is adapted. The filter would still work in 2.3. Least programming for maximum functionality, and availability to reports at the same moment. The deeper reason for the question you ask shows a weak point in GRAMPS: difficulty to work with filters! You could make a filter: 'Age on death <val>' or 'Age on death between <age1> and <age2>' or 'Age on <date> between <val> and <val>', and people would already be happy. However, the problem I percieve is: changing a value for a different search quickly is not possible: call filter editor, add rule, select correct rule (of the many!), enter data, save rule, save filter, select in filter siderbar, enter. A search like 'Age on death <val>' should be possible from the filter sidebar somehow with a minimum of mouse clicks, and a maximum of user friendlyness. Then adding fields in person view, is not needed (sorting view would take as long as doing the filter search I think). A general method for doing easier filter search should be developed, instead of adding more and more derived columns, and having the user relate to column sorting and searching in the columns (still not easy). So, I'm not so sure adding them as columns to the person view is a good idea. Where do you stop? Also, how does it impact performance? After all the performance changes for 2.2.6, it would not be nice to start running in problems again. Benny Quoting "Douglas S. Blank" <db...@cs...>: > As I was working toward making estimates of birth dates, death dates, and > marriage dates better, I realized that gramps first needs to better use > the dates that we know for certain. > > For example, it is very difficult to find someone in the database that > died at a particular age, say at 114. This was made apparent when running > either Eero's StatisticsChart or the temporary Lifespan Distribution view > that I sent around yesterday. Trying to locate the anomalies that appear > in these reports is basically impossible. > > Also, it is not easy to find those people that would have been about 55 > years old in the year 1851. This is something that I find myself doing > quite often, for example, when looking at census reports. This is possible > using the event comparison, sorting on birth dates, and doing some > addition, but isn't easy. > > So, I have two new columns for the Person view: "Age at Death", and "Age > on Date". I think these are very useful; I suspect that people might like > to have them in the official gramps. > > If so, this brings up some questions: > > 1) Don and Richard both indicated that the model/view code may change > soon. These two columns are pretty simple code (except for the date, see > next), so shouldn't have a large impact. Should we add them to 2.2 and/or > 2.3, or wait till the new model/view is implemented? > > 2) The "Age on Date" requires a date. I imagine that the column heading > should be "Age on December 31, 1851", or "Age in 1851". Of course, that > date should be easy to change. Where should this date be stored? How > should it be set? Some ideas: > > - don't store it. keep it in memory, and let it default to today's date on > startup > - keep it and set in Preferences (clumsy, but easy to do) > - set it via a dialog by right-clicking on that column > > 3) Is the plan to have gramps support sortable person-view columns? If so, > that would be great. If not, then we may need to figure out how to get > these ages in a sorted fashion. > > 4) Do you think that both of these virtual columns would make good values > to filter on? > > 5) Are there other age-related values that you would like to see in the > person view, or in other places? > > Thanks for any and all feedback, > > -Doug > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your > job easier. > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |
From: Douglas S. B. <db...@cs...> - 2007-02-09 12:29:38
|
Benny, Thanks for the comments. I agree that these values need filters, but I'm thinking ahead. With an *estimated* "age at death", and estimated "age on date", I want to also see these values. If you go back 350 years, there may be quite a range to them, and a filter may not be the best way to search for them. Your range filter can be useful, but I want to visualize the people at that point in time, and the displayed age really helps. A filter with a combined displayed value is the best solution. I wouldn't want to have to set a different filter for each age in the census. Set the filter to select a subset, and then see the ages at a particular year. These columns don't take any longer than, say, spouse, to retrieve and build. They only display when you have them selected, are cached, and only are computed for the names on the screen (like all of the other columns). But having a filter on these fields will be slow, as it has to compute it for every one of them. When we make a filter, we might want to think about actually moving computed values to the database. But that is step two, I think. Step one is the display. Where do we stop in making columns to display? There should be as many as users can use. There is no need to keep the possibilities small. There is no penalty for having a large number of possible columns, and the infrastructure is in place to make these a one-time computation per row. If you don't want to see them, there is zero impact on your view. -Doug On Fri, February 9, 2007 3:45 am, ben...@ug... wrote: > I think adding some calculated fields to the dialogs of gramps is a good > idea. > > Adding it to the person view is in my view not good, and is actually a > workaround for the not so good working filter search in GRAMPS. > > Let me explain: > > You can let users do these searches without columns, with more > flexebility with > filters. You could make a filter now to add this functionality to 2.2.7, > independent if dialog or view is adapted. The filter would still work in > 2.3. > Least programming for maximum functionality, and availability to > reports at the > same moment. > > The deeper reason for the question you ask shows a weak point in GRAMPS: > difficulty to work with filters! You could make a filter: 'Age on death > <val>' > or 'Age on death between <age1> and <age2>' or 'Age on <date> between > <val> and > <val>', and people would already be happy. > However, the problem I percieve is: changing a value for a different > search > quickly is not possible: call filter editor, add rule, select correct rule > (of > the many!), enter data, save rule, save filter, select in filter siderbar, > enter. > > A search like 'Age on death <val>' should be possible from the filter > sidebar > somehow with a minimum of mouse clicks, and a maximum of user > friendlyness. > Then adding fields in person view, is not needed (sorting view would take > as > long as doing the filter search I think). A general method for doing > easier > filter search should be developed, instead of adding more and more derived > columns, and having the user relate to column sorting and searching in the > columns (still not easy). > > So, I'm not so sure adding them as columns to the person view is a good > idea. > Where do you stop? Also, how does it impact performance? After all the > performance changes for 2.2.6, it would not be nice to start running in > problems again. > > Benny > > > Quoting "Douglas S. Blank" <db...@cs...>: > >> As I was working toward making estimates of birth dates, death dates, >> and >> marriage dates better, I realized that gramps first needs to better use >> the dates that we know for certain. >> >> For example, it is very difficult to find someone in the database that >> died at a particular age, say at 114. This was made apparent when >> running >> either Eero's StatisticsChart or the temporary Lifespan Distribution >> view >> that I sent around yesterday. Trying to locate the anomalies that appear >> in these reports is basically impossible. >> >> Also, it is not easy to find those people that would have been about 55 >> years old in the year 1851. This is something that I find myself doing >> quite often, for example, when looking at census reports. This is >> possible >> using the event comparison, sorting on birth dates, and doing some >> addition, but isn't easy. >> >> So, I have two new columns for the Person view: "Age at Death", and "Age >> on Date". I think these are very useful; I suspect that people might >> like >> to have them in the official gramps. >> >> If so, this brings up some questions: >> >> 1) Don and Richard both indicated that the model/view code may change >> soon. These two columns are pretty simple code (except for the date, see >> next), so shouldn't have a large impact. Should we add them to 2.2 >> and/or >> 2.3, or wait till the new model/view is implemented? >> >> 2) The "Age on Date" requires a date. I imagine that the column heading >> should be "Age on December 31, 1851", or "Age in 1851". Of course, that >> date should be easy to change. Where should this date be stored? How >> should it be set? Some ideas: >> >> - don't store it. keep it in memory, and let it default to today's date >> on >> startup >> - keep it and set in Preferences (clumsy, but easy to do) >> - set it via a dialog by right-clicking on that column >> >> 3) Is the plan to have gramps support sortable person-view columns? If >> so, >> that would be great. If not, then we may need to figure out how to get >> these ages in a sorted fashion. >> >> 4) Do you think that both of these virtual columns would make good >> values >> to filter on? >> >> 5) Are there other age-related values that you would like to see in the >> person view, or in other places? >> >> Thanks for any and all feedback, >> >> -Doug |
From: <ben...@ug...> - 2007-02-09 15:13:16
|
Doug, you did not convince me yet. First, we agree a filter should be created. Great. So, should also a column be added? You are correct in noting it does not hurt, you can disactivate it, and it would probably not be the default. However, we should also not add columns that are not needed. A user should be directed to the best tool to do a job. Offering two tools is confusing if not needed, and one is better. Disadvantage: you cannot sort in person view. you cannot change column order (so seeing the column might involve scrolling right). Let's consider some usecases: A is using a column B is using an adapted filter sidebar (you select a custom filter and the sidebar allows you to change the default values of the filter, like age, ...) C is with data in statusbar or with a tooltip appearing with hover over a name. 1/I need to now which Blank is 55 years on death. --> A: scroll to Blank, or start typing, expand Blank, search a Blank with age 55 --> B: set name Blank, select custom filter, set value filter to 55, enter --> C: like A but look in tooltip/statusbar 2/I need to now which Blank or Blenk or Blonk is 55 years on death --> A: now you have to expand several names, start looking --> B: just set name to Bl[aeo]nk, check regular expression box, and press enter --> C: like A but look in tooltip/statusbar 3/I need a person with estimated age 55 in 1830. --> A: reset column to year 1830. As sort is not possible, you cannot find the person --> B: select filter, set age to 55, year to 1830, press enter --> C: like A So, I would conclude, it does not hurt to add the column, but will you really use it? The only problem with filters might be speed/performance. However, you need to know name already to do A, and search on name can be optimized with filter via database access methods if needed. Benny Quoting "Douglas S. Blank" <db...@cs...>: > Benny, > > Thanks for the comments. I agree that these values need filters, but I'm > thinking ahead. With an *estimated* "age at death", and estimated "age on > date", I want to also see these values. If you go back 350 years, there > may be quite a range to them, and a filter may not be the best way to > search for them. Your range filter can be useful, but I want to visualize > the people at that point in time, and the displayed age really helps. > > A filter with a combined displayed value is the best solution. I wouldn't > want to have to set a different filter for each age in the census. Set the > filter to select a subset, and then see the ages at a particular year. > > These columns don't take any longer than, say, spouse, to retrieve and > build. They only display when you have them selected, are cached, and only > are computed for the names on the screen (like all of the other columns). > But having a filter on these fields will be slow, as it has to compute it > for every one of them. When we make a filter, we might want to think about > actually moving computed values to the database. But that is step two, I > think. Step one is the display. > > Where do we stop in making columns to display? There should be as many as > users can use. There is no need to keep the possibilities small. There is > no penalty for having a large number of possible columns, and the > infrastructure is in place to make these a one-time computation per row. > If you don't want to see them, there is zero impact on your view. > > -Doug > > On Fri, February 9, 2007 3:45 am, ben...@ug... wrote: >> I think adding some calculated fields to the dialogs of gramps is a good >> idea. >> >> Adding it to the person view is in my view not good, and is actually a >> workaround for the not so good working filter search in GRAMPS. >> >> Let me explain: >> >> You can let users do these searches without columns, with more >> flexebility with >> filters. You could make a filter now to add this functionality to 2.2.7, >> independent if dialog or view is adapted. The filter would still work in >> 2.3. >> Least programming for maximum functionality, and availability to >> reports at the >> same moment. >> >> The deeper reason for the question you ask shows a weak point in GRAMPS: >> difficulty to work with filters! You could make a filter: 'Age on death >> <val>' >> or 'Age on death between <age1> and <age2>' or 'Age on <date> between >> <val> and >> <val>', and people would already be happy. >> However, the problem I percieve is: changing a value for a different >> search >> quickly is not possible: call filter editor, add rule, select correct rule >> (of >> the many!), enter data, save rule, save filter, select in filter siderbar, >> enter. >> >> A search like 'Age on death <val>' should be possible from the filter >> sidebar >> somehow with a minimum of mouse clicks, and a maximum of user >> friendlyness. >> Then adding fields in person view, is not needed (sorting view would take >> as >> long as doing the filter search I think). A general method for doing >> easier >> filter search should be developed, instead of adding more and more derived >> columns, and having the user relate to column sorting and searching in the >> columns (still not easy). >> >> So, I'm not so sure adding them as columns to the person view is a good >> idea. >> Where do you stop? Also, how does it impact performance? After all the >> performance changes for 2.2.6, it would not be nice to start running in >> problems again. >> >> Benny >> >> >> Quoting "Douglas S. Blank" <db...@cs...>: >> >>> As I was working toward making estimates of birth dates, death dates, >>> and >>> marriage dates better, I realized that gramps first needs to better use >>> the dates that we know for certain. >>> >>> For example, it is very difficult to find someone in the database that >>> died at a particular age, say at 114. This was made apparent when >>> running >>> either Eero's StatisticsChart or the temporary Lifespan Distribution >>> view >>> that I sent around yesterday. Trying to locate the anomalies that appear >>> in these reports is basically impossible. >>> >>> Also, it is not easy to find those people that would have been about 55 >>> years old in the year 1851. This is something that I find myself doing >>> quite often, for example, when looking at census reports. This is >>> possible >>> using the event comparison, sorting on birth dates, and doing some >>> addition, but isn't easy. >>> >>> So, I have two new columns for the Person view: "Age at Death", and "Age >>> on Date". I think these are very useful; I suspect that people might >>> like >>> to have them in the official gramps. >>> >>> If so, this brings up some questions: >>> >>> 1) Don and Richard both indicated that the model/view code may change >>> soon. These two columns are pretty simple code (except for the date, see >>> next), so shouldn't have a large impact. Should we add them to 2.2 >>> and/or >>> 2.3, or wait till the new model/view is implemented? >>> >>> 2) The "Age on Date" requires a date. I imagine that the column heading >>> should be "Age on December 31, 1851", or "Age in 1851". Of course, that >>> date should be easy to change. Where should this date be stored? How >>> should it be set? Some ideas: >>> >>> - don't store it. keep it in memory, and let it default to today's date >>> on >>> startup >>> - keep it and set in Preferences (clumsy, but easy to do) >>> - set it via a dialog by right-clicking on that column >>> >>> 3) Is the plan to have gramps support sortable person-view columns? If >>> so, >>> that would be great. If not, then we may need to figure out how to get >>> these ages in a sorted fashion. >>> >>> 4) Do you think that both of these virtual columns would make good >>> values >>> to filter on? >>> >>> 5) Are there other age-related values that you would like to see in the >>> person view, or in other places? >>> >>> Thanks for any and all feedback, >>> >>> -Doug > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your > job easier. > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |
From: Douglas S. B. <db...@cs...> - 2007-02-09 20:00:21
|
ben...@ug... wrote: > Doug, > > you did not convince me yet. I should add that I'm not just trying to convince you, but me as well :) > First, we agree a filter should be created. Great. I don't think it would be a good idea to create a filter for which the matching rows can't be easily verified. You may have to actually see the age columns displayed to see exactly what I mean. Take a hypothetical filter "Age at Death between 55 and 60". Sounds simple, eh? But in reality the age at death is based on a range of birth dates, and range of death dates. This is nicely computed in ReportBase.ReportUtils.estimate_age(), but it isn't always what you expect. So this filter is actually using three different age ranges (birth, death, and match range). For example, you might actually see data in this column like "-15 to 30". That means that this person died somewhere between 15 years before he was born, to 30 years later. Obviously, there is a logical error in one of the dates, and one that you might not have noticed before. Things get even harrier when you add in the notion of gramps-estimated ages. The way that I initially described the reason for using these columns was for *finding* rows. That was a mistake and, as you point out, can be performed via a filter. (Of course, you can also find data by looking, and I sometimes I like to do that too.) But I should have motivated these columns as another tool to help you see your genealogical data. Sometimes, I find interesting connections by just wondering around through the data. Someone mentioned here last week about the possibility of finding two branches of his tree that lived on the same street, about the same time. You wouldn't necessarily know to make that an explicit filter, but you can discover it by looking at visualization tools, like maps and column data. > So, should also a column be added? You are correct in noting it does not hurt, > you can disactivate it, and it would probably not be the default. However, we > should also not add columns that are not needed. A user should be directed to > the best tool to do a job. Offering two tools is confusing if not needed, and > one is better. > > Disadvantage: you cannot sort in person view. you cannot change column > order (so > seeing the column might involve scrolling right). Those aren't disadvantages to having the column, those are limitations to the current interface, or someone's setup. > Let's consider some usecases: > A is using a column > B is using an adapted filter sidebar (you select a custom filter and > the sidebar > allows you to change the default values of the filter, like age, ...) > C is with data in statusbar or with a tooltip appearing with hover over > a name. > > 1/I need to now which Blank is 55 years on death. > --> A: scroll to Blank, or start typing, expand Blank, search a Blank with age > 55 > --> B: set name Blank, select custom filter, set value filter to 55, enter > --> C: like A but look in tooltip/statusbar > > 2/I need to now which Blank or Blenk or Blonk is 55 years on death > --> A: now you have to expand several names, start looking > --> B: just set name to Bl[aeo]nk, check regular expression box, and > press enter > --> C: like A but look in tooltip/statusbar > > 3/I need a person with estimated age 55 in 1830. > --> A: reset column to year 1830. As sort is not possible, you cannot find the > person > --> B: select filter, set age to 55, year to 1830, press enter > --> C: like A > > > So, I would conclude, it does not hurt to add the column, but will you really > use it? > The only problem with filters might be speed/performance. However, you need to > know name already to do A, and search on name can be optimized with filter via > database access methods if needed. Here is one use-case that I am thinking of: I have a ship's log of the passengers that made the trip from LaHavre to New Orleans. I'm looking for members of my family, but I'm not sure which ones came over together. The full names are listed, and there are many misspellings. I set the date for "Age on Date" for the time of the ship's log. I glance down the ship's log, and through my filtered subset of family members. In the log, I see: "G. Blank, 55" "K. Blank, 53" "?, Blank, 26" "?, Blank, 13" In my Gramp's people view I can easily see which one's are close, and then see if these are indeed my family. There are many logs like this (census lists, ship's logs, wills and testaments) that give ages and partial names. Ok, I think I have convinced myself that I need these columns. Can anyone else use this option? -Doug > Benny > > Quoting "Douglas S. Blank" <db...@cs...>: > >> Benny, >> >> Thanks for the comments. I agree that these values need filters, but I'm >> thinking ahead. With an *estimated* "age at death", and estimated "age on >> date", I want to also see these values. If you go back 350 years, there >> may be quite a range to them, and a filter may not be the best way to >> search for them. Your range filter can be useful, but I want to visualize >> the people at that point in time, and the displayed age really helps. >> >> A filter with a combined displayed value is the best solution. I wouldn't >> want to have to set a different filter for each age in the census. Set the >> filter to select a subset, and then see the ages at a particular year. >> >> These columns don't take any longer than, say, spouse, to retrieve and >> build. They only display when you have them selected, are cached, and only >> are computed for the names on the screen (like all of the other columns). >> But having a filter on these fields will be slow, as it has to compute it >> for every one of them. When we make a filter, we might want to think about >> actually moving computed values to the database. But that is step two, I >> think. Step one is the display. >> >> Where do we stop in making columns to display? There should be as many as >> users can use. There is no need to keep the possibilities small. There is >> no penalty for having a large number of possible columns, and the >> infrastructure is in place to make these a one-time computation per row. >> If you don't want to see them, there is zero impact on your view. >> >> -Doug >> >> On Fri, February 9, 2007 3:45 am, ben...@ug... wrote: >>> I think adding some calculated fields to the dialogs of gramps is a good >>> idea. >>> >>> Adding it to the person view is in my view not good, and is actually a >>> workaround for the not so good working filter search in GRAMPS. >>> >>> Let me explain: >>> >>> You can let users do these searches without columns, with more >>> flexebility with >>> filters. You could make a filter now to add this functionality to 2.2.7, >>> independent if dialog or view is adapted. The filter would still work in >>> 2.3. >>> Least programming for maximum functionality, and availability to >>> reports at the >>> same moment. >>> >>> The deeper reason for the question you ask shows a weak point in GRAMPS: >>> difficulty to work with filters! You could make a filter: 'Age on death >>> <val>' >>> or 'Age on death between <age1> and <age2>' or 'Age on <date> between >>> <val> and >>> <val>', and people would already be happy. >>> However, the problem I percieve is: changing a value for a different >>> search >>> quickly is not possible: call filter editor, add rule, select correct rule >>> (of >>> the many!), enter data, save rule, save filter, select in filter siderbar, >>> enter. >>> >>> A search like 'Age on death <val>' should be possible from the filter >>> sidebar >>> somehow with a minimum of mouse clicks, and a maximum of user >>> friendlyness. >>> Then adding fields in person view, is not needed (sorting view would take >>> as >>> long as doing the filter search I think). A general method for doing >>> easier >>> filter search should be developed, instead of adding more and more derived >>> columns, and having the user relate to column sorting and searching in the >>> columns (still not easy). >>> >>> So, I'm not so sure adding them as columns to the person view is a good >>> idea. >>> Where do you stop? Also, how does it impact performance? After all the >>> performance changes for 2.2.6, it would not be nice to start running in >>> problems again. >>> >>> Benny >>> >>> >>> Quoting "Douglas S. Blank" <db...@cs...>: >>> >>>> As I was working toward making estimates of birth dates, death dates, >>>> and >>>> marriage dates better, I realized that gramps first needs to better use >>>> the dates that we know for certain. >>>> >>>> For example, it is very difficult to find someone in the database that >>>> died at a particular age, say at 114. This was made apparent when >>>> running >>>> either Eero's StatisticsChart or the temporary Lifespan Distribution >>>> view >>>> that I sent around yesterday. Trying to locate the anomalies that appear >>>> in these reports is basically impossible. >>>> >>>> Also, it is not easy to find those people that would have been about 55 >>>> years old in the year 1851. This is something that I find myself doing >>>> quite often, for example, when looking at census reports. This is >>>> possible >>>> using the event comparison, sorting on birth dates, and doing some >>>> addition, but isn't easy. >>>> >>>> So, I have two new columns for the Person view: "Age at Death", and "Age >>>> on Date". I think these are very useful; I suspect that people might >>>> like >>>> to have them in the official gramps. >>>> >>>> If so, this brings up some questions: >>>> >>>> 1) Don and Richard both indicated that the model/view code may change >>>> soon. These two columns are pretty simple code (except for the date, see >>>> next), so shouldn't have a large impact. Should we add them to 2.2 >>>> and/or >>>> 2.3, or wait till the new model/view is implemented? >>>> >>>> 2) The "Age on Date" requires a date. I imagine that the column heading >>>> should be "Age on December 31, 1851", or "Age in 1851". Of course, that >>>> date should be easy to change. Where should this date be stored? How >>>> should it be set? Some ideas: >>>> >>>> - don't store it. keep it in memory, and let it default to today's date >>>> on >>>> startup >>>> - keep it and set in Preferences (clumsy, but easy to do) >>>> - set it via a dialog by right-clicking on that column >>>> >>>> 3) Is the plan to have gramps support sortable person-view columns? If >>>> so, >>>> that would be great. If not, then we may need to figure out how to get >>>> these ages in a sorted fashion. >>>> >>>> 4) Do you think that both of these virtual columns would make good >>>> values >>>> to filter on? >>>> >>>> 5) Are there other age-related values that you would like to see in the >>>> person view, or in other places? >>>> >>>> Thanks for any and all feedback, >>>> >>>> -Doug |
From: <rom...@ya...> - 2007-02-09 09:01:46
|
> Adding it to the person view is in my view not good, Why not using the Status bar ? a third option on View preferences >> Status Bar >> The Status Bar is located to the right of the Progress Bar, on the very bottom of the GRAMPS window. It displays information about current GRAMPS activity and contextual information about the selected items. http://gramps-project.org/grampsmanuals/gramps-manual-en/ch02.html#mainwin-fig >> Status bar >> This option controls the information displayed in the status bar. This can be either the Active Person's name and GRAMPS ID or Active Person's relationship to the Home person. http://gramps-project.org/grampsmanuals/gramps-manual-en/ch04.html#gramps-prefs-display ___________________________________________________________________________ Yahoo! Mail rvente le mail ! Duvrez le nouveau Yahoo! Mail et son interface rlutionnaire. http://fr.mail.yahoo.com |
From: Douglas S. B. <db...@cs...> - 2007-02-09 12:34:15
|
On Fri, February 9, 2007 4:06 am, J=C3=A9r=C3=B4me wrote: >> Adding it to the person view is in my view not good, > > Why not using the Status bar ? > a third option on View preferences That is not bad (better than *just* a filter), but I think it would actually take more code and be less useful than just having a column. -Doug >>> Status Bar >>> The Status Bar is located to the right of the Progress Bar, on the ve= ry >>> bottom of the GRAMPS window. It displays information about current >>> GRAMPS activity and contextual information about the selected items. > > http://gramps-project.org/grampsmanuals/gramps-manual-en/ch02.html#main= win-fig > >>> Status bar >>> This option controls the information displayed in the status bar. Thi= s >>> can be either the Active Person's name and GRAMPS ID or Active Person= 's >>> relationship to the Home person. > > http://gramps-project.org/grampsmanuals/gramps-manual-en/ch04.html#gram= ps-prefs-display > > > > > > > > _______________________________________________________________________= ____ > Yahoo! Mail r=E9invente le mail ! D=E9couvrez le nouveau Yahoo! Mail et= son > interface r=E9volutionnaire. > http://fr.mail.yahoo.com > > > -----------------------------------------------------------------------= -- > Using Tomcat but need to do more? Need to support web services, securit= y? > Get stuff done quickly with pre-integrated technology to make your job > easier. > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geron= imo > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat= =3D121642_______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > --=20 Douglas S. Blank Associate Professor, Bryn Mawr College http://cs.brynmawr.edu/~dblank/ Office: 610 526 601 |
From: Eero T. <ee...@us...> - 2007-02-09 20:21:24
|
Hi, On Friday 09 February 2007 05:08, Douglas S. Blank wrote: > As I was working toward making estimates of birth dates, death dates, and > marriage dates better, I realized that gramps first needs to better use > the dates that we know for certain. > > For example, it is very difficult to find someone in the database that > died at a particular age, say at 114. This was made apparent when running > either Eero's StatisticsChart or the temporary Lifespan Distribution view > that I sent around yesterday. Trying to locate the anomalies that appear > in these reports is basically impossible. > > Also, it is not easy to find those people that would have been about 55 > years old in the year 1851. This is something that I find myself doing > quite often, for example, when looking at census reports. This is > possible using the event comparison, sorting on birth dates, and doing > some addition, but isn't easy. > > So, I have two new columns for the Person view: "Age at Death", and "Age > on Date". I think these are very useful; I suspect that people might like > to have them in the official gramps. I like these. IMHO second might be better just as filter because it requires inputting data. As a column it IMHO should be just "Age now". Or as "Age at Death" is for dead people and "Age now" for living one, maybe they could be joined to same column? What would be show if person is missing birth (or death) date? And how those persons would be sorted? - Eero |
From: Douglas S. B. <db...@cs...> - 2007-02-09 20:31:17
|
Eero Tamminen wrote: > Hi, > > On Friday 09 February 2007 05:08, Douglas S. Blank wrote: >> As I was working toward making estimates of birth dates, death dates, and >> marriage dates better, I realized that gramps first needs to better use >> the dates that we know for certain. >> >> For example, it is very difficult to find someone in the database that >> died at a particular age, say at 114. This was made apparent when running >> either Eero's StatisticsChart or the temporary Lifespan Distribution view >> that I sent around yesterday. Trying to locate the anomalies that appear >> in these reports is basically impossible. >> >> Also, it is not easy to find those people that would have been about 55 >> years old in the year 1851. This is something that I find myself doing >> quite often, for example, when looking at census reports. This is >> possible using the event comparison, sorting on birth dates, and doing >> some addition, but isn't easy. >> >> So, I have two new columns for the Person view: "Age at Death", and "Age >> on Date". I think these are very useful; I suspect that people might like >> to have them in the official gramps. > > I like these. IMHO second might be better just as filter because it > requires inputting data. As a column it IMHO should be just "Age now". > Or as "Age at Death" is for dead people and "Age now" for living one, > maybe they could be joined to same column? I agree, but I really like "Age on Date" as a column, if we can figure out how to input the date, and where to store it, easily. > What would be show if person is missing birth (or death) date? > And how those persons would be sorted? People that don't have a valid computed age show as a blank. Sorting is easy, as it is just the age "%3d" and a age range shows as "%3d-%d" so that they sort correctly. I expect that gramps-estimated ages would be followed by and asterisk (or some symbol) so that everything would sort correctly, marker colors would still work, but you could see the estimated ages. (Gramps-Estimated ages would be a toggle to show/not show). -Doug > > - Eero > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier. > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: <ben...@ug...> - 2007-02-09 22:15:22
|
Doug, Although extra columns would fit the needs you put forward, there are still some problems. I think you must understand it is extremely unlikely that much extra columns are added, let alone columns that need processing time to calculate. Performance of the people view is very important. For the same reason sorting on columns will probably not be allowed (could be made to work, but not with present implementation which is needed for speed reasons). The entire improvement done in 2.2.5 can disappear with this. Perhaps you should try your hack on the 120.000 database available on http://developers.gramps-project.org/tiki-index.php?page=GrampsPerformance and test the impact. Storing a calculated value in a database is also highly unlikely. It could cause disaster for the saving time of a person record, as well as problems when the algorithm is improved after an upgrade, ... A filter has the disadvantage as you say that you do not see why it returns the data you request. Like if you do name search Jon, and you get Jan returned. You can deduce that Jan has an alternate name Jon, but you do not see it. This is a general issue with filters, a general solution for this problem not requiring the addition of columns would be most welcome. Benny Quoting "Douglas S. Blank" <db...@cs...>: > Eero Tamminen wrote: >> Hi, >> >> On Friday 09 February 2007 05:08, Douglas S. Blank wrote: >>> As I was working toward making estimates of birth dates, death dates, and >>> marriage dates better, I realized that gramps first needs to better use >>> the dates that we know for certain. >>> >>> For example, it is very difficult to find someone in the database that >>> died at a particular age, say at 114. This was made apparent when running >>> either Eero's StatisticsChart or the temporary Lifespan Distribution view >>> that I sent around yesterday. Trying to locate the anomalies that appear >>> in these reports is basically impossible. >>> >>> Also, it is not easy to find those people that would have been about 55 >>> years old in the year 1851. This is something that I find myself doing >>> quite often, for example, when looking at census reports. This is >>> possible using the event comparison, sorting on birth dates, and doing >>> some addition, but isn't easy. >>> >>> So, I have two new columns for the Person view: "Age at Death", and "Age >>> on Date". I think these are very useful; I suspect that people might like >>> to have them in the official gramps. >> >> I like these. IMHO second might be better just as filter because it >> requires inputting data. As a column it IMHO should be just "Age now". >> Or as "Age at Death" is for dead people and "Age now" for living one, >> maybe they could be joined to same column? > > I agree, but I really like "Age on Date" as a column, if we can figure > out how to input the date, and where to store it, easily. > >> What would be show if person is missing birth (or death) date? >> And how those persons would be sorted? > > People that don't have a valid computed age show as a blank. Sorting is > easy, as it is just the age "%3d" and a age range shows as "%3d-%d" so > that they sort correctly. I expect that gramps-estimated ages would be > followed by and asterisk (or some symbol) so that everything would sort > correctly, marker colors would still work, but you could see the > estimated ages. (Gramps-Estimated ages would be a toggle to show/not show). > > -Doug > >> >> - Eero >> >> ------------------------------------------------------------------------- >> Using Tomcat but need to do more? Need to support web services, security? >> Get stuff done quickly with pre-integrated technology to make your >> job easier. >> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo >> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 >> _______________________________________________ >> Gramps-devel mailing list >> Gra...@li... >> https://lists.sourceforge.net/lists/listinfo/gramps-devel >> > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your > job easier. > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |
From: Duncan L. <dli...@gm...> - 2007-02-16 10:07:36
|
On Thu, 2007-02-08 at 22:08 -0500, Douglas S. Blank wrote: > Eero's StatisticsChart I can't find this one where is it? Duncan --=20 Linux user: 372812 | GPG key ID: 21A8C63A | http://lithgow-schmidt.dk |
From: Douglas S. B. <db...@cs...> - 2007-02-16 12:41:07
|
On Fri, February 16, 2007 5:07 am, Duncan Lithgow wrote: > On Thu, 2007-02-08 at 22:08 -0500, Douglas S. Blank wrote: >> Eero's StatisticsChart > I can't find this one where is it? That one is already included with gramps, under Reports -> Graphical -> Statistics Chart, and named gramps2/plugins/StatisticsChart.py. Thanks for making this list of plugins; quite useful! BTW, I expanded the code I originally posted for retrieving and installing plugins and made an "automatic upgrade" (for another project). It can read a zipfile with a manifest file detailing where to put the files. It could be turned into a plugin, and it could read your list... Just thinking. For more details, see: http://cvs.cs.brynmawr.edu/cgi-bin/viewcvs.cgi/Myro/myro/system.py?rev=HEAD&content-type=text/vnd.viewcvs-markup -Doug > Duncan > > -- > Linux user: 372812 | GPG key ID: 21A8C63A | http://lithgow-schmidt.dk > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV_______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > -- Douglas S. Blank Associate Professor, Bryn Mawr College http://cs.brynmawr.edu/~dblank/ Office: 610 526 601 |