You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(35) |
Jun
(11) |
Jul
(41) |
Aug
(96) |
Sep
(29) |
Oct
(44) |
Nov
(70) |
Dec
(61) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(126) |
Feb
(31) |
Mar
(64) |
Apr
(84) |
May
(57) |
Jun
(56) |
Jul
(20) |
Aug
(23) |
Sep
(31) |
Oct
(19) |
Nov
(60) |
Dec
(34) |
2003 |
Jan
(30) |
Feb
(61) |
Mar
(32) |
Apr
(30) |
May
(78) |
Jun
(55) |
Jul
(111) |
Aug
(108) |
Sep
(104) |
Oct
(98) |
Nov
(92) |
Dec
(73) |
2004 |
Jan
(71) |
Feb
(70) |
Mar
(68) |
Apr
(40) |
May
(118) |
Jun
(51) |
Jul
(71) |
Aug
(251) |
Sep
(77) |
Oct
(155) |
Nov
(74) |
Dec
(57) |
2005 |
Jan
(183) |
Feb
(94) |
Mar
(170) |
Apr
(242) |
May
(233) |
Jun
(42) |
Jul
(69) |
Aug
(70) |
Sep
(99) |
Oct
(60) |
Nov
(65) |
Dec
(210) |
2006 |
Jan
(169) |
Feb
(99) |
Mar
(31) |
Apr
(179) |
May
(142) |
Jun
(72) |
Jul
(131) |
Aug
(98) |
Sep
(110) |
Oct
(189) |
Nov
(262) |
Dec
(207) |
2007 |
Jan
(376) |
Feb
(255) |
Mar
(168) |
Apr
(174) |
May
(167) |
Jun
(192) |
Jul
(197) |
Aug
(171) |
Sep
(307) |
Oct
(572) |
Nov
(454) |
Dec
(471) |
2008 |
Jan
(707) |
Feb
(365) |
Mar
(464) |
Apr
(410) |
May
(251) |
Jun
(142) |
Jul
(112) |
Aug
(143) |
Sep
(94) |
Oct
(280) |
Nov
(337) |
Dec
(232) |
2009 |
Jan
(508) |
Feb
(491) |
Mar
(363) |
Apr
(280) |
May
(186) |
Jun
(250) |
Jul
(231) |
Aug
(487) |
Sep
(189) |
Oct
(344) |
Nov
(456) |
Dec
(439) |
2010 |
Jan
(514) |
Feb
(725) |
Mar
(591) |
Apr
(256) |
May
(209) |
Jun
(75) |
Jul
(118) |
Aug
(248) |
Sep
(230) |
Oct
(393) |
Nov
(368) |
Dec
(276) |
2011 |
Jan
(457) |
Feb
(308) |
Mar
(358) |
Apr
(277) |
May
(333) |
Jun
(320) |
Jul
(198) |
Aug
(186) |
Sep
(87) |
Oct
(238) |
Nov
(123) |
Dec
(129) |
2012 |
Jan
(127) |
Feb
(182) |
Mar
(208) |
Apr
(134) |
May
(230) |
Jun
(138) |
Jul
(126) |
Aug
(176) |
Sep
(231) |
Oct
(235) |
Nov
(164) |
Dec
(219) |
2013 |
Jan
(316) |
Feb
(371) |
Mar
(393) |
Apr
(165) |
May
(321) |
Jun
(301) |
Jul
(124) |
Aug
(183) |
Sep
(191) |
Oct
(285) |
Nov
(172) |
Dec
(196) |
2014 |
Jan
(392) |
Feb
(284) |
Mar
(134) |
Apr
(206) |
May
(123) |
Jun
(115) |
Jul
(41) |
Aug
(157) |
Sep
(122) |
Oct
(124) |
Nov
(63) |
Dec
(56) |
2015 |
Jan
(249) |
Feb
(335) |
Mar
(277) |
Apr
(98) |
May
(274) |
Jun
(214) |
Jul
(142) |
Aug
(240) |
Sep
(57) |
Oct
(77) |
Nov
(18) |
Dec
(171) |
2016 |
Jan
(217) |
Feb
(167) |
Mar
(62) |
Apr
(180) |
May
(270) |
Jun
(86) |
Jul
(112) |
Aug
(50) |
Sep
(57) |
Oct
(91) |
Nov
(62) |
Dec
(101) |
2017 |
Jan
(116) |
Feb
(115) |
Mar
(85) |
Apr
(35) |
May
(54) |
Jun
(123) |
Jul
(65) |
Aug
(35) |
Sep
(103) |
Oct
(28) |
Nov
(21) |
Dec
(7) |
2018 |
Jan
(27) |
Feb
(64) |
Mar
(42) |
Apr
(72) |
May
(49) |
Jun
(24) |
Jul
(18) |
Aug
(4) |
Sep
(9) |
Oct
(39) |
Nov
(11) |
Dec
(45) |
2019 |
Jan
(35) |
Feb
(24) |
Mar
(28) |
Apr
(38) |
May
(16) |
Jun
(41) |
Jul
|
Aug
(49) |
Sep
(41) |
Oct
(22) |
Nov
(15) |
Dec
(32) |
2020 |
Jan
(61) |
Feb
(3) |
Mar
(31) |
Apr
(29) |
May
(38) |
Jun
(16) |
Jul
(26) |
Aug
(87) |
Sep
(12) |
Oct
(4) |
Nov
(14) |
Dec
(5) |
2021 |
Jan
(3) |
Feb
(4) |
Mar
(26) |
Apr
(2) |
May
(55) |
Jun
(64) |
Jul
(96) |
Aug
(71) |
Sep
(1) |
Oct
(2) |
Nov
(17) |
Dec
(5) |
2022 |
Jan
(23) |
Feb
(22) |
Mar
(9) |
Apr
(7) |
May
(8) |
Jun
(6) |
Jul
(2) |
Aug
|
Sep
(14) |
Oct
(10) |
Nov
(1) |
Dec
(10) |
2023 |
Jan
(3) |
Feb
|
Mar
|
Apr
(34) |
May
(14) |
Jun
(25) |
Jul
(10) |
Aug
(13) |
Sep
|
Oct
|
Nov
(2) |
Dec
(7) |
2024 |
Jan
(1) |
Feb
(23) |
Mar
(33) |
Apr
(19) |
May
(5) |
Jun
(46) |
Jul
(2) |
Aug
(7) |
Sep
(7) |
Oct
|
Nov
|
Dec
|
From: Trevor R. <tr...@rh...> - 2005-12-28 05:36:21
|
On Wed, 28 Dec 2005 04:21 pm, db...@br... wrote: > Eero, > > Thanks for the feedback. I've taken your comments into account, and have a > second version available at: > > http://emergent.brynmawr.edu/emergent/GrampsCalendarReport Once I clicked ok to generate the calendar to pdf I got the following error. So, is this a problem in the plugin or with gramps itself? GRAMPS has encountered an internal error. Please copy the message below and post a bug report at http://sourceforge.net/projects/gramps or send an email message to gra...@li... GRAMPS : 2.0.10-0.CVS20051207 LANG : en_GB LANGUAGE : en_GB:en Python : 2.4.1 final GTK : 2.8.3 PyGTK : 2.6.2 OS : Mandriva Linux release 2006.0 (Community) for i586 Traceback (most recent call last): File "/home/trevor/gramps2/src/Report.py", line 1891, in report MyReport.write_report() File "./plugins/Calendar.py", line 212, in write_report self.get_holidays(self.options_class.options_dict["year"]) # FIXME: pass in country code File "./plugins/Calendar.py", line 198, in get_holidays element = parser.Parse('/usr/share/gramps/plugins/holidays.xml') # FIXME: put this file where it belongs File "./plugins/Calendar.py", line 599, in Parse ParserStatus = Parser.Parse(open(filename,'r').read(), 1) IOError: [Errno 2] No such file or directory: '/usr/share/gramps/plugins/holidays.xml' -- Regards Trevor Rhodes =========================================== Powered by Linux - Mandriva 2005LE Registered Linux user # 290542 at http://counter.li.org Registered Machine #'s 186951 = Mandriva Club Silver Member Source : my 100 % Microsoft-free personal computer. =========================================== 16:34:55 up 5 days, 1:43, 3 users, load average: 0.34, 0.40, 0.28 Never mud wrestle with a pig.. you get dirty and the pig enjoys it! Never try to teach a pig to dance. You waste your time and annoy the pig. Theoretically pigs can fly if propelled with enough force. |
From: <db...@br...> - 2005-12-28 05:21:22
|
Eero, Thanks for the feedback. I've taken your comments into account, and have = a second version available at: http://emergent.brynmawr.edu/emergent/GrampsCalendarReport I realized that having major holidays on the calendar would make it much more useful, and was something I wanted to have on the calendar's for my family. Also, being able to see date events through time might be a very nice tool for exploring family histories. For example, dying on May 6th, 1937 in Lakehurst, New Jersey might not ring any bells. But if you happen to look at your family tree data on a calendar with major events, you might suspect that the Hindenburg might have played a role. So I set out to try to make an easy way for users to add events to the calendar. I wanted some events to be recurring (for example, every year o= n April 1, but also like the third Wednesday in August). I ended up making an XML file with some fields. It is simple, can't do everything, but can be extended in many ways. This can get complicated if you want to reflect specific recurring holidays because they have moved around dpending on th= e time and the country. But this simple interface can handle that if one wanted to. If the calendar ends up being included in gramps, I'll write u= p some docs. There are still some font issues, and I used gettext for the month names and the week days. That seemed to be the most reliable method. Those will be english until they are translated. Some questions: 1. Where should the xml file go where it will be able to be found? How does one then construct the path to that location? Is there something els= e like that in gramps (the user can edit it, but needs to be found automatically)? 2. What would be the easiest BaseDoc method to use to print a square of text that would wrap text, and detect that I had too much text? 3. How do I get the country code of the LANG? The holidays.xml file can b= e broken into sections based on country code. Is there a better way? I assume that the text in those sections will be in the appropriate language. 4. It appears that you can edit the style "default" but those changes are overwritten. Is that right? If so, maybe the default style shouldn't be editable. Thanks for hints, and additional feedback. If someone would like to work on the calendar, I think I have done about as much as I can do. - |
From: Don A. <don...@co...> - 2005-12-27 22:42:30
|
Don't worry. I don't see any major change of direction. Many people request features like "Be a web based program so all my family can enter information into the database". The only problem is they do not think of the quality of the results. Give Aunt Martha access to change things in your database, and she may remember that "Cousin Harold got sick and died 50 years ago, and Cousin Louise said he died of Ebola." Do you want her changing your data based off an old memory of what she thinks someone once said? Or would you prefer to have a bit more proof? Every genealogist has their own level of required proof. And it is up to every genealogist to decide what that level is. Pulling data from the internet and assuming it is true is probably even less reliable that allowing a novice family member directly edit your data. Don=20 On Tue, 2005-12-27 at 12:20 -0500, Jim Winfrey wrote: > wb wrote: >=20 > >On Tuesday December 27 2005 00:47, Alexandre Prokoudine wrote: > > =20 > > > >>Now, seriously, this is even more interesting, because the more > >>people publish their genealogy reports, the more common relatives > >>will be found. > >> =20 > >> > > > >I'm not very experienced at genealogy, but there are a LOT of data=20 > >quality problems with internet-published genealogical data. In the=20 > >short time I have done this, I have found contradictory, incomplete,=20 > >and just plain wrong information. > > > >Many times in the last few months, I wished that Google would get into=20 > >that business and beat this data into shape. > > > >If you can't verify information at the source, you can build a big=20 > >database, and have no confidence in it at all. Beside that, few people=20 > >are willing to publish their databases (like GED files). Most want to=20 > >present pretty webpages, which are sometimes worse than nothing for =20 > >researching your heritage. Not many people want to 'release' their=20 > >information for free. They do want to impress you with their=20 > >cleverness at researching all of that information. > > > > -- WB > > =20 > > > A couple of genealogy programs have built in IGI search capabilities. =20 > The results just from within the Family Search database have numerous=20 > errors. You can get 10 hits on a person and it will have 6 different=20 > birth dates. The problem, I think, is that people learn to use on line=20 > databases before they learn to be genealogists. They make assumptions,=20 > blindly copy others errors, make errors on their own and occasionally=20 > deliberately change the facts to make the person "fit". I hope Gramps=20 > will remain a tool to manage and report data and not try to become the=20 > Family Tree Maker of Unix bases OPs. >=20 > Jim >=20 >=20 > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi= les > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel >=20 --=20 Don Allingham <don...@co...> |
From: Eero T. <ee...@us...> - 2005-12-27 20:14:12
|
Hi, On Tuesday 27 December 2005 08:54, db...@br... wrote: > I've been hacking on a calendar graphical report using the new interface > with GRAMPS 2.0, and wanted to let you know about it sooner than later. > This time of year I usually print a calendar with all my relatives > birthdays and anniversaries. This year, I really wanted to do it from > GRAMPS. This is my first GRAMPS report, and someone may want to look over > the logic to get spouses. But it works for me. > > You can find some screen dumps and the code here: > > http://emergent.brynmawr.edu/emergent/GrampsCalendarReport > > The report has options to select a filter, the year of the calendar, > living people only, birthdays and/or anniversaries. > > In addition to generating a calendar, this code also has implemented part > of a proposal to make the report interface a little kinder on the coder. > I did this to make report writing easier by having Python do all of the > dirty work. This also has the benefit of making the code a little more > modular, and separates the details of the GUI from the details of the > logic of the report. > > In any event, the code builds on the existing report infrastructure, and > should run on GRAMPS 2.0. > > Let me know if you have issues or suggestions. The calendar doesn't look quite OK. The names overlap day numbers, the numbers are very small and month is shown as a number. see the attached screenshot. I know this is very early, but I'd like to suggest some easy eye-candy enhancements too: - Make the day numbers significantly larger and centered - Numbers for Sundays could be on another color (or be gray instead of black) - The top part (with month and weekday names) could have a very light background color There are two ways to localize the day names, either use gettext for them, or calendar specific locale stuff. Using gettext would probably be easier and more flexible (for localizers), but locale functions use would automatically produce correct day names... (not sure about how to do that in Python though) - Eero |
From: Steve H. <dig...@mi...> - 2005-12-27 18:34:39
|
[Perhaps a thread for the users list instead of here?] From: wb, Dec 27, 2005 9:58 AM > > I'm not very experienced at genealogy, but there are a LOT of data > quality problems with internet-published genealogical data. In the > short time I have done this, I have found contradictory, incomplete, > and just plain wrong information. Yes, the internet has not helped at all with data reliability. It is still up to each researcher to value the data and to build a case based on that interpretation. > Many times in the last few months, I wished that Google would get > into that business and beat this data into shape. Google can not establish good information from bad. At best, it prioritizes info based on how users value it, but it can not resolve resolution beyond what it has. > If you can't verify information at the source, you can build a big > database, and have no confidence in it at all. Exactly! > Beside that, few people are willing to publish their databases (like > GED files). Most want to present pretty webpages, which are > sometimes worse than nothing for researching your heritage. Totally agreed. I prefer to find data in newspaper-boring websites, it tells me the researcher is concerned about their research, not presentation. > Not many people want to 'release' their information for free. Free GED files are nearly useless, most times they are assembled from others. What is most important is having primary evidence. Scans of actual documents are invaluable, and verbatim transcriptions almost as good (as long as I trust the recorder!). But how often have you been to a genealogy website that offers images of important primary documents? > They do want to impress you with their cleverness at researching all > of that information. I think it's more naivety. It takes a while in the trenches to begin to recognize what is valuable and how to present it as such. But it is easy to press a button and spew questionable data all over the web. -- Steve Hall [ digitect mindspring com ] :: My Hall Genealogy :: http://www.mindspring.com/~steve_hall/trees/hall/ |
From: Jim W. <ji...@li...> - 2005-12-27 17:21:49
|
wb wrote: >On Tuesday December 27 2005 00:47, Alexandre Prokoudine wrote: > > >>Now, seriously, this is even more interesting, because the more >>people publish their genealogy reports, the more common relatives >>will be found. >> >> > >I'm not very experienced at genealogy, but there are a LOT of data >quality problems with internet-published genealogical data. In the >short time I have done this, I have found contradictory, incomplete, >and just plain wrong information. > >Many times in the last few months, I wished that Google would get into >that business and beat this data into shape. > >If you can't verify information at the source, you can build a big >database, and have no confidence in it at all. Beside that, few people >are willing to publish their databases (like GED files). Most want to >present pretty webpages, which are sometimes worse than nothing for >researching your heritage. Not many people want to 'release' their >information for free. They do want to impress you with their >cleverness at researching all of that information. > > -- WB > > A couple of genealogy programs have built in IGI search capabilities. The results just from within the Family Search database have numerous errors. You can get 10 hits on a person and it will have 6 different birth dates. The problem, I think, is that people learn to use on line databases before they learn to be genealogists. They make assumptions, blindly copy others errors, make errors on their own and occasionally deliberately change the facts to make the person "fit". I hope Gramps will remain a tool to manage and report data and not try to become the Family Tree Maker of Unix bases OPs. Jim |
From: wb <wb...@va...> - 2005-12-27 16:13:48
|
On Tuesday December 27 2005 00:38, Julio Sanchez wrote: > 2005/12/27, wb <wb...@va...>: > > I publish some of my family graphs at > > http://personal.vallnet.com/~someguy/ > > Interesting, if I understood that right, that would make you a > distant relative of my wife, since I think she is descended from one > of Charles V great-great-great-grandfathers. I don't put great trust in my data from that far back. All of that I=20 received from GEDCOM files available on the net, and I have no estimate=20 of its' reliability. <snip> > You cannot put a graph on a huge PDF file. As far as know, 3240 > dots is the limit. You may view it well, but some print shops will > not. Last summer I had this problem printing a 1,5m x 1,5m graph, it > would end up truncated. I had to resort to svg output.=20 > Unfortunately for svg you need Unicode fonts, while PostScript output > seems to require Latin1. Argh... Really... I did not know of any such arbitrary limit. I noticed that=20 Windows machines could not display some graphs in PDF format, and Linux=20 machines could. I attributed it to low-quality Microsoft=20 implementation. I have also taken large graphs to a print shop and=20 they were able to load them (into a Windows system) and print them on a=20 commercial printer. I just assumed that they had larger disks and=20 memory than most home users. <snip> > On this, I implemented a couple of related concepts. First, > color-code edges. Here the idea was to give a different color to > each agnatic lineage, the set of people descending from a common > ancestor by a pure paternal descent line. In hand-drawn trees, they > tend to do this by changing the leave decoration used for the > different tree branches. It is very good for getting orientation on > a large graph. > > Second, highlight (bolden) the lines leading to some distinguished > person (typically the person for whome the tree is printed, usually > you or one of your children) so that at each family, you see quickly > which child is the distinguished person descended from. I will have to consider these ideas. > > 11. Add legends for each graph with the individual counts and > > copyright announcements and such. > > Oh, yes, I'd love that. I had a quick look on how to do it and did > not find an obvious way. =46rom the included dot file: labelloc=3Dbottom; labeljust=3Dleft; label=3D"(42 people)\n(C) 2005 by Wayne=20 Bergeron\nhttp://personal.vallnet.com/someguy/\na...@ya..."; It is a pain to format the labels into the dot file, but they print=20 well. =2D-=20 If lightning is the anger of the gods, the=20 gods are concerned mostly with trees. =09 - - Lao Tse |
From: wb <wb...@va...> - 2005-12-27 16:13:47
|
On Tuesday December 27 2005 00:47, Alexandre Prokoudine wrote: > Now, seriously, this is even more interesting, because the more > people publish their genealogy reports, the more common relatives > will be found. I'm not very experienced at genealogy, but there are a LOT of data quality problems with internet-published genealogical data. In the short time I have done this, I have found contradictory, incomplete, and just plain wrong information. Many times in the last few months, I wished that Google would get into that business and beat this data into shape. If you can't verify information at the source, you can build a big database, and have no confidence in it at all. Beside that, few people are willing to publish their databases (like GED files). Most want to present pretty webpages, which are sometimes worse than nothing for researching your heritage. Not many people want to 'release' their information for free. They do want to impress you with their cleverness at researching all of that information. -- WB -- Opera is an advanced form of yodeling. -- Brian Eno |
From: <db...@br...> - 2005-12-27 06:54:32
|
GRAMPS developers, I've been hacking on a calendar graphical report using the new interface with GRAMPS 2.0, and wanted to let you know about it sooner than later. This time of year I usually print a calendar with all my relatives birthdays and anniversaries. This year, I really wanted to do it from GRAMPS. This is my first GRAMPS report, and someone may want to look over the logic to get spouses. But it works for me. You can find some screen dumps and the code here: http://emergent.brynmawr.edu/emergent/GrampsCalendarReport The report has options to select a filter, the year of the calendar, living people only, birthdays and/or anniversaries. In addition to generating a calendar, this code also has implemented part of a proposal to make the report interface a little kinder on the coder. = I did this to make report writing easier by having Python do all of the dirty work. This also has the benefit of making the code a little more modular, and separates the details of the GUI from the details of the logic of the report. In any event, the code builds on the existing report infrastructure, and should run on GRAMPS 2.0. Let me know if you have issues or suggestions. -Doug |
From: Alexandre P. <ale...@gm...> - 2005-12-27 06:47:27
|
On 12/27/05, Julio Sanchez wrote: > > I publish some of my family graphs at > > http://personal.vallnet.com/~someguy/ > > Interesting, if I understood that right, that would make you a distant > relative of my wife, since I think she is descended from one of > Charles V great-great-great-grandfathers. Remember this day, guys. This is the first step to Google Genealogy - another ultimate service to find relatives and ancestors on the Web :) Now, seriously, this is even more interesting, because the more people publish their genealogy reports, the more common relatives will be found. Alexandre |
From: Julio S. <jul...@gm...> - 2005-12-27 06:38:34
|
2005/12/27, wb <wb...@va...>: > I publish some of my family graphs at > http://personal.vallnet.com/~someguy/ Interesting, if I understood that right, that would make you a distant relative of my wife, since I think she is descended from one of Charles V great-great-great-grandfathers. I also see that you graphs are large as mine, it is good for setting the context, since what works for 200 hundred boxes does not work necessarily for 2000. > Some useful options for processing the dot files are: > > 1. Put the graph in black and white, without having to run Gramps to > generate another report. Females are indicated by rounded node > geometry (a rounded box). Makes it easier to print on my old black & > white printer. > > 2. Adjusting the weights of the edges. I can make a graph collect all > of the children of parents close together (which I prefer), or to > collect married individuals close together. By default, all edges are > equally important. In my trials, I never got satisfying results with this. But I guess it has more to do with the kind of graphs that interest me, that are from the 'family as stack' variety. I did a partial reimplementation of it, but it is still has some gotchas. I should have another look at it. > 3. Adjust the scale of the output. > > 4. Adjust the physical dimensions of the output. > > 5. Adjust the rank and node separation distances. No objection on any of these. > 6. Allow the sorting of the output nodes by birth date and name. This > tends to lead to a more orderly graph. The dot utility does not > guarantee to keep nodes in order, but it tends to. When you have 75 or > 100 people in a generation, this matters. Ah, yes. This is the major gripe. What I did was playing with ordering=3Din and ordering=3Dout. It works rather well for mostly flat graphs, e.g. ancestor or descendant graphs. But many graphs I like are variations of 'having a common ancestor with' that are quickly nonplanar. In this case, the result with default parameters is aesthetically pleasant, but makes no sense form a genealogy point of view. Playing with ordering (=3Din or =3Dout) and astute ordering of the input dot file (I experimented with several methods for this) helps in achieving interesting results, but in the end may be uglier. In particular, I hate long lines from one side of the graph to the other when they are caused by silly node placement. They are more common if you don't let graphviz do its thing. Graphviz is a vengative thing, may seem to oblige but will make you pay for it. In the end, I suspect that the most effective way to handle this would be for graphviz not to change edge ordering unless necessary. =20 Another possible improvement: have edges respect the order even if boxes themselves do not. I mean, the edges leave the parents in birth order, even if they cross each other later. Currently, edge order seems pretty random. > 7. Allow the highlighting in red of all families that don't make sense, > like families with 3 or more married spouses. Or children who are > natural children of two marriages. This happens a lot when a GEDCOM > file is imported, as was discussed on the mailing list last week. > > 8. Adjust the page size of the output (other than the standard sizes > defined in ghostscript). This lets me print a large graph on a > continuous feed dot-matrix printer. It also lets me put a graph on one > huge PDF file. Then, I can bring it to Kinko's and print it on their > big printer. You cannot put a graph on a huge PDF file. As far as know, 3240 dots is the limit. You may view it well, but some print shops will not.=20 Last summer I had this problem printing a 1,5m x 1,5m graph, it would end up truncated. I had to resort to svg output. Unfortunately for svg you need Unicode fonts, while PostScript output seems to require Latin1. Argh... > 9. Allow highlighting of one node (usually the home individual) by > making that node a different color or shape. On this, I implemented a couple of related concepts. First, color-code edges. Here the idea was to give a different color to each agnatic lineage, the set of people descending from a common ancestor by a pure paternal descent line. In hand-drawn trees, they tend to do this by changing the leave decoration used for the different tree branches. It is very good for getting orientation on a large graph. Second, highlight (bolden) the lines leading to some distinguished person (typically the person for whome the tree is printed, usually you or one of your children) so that at each family, you see quickly which child is the distinguished person descended from. These two changes allow moving up and down the tree by using easy visual cl= ues. > 10. Allow the setting of all dot file parameters (like center, ratio, > rankdir, and the ones mentioned elsewhere in this message). > > 11. Add legends for each graph with the individual counts and copyright > announcements and such. Oh, yes, I'd love that. I had a quick look on how to do it and did not find an obvious way. > 12. Allow the selection of the direction of the graph (rankdir=3Drl and > rotate=3D0) without having to run another report from Gramps. I like > time (and descent) to run from left to right and the display to be > horizontal. > > 13. Something I never was able to do to the graphviz graph -- to add > information from the Gramps database that was not originally included > in the graph. For instance, a picture or date AND location. I think there should be demand for this. Of course, if you want to have photos, you have to be more conservative with your graph or they won't be visible, Also another thing I did was to improve the abbreviated date display.=20 Currently, you can have either full dates or just the year, but in the latter case you will just get the begginining year in a range or span and no indication on whether the year is exact or is only orientative. I implemented a method to handle better the year-only case. > P.S. I have attached two dot files that represent the entire example > database. One is original, and the other is modified by a script I > commonly use. To see them, in bash, do: > > display <(dot -Tps example.dot) & > display <(dot -Tps example.dot.mydot) & I did not look at them yet, I will later. Regards, Julio |
From: wb <wb...@va...> - 2005-12-26 23:21:32
|
I just realized that I tried to send this to the list, and only sent it to Don Allingham. Twice. So, here it is: -------- On Sunday December 25 2005 12:49, you wrote: > Actually, I think we would all like to see what you have done. If you > could post your modified graphviz output using the sample database, > it would show us your ideas. (under "Help", select "Open Example > Database"). I will do that, but it would not be as instructive, I think, as outlining the modifications I do (by script) to the .dot files. I publish some of my family graphs at http://personal.vallnet.com/~someguy/ See them for examples. To get just what you want, modifying the dot files is the only way to go. Whatever the developers do, DO NOT remove the ability to produce dot files. Some useful options for processing the dot files are: 1. Put the graph in black and white, without having to run Gramps to generate another report. Females are indicated by rounded node geometry (a rounded box). Makes it easier to print on my old black & white printer. 2. Adjusting the weights of the edges. I can make a graph collect all of the children of parents close together (which I prefer), or to collect married individuals close together. By default, all edges are equally important. 3. Adjust the scale of the output. 4. Adjust the physical dimensions of the output. 5. Adjust the rank and node separation distances. 6. Allow the sorting of the output nodes by birth date and name. This tends to lead to a more orderly graph. The dot utility does not guarantee to keep nodes in order, but it tends to. When you have 75 or 100 people in a generation, this matters. 7. Allow the highlighting in red of all families that don't make sense, like families with 3 or more married spouses. Or children who are natural children of two marriages. This happens a lot when a GEDCOM file is imported, as was discussed on the mailing list last week. 8. Adjust the page size of the output (other than the standard sizes defined in ghostscript). This lets me print a large graph on a continuous feed dot-matrix printer. It also lets me put a graph on one huge PDF file. Then, I can bring it to Kinko's and print it on their big printer. 9. Allow highlighting of one node (usually the home individual) by making that node a different color or shape. 10. Allow the setting of all dot file parameters (like center, ratio, rankdir, and the ones mentioned elsewhere in this message). 11. Add legends for each graph with the individual counts and copyright announcements and such. 12. Allow the selection of the direction of the graph (rankdir=rl and rotate=0) without having to run another report from Gramps. I like time (and descent) to run from left to right and the display to be horizontal. 13. Something I never was able to do to the graphviz graph -- to add information from the Gramps database that was not originally included in the graph. For instance, a picture or date AND location. P.S. I have attached two dot files that represent the entire example database. One is original, and the other is modified by a script I commonly use. To see them, in bash, do: display <(dot -Tps example.dot) & display <(dot -Tps example.dot.mydot) & -- Wayne Bergeron -- Scorched Earth Party: Fighting for a different America. |
From: Eero T. <ee...@us...> - 2005-12-26 15:41:12
|
Hi, On Sunday 25 December 2005 17:43, wb wrote: > > I was told to drop you a line with my suggestions of making reports. > > Since I had some problem concerning 'my ideal visualisation of > > pedigree' maybe I share with you with my idea. Reports being made by > > plugins are nice and neat, but on the other hand user can not > > personalize it, can he? I mean, my problem was like 'I want whole the > > pedigree' basically, whole database, there's only one way, as far as > > I know, of doing that - using graphviz. It's a little bit spartan, > > but it works. It's just you can't easily make pedigree using graphviz > > the way you would, if you could (how to edit look of that graph?). > > So, it's just an idea, I'm not a programmer myself, is it possible to > > make reports layouts more editable? Getting GraphViz options that are useful for a large variety of databases (large, small, wide, narrow pedigrees), requires a lot of experimenting and and just changing the order of nodes in the graph can produce completely diffferent looking graph, so getting a set of good GraphViz options and their values is a lot of effort. > When I began using Gramps, I had a similar problem. > > The solution, for me, was to produce Graphviz code, like you suggest. > > I am somewhat of a programmer, so I then wrote scripts to modify the dot > files. The scripts got a little more complicated than I would like, > but they produce EXACTLY the graph I want. > > It would be nice if the Gramps code generator would allow the selection, > in Gramps, of many of the graphviz parameters. Parameters like > coloring, spacing, node geometry, and so on. But, it is probably > easier to just do this kind of manipulation in scripts outside of > Gramps. No, it should be pretty easy to do in Gramps. Just post: - the options and value ranges you're interested about - a good default value for each option, and - some examples of how the GraphViz outputs will look/differ and I could look at it. (Or maybe Alex if I'm too slow to respond? :-)) > What exact changes to the graphviz graphs would you like? > > A lot of changes to the graphs can be done with very simple bash > scripts, after Gramps produces the graph. ATM the main problem with GraphViz is the font selection. There are two bad choices: - Default font: + No problems with layout - Doesn't support Unicode, just latin1 - GNU Unicode font - Text can go over their node borders (problem with font metrics?) + Supports about all characters - Eero |
From: Alex R. <sh...@gr...> - 2005-12-26 01:15:46
|
On Sun, 2005-12-25 at 11:18 +0100, pielgrzym wrote: >=20 > The second matter of my post is polish translation. I am Pole, so if > you want I can try to refresh (2 years?) old polish translation, since > GRAMPS is very good piece of software I'd be nice if Poles could have > decent polish locales for it, ne?;) I think there is no possible objection here :-) If you decide to help with the translation, here's some info about generally working with po files as well as some GRAMPS specifics: http://developers.gramps-project.org/tiki-index.php?page=3DTipsForTransl= ators Please feel free to ask, although I will be out of town between tomorrow and Jan 2. Alex --=20 Alexander Roitman http://www.gramps-project.org |
From: Don A. <don...@co...> - 2005-12-25 18:49:39
|
On Sun, 2005-12-25 at 09:43 -0600, wb wrote: > When I began using Gramps, I had a similar problem. >=20 > The solution, for me, was to produce Graphviz code, like you suggest. >=20 > I am somewhat of a programmer, so I then wrote scripts to modify the dot=20 > files. The scripts got a little more complicated than I would like,=20 > but they produce EXACTLY the graph I want. >=20 > It would be nice if the Gramps code generator would allow the selection,=20 > in Gramps, of many of the graphviz parameters. Parameters like=20 > coloring, spacing, node geometry, and so on. But, it is probably=20 > easier to just do this kind of manipulation in scripts outside of=20 > Gramps. >=20 > What exact changes to the graphviz graphs would you like? >=20 > A lot of changes to the graphs can be done with very simple bash=20 > scripts, after Gramps produces the graph. Actually, I think we would all like to see what you have done. If you could post your modified graphviz output using the sample database, it would show us your ideas. (under "Help", select "Open Example Database"). We would like to improve the reports, but the development team usually doesn't have as much time to do things like this as we like. If we can get users to submit patches, examples, or other things like this, it helps us quite a bit. With good examples, we can do a lot. The new web page generator came into play because about three people submitted good examples for use to look at. Any help we can get is always appreciated. The core development team is small, and most of our time goes to support. So if users can help us with good, high quality examples, it makes our job much easier. It is much quicker to implement something when you have a good example, instead of having to come with ideas on our own and implement them. My artistic ability is pretty low. Compare the early web page generator (which I designed) with the current one (which users designed), and you'll see why we like to have input from our users. Don --=20 Don Allingham <don...@co...> |
From: wb <wb...@va...> - 2005-12-25 15:43:56
|
On Sunday December 25 2005 04:18, pielgrzym wrote: > Hello, > I was told to drop you a line with my suggestions of making reports. > Since I had some problem concerning 'my ideal visualisation of > pedigree' maybe I share with you with my idea. Reports being made by > plugins are nice and neat, but on the other hand user can not > personalize it, can he? I mean, my problem was like 'I want whole the > pedigree' basically, whole database, there's only one way, as far as > I know, of doing that - using graphviz. It's a little bit spartan, > but it works. It's just you can't easily make pedigree using graphviz > the way you would, if you could (how to edit look of that graph?). > So, it's just an idea, I'm not a programmer myself, is it possible to > make reports layouts more editable? When I began using Gramps, I had a similar problem. The solution, for me, was to produce Graphviz code, like you suggest. I am somewhat of a programmer, so I then wrote scripts to modify the dot files. The scripts got a little more complicated than I would like, but they produce EXACTLY the graph I want. It would be nice if the Gramps code generator would allow the selection, in Gramps, of many of the graphviz parameters. Parameters like coloring, spacing, node geometry, and so on. But, it is probably easier to just do this kind of manipulation in scripts outside of Gramps. What exact changes to the graphviz graphs would you like? A lot of changes to the graphs can be done with very simple bash scripts, after Gramps produces the graph. -- USA Today has come out with a new survey: Apparently three out of four people make up 75 percent of the population. -- David Letterman |
From: pielgrzym <pie...@gm...> - 2005-12-25 10:18:54
|
Hello, I was told to drop you a line with my suggestions of making reports. Since I had some problem concerning 'my ideal visualisation of pedigree' maybe I share with you with my idea. Reports being made by plugins are nice and neat, but on the other hand user can not personalize it, can he? I mean, my problem was like 'I want whole the pedigree' basically, whole database, there's only one way, as far as I know, of doing that - using graphviz. It's a little bit spartan, but it works. It's just you can't easily make pedigree using graphviz the way you would, if you could (how to edit look of that graph?). So, it's just an idea, I'm not a programmer myself, is it possible to make reports layouts more editable? The second matter of my post is polish translation. I am Pole, so if you want I can try to refresh (2 years?) old polish translation, since GRAMPS is very good piece of software I'd be nice if Poles could have decent polish locales for it, ne?;) greetz for GRAMPS team, good work piel aka pielgrzym -- a bo czemu nie? |
From: Don A. <don...@co...> - 2005-12-25 05:04:20
|
I just wanted to take a moment to wish our users and our developers a Happy Holiday season. Whether you celebrate Christmas, Hanukkah, Kwanza, the New Year, the Winter Solstice or Summer Solstice (for those of you down under), we wish you the best during this season. Don --=20 Don Allingham <don...@co...> |
From: Don A. <don...@co...> - 2005-12-24 20:54:21
|
As the year winds down, I thought it might be nice to take a look back at the year the GRAMPS project had. Things just kind of creep up on you, and you tend to forget the progress that was made. Here are some of the major events that occurred this year: * Release of GRAMPS 2.0. This marked a major step forward for the project introducing many new advanced features, including the=20 new database backend. * New web sites. We moved from our basic web page at SourceForge to a set of four sites with our own domain. These sites include: http://gramps-project.org - the new home of GRAMPS on the web http://developers.gramps-project.org - the wiki site for development issues http://blog.gramps-project.org - GRAMPS very own blog site. This is a great place to get caught up on the thoughts of the=20 development team. http://library.gramps-project.org - a site where GRAMPS users' can can post their GRAMPS generated web sites free of charge. =20 * Release of the Linux Genealogy Live CD. Based of the Ubuntu Live CD, this allows Windows and other computer users to try Linux and several Linux-based genealogy programs (including GRAMPS) without affecting their current system. This was also followed up by the Linux Genealogy Install CD, that allows users to install Ubuntu and a=20 range of linux genealogy programs on their computer. * The IRC channel (#gramps on irc.freenode.net) has become an active center, where users and developers can interact. This has become an integral part in the GRAMPS development, and all users and=20 developers are welcome. * Work has started on the next major release (2.2), which will include a lot of major new features. * We started hosting a general Linux-Genealogy mailing list on the=20 gramps-project site. This list is for the discussion of any issues related to Linux and genealogy - not just GRAMPS. * Work is under way for a printed and bound version of the manual, which will be printed by lulu.com. At this point, we figure the manual will=20 probably be about 250 pages, and hopefully will be available for under $15. * We have been included in more distributions. We are available in the=20 universe repository of Ubuntu and in the fedora-extras repository for Fedora. Novell has also listed us as a "Cool Tool" in their "Novell=20 Cool Solutions"=20 * We have had several favorable reviews this year. Linux Format Magazine, Linux Magazine, and Linux Pro Magazine all rand articles on the project. We were also reviewed by Dick Eastman's Genealogy=20 Newsletter. =20 We are looking forward to the new year. We think even bigger things are in store for the project. --=20 Don Allingham http://don.allingham.org |
From: Alex R. <sh...@gr...> - 2005-12-23 00:28:20
|
Hello, We have discovered just recently some nasty things in our Check and Repair code in the stable branch: We were looping over the cursor, but committed changes (if there were any) using key-based access. It turns out, such practice may lead to inadvertently adding duplicate records. Some users have data screwed up just this way, so it is likely to be the consequence of such practice. Now this plugin has been switched away from using cursors in favor of using key-based iteration. We should adopt the policy of only using cursors for read access, but not for write access (at least, not for the trasaction-related key-based write access). The problem remains though with the duplicate records. Potentially, every user's data can be damaged and have duplicate records. It is hard to notice during daily use of gramps, since the regular key-based access only retrieves a first record of all the dupes. But this problem becomes critical when iterating over the data. Specifically, it breaks upgrade from gramps20 to HEAD. My long rant leads to this: the check and repair in the gramps20 CVS has added code now to detect and remove such duplicates, thus aiding the transition to HEAD in the future and otherwise preventing other problems. This this is potentially dangerous step, would everybody who has a chance PLEASE run check and repair on any data you have handy, just to expose any possible problems before 2.0.10 is released. As always, please exercise proper precautions and work on the copy, not the real data. Please let me know of any problems you encounter with this. Alex --=20 Alexander Roitman http://www.gramps-project.org |
From: Alex R. <sh...@gr...> - 2005-12-22 19:28:30
|
On Thu, 2005-12-22 at 17:23 +0100, Benny.Malengier@UGent.be wrote: > I did not completely go over the code for the backends. Are Gedcom and su= ch > loaded in a temporary BSDDB on startup? No, loaded into memory. BSDDB provides dictionary-like access where the "dictionary" is actually the DB residing on the disk. GEDCOM and XML backends simply keep dictionaries in memory, and save on exit. As such, these backends are very quick until the amount of data fits into RAM, but once swapping is necessary there's a major performance drop. Therefore, their use is only recommended for a "quickly look over the data" scenario, not real work on a large database. Alex --=20 Alexander Roitman http://www.gramps-project.org |
From: Alex R. <sh...@gr...> - 2005-12-22 19:25:26
|
Doug, On Thu, 2005-12-22 at 14:56 +0000, db...@cs... wrote: > I am very interested in seeing the newly refactored database modules. It = has > been my goal for a while to make a clean separation between database and = the > rest of gramps' complexity. Just check out the HEAD ('cvs co gramps2' without any branch tags) and look under src/GrampsDb directory. Richard has done a great job with comments, things shoul be very clear. > I very much appreciate the discussion recently in teasing out the data mo= dels > and trying to formally describe the data. >=20 > I would gladly work on a relational database backend (as soon as the data= base > and tables are understood). It sounds like others are willing too. Just to put more oil into that flame -- it seems that the BSDDB allows concurrent multi-user db access with proper locking etc, for both reading and writing. So if anybody wants to write a web interface then relational DB is not a necessary prerequisite for that. One can write whatever interface (web-based?) to BSD DB and allow several user to tweak same db. As Benny correctly mentioned, the one thing a relational DB would buy us is the ability to do custom SQL queries, but apart from that there's nothing so special in the relational DB that would make it much easier for writing e.g. web interface. Alex --=20 Alexander Roitman http://www.gramps-project.org |
From: Don A. <don...@co...> - 2005-12-22 17:27:00
|
However, I should note, that in some cases we build the equivalent of cross reference tables in memory using python dictionaries (hash tables). It is very likely that we can build the equivalent back reference tables in memory on reading the GEDCOM or XML files. We would probably need to do a bit of benchmarking to see if this buys us anything. Its hard to tell with in-memory representations. Depending on what you are doing, a list search can be quick or slow. Don Don Allingham wrote: > The other backends are in-memory representations. Back references here > are not really a problem, because the disk is never hit. > > Neither of these backends are intended for large databases, but since > everthing is in memory, the searches are not that painful. > > Don > > Benny.Malengier@UGent.be wrote: > >> Quoting Alex Roitman <sh...@gr...>: >> >>> On Wed, 2005-12-21 at 18:23 +0000, Richard Taylor wrote: >>> >>>> Sorry, my mistake, EditRepository does a sequencial scan to get the >>>> backlinks >>>> from Sources, I thought it was using an explicit backlink in >>>> Repository. No >>>> problem I will change EditRepository to use reference_map. >>> >>> >>> >>> Other places where backlinks were obtained by walking the DB are: >>> EditPlace (Place editor, display_references) >>> ImageSelect (Media editor, GlobalMediaProperties.display_refs). >>> >>> And we should probably do the same for the EventEditor: a tab with >>> all the Person/Family objects linking to this event. The Witness >>> tab will be gone, and this References tab should replace it. Then >>> finding a witness is a matter of sorting by the Role column. >> >> >> >> I did not completely go over the code for the backends. Are Gedcom and >> such >> loaded in a temporary BSDDB on startup? >> >> If not, as I mentioned in my other post, making heavy use of >> reference_map will >> be slow if BSDDB is not used as backend. Perhaps the frontend should >> have some >> indication if what will be shown on screen will be fast or not and not >> offer an >> option if it's slow on the backend that is activated or do it without >> blocking >> the interface like what happens now for sourcereferences in the >> sourceeditor of >> 2.0.9: the tab has italics as long as it's working retrieving the >> references, >> and becomes bold if finished. >> The more BSDDB optimized queries and searches are added to the BSDDB >> backend the >> more this might become an issue. >> >> Just to mention it, >> Benny >> >> >> ---------------------------------------------------------------- >> This message was sent using IMP, the Internet Messaging Program. >> >> >> >> ------------------------------------------------------- >> This SF.net email is sponsored by: Splunk Inc. Do you grep through log >> files >> for problems? Stop! Download the new AJAX search engine that makes >> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! >> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click >> _______________________________________________ >> Gramps-devel mailing list >> Gra...@li... >> https://lists.sourceforge.net/lists/listinfo/gramps-devel >> > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: Don A. <don...@co...> - 2005-12-22 17:20:56
|
The other backends are in-memory representations. Back references here are not really a problem, because the disk is never hit. Neither of these backends are intended for large databases, but since everthing is in memory, the searches are not that painful. Don Benny.Malengier@UGent.be wrote: > Quoting Alex Roitman <sh...@gr...>: > >> On Wed, 2005-12-21 at 18:23 +0000, Richard Taylor wrote: >> >>> Sorry, my mistake, EditRepository does a sequencial scan to get the >>> backlinks >>> from Sources, I thought it was using an explicit backlink in >>> Repository. No >>> problem I will change EditRepository to use reference_map. >> >> >> Other places where backlinks were obtained by walking the DB are: >> EditPlace (Place editor, display_references) >> ImageSelect (Media editor, GlobalMediaProperties.display_refs). >> >> And we should probably do the same for the EventEditor: a tab with >> all the Person/Family objects linking to this event. The Witness >> tab will be gone, and this References tab should replace it. Then >> finding a witness is a matter of sorting by the Role column. > > > I did not completely go over the code for the backends. Are Gedcom and such > loaded in a temporary BSDDB on startup? > > If not, as I mentioned in my other post, making heavy use of > reference_map will > be slow if BSDDB is not used as backend. Perhaps the frontend should > have some > indication if what will be shown on screen will be fast or not and not > offer an > option if it's slow on the backend that is activated or do it without > blocking > the interface like what happens now for sourcereferences in the > sourceeditor of > 2.0.9: the tab has italics as long as it's working retrieving the > references, > and becomes bold if finished. > The more BSDDB optimized queries and searches are added to the BSDDB > backend the > more this might become an issue. > > Just to mention it, > Benny > > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program. > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: Benny.Malengier@UGent.be - 2005-12-22 16:23:52
|
Quoting Alex Roitman <sh...@gr...>: > On Wed, 2005-12-21 at 18:23 +0000, Richard Taylor wrote: >> Sorry, my mistake, EditRepository does a sequencial scan to get the >> backlinks >> from Sources, I thought it was using an explicit backlink in Repository. No >> problem I will change EditRepository to use reference_map. > > Other places where backlinks were obtained by walking the DB are: > EditPlace (Place editor, display_references) > ImageSelect (Media editor, GlobalMediaProperties.display_refs). > > And we should probably do the same for the EventEditor: a tab with > all the Person/Family objects linking to this event. The Witness > tab will be gone, and this References tab should replace it. Then > finding a witness is a matter of sorting by the Role column. I did not completely go over the code for the backends. Are Gedcom and such loaded in a temporary BSDDB on startup? If not, as I mentioned in my other post, making heavy use of reference_map will be slow if BSDDB is not used as backend. Perhaps the frontend should have some indication if what will be shown on screen will be fast or not and not offer an option if it's slow on the backend that is activated or do it without blocking the interface like what happens now for sourcereferences in the sourceeditor of 2.0.9: the tab has italics as long as it's working retrieving the references, and becomes bold if finished. The more BSDDB optimized queries and searches are added to the BSDDB backend the more this might become an issue. Just to mention it, Benny ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |