From: Don A. <dal...@us...> - 2005-05-03 15:16:23
|
We are hoping to release GRAMPS 2.0 this weekend. This has been in development for over a year, and has been a fairly massive effort by the development team. And to be honest, we are a little nervous. GRAMPS 1.0.X has become rather stable over the past year or so. Each point release has had fewer and fewer bug reports. People have come to expect stability. GRAMPS 2.0 has had a lot of major changes - more than what is visually detectable. Having a lot of changes increases the chances for new bugs to creep in. The underlying database has changed, as has the method in which we access it. The development team has been testing the code (with a special commendation to Martin Hawlisch) and it seems that the errors we uncovering lately are rather obscure, giving us a bit more confidence in the stability of the new code. However, this isn't good enough for me. In real life, I am an electrical engineer working on the design of computer chips. What I have learned over the past 15+ years is that the person who designs something usually isn't the best person to test the same thing. When you test something you design, you tend to go in with preconcieved notions that affect how you test - often causing you to miss certain bugs. This is why most companies have one group to design something and another group to test it. Between the gramps-devel and gramps-users mailing lists, we have several hundred members. We would ask that you download the 1.1.99 release (the 2.0 prerelease), and help us look for bugs. Please report problems to either gra...@li..., or preferably, using the bug tracker at http://sf.net/projects/gramps. GRAMPS 1.1.99 requires at least then GNOME 2.8 and pygtk 2.4 libraries. Most recent distributions support this, including Ubuntu 4.10 and 5.04, Debian unstable (SID), Fedora Core 3 and 4, SUSE 9.3, Mandriva 10.2 (formally Mandrake), Gentoo, and FreeBSD. Thanks. Don |
From: Alex R. <sh...@al...> - 2005-05-03 15:51:44
|
On 05/03/2005 10:15:56 AM, Don Allingham wrote: [snip] >=20 > Between the gramps-devel and gramps-users mailing lists, we have several > hundred members. We would ask that you download the 1.1.99 release (the > 2.0 prerelease), and help us look for bugs. Please report problems to > either gra...@li..., or preferably, using the bug > tracker at http://sf.net/projects/gramps. > [snip] I would also like to add that there's a new poll up on the gramps-project.org site, asking about your experience with 1.1.99. Whether you find bugs or not (!!!), please consider spending a minute to vote and let us know that you tried it and how it turned out. As always, comments are welcome. Thanks, Alex --=20 Alexander Roitman http://ebner.neuroscience.umn.edu/people/alex.html Dept. of Neuroscience, Lions Research Building 2001 6th Street SE, Minneapolis, MN 55455 Tel (612) 625-7566 FAX (612) 626-9201 |
From: Bram M. <bra...@li...> - 2005-05-05 12:43:08
|
Hi I don't have much time to test right now but I'd like to install 1.1.99 (from James' deb) and have a quick look anyway. But before I install this version over my existing 1.1.90-1 I'd like to create a backup of my existing data. Is it sufficient to just copy the files in my gramps folder (the .grdb) files? Or are there any settings stored somewhere else? Like in gconf or something? TIA Bram -- # Mertens Bram "M8ram" <bra...@li...> Linux User #349737 # # debian testing kernel 2.6.8-1-686 i686 512MB RAM # # 14:39:23 up 40 days, 20:53, 12 users, load average: 0.29, 0.26, 0.24 # |
From: Don A. <don...@co...> - 2005-05-05 13:40:51
|
On Thu, 2005-05-05 at 14:43 +0200, Bram Mertens wrote: > Hi > > I don't have much time to test right now but I'd like to install 1.1.99 > (from James' deb) and have a quick look anyway. > > But before I install this version over my existing 1.1.90-1 I'd like to > create a backup of my existing data. Is it sufficient to just copy the > files in my gramps folder (the .grdb) files? > > Or are there any settings stored somewhere else? Like in gconf or > something? > > TIA > > Bram Bram, Copying the GRDB files should be sufficient. While there are some settings in gconf, the should not change unless you go into the preferences dialog. Also, the gconf settings did not change and are compatible between the versions. Don -- Don Allingham <don...@co...> |
From: Alex R. <sh...@gr...> - 2005-05-05 22:42:18
|
Bram, On 05/05/2005 07:43:26 AM, Bram Mertens wrote: >=20 > I don't have much time to test right now but I'd like to install 1.1.99 > (from James' deb) and have a quick look anyway. >=20 > But before I install this version over my existing 1.1.90-1 I'd like to > create a backup of my existing data. Is it sufficient to just copy the > files in my gramps folder (the .grdb) files? >=20 > Or are there any settings stored somewhere else? Like in gconf or > something? Just back up your grdb's, just in case. If you'd like extra sense of security, before upgrading, export every file to XML database or gramps packages. Keep copies of all grdb's and XML/package files in safe place. Other than your data, there's nothing you should worry about. Alex --=20 Alexander Roitman http://www.gramps-project.org |
From: James T. <tr...@de...> - 2005-05-05 13:42:09
|
On Thu, May 05, 2005 at 02:43:26PM +0200, Bram Mertens wrote: > Hi > > I don't have much time to test right now but I'd like to install 1.1.99 > (from James' deb) and have a quick look anyway. > > But before I install this version over my existing 1.1.90-1 I'd like to > create a backup of my existing data. Is it sufficient to just copy the > files in my gramps folder (the .grdb) files? 1.1.99 uses a different storage mechanism (a db instead of xml). You will need to explicitly import the old data, so as long as you don't delete the old file your data will be safe. -- James Treacy tr...@de... |
From: Don A. <don...@co...> - 2005-05-05 13:59:50
|
On Thu, 2005-05-05 at 09:40 -0400, James Treacy wrote: > On Thu, May 05, 2005 at 02:43:26PM +0200, Bram Mertens wrote: > > Hi > > > > I don't have much time to test right now but I'd like to install 1.1.99 > > (from James' deb) and have a quick look anyway. > > > > But before I install this version over my existing 1.1.90-1 I'd like to > > create a backup of my existing data. Is it sufficient to just copy the > > files in my gramps folder (the .grdb) files? > > 1.1.99 uses a different storage mechanism (a db instead of xml). You > will need to explicitly import the old data, so as long as you don't > delete the old file your data will be safe. Actually, since he's upgrading from 1.1.90 to 1.1.99, he should already be using the new .grdb files. Don -- Don Allingham <don...@co...> |
From: Doug M-C <li...@ds...> - 2005-05-05 17:21:46
|
I have a couple of reflections/questions. Nothing that should stop 2.0, but usability issues... 1) The program is fairly sloooow! (Intel Pentium III 800Mhz w/ 512MB RAM and Ubuntu 5.04 using XFCE4 rather than Gnome, gramps 1.1.99-1 with a database of several thousand items (2500 individuals?)) Specifically, when I double click a person/source/whatever to edit, it takes several (3? 4?) seconds for the edit window to appear; when I click the <add> button to add a filter rule to a new filter, it takes five or more seconds for the filter rule window to pop up; and the current filter action of "any textual record contains..." has taken over 3 minutes and the display still has not updated (the phrase might be in about half the records). 2) When I imported my gedcom back whenever, the gedcom had each source as a separate entry (all 2650 or so of them!!!!!) So now I have a database with 2650 odd 'imported sources' and I am struggling to find a way to organise them properly. There are probably only a couple of hundred individual sources with the vast majority of the material coming from just four or five sources. Each source lists mainly Event IDs in the reference tab. There is no search mechanism in gramps beyond the (in this case) very unwieldy filter system, yes? So I cannot just search for 'E0003', for example. There is also no easy 'find and replace' mechanism. So, and please jump in if anyone has a better suggestion, I think I need to export back to the xml format and open it up in gedit and do my searching and find and replacing there. And then re-import the file into the 2.0 database format. I probably should have done that to the gedcom originally, but didn't even realise the problem until it was in gramps and I was already using the data. 3) I have also reported a bug in the bug tracker regarding IDs, minor issue now but could lead to serious data problems later on. Looking forward to the official release of 2.0. Thanks for all the hard work, Don, Alex and the rest of the development team, it is truly appreciated immensely by us users. Doug -- Doug M-C ++++++++++++++++++++++++++ Email: <lists AT dshop DOT morrison-cleary DOT info> Key ID: D5CC3E8F Check the header for all relevant policies. |
From: Don A. <don...@co...> - 2005-05-05 18:22:14
|
On Thu, 2005-05-05 at 12:21 -0500, Doug M-C wrote: > I have a couple of reflections/questions. Nothing that should stop > 2.0, but usability issues... > > 1) The program is fairly sloooow! (Intel Pentium III > 800Mhz w/ 512MB RAM and Ubuntu 5.04 using XFCE4 > rather than Gnome, gramps 1.1.99-1 with a database of several > thousand items (2500 individuals?)) > > Specifically, when I double click a person/source/whatever to > edit, it takes several (3? 4?) seconds for the edit window to > appear; when I click the <add> button to add a filter rule to a > new filter, it takes five or more seconds for the filter rule > window to pop up; and the current filter action of "any textual > record contains..." has taken over 3 minutes and the display still > has not updated (the phrase might be in about half the records). This is rather odd. I don't see this on my 1GHz PIII (256MB) laptop. It is also running Ubuntu 5.04 with full GNOME. Do you have a test case you could send me? > 2) When I imported my gedcom back whenever, the gedcom had each > source as a separate entry (all 2650 or so of them!!!!!) So now I > have a database with 2650 odd 'imported sources' and I am > struggling to find a way to organise them properly. There are > probably only a couple of hundred individual sources with the vast > majority of the material coming from just four or five sources. > Each source lists mainly Event IDs in the reference tab. Could you send me the GEDCOM file? Don -- Don Allingham <don...@co...> |
From: Alex R. <sh...@gr...> - 2005-05-05 23:57:09
|
Doug, On 05/05/2005 12:21:37 PM, Doug M-C wrote: > 1) The program is fairly sloooow! (Intel Pentium III > 800Mhz w/ 512MB RAM and Ubuntu 5.04 using XFCE4 > rather than Gnome, gramps 1.1.99-1 with a database of several > thousand items (2500 individuals?)) >=20 > Specifically, when I double click a person/source/whatever to > edit, it takes several (3? 4?) seconds for the edit window to > appear; when I click the <add> button to add a filter rule to a > new filter, it takes five or more seconds for the filter rule > window to pop up; and the current filter action of "any textual > record contains..." has taken over 3 minutes and the display still > has not updated (the phrase might be in about half the records). Sounds strange. I am not seeing any slowness. I have to admit that my machines have faster clock rate, and are Pentium IV, but with less memory. > 2) When I imported my gedcom back whenever, the gedcom had each > source as a separate entry (all 2650 or so of them!!!!!) So now I > have a database with 2650 odd 'imported sources' and I am > struggling to find a way to organise them properly. There are > probably only a couple of hundred individual sources with the vast > majority of the material coming from just four or five sources. > Each source lists mainly Event IDs in the reference tab. >=20 > There is no search mechanism in gramps beyond the (in this case) > very unwieldy filter system, yes? So I cannot just search for > 'E0003', for example. Not yet. We are planning to create an Event View, but it's still being mulled over. What you can currently do is to double-click on any entry in the Reference tab of the Source editor and that should open the corresponding object's editor: event editor in case of clicking on E0003. You should see what event it is then. Would it help if we showed the brief event info as tooltip when you put the mouse over the E0003 entry? We should be able to do it fairly easily. > There is also no easy 'find and replace' mechanism. No, and that will have to change :-) There's already an internal "find" mechanism, though now interface only supports it for people via filter. We could make a separate "advance find" tool which will collect all objects whose records match the substring. > So, and please jump in if anyone has a better suggestion, I think > I need to export back to the xml format and open it up in gedit > and do my searching and find and replacing there. And then > re-import the file into the 2.0 database format. I probably should > have done that to the gedcom originally, but didn't even realise > the problem until it was in gramps and I was already using the > data. I would go back and modify the GEDCOM. > 3) I have also reported a bug in the bug tracker regarding IDs, > minor issue now but could lead to serious data problems later on. Don has fixed the "Reorder IDs" tool. The old tree used S1, S2, etc, while the new version uses S0001, S0002, etc, by default. If you see that your IDs are S1 etc and you want to switch to new scheme, the Reorder tool should do the job. Thanks for all your feedback! We will have to postpone some of the things until after 2.0.0, simply because we have to stop somewhere and release. But now that things stop changing so fast, we can slow down and polish whatever is not completely well done,=20 for 2.0.1. Alex --=20 Alexander Roitman http://www.gramps-project.org |
From: Richard T. <rjt...@th...> - 2005-05-06 06:28:25
|
On Friday 06 May 2005 00:57, Alex Roitman wrote: > Would it help if we showed the brief event info as tooltip > when you put the mouse over the E0003 entry? We should be able > to do it fairly easily. There is code in TreeTips.py that makes adding tooltips to trees very simple. The time consuming thing is writting the code to generate the tooltips text for each object. There is code in ScratchPad.py for generating tooltips for some of the objects, this could be moved to somewhere more appropriate so that it could easily be added to all TreeViews. The tooltips in ScratchPad could do with some more attention. I have not done a great job of getting nice layout in pango and the MediaObject tooltips would be great if they had thumbnails. Richard -- You can normally find me on Jabber as Ric...@ja... |
From: Alex R. <sh...@gr...> - 2005-05-06 12:58:54
|
On 05/06/2005 01:27:59 AM, Richard Taylor wrote: > On Friday 06 May 2005 00:57, Alex Roitman wrote: > > Would it help if we showed the brief event info as tooltip > > when you put the mouse over the E0003 entry? We should be able > > to do it fairly easily. >=20 > There is code in TreeTips.py that makes adding tooltips to trees very sim= ple.=20 This is exactly what I meant (following the 2.0.0). > The time consuming thing is writting the code to generate the tooltips te= xt=20 > for each object. There is code in ScratchPad.py for generating tooltips f= or=20 > some of the objects, this could be moved to somewhere more appropriate so= =20 > that it could easily be added to all TreeViews. Maybe Utils.py? Alex --=20 Alexander Roitman http://www.gramps-project.org |
From: Doug M-C <li...@ds...> - 2005-05-05 18:15:56
|
Another quick usability issue... when exporting to the gramps xml format, the resulting file is a binary file. So, "As XML is a text-based human-readable format, you may also use it to take a look at your data." (quoted from the help documentation) is wrong! We cannot just load it into a text editor and take a look. I thought the binary xml format was just a gzip of the text format, or something similar, but my archive manager doesn't seem to recognize it as any sort of archive. Am I missing something here?? Thanks. Doug -- Doug M-C ++++++++++++++++++++++++++ Email: <lists AT dshop DOT morrison-cleary DOT info> Key ID: D5CC3E8F Check the header for all relevant policies. |
From: Doug M-C <li...@ds...> - 2005-05-05 19:03:14
|
On Thu, 5 May 2005 12:55:08 -0500 Doug M-C <li...@ds...> wrote: <snipped> > I thought the binary xml format was just a gzip of the text > format, or something similar, but my archive manager doesn't > seem to recognize it as any sort of archive. Am I missing > something here?? Ignore this paragraph, please! Of course it is gzipped and I use gunzip to extract it. I knew that, my brain was just not functioning very well in the moment. Oh well. Doug |
From: Doug M-C <li...@ds...> - 2005-05-06 03:28:47
|
On Thu, 05 May 2005 23:57:20 +0000 Alex Roitman <sh...@gr...> wrote: > Doug, > > On 05/05/2005 12:21:37 PM, Doug M-C wrote: > > 1) The program is fairly sloooow! (Intel Pentium III > > 800Mhz w/ 512MB RAM and Ubuntu 5.04 using XFCE4 > > rather than Gnome, gramps 1.1.99-1 with a database of several > > thousand items (2500 individuals?)) > Sounds strange. I am not seeing any slowness. I have to > admit that my machines have faster clock rate, and are Pentium > IV, but with less memory. Just sent Don the database, maybe he can make sense of it. It is 5 seconds from double click to edit screen, and 10 seconds to the window to add a filter rule or a source to an event, etc! > > > 2) When I imported my gedcom back whenever, the gedcom had > > each source as a separate entry (all 2650 or so of them!!!!!) > > So now I have a database with 2650 odd 'imported sources' and > > I am struggling to find a way to organise them properly. There > > are probably only a couple of hundred individual sources with > > the vast majority of the material coming from just four or > > five sources. Each source lists mainly Event IDs in the > > reference tab. > > > > There is no search mechanism in gramps beyond the (in this > > case) very unwieldy filter system, yes? So I cannot just > > search for'E0003', for example. > > Not yet. We are planning to create an Event View, but it's still > being mulled over. What you can currently do is to double-click > on any entry in the Reference tab of the Source editor and that > should open the corresponding object's editor: event editor in > case of clicking on E0003. You should see what event it is then. Duh, that's what I used to do, I knew that! Still an Event View would be helpful and fits the basic principle of modern genealogy that each event is its own object of data simply connected to other discreet data objects like people, etc. > > Would it help if we showed the brief event info as tooltip > when you put the mouse over the E0003 entry? We should be able > to do it fairly easily. Yes, yes, yes, tooltips are wonderful things and we should use them whenever possible to convey extra "at-a-glance" information, please?! > > There is also no easy 'find and replace' mechanism. > > No, and that will have to change :-) There's already an internal > "find" mechanism, though now interface only supports it for > people via filter. We could make a separate "advance find" tool > which will collect all objects whose records match the > substring. Ultimately this will be a good tool to have. It could wreak havoc with a database, though. My particular problem may not actually benefit much anyway... it is going to be a looooong slog through the xml data carefully examining each entry and changing or replacing as needed. As I have looked at this more carefully, I'm not actually sure I would take the risk of a find and replace function???!!! <snipped> > 3) I have also reported a bug in the bug tracker regarding > > IDs, minor issue now but could lead to serious data problems > > later on. > > Don has fixed the "Reorder IDs" tool. The old tree used S1, S2, > etc, while the new version uses S0001, S0002, etc, by default. > If you see that your IDs are S1 etc and you want to switch to > new scheme, the Reorder tool should do the job. The reorder tool doesn't work yet! > > Thanks for all your feedback! We will have to postpone some of > the things until after 2.0.0, simply because we have to stop > somewhere and release. But now that things stop changing so > fast, we can slow down and polish whatever is not completely > well done, for 2.0.1. > Thanks for all your hard work. 2.0 is wonderful. Doug -- Doug M-C ++++++++++++++++++++++++++ Email: <lists AT dshop DOT morrison-cleary DOT info> Key ID: D5CC3E8F Check the header for all relevant policies. |
From: Don A. <don...@co...> - 2005-05-06 03:37:36
|
On Thu, 2005-05-05 at 22:28 -0500, Doug M-C wrote: > > Don has fixed the "Reorder IDs" tool. The old tree used S1, S2, > > etc, while the new version uses S0001, S0002, etc, by default. > > If you see that your IDs are S1 etc and you want to switch to > > new scheme, the Reorder tool should do the job. > > The reorder tool doesn't work yet! > Actually it does, just that it was checked into CVS, and SourceForge's CVS takes about a day for it to show up in anonymous CVS. This will be in 2.0. Don |
From: Doug M-C <li...@ds...> - 2005-05-06 19:41:35
|
On Thu, 5 May 2005 12:21:37 -0500 Doug M-C <li...@ds...> wrote: > 2) When I imported my gedcom back whenever, the gedcom had each > source as a separate entry (all 2650 or so of them!!!!!) So now > I have a database with 2650 odd 'imported sources' and I am > struggling to find a way to organise them properly. There are > probably only a couple of hundred individual sources with the > vast majority of the material coming from just four or five > sources. Each source lists mainly Event IDs in the reference > tab. I have been playing around with the data for a day or so now and came up with a basic workflow to edit the sources. Unfortunately, I figure it will probably take me about a month to get it all done! Although I haven't done a lot of genealogy work on this particular file since I imported it, I was hoping to avoid going back to the gedcoms and losing whatever work I had done. However, another issue with the data came up and I probably have to start from a fresh gedcom anyway. (My mother has done enough work on the same base data over the last 2 years to render my data useless.) So, I thought I would import the original gedcoms directly into a test database in 1.1.99... see if the import mechanism had improved along with all the other improvements. Then I would be ready to import a new gedcom into a fresh database and go from there. Unfortunately, importing inline sources has actually gotten worse! When I first imported my data (may have been a 0.9.x or an early 1.0.x gramps) the information contained in the SOUR element was imported as a *note* in gramps. So the information in the gedcom remained present, if not very accessible, in gramps. In 1.1.99, ***nothing*** is imported except the presence of a source reference. So none of the data from the gedcom is preserved in ANY way in gramps! The contrast between the handling of sources and the handling of places in an import has me particularly confused. When a PLAC element is imported into gramps 2 things happen: 1) the data in the PLAC element is used as the title of the <placeobj> tag, and 2) if the data in the PLAC element is identical to the data in another PLAC element, then another <placeobj> tag is NOT created, but a link to the first <placeobj> is created. Is there any reason why BOTH of these things could not be done for importing of sources into gramps? Use the data in the SOUR element to create the <stitle> tag (with one caveat below), and combining all the identical SOUR elements into a single <source> tag? I assume it would simply require the same algorithm used with places to be used with sources also? The one caveat is that when the sources were entered in the original software from which the gedcoms were produced, the source was a limited length note field. Therefore, lots of the sources say "Death certificate" only. Obviously, these do not all refer to the same death certificate, but refer to the death certificate of the person under which the event with the SOUR is found. So it would be very handy if the algorithm could be extended just far enough so that any time a series of standard phrases (death certificate, marriage certificate, marriage license, etc) were found, the name of the attached person was added to the title (eg: "MARKHAM, Thomas death certificate"). The software we have been using in the past did change over to a more up-to-date source model. So, maybe, the new gedcom will have the source citations in a separate place with links, but if it doesn't, please can we have an import mechanism that handles inline source citations with the same intelligence as place references? Thanks. Doug -- Doug M-C ++++++++++++++++++++++++++ Email: <lists AT dshop DOT morrison-cleary DOT info> Key ID: D5CC3E8F Check the header for all relevant policies. |
From: Don A. <don...@co...> - 2005-05-07 04:13:22
|
On Fri, 2005-05-06 at 14:41 -0500, Doug M-C wrote: > Unfortunately, importing inline sources has actually gotten worse! > When I first imported my data (may have been a 0.9.x or an early > 1.0.x gramps) the information contained in the SOUR element was > imported as a *note* in gramps. So the information in the gedcom > remained present, if not very accessible, in gramps. > > In 1.1.99, ***nothing*** is imported except the presence of a > source reference. So none of the data from the gedcom is preserved > in ANY way in gramps! I found the bug that was responsible for this and I have fixed it. It will be incorporated into the 2.0 release. Imported inline sources now have meaningful titles and are combined when possible. Don |
From: Doug M-C <li...@ds...> - 2005-05-07 04:29:36
|
On Fri, 06 May 2005 22:09:19 -0600 Don Allingham <don...@co...> wrote: > I found the bug that was responsible for this and I have fixed > it. It will be incorporated into the 2.0 release. Imported > inline sources now have meaningful titles and are combined when > possible. > > Don Great work, thank you, thank you, thank you. Doug -- Doug M-C ++++++++++++++++++++++++++ Email: <lists AT dshop DOT morrison-cleary DOT info> Key ID: D5CC3E8F Check the header for all relevant policies. |