From: Juliusz G. <jg...@gm...> - 2010-05-26 21:19:05
|
Hi, First of all I want to say thanks to the authors for a nice piece of software. It's the best of its kind I have found so far. However, one thing really bothers me: Why isn't all the media imported into the database? What's more, I don't like the fact that the location of the database is kind of hidden from me and I cannot choose separate location for every family tree (like creating a new, separate project for my family tree). I have read that some time ago you had project files but this was changed because the database is useless without a log file and log files were stored in .gramps folder. I just don't get this decision. Why can't you just invent a file format which would contain the database and the log and the media, or simply let the user choose the directory for all the family tree's files (database + logs + media)? This way I could just pass this file or directory to someone else and they would have the complete family tree. Finally, the fact that media is not part of the family tree (or database, or let's call it project) seems just weird to me. I mean, this is genealogy software and I want to give the family tree to other family members or my kids when I have them. How can I assume that they'll have the same directory structure on their computers? I don't even think anyone in my family uses Linux. I tried to export all the data to a Gramps XML Package, but it seems it doesn't include photos. Gramps after reimporting the data from this XML stupidly assumes old paths to media files. I mean, come on, am I missing something obvious or this is just ridiculous? Do you plan to reinvent the file format and/or project management? In my opinion, all of this is simply counterintuitive now. It's a pity, because I really like the program. It has some other minor annoyances (not conforming to Gnome guidelines sometimes) but the one I mentioned seems like a real deal breaker to me. Regards, -- Juliusz Gonera http://juliuszgonera.com/ |
From: Stephen G. <ste...@op...> - 2010-05-26 21:48:51
|
Hi Juliusz, I'm not really the guy who can answer all this, but ... On 27/05/2010 7:18 AM, Juliusz Gonera wrote: > Hi, > > First of all I want to say thanks to the authors for a nice piece of > software. It's the best of its kind I have found so far. > > However, one thing really bothers me: Why isn't all the media imported > into the database? What's more, I don't like the fact that the location > of the database is kind of hidden from me and I cannot choose separate > location for every family tree (like creating a new, separate project > for my family tree). > > I have read that some time ago you had project files but this was > changed because the database is useless without a log file and log files > were stored in .gramps folder. I just don't get this decision. Why can't > you just invent a file format which would contain the database and the > log and the media, or simply let the user choose the directory for all > the family tree's files (database + logs + media)? This way I could just > pass this file or directory to someone else and they would have the > complete family tree. > > Finally, the fact that media is not part of the family tree (or > database, or let's call it project) seems just weird to me. I mean, this > is genealogy software and I want to give the family tree to other family > members or my kids when I have them. How can I assume that they'll have > the same directory structure on their computers? I don't even think > anyone in my family uses Linux. > > I tried to export all the data to a Gramps XML Package, but it seems it > doesn't include photos. Gramps after reimporting the data from this XML > stupidly assumes old paths to media files. > When you export you have to choice of two Gramps XML formats. - GRAMPS XML (exports just the family tree) - GRAMPS PACKAGE (exports the family tree AND all media including photos, sound and other files) The package is portable across computers (and should be platforms) as the package contains all media, they will be imported into their own directory, upon completion of the import GRAMPS will notify you of the directiry the media has been placed in. Should a user wish the media to be put into another directory he/she can move the entre directory, and change the base path to the media directory through GRAMPS. The GRAMPS XML formats have been designed primarily for sharing files or for backup purposes. > I mean, come on, am I missing something obvious or this is just > ridiculous? Do you plan to reinvent the file format and/or project > management? In my opinion, all of this is simply counterintuitive now. > > It's a pity, because I really like the program. It has some other minor > annoyances (not conforming to Gnome guidelines sometimes) but the one I > mentioned seems like a real deal breaker to me. > > Regards, > > > > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 9.0.819 / Virus Database: 271.1.1/2897 - Release Date: 05/26/10 16:25:00 > > |
From: Juliusz G. <jg...@gm...> - 2010-05-29 17:06:49
|
Stephen George wrote: > When you export you have to choice of two Gramps XML formats. > - GRAMPS XML (exports just the family tree) > - GRAMPS PACKAGE (exports the family tree AND all media including > photos, sound and other files) > > The package is portable across computers (and should be platforms) as > the package contains all media, they will be imported into their own > directory, upon completion of the import GRAMPS will notify you of the > directiry the media has been placed in. Should a user wish the media > to be put into another directory he/she can move the entre directory, > and change the base path to the media directory through GRAMPS. > > The GRAMPS XML formats have been designed primarily for sharing files > or for backup purposes. OK, I've tried it again, and yes, it works. The thing was that I didn't have a clue that I should first set the absolute path to media path in Edit->Preferences (BTW this isn't right, under Edit->Preferences only global program preferences should be set, not family tree specific). It looked like the imported data was using the old path while it wasn't (the whole directory structure was copied into new location resulting in a very long directory tree). Well, I'll try to get used to it. Thanks for help. -- Juliusz Gonera http://juliuszgonera.com/ |
From: Duncan L. <dun...@gm...> - 2010-05-29 19:13:25
|
On 29 May 2010 19:06, Juliusz Gonera <jg...@gm...> wrote: ... > Edit->Preferences (BTW this isn't right, under Edit->Preferences only > global program preferences should be set, not family tree specific). It I agree that this is actually a bug. Could you also report it please? Duncan -- 'The unconsidered life is not worth living' - Socrates |
From: Duncan L. <dun...@gm...> - 2010-05-29 19:14:08
|
On 29 May 2010 21:12, Duncan Lithgow <dun...@gm...> wrote: > On 29 May 2010 19:06, Juliusz Gonera <jg...@gm...> wrote: > ... >> Edit->Preferences (BTW this isn't right, under Edit->Preferences only >> global program preferences should be set, not family tree specific). It > > I agree that this is actually a bug. Could you also report it please? sorry, you already have, thanks -- 'The unconsidered life is not worth living' - Socrates |
From: Doug B. <dou...@gm...> - 2010-05-26 21:52:26
|
On Wed, May 26, 2010 at 5:18 PM, Juliusz Gonera <jg...@gm...> wrote: > Hi, > > First of all I want to say thanks to the authors for a nice piece of > software. It's the best of its kind I have found so far. > > However, one thing really bothers me: Why isn't all the media imported > into the database? What's more, I don't like the fact that the location > of the database is kind of hidden from me and I cannot choose separate > location for every family tree (like creating a new, separate project > for my family tree). > > I have read that some time ago you had project files but this was > changed because the database is useless without a log file and log files > were stored in .gramps folder. I just don't get this decision. Why can't > you just invent a file format which would contain the database and the > log and the media, or simply let the user choose the directory for all > the family tree's files (database + logs + media)? This way I could just > pass this file or directory to someone else and they would have the > complete family tree. > > Finally, the fact that media is not part of the family tree (or > database, or let's call it project) seems just weird to me. I mean, this > is genealogy software and I want to give the family tree to other family > members or my kids when I have them. How can I assume that they'll have > the same directory structure on their computers? I don't even think > anyone in my family uses Linux. > > I tried to export all the data to a Gramps XML Package, but it seems it > doesn't include photos. Gramps after reimporting the data from this XML > stupidly assumes old paths to media files. > > I mean, come on, am I missing something obvious or this is just > ridiculous? Do you plan to reinvent the file format and/or project > management? In my opinion, all of this is simply counterintuitive now. > > It's a pity, because I really like the program. It has some other minor > annoyances (not conforming to Gnome guidelines sometimes) but the one I > mentioned seems like a real deal breaker to me. > > Regards, > -- > Juliusz Gonera > http://juliuszgonera.com/ Juliusz, I'm just one of the people that contribute, so I'm not speaking for anyone but me. Gramps is a work-in-progress, and continually gets better every year. Every day, really. You have indeed missed some things---not sure if they are obvious or not: 1. You can put the main Gramps folder where ever you want. .gramps in the home directory is the default, but you can change that in Preferences. 2. Files (such as photos) are not stored in a database, but in the file system. The decision was based on the idea that file systems were designed to hold files. If you put those in a folder structure, you can use them outside of Gramps, too. 3. When you make a Gramps XML Package, it copies all of the files into a file structure that mirrors their current locations. This works across platforms. You do not need to use Linux. This is the most flexible way to accommodate all of the ways people use Gramps. 4. The Gramps-developer environment is very open to discussions of productive, alternative methods of operation. Especially if those come with a thoughtful analysis and understanding of the current state, and a clear direction to head. We have a series of Gramps Enhancement ProposalS: http://www.gramps-project.org/wiki/index.php?title=GEPS 5. The idea of the central location of all databases is one that was made based on the best understanding of the technology at the time, by the small number of developers at the time. I think that this can be improved, and I'm working on an idea along these lines. So, if you (or anyone) would like to work on making Gramps better, you might want to join the gramps-developer mailing list. We discuss stuff like this every day. Of course we also get people that pop in, claim that they don't like X, and move on. That's fine too. But we do cater to those people that actually use Gramps, and understand the way it works before they suggest alternative methods. Hope that helps! -Doug > ------------------------------------------------------------------------------ > > _______________________________________________ > Gramps-users mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-users > |
From: Juliusz G. <jg...@gm...> - 2010-05-29 17:06:01
|
Doug Blank wrote: > Juliusz, > > I'm just one of the people that contribute, so I'm not speaking for > anyone but me. > > Gramps is a work-in-progress, and continually gets better every year. > Every day, really. > I know and I appreciate it. Last time I tried it a year ago and I see the progress. > You have indeed missed some things---not sure if they are obvious or not: > > 1. You can put the main Gramps folder where ever you want. .gramps in > the home directory is the default, but you can change that in > Preferences. > Yes, I know. But this is a global setting and I would like it to be family tree specific. > 2. Files (such as photos) are not stored in a database, but in the > file system. The decision was based on the idea that file systems were > designed to hold files. If you put those in a folder structure, you > can use them outside of Gramps, too. > I agree with that. Databases are not for files. But I consider photos such an integral part of the family tree (I'm talking about 1-3 photos per person, just to be able to identify each person) that it just bothers me that they're somewhere else. Maybe an option to add a photo to the family tree while adding it to the media would be a good idea (so the user could decide whether they want to make it an internal or external resource). This way I could make those few photos an integral part of the family tree. And I'm not talking about putting them inside a database. I'm thinking rather about two solutions: 1. A new file metaformat which would contain the database files and media files. 2. Or simpler, a project file and a directory with all the data, e.g. name of the file: my_family_tree.gramps name of the directory: my_family_tree (both in the same path) > 3. When you make a Gramps XML Package, it copies all of the files into > a file structure that mirrors their current locations. This works > across platforms. You do not need to use Linux. This is the most > flexible way to accommodate all of the ways people use Gramps. > Yes, but this just doesn't seem convenient when more people want to work with one family tree on more than one computer. Let's say that I want to give the family tree to my mother on a pendrive so that she can edit some things. Then, I want to copy it back to have all the updated data. The way I understand it works right now is: 1. I export the family tree to XML Package. 2. My mother creates an empty family tree on her computer. 3. She imports the package. 4. She makes the changes. 5. She exports the family tree. 6. I delete my old family tree on my computer. 7. I create a new empty family tree on my computer. 8. I import the family tree from my mother. This really seems like too many steps to me (and I still skipped the part about changing the absolute path and moving media files). I would rather see it like this: 1. I copy my family tree directory/project file to a pendrive. 2. My mother opens it on her computer. 3. She makes the changes. 4. I copy the updated family tree back to my HDD replacing the old one. Moreover, I could even do such a thing as setting a version control repo for the whole thing and writing a script for my mom that would get the newest version from the repo before she opens Gramps and commit the changes after she closes it. This is quite more difficult if my family tree files (that is database + media) can be scattered all over the HDD. > 4. The Gramps-developer environment is very open to discussions of > productive, alternative methods of operation. Especially if those come > with a thoughtful analysis and understanding of the current state, and > a clear direction to head. We have a series of Gramps Enhancement > ProposalS: http://www.gramps-project.org/wiki/index.php?title=GEPS > How can one add another proposal? > 5. The idea of the central location of all databases is one that was > made based on the best understanding of the technology at the time, by > the small number of developers at the time. I think that this can be > improved, and I'm working on an idea along these lines. > Good to hear that, I'm curious to see it. > So, if you (or anyone) would like to work on making Gramps better, you > might want to join the gramps-developer mailing list. We discuss stuff > like this every day. Of course we also get people that pop in, claim > that they don't like X, and move on. That's fine too. But we do cater > to those people that actually use Gramps, and understand the way it > works before they suggest alternative methods. > OK, I'll subscribe. I doubt I'll be able to help right now but who knows. Thanks for the reply. I'm positively surprised of how fast I received those replies ;) -- Juliusz Gonera http://juliuszgonera.com/ |
From: Benny M. <ben...@gm...> - 2010-05-30 10:09:46
|
2010/5/29 Juliusz Gonera <jg...@gm...> > > > > 2. Files (such as photos) are not stored in a database, but in the > > file system. The decision was based on the idea that file systems were > > designed to hold files. If you put those in a folder structure, you > > can use them outside of Gramps, too. > > > > I agree with that. Databases are not for files. But I consider photos > such an integral part of the family tree (I'm talking about 1-3 photos > per person, just to be able to identify each person) that it just > bothers me that they're somewhere else. Maybe an option to add a photo > to the family tree while adding it to the media would be a good idea (so > the user could decide whether they want to make it an internal or > external resource). This way I could make those few photos an integral > part of the family tree. And I'm not talking about putting them inside a > database. I'm thinking rather about two solutions: > > 1. A new file metaformat which would contain the database files and > media files. > 2. Or simpler, a project file and a directory with all the data, e.g. > name of the file: my_family_tree.gramps > name of the directory: my_family_tree > (both in the same path) > I'm not in favor of this. It might be useful, but it is a lot of complication in the code for little gain. > > > 3. When you make a Gramps XML Package, it copies all of the files into > > a file structure that mirrors their current locations. This works > > across platforms. You do not need to use Linux. This is the most > > flexible way to accommodate all of the ways people use Gramps. > > > > Yes, but this just doesn't seem convenient when more people want to work > with one family tree on more than one computer. Let's say that I want to > give the family tree to my mother on a pendrive so that she can edit > some things. Then, I want to copy it back to have all the updated data. > The way I understand it works right now is: > > 1. I export the family tree to XML Package. > 2. My mother creates an empty family tree on her computer. > 3. She imports the package. > 4. She makes the changes. > 5. She exports the family tree. > 6. I delete my old family tree on my computer. > 7. I create a new empty family tree on my computer. > 8. I import the family tree from my mother. > > This really seems like too many steps to me (and I still skipped the > part about changing the absolute path and moving media files). > I would rather see it like this: > > 1. I copy my family tree directory/project file to a pendrive. > 2. My mother opens it on her computer. > 3. She makes the changes. > 4. I copy the updated family tree back to my HDD replacing the old one. > > Moreover, I could even do such a thing as setting a version control repo > for the whole thing and writing a script for my mom that would get the > newest version from the repo before she opens Gramps and commit the > changes after she closes it. This is quite more difficult if my family > tree files (that is database + media) can be scattered all over the HDD. > > Some things here. *Some people set their database location on an NFS share, and can work on different computers like that. This works provided that the bsddb versions on the different computers are compatible, and the same Gramps version is used. *You can open/save a family tree from a different place via the command line. So it is possible to create .desktop files per family tree. The main reasoning to stick with the current layout is simplicity. The average Gramps users is not a PC-guru, so it should just work. For jour use case where you give 8. steps, I can give you this: 1. I export the family tree to XML Package. 2. My mother clicks on the file 3. She makes the changes. 4. She exports the family tree. 5. I click the xml file 6. with manager I change the file name and delete the old one Benny > > 4. The Gramps-developer environment is very open to discussions of > > productive, alternative methods of operation. Especially if those come > > with a thoughtful analysis and understanding of the current state, and > > a clear direction to head. We have a series of Gramps Enhancement > > ProposalS: http://www.gramps-project.org/wiki/index.php?title=GEPS > > > How can one add another proposal? > > > 5. The idea of the central location of all databases is one that was > > made based on the best understanding of the technology at the time, by > > the small number of developers at the time. I think that this can be > > improved, and I'm working on an idea along these lines. > > > Good to hear that, I'm curious to see it. > > > So, if you (or anyone) would like to work on making Gramps better, you > > might want to join the gramps-developer mailing list. We discuss stuff > > like this every day. Of course we also get people that pop in, claim > > that they don't like X, and move on. That's fine too. But we do cater > > to those people that actually use Gramps, and understand the way it > > works before they suggest alternative methods. > > > OK, I'll subscribe. I doubt I'll be able to help right now but who knows. > > Thanks for the reply. I'm positively surprised of how fast I received > those replies ;) > > -- > Juliusz Gonera > http://juliuszgonera.com/ > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Gramps-users mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-users > |
From: Juliusz G. <jg...@gm...> - 2010-05-30 18:27:54
|
Benny Malengier wrote: > > 1. A new file metaformat which would contain the database files and > media files. > 2. Or simpler, a project file and a directory with all the data, e.g. > name of the file: my_family_tree.gramps > name of the directory: my_family_tree > (both in the same path) > > > I'm not in favor of this. It might be useful, but it is a lot of > complication in the code for little gain. Why would the second option be complicated? It's enough to provide an Open file dialog instead of the Family Tree manager. Then, instead of having two Quit options (Quit or Quit abandonning changes), we would have only one option (asking if we want to save changes on exit, like in other programs) and a Save option, to save the changes whenever we want to. > Some things here. > *Some people set their database location on an NFS share, and can work > on different computers like that. This works provided that the bsddb > versions on the different computers are compatible, and the same > Gramps version is used. And what about media paths? Can I point them to NFS? > *You can open/save a family tree from a different place via the > command line. So it is possible to create .desktop files per family > tree. The main reasoning to stick with the current layout is > simplicity. The average Gramps users is not a PC-guru, so it should > just work. For jour use case where you give 8. steps, I can give you this: > 1. I export the family tree to XML Package. > 2. My mother clicks on the file > 3. She makes the changes. > 4. She exports the family tree. > 5. I click the xml file > 6. with manager I change the file name and delete the old one It can be a solution, but I would say that the average MS Word user or Photoshop user is also not a PC guru, but they somehow grasp the concept of files and projects. -- Juliusz Gonera http://juliuszgonera.com/ |
From: Benny M. <ben...@gm...> - 2010-05-30 22:41:30
|
2010/5/30 Juliusz Gonera <jg...@gm...> > Benny Malengier wrote: > > 1. A new file metaformat which would contain the database files and >> media files. >> 2. Or simpler, a project file and a directory with all the data, e.g. >> name of the file: my_family_tree.gramps >> name of the directory: my_family_tree >> (both in the same path) >> > > I'm not in favor of this. It might be useful, but it is a lot of > complication in the code for little gain. > > > Why would the second option be complicated? It's enough to provide an Open > file dialog instead of the Family Tree manager. Then, instead of having two > Quit options (Quit or Quit abandonning changes), we would have only one > option (asking if we want to save changes on exit, like in other programs) > and a Save option, to save the changes whenever we want to. > > Gramps does not save files, it saves in a database. Showing a database as a file is something that only works for minisql, not with the systhem gramps uses, so the present format is a _technical_ limitation connected with the database we use. We are much simpler than requiring users to set up a postgresql of mysql database, but more complicated than a file. > Some things here. > *Some people set their database location on an NFS share, and can work on > different computers like that. This works provided that the bsddb versions > on the different computers are compatible, and the same Gramps version is > used. > > > And what about media paths? Can I point them to NFS? > You should have all your media files as relative paths. As to NFS, in unix everything is mounted, so there is no difference. > > > *You can open/save a family tree from a different place via the command > line. So it is possible to create .desktop files per family tree. The main > reasoning to stick with the current layout is simplicity. The average Gramps > users is not a PC-guru, so it should just work. For jour use case where you > give 8. steps, I can give you this: > 1. I export the family tree to XML Package. > 2. My mother clicks on the file > 3. She makes the changes. > 4. She exports the family tree. > 5. I click the xml file > 6. with manager I change the file name and delete the old one > > > It can be a solution, but I would say that the average MS Word user or > Photoshop user is also not a PC guru, but they somehow grasp the concept of > files and projects. > Well, as said, that is because what they save are files. In MS Word it is actually a zipped format with the xml and the other objects. Gramps does not save in a file though, trying to make it seem like we do happened in version 2.2.x, and created many problems. With the family tree manager we avoid confronting the user with the complexity of a database, but we do offer them all the advantages: atomic commit, fallback/rollback. Try to jank out the power while writing a word document and do the same with gramps. Gramps will have no problem at all _ever_ with power loss. You roll back to last atomic commit. Benny > -- > > Juliusz Gonerahttp://juliuszgonera.com/ > > |
From: Nick W. <ni...@be...> - 2010-05-26 22:06:10
|
I would not *want* my media objects subsumed into 'gramps' files - media files are media files, and though they can be stored into the database, there is no inherent advantage. When you say you tried exporting to XML and re-importing, it is not clear to me which option you have used. One type of export creates an XML of your database objects; the other includes all of the media files as well. If you have exported to the latter, it is effectively a backup of the database and your media files, and could be distributed, etc. And in doing it that way, you would not lose data (as with GEDCOM), nor would you be constrained to a proprietary format (as with other genealogical programmes). The location of the Gramps database(s) is no secret, and when you create a new database (or family tree, or 'project' if you will...), it creates a new directory that contains the files. I'm not sure what the problem with that is. The 'project' directories can be individually backed up and copied about - though I think a preferred option might be the export to XML. The future of Gramps includes a number of significant development strands, including Gramps Connect, a web-based collaboration tool. If you haven't heard about it, search around on the wiki to learn more. One of major reasons I started and stay with Gramps is I believe the structuring and analysis of genealogical needs is without peer - and with sufficient export capabilities to future-proof my data. Nick Wallingford Tauranga, NZ > Hi, > > First of all I want to say thanks to the authors for a nice piece of > software. It's the best of its kind I have found so far. > > However, one thing really bothers me: Why isn't all the media imported > into the database? What's more, I don't like the fact that the location > of the database is kind of hidden from me and I cannot choose separate > location for every family tree (like creating a new, separate project > for my family tree). > > I have read that some time ago you had project files but this was > changed because the database is useless without a log file and log files > were stored in .gramps folder. I just don't get this decision. Why can't > you just invent a file format which would contain the database and the > log and the media, or simply let the user choose the directory for all > the family tree's files (database + logs + media)? This way I could just > pass this file or directory to someone else and they would have the > complete family tree. > > Finally, the fact that media is not part of the family tree (or > database, or let's call it project) seems just weird to me. I mean, this > is genealogy software and I want to give the family tree to other family > members or my kids when I have them. How can I assume that they'll have > the same directory structure on their computers? I don't even think > anyone in my family uses Linux. > > I tried to export all the data to a Gramps XML Package, but it seems it > doesn't include photos. Gramps after reimporting the data from this XML > stupidly assumes old paths to media files. > > I mean, come on, am I missing something obvious or this is just > ridiculous? Do you plan to reinvent the file format and/or project > management? In my opinion, all of this is simply counterintuitive now. > > It's a pity, because I really like the program. It has some other minor > annoyances (not conforming to Gnome guidelines sometimes) but the one I > mentioned seems like a real deal breaker to me. > > Regards, > -- > Juliusz Gonera > http://juliuszgonera.com/ > > ------------------------------------------------------------------------------ > > _______________________________________________ > Gramps-users mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-users > |
From: Juliusz G. <jg...@gm...> - 2010-05-29 17:05:46
|
Nick Wallingford wrote: > I would not *want* my media objects subsumed into 'gramps' files - media > files are media files, and though they can be stored into the database, > there is no inherent advantage. > I already explained my idea a bit better (I hope) in reply to Doug's message. I don't want to put them into the database and I also don't want to put albums of photos inside a family tree. I just want a few photos per person to be an integral part of the family tree so that every person can be easily identified. > When you say you tried exporting to XML and re-importing, it is not clear > to me which option you have used. One type of export creates an XML of > your database objects; the other includes all of the media files as well. > If you have exported to the latter, it is effectively a backup of the > database and your media files, and could be distributed, etc. And in > doing it that way, you would not lose data (as with GEDCOM), nor would you > be constrained to a proprietary format (as with other genealogical > programmes). > I'm sorry, I didn't notice that the files were created in my home directory after importing because the paths didn't change and looked like absolute paths. In fact, they were relative but the whole directory structure was reconstructed inside the new media directory. This was a bit misleading. > The location of the Gramps database(s) is no secret, and when you create a > new database (or family tree, or 'project' if you will...), it creates a > new directory that contains the files. I'm not sure what the problem with > that is. The 'project' directories can be individually backed up and > copied about - though I think a preferred option might be the export to > XML. > I'm not saying that's it's a secret. It's just not how I, and I think many people, expect a program operating on data to work. People are used that if they e.g. open a word processor, then they can open their documents which are stored in files that they saved in specific locations selected for every file. The same with a graphics editor, CAD software, programming IDEs, virtually everything that uses the concept of a document or project. A family tree, as I see it, is a kind of project, yet Gramps is totally different in handling projects than other applications. I'm not saying that its approach is necessarily worse. But it's not a standard, something that I'm used to and that's why it makes it kind of counterintuitive for me. > The future of Gramps includes a number of significant development strands, > including Gramps Connect, a web-based collaboration tool. If you haven't > heard about it, search around on the wiki to learn more. > I will have a look at it. Thanks. -- Juliusz Gonera http://juliuszgonera.com/ |
From: Duncan L. <dun...@gm...> - 2010-05-28 06:16:53
|
On 26 May 2010 23:18, Juliusz Gonera <jg...@gm...> wrote: ... > It's a pity, because I really like the program. It has some other minor > annoyances (not conforming to Gnome guidelines sometimes) The Gnome HIG is one of my little projects every now and then, so please tell me which, perhaps in a new thread, aspects you've noticed. Duncan -- 'The unconsidered life is not worth living' - Socrates |
From: Jim W. <jim...@gm...> - 2010-05-30 21:39:11
|
> > , > > I'm just one of the people that contribute, so I'm not speaking for > anyone but me. > > Gramps is a work-in-progress, and continually gets better every year. > Every day, really. > > You have indeed missed some things---not sure if they are obvious or not: > > 1. You can put the main Gramps folder where ever you want. .gramps in > the home directory is the default, but you can change that in > Preferences. > > 2. Files (such as photos) are not stored in a database, but in the > file system. The decision was based on the idea that file systems were > designed to hold files. If you put those in a folder structure, you > can use them outside of Gramps, too. > > 3. When you make a Gramps XML Package, it copies all of the files into > a file structure that mirrors their current locations. This works > across platforms. You do not need to use Linux. This is the most > flexible way to accommodate all of the ways people use Gramps. > > 4. The Gramps-developer environment is very open to discussions of > productive, alternative methods of operation. Especially if those come > with a thoughtful analysis and understanding of the current state, and > a clear direction to head. We have a series of Gramps Enhancement > ProposalS: http://www.gramps-project.org/wiki/index.php?title=GEPS > > 5. The idea of the central location of all databases is one that was > made based on the best understanding of the technology at the time, by > the small number of developers at the time. I think that this can be > improved, and I'm working on an idea along these lines. > > So, if you (or anyone) would like to work on making Gramps better, you > might want to join the gramps-developer mailing list. We discuss stuff > like this every day. Of course we also get people that pop in, claim > that they don't like X, and move on. That's fine too. But we do cater > to those people that actually use Gramps, and understand the way it > works before they suggest alternative methods. > > Hope that helps! > > -Doug > > My portability wish would to be able to park my Gramps database in something like DropBox where I could access it on any of my computers. I have tried to tame the Gramps XML import/export but with a database of 16k+ people, the time it takes way too long to be practical. Jim |
From: Benny M. <ben...@gm...> - 2010-05-30 22:53:17
|
2010/5/30 Jim Winfrey <jim...@gm...> > , >> >> I'm just one of the people that contribute, so I'm not speaking for >> anyone but me. >> >> Gramps is a work-in-progress, and continually gets better every year. >> Every day, really. >> >> You have indeed missed some things---not sure if they are obvious or not: >> >> 1. You can put the main Gramps folder where ever you want. .gramps in >> the home directory is the default, but you can change that in >> Preferences. >> >> 2. Files (such as photos) are not stored in a database, but in the >> file system. The decision was based on the idea that file systems were >> designed to hold files. If you put those in a folder structure, you >> can use them outside of Gramps, too. >> >> 3. When you make a Gramps XML Package, it copies all of the files into >> a file structure that mirrors their current locations. This works >> across platforms. You do not need to use Linux. This is the most >> flexible way to accommodate all of the ways people use Gramps. >> >> 4. The Gramps-developer environment is very open to discussions of >> productive, alternative methods of operation. Especially if those come >> with a thoughtful analysis and understanding of the current state, and >> a clear direction to head. We have a series of Gramps Enhancement >> ProposalS: http://www.gramps-project.org/wiki/index.php?title=GEPS >> >> 5. The idea of the central location of all databases is one that was >> made based on the best understanding of the technology at the time, by >> the small number of developers at the time. I think that this can be >> improved, and I'm working on an idea along these lines. >> >> So, if you (or anyone) would like to work on making Gramps better, you >> might want to join the gramps-developer mailing list. We discuss stuff >> like this every day. Of course we also get people that pop in, claim >> that they don't like X, and move on. That's fine too. But we do cater >> to those people that actually use Gramps, and understand the way it >> works before they suggest alternative methods. >> >> Hope that helps! >> >> -Doug >> >> > My portability wish would to be able to park my Gramps database in > something like DropBox where I could access it on any of my computers. I > have tried to tame the Gramps XML import/export but with a database of 16k+ > people, the time it takes way too long to be practical. > You could if you could mount dropbox via fuse. I did not try those services, but are they not meant to sync local files with remote ones? If so, I don't see what the problem would be to sync your gramps database. Perhaps slow, but not a problem. On the second computer you wait for it to sync, and start working. If you want a network drive, then you need the mount way, something like Wuala offers that (http://wua.la/en/learn/features a linux client available), there must be others. First Gb is free there. 16000+ people in Gramps might be bigger though, you should look in your storage directory... Not sure it would be fast though. If it works on local file and syncs, it should be fast. But as this is a database, saving something to it can cause quite some change in the file, which then must be synced, so a lock will placed, probably slowing your access via Gramps. You should try it (on backup, or taking regular backups in beginning due to testing) and write back. Do not underestimate the lag of a network connection, if you need to work with a local app, waiting for network traffic, depending on the implementation, it might be very slow. Benny > Jim > > > ------------------------------------------------------------------------------ > > > _______________________________________________ > Gramps-users mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-users > > |
From: Duncan L. <dun...@gm...> - 2010-05-31 06:27:27
|
Regarding using dropbox or similar services to sync between pcs... I looked into this and found that one clear problem was the size of log files, don't ask me why they get so big, but mine were significantly bigger than my database. Duncan -- 'The unconsidered life is not worth living' - Socrates |
From: Benny M. <ben...@gm...> - 2010-05-31 08:33:09
|
2010/5/31 Duncan Lithgow <dun...@gm...> > Regarding using dropbox or similar services to sync between pcs... > > I looked into this and found that one clear problem was the size of > log files, don't ask me why they get so big, but mine were > significantly bigger than my database. > > We set a flag to remove log files, but indeed, it does not seem to do much. It is something we should look at, but it has low priority. There is thread where this is discussed. If I remember correctly, gramps closes cleanly, you can remove all but the last log file without consequence. You can try, make a backup and remove all but the last. You only need all the log files for database rollback to an earlier state, something that Gramps users probably don't really need. But you can understand why keeping _all_ states, can cause a lot of disk space to be used. Benny > Duncans > -- > 'The unconsidered life is not worth living' - Socrates > |
From: Juliusz G. <jg...@gm...> - 2010-06-02 18:28:17
|
Benny Malengier wrote: > Gramps does not save files, it saves in a database. Showing a > database as a file is something that only works for minisql, not with > the systhem gramps uses, so the present format is a _technical_ > limitation connected with the database we use. We are much simpler > than requiring users to set up a postgresql of mysql database, but > more complicated than a file. It's also possible for SQLite. Has it ever been considered as a Gramps database? Anyway, as I said, I know that it's not a single file at the moment. But it could be or it could be at least a selected directory for one project. > And what about media paths? Can I point them to NFS? > > > You should have all your media files as relative paths. As to NFS, in > unix everything is mounted, so there is no difference. My mother uses Windows. I guess the only way would be Samba. Can I set a path to a Samba resource? > Well, as said, that is because what they save are files. In MS Word it > is actually a zipped format with the xml and the other objects. Gramps > does not save in a file though, trying to make it seem like we do > happened in version 2.2.x, and created many problems. What was the situation back then? What was the file format? What were the problems? > With the family tree manager we avoid confronting the user with the > complexity of a database, but we do offer them all the advantages: > atomic commit, fallback/rollback. Try to jank out the power while > writing a word document and do the same with gramps. Gramps will have > no problem at all _ever_ with power loss. You roll back to last atomic > commit. Yes, that's nice, but I don't cut off the power too often. Even then, it's possible to save most of the data in case of power shortage (and that's what most programs, even not database driven, do nowadays). -- Juliusz Gonera http://juliuszgonera.com/ |
From: Benny M. <ben...@gm...> - 2010-06-03 07:30:17
|
2010/6/2 Juliusz Gonera <jg...@gm...> > Benny Malengier wrote: > > Gramps does not save files, it saves in a database. Showing a database > as a file is something that only works for minisql, not with the systhem > gramps uses, so the present format is a _technical_ limitation connected > with the database we use. We are much simpler than requiring users to set up > a postgresql of mysql database, but more complicated than a file. > > > It's also possible for SQLite. Has it ever been considered as a Gramps > database? Anyway, as I said, I know that it's not a single file at the > moment. But it could be or it could be at least a selected directory for one > project. > There is work in connection with Gramps-connect, to allow for sqlite. We actually use django, which as a backend can use that or postgres/mysql. A dictionary was indeed an option, be considered that to be confusing for the average user. An advanced user can use directories via the command line options. Doing gramps -l shows directories, not the top path. > > > And what about media paths? Can I point them to NFS? >> > > You should have all your media files as relative paths. As to NFS, in unix > everything is mounted, so there is no difference. > > > My mother uses Windows. I guess the only way would be Samba. Can I set a > path to a Samba resource? > > This did not work in the past. I think it should be possible, but the database we use probably choked on samba paths in the past. > > Well, as said, that is because what they save are files. In MS Word it > is actually a zipped format with the xml and the other objects. Gramps does > not save in a file though, trying to make it seem like we do happened in > version 2.2.x, and created many problems. > > > What was the situation back then? What was the file format? What were the > problems? > > The file format was grdb, with the database in one location, leading to the problem: http://gramps-project.org/wiki/index.php?title=Recover_corrupted_grdb#Version_2.2.x:_GRDB_corruption In essence this was due to log files not being part of the single file, but that was a limitation of the database we use (bsddb). With the family tree manager we avoid confronting the user with the > complexity of a database, but we do offer them all the advantages: atomic > commit, fallback/rollback. Try to jank out the power while writing a word > document and do the same with gramps. Gramps will have no problem at all > _ever_ with power loss. You roll back to last atomic commit. > > > Yes, that's nice, but I don't cut off the power too often. Even then, it's > possible to save most of the data in case of power shortage (and that's what > most programs, even not database driven, do nowadays). > Yes, I see MS office still creates these $ files. That is a big complication though (in the sense that _we_ have to write code for that, as opposed to using a system that exists. The reason OSS can be successful even with limited people hacking on things is due to the reuse of open libraries. Is somebody out there has a system for a one file bsddb database, then I'm all for it to use it. But I don't think we can implement a system ourself. The best option is gramps-connect, that would allow to use sqlite, but the price would be another database layer, so it might be slower: gramps --> gen.lib Gramps api -> django backend -> sqlite database. This is actually quite far in development, but needs some extra developers to be able to really integrate it in Gramps. Benny > > -- > Juliusz Gonerahttp://juliuszgonera.com/ > > |
From: Gerald B. <ger...@gm...> - 2010-06-03 13:41:36
|
We could consider using sqlite natively as the backend. Just set it up to handle the eight pickled object types as BLOBs, adding the handle as the primary key. I'm not sure what we would gain this way though, since we would not be using sqlite as anything more than an extra layer to get to our data store. OTOH if we did do this, we could then swap out sqlite for any other backend (postgres, DB2, Oracle, etc.) with minimal changes. A long way from a real RDBMS design, though. On Thu, Jun 3, 2010 at 3:30 AM, Benny Malengier <ben...@gm...> wrote: > > > 2010/6/2 Juliusz Gonera <jg...@gm...> >> >> Benny Malengier wrote: >> >> Gramps does not save files, it saves in a database. Showing a database as >> a file is something that only works for minisql, not with the systhem gramps >> uses, so the present format is a _technical_ limitation connected with the >> database we use. We are much simpler than requiring users to set up a >> postgresql of mysql database, but more complicated than a file. >> >> It's also possible for SQLite. Has it ever been considered as a Gramps >> database? Anyway, as I said, I know that it's not a single file at the >> moment. But it could be or it could be at least a selected directory for one >> project. > > There is work in connection with Gramps-connect, to allow for sqlite. We > actually use django, which as a backend can use that or postgres/mysql. > A dictionary was indeed an option, be considered that to be confusing for > the average user. An advanced user can use directories via the command line > options. Doing gramps -l shows directories, not the top path. > >> >> >>> And what about media paths? Can I point them to NFS? >> >> You should have all your media files as relative paths. As to NFS, in unix >> everything is mounted, so there is no difference. >> >> My mother uses Windows. I guess the only way would be Samba. Can I set a >> path to a Samba resource? > > This did not work in the past. I think it should be possible, but the > database we use probably choked on samba paths in the past. > >> >> Well, as said, that is because what they save are files. In MS Word it is >> actually a zipped format with the xml and the other objects. Gramps does not >> save in a file though, trying to make it seem like we do happened in version >> 2.2.x, and created many problems. >> >> What was the situation back then? What was the file format? What were the >> problems? > > The file format was grdb, with the database in one location, leading to the > problem: > http://gramps-project.org/wiki/index.php?title=Recover_corrupted_grdb#Version_2.2.x:_GRDB_corruption > In essence this was due to log files not being part of the single file, but > that was a limitation of the database we use (bsddb). > >> With the family tree manager we avoid confronting the user with the >> complexity of a database, but we do offer them all the advantages: atomic >> commit, fallback/rollback. Try to jank out the power while writing a word >> document and do the same with gramps. Gramps will have no problem at all >> _ever_ with power loss. You roll back to last atomic commit. >> >> Yes, that's nice, but I don't cut off the power too often. Even then, it's >> possible to save most of the data in case of power shortage (and that's what >> most programs, even not database driven, do nowadays). > > Yes, I see MS office still creates these $ files. That is a big complication > though (in the sense that _we_ have to write code for that, as opposed to > using a system that exists. The reason OSS can be successful even with > limited people hacking on things is due to the reuse of open libraries. Is > somebody out there has a system for a one file bsddb database, then I'm all > for it to use it. But I don't think we can implement a system ourself. The > best option is gramps-connect, that would allow to use sqlite, but the price > would be another database layer, so it might be slower: > gramps --> gen.lib Gramps api -> django backend -> sqlite database. > > This is actually quite far in development, but needs some extra developers > to be able to really integrate it in Gramps. > > Benny > >> >> -- >> Juliusz Gonera >> http://juliuszgonera.com/ > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > Gramps-users mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-users > > -- Gerald Britton |
From: Doug B. <dou...@gm...> - 2010-06-04 12:24:20
|
On Thu, Jun 3, 2010 at 9:41 AM, Gerald Britton <ger...@gm...> wrote: > We could consider using sqlite natively as the backend. Just set it > up to handle the eight pickled object types as BLOBs, adding the > handle as the primary key. I'm not sure what we would gain this way > though, since we would not be using sqlite as anything more than an > extra layer to get to our data store. OTOH if we did do this, we > could then swap out sqlite for any other backend (postgres, DB2, > Oracle, etc.) with minimal changes. A long way from a real RDBMS > design, though. I've been looking at Gerald's suggestion of using sqlite as a non-relational data store, and I think it does make some sense for Gramps. The most important, I think, is that the file structure is guaranteed to be backwards compatible. However, there are some other benefits: data in a single file, no log files, well-understood, and data format is cross-platform. I'd also like to know: would it be faster? would it be smaller? would it be as reliable as BSDDB? These questions I hope to answer. -Doug > > On Thu, Jun 3, 2010 at 3:30 AM, Benny Malengier > <ben...@gm...> wrote: >> >> >> 2010/6/2 Juliusz Gonera <jg...@gm...> >>> >>> Benny Malengier wrote: >>> >>> Gramps does not save files, it saves in a database. Showing a database as >>> a file is something that only works for minisql, not with the systhem gramps >>> uses, so the present format is a _technical_ limitation connected with the >>> database we use. We are much simpler than requiring users to set up a >>> postgresql of mysql database, but more complicated than a file. >>> >>> It's also possible for SQLite. Has it ever been considered as a Gramps >>> database? Anyway, as I said, I know that it's not a single file at the >>> moment. But it could be or it could be at least a selected directory for one >>> project. >> >> There is work in connection with Gramps-connect, to allow for sqlite. We >> actually use django, which as a backend can use that or postgres/mysql. >> A dictionary was indeed an option, be considered that to be confusing for >> the average user. An advanced user can use directories via the command line >> options. Doing gramps -l shows directories, not the top path. >> >>> >>> >>>> And what about media paths? Can I point them to NFS? >>> >>> You should have all your media files as relative paths. As to NFS, in unix >>> everything is mounted, so there is no difference. >>> >>> My mother uses Windows. I guess the only way would be Samba. Can I set a >>> path to a Samba resource? >> >> This did not work in the past. I think it should be possible, but the >> database we use probably choked on samba paths in the past. >> >>> >>> Well, as said, that is because what they save are files. In MS Word it is >>> actually a zipped format with the xml and the other objects. Gramps does not >>> save in a file though, trying to make it seem like we do happened in version >>> 2.2.x, and created many problems. >>> >>> What was the situation back then? What was the file format? What were the >>> problems? >> >> The file format was grdb, with the database in one location, leading to the >> problem: >> http://gramps-project.org/wiki/index.php?title=Recover_corrupted_grdb#Version_2.2.x:_GRDB_corruption >> In essence this was due to log files not being part of the single file, but >> that was a limitation of the database we use (bsddb). >> >>> With the family tree manager we avoid confronting the user with the >>> complexity of a database, but we do offer them all the advantages: atomic >>> commit, fallback/rollback. Try to jank out the power while writing a word >>> document and do the same with gramps. Gramps will have no problem at all >>> _ever_ with power loss. You roll back to last atomic commit. >>> >>> Yes, that's nice, but I don't cut off the power too often. Even then, it's >>> possible to save most of the data in case of power shortage (and that's what >>> most programs, even not database driven, do nowadays). >> >> Yes, I see MS office still creates these $ files. That is a big complication >> though (in the sense that _we_ have to write code for that, as opposed to >> using a system that exists. The reason OSS can be successful even with >> limited people hacking on things is due to the reuse of open libraries. Is >> somebody out there has a system for a one file bsddb database, then I'm all >> for it to use it. But I don't think we can implement a system ourself. The >> best option is gramps-connect, that would allow to use sqlite, but the price >> would be another database layer, so it might be slower: >> gramps --> gen.lib Gramps api -> django backend -> sqlite database. >> >> This is actually quite far in development, but needs some extra developers >> to be able to really integrate it in Gramps. >> >> Benny >> >>> >>> -- >>> Juliusz Gonera >>> http://juliuszgonera.com/ >> >> ------------------------------------------------------------------------------ >> ThinkGeek and WIRED's GeekDad team up for the Ultimate >> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the >> lucky parental unit. See the prize list and enter to win: >> http://p.sf.net/sfu/thinkgeek-promo >> _______________________________________________ >> Gramps-users mailing list >> Gra...@li... >> https://lists.sourceforge.net/lists/listinfo/gramps-users >> >> > > > > -- > Gerald Britton > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > Gramps-users mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-users > |
From: Gerald B. <ger...@gm...> - 2010-06-04 13:09:22
|
On Fri, Jun 4, 2010 at 8:16 AM, Doug Blank <dou...@gm...> wrote: > On Thu, Jun 3, 2010 at 9:41 AM, Gerald Britton <ger...@gm...> wrote: >> We could consider using sqlite natively as the backend. Just set it >> up to handle the eight pickled object types as BLOBs, adding the >> handle as the primary key. I'm not sure what we would gain this way >> though, since we would not be using sqlite as anything more than an >> extra layer to get to our data store. OTOH if we did do this, we >> could then swap out sqlite for any other backend (postgres, DB2, >> Oracle, etc.) with minimal changes. A long way from a real RDBMS >> design, though. > > I've been looking at Gerald's suggestion of using sqlite as a > non-relational data store, and I think it does make some sense for > Gramps. The most important, I think, is that the file structure is > guaranteed to be backwards compatible. However, there are some other > benefits: data in a single file, no log files, well-understood, and > data format is cross-platform. I'd also like to know: would it be > faster? would it be smaller? would it be as reliable as BSDDB? These > questions I hope to answer. FWIW it should be easy to implement. Just change calls to bsddb to calls to sqlite with simple SELECT, UPDATE, or DELETE commands With a little more work (not much, really), we could have SQL- (whichever one you like) manage the secondary indices. Say we set up our tables like this: CREATE TABLE People as ( handle char(8) primary key, grampsid char(8) unique, surname varchar(255), data text, ); CREATE TABLE Families ... etc. Then, create secondary indices on grampsid (unique) and surname (not unique). Set up appropriate rules for actions when related objects are deleted (probably set to null in most cases). Then we can use the power of SQL to do our dirty work. We could also use _any_ backend by importing the proper module or just using pyodbc to connect to DB2, Oracle, SQL Server, Postgresql, MySQL, etc. (though as it is today I wouldn't recommend MySQL for this app) The next level would be using SQL to manage the refmaps as well. Ironic in a way, since that is an RDBMS's bread and butter. > > -Doug > >> >> On Thu, Jun 3, 2010 at 3:30 AM, Benny Malengier >> <ben...@gm...> wrote: >>> >>> >>> 2010/6/2 Juliusz Gonera <jg...@gm...> >>>> >>>> Benny Malengier wrote: >>>> >>>> Gramps does not save files, it saves in a database. Showing a database as >>>> a file is something that only works for minisql, not with the systhem gramps >>>> uses, so the present format is a _technical_ limitation connected with the >>>> database we use. We are much simpler than requiring users to set up a >>>> postgresql of mysql database, but more complicated than a file. >>>> >>>> It's also possible for SQLite. Has it ever been considered as a Gramps >>>> database? Anyway, as I said, I know that it's not a single file at the >>>> moment. But it could be or it could be at least a selected directory for one >>>> project. >>> >>> There is work in connection with Gramps-connect, to allow for sqlite. We >>> actually use django, which as a backend can use that or postgres/mysql. >>> A dictionary was indeed an option, be considered that to be confusing for >>> the average user. An advanced user can use directories via the command line >>> options. Doing gramps -l shows directories, not the top path. >>> >>>> >>>> >>>>> And what about media paths? Can I point them to NFS? >>>> >>>> You should have all your media files as relative paths. As to NFS, in unix >>>> everything is mounted, so there is no difference. >>>> >>>> My mother uses Windows. I guess the only way would be Samba. Can I set a >>>> path to a Samba resource? >>> >>> This did not work in the past. I think it should be possible, but the >>> database we use probably choked on samba paths in the past. >>> >>>> >>>> Well, as said, that is because what they save are files. In MS Word it is >>>> actually a zipped format with the xml and the other objects. Gramps does not >>>> save in a file though, trying to make it seem like we do happened in version >>>> 2.2.x, and created many problems. >>>> >>>> What was the situation back then? What was the file format? What were the >>>> problems? >>> >>> The file format was grdb, with the database in one location, leading to the >>> problem: >>> http://gramps-project.org/wiki/index.php?title=Recover_corrupted_grdb#Version_2.2.x:_GRDB_corruption >>> In essence this was due to log files not being part of the single file, but >>> that was a limitation of the database we use (bsddb). >>> >>>> With the family tree manager we avoid confronting the user with the >>>> complexity of a database, but we do offer them all the advantages: atomic >>>> commit, fallback/rollback. Try to jank out the power while writing a word >>>> document and do the same with gramps. Gramps will have no problem at all >>>> _ever_ with power loss. You roll back to last atomic commit. >>>> >>>> Yes, that's nice, but I don't cut off the power too often. Even then, it's >>>> possible to save most of the data in case of power shortage (and that's what >>>> most programs, even not database driven, do nowadays). >>> >>> Yes, I see MS office still creates these $ files. That is a big complication >>> though (in the sense that _we_ have to write code for that, as opposed to >>> using a system that exists. The reason OSS can be successful even with >>> limited people hacking on things is due to the reuse of open libraries. Is >>> somebody out there has a system for a one file bsddb database, then I'm all >>> for it to use it. But I don't think we can implement a system ourself. The >>> best option is gramps-connect, that would allow to use sqlite, but the price >>> would be another database layer, so it might be slower: >>> gramps --> gen.lib Gramps api -> django backend -> sqlite database. >>> >>> This is actually quite far in development, but needs some extra developers >>> to be able to really integrate it in Gramps. >>> >>> Benny >>> >>>> >>>> -- >>>> Juliusz Gonera >>>> http://juliuszgonera.com/ >>> >>> ------------------------------------------------------------------------------ >>> ThinkGeek and WIRED's GeekDad team up for the Ultimate >>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the >>> lucky parental unit. See the prize list and enter to win: >>> http://p.sf.net/sfu/thinkgeek-promo >>> _______________________________________________ >>> Gramps-users mailing list >>> Gra...@li... >>> https://lists.sourceforge.net/lists/listinfo/gramps-users >>> >>> >> >> >> >> -- >> Gerald Britton >> >> ------------------------------------------------------------------------------ >> ThinkGeek and WIRED's GeekDad team up for the Ultimate >> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the >> lucky parental unit. See the prize list and enter to win: >> http://p.sf.net/sfu/thinkgeek-promo >> _______________________________________________ >> Gramps-users mailing list >> Gra...@li... >> https://lists.sourceforge.net/lists/listinfo/gramps-users >> > -- Gerald Britton |