User talk:Dsblank

From Gramps
Revision as of 00:04, 14 October 2011 by Gioto (talk | contribs) (Would be possible for the developers to look over the summary and update it as much as possible to reflect the current state? Thank you)
Jump to: navigation, search

Hello Doug,

Thanks for everything. I appreciate all your work with GRAMPS very much. That should be obvious anyway: who wouldn't? --Lcc 19:46, 22 March 2009 (UTC)

DB Schema

How goes the work on the DB schema? Could I help? I think I've done all the research on DB abstraction that I can. I'm not certain it's necessary to push the main devs on an abstraction layer quite yet. I'd like to test them out a little first. The DB schema is something we can nail down and push for a consensus on though. --AaronS 04:37, 29 March 2009 (UTC)

If you wanted to help explore the DB schema, you could attempt to derive a set of tables from the GRAMPS XML dtd. This is a different approach from what I was doing (converting the Python BSDDB code directly to DB schema, keeping intact all GRAMPS handles, and making up new ones where required). Thanks for getting this ball rolling! --Dsblank 23:19, 29 March 2009 (UTC)

Is your most current work on the schema at trunk/src/plugins/export/ExportSql.py? I'd prefer to keep our work coordinated together. We could just work directly with the exportsql.py module but it may make sense to work with more of a straight up db import file of just table creates and drops. relationships could be put in comments. that might make it less clutter for the main devs when we pitch it to them. Another option would be to create an actual table chart. have you ever used dia? I haven't found a really great table charting app yet but dia does an OK job. I don't have svn commit yet. how would you prefer to pass work back and forth? a tracker item. wiki page or wiki media file? Also to recap should we just use the exportsql.py code, db import file, or table mapping chart? --AaronS 04:35, 30 March 2009 (UTC)

Yes, that is the first stab at just creating a simple sqlite export... mostly just thinking out loud there. I agree that it would be a good idea to diagram the tables. It would be nice to have a table representation that could generate UML, dia, code... perhaps all we need to do is describe the tables in a text file, which could be read in by our programs to generate these outputs? I guess the XML doesn't work for that role, as it is hierarchical ... maybe a flat XML DTD version? --Dsblank 14:50, 30 March 2009 (UTC)

Do you have a specific solution in mind? That would be nice but I haven't heard of anything that can do all that. I was thinking the easiest would be to just have a import.sql file that would have all the sql to create the tables. We might have to have some additional notes but there aren't too many tables so a full table mapping chart might not be necessary though nice. Most 3rd party sqlite db tools should be able to just automatically load them and export them. firefox has a sqlite manager plugin that I've used in the past. https://addons.mozilla.org/en-US/firefox/addon/5817. I know we haven't fully settled on sqlite but it should be fine for a schema mockup. --AaronS 17:36, 30 March 2009 (UTC)

I don't have time right now to start looking into them but there may be some options that might help with at least some of it. Unless you have a specific solution in mind i'll do some research on them later.

--AaronS 18:23, 30 March 2009 (UTC)

GEPS 013: Server mode

Hi, looking at your prototype, I thought on someone who knows python, practices genealogy and planned (dream ?) to work on something like that : [1]

--Romjerome 08:54, 2 August 2009 (UTC)

Looks like a good plan! I'm glad that we can build on top of GRAMPS though. I think a GRAMPS on-line version will be really very nice! Can't wait! --Dsblank 09:00, 2 August 2009 (UTC)

Someone (see above) pointed out something similar !

--Romjerome 06:52, 17 August 2009 (UTC)

Capitalization

Hello dsblank,

I think it'd be nice if the wiki could follow a standard capitalization practice. I like the one in Wikipedia: Headers are sentence-capitalized, meaning only the first word is capitalized by rule. --Lcc 16:52, 29 March 2010 (UTC)

middle_name field

Hello Dsblank,

I was reading about Gramps on the internet and found this thread: http://www.google.com/url?url=http://groups.google.com/g/bfe7ff06/t/51188781aad5e533/d/f5341c781fa62ed6%3Fq%3Dgramps%2Bsoftware%23f5341c781fa62ed6&ei=Sg0ZTJOWGoK9lwfPi7iYDQ&sa=t&ct=res&cd=3&source=groups&usg=AFQjCNFyNoHx4pcG9fc7T_tmCQZlQLZomA

I think it shows how interesting this could be for Gramps. It doesn't seem it would be too difficult to add this field. --Lcc 11:14, 18 June 2010 (UTC)

Yes, I think we need to add a general-purpose, user-nameable field to the Name object. Maybe more than one. Database changes (using the current BSDDB) are very destabilizing to Gramps. But I think we should do this for Gramps 3.3. --Dsblank 12:16, 18 June 2010 (UTC)

data entry theme

Greetings Doug,

I've been following the discussion regarding data entry on the mailing lists. As interesting as it may be, I think there's some naivety to it. Archives avoid giving full access for a reason, and this is competition. The really relevant data transfer will always depend on human effort, and that is where Gramps should be independent -- that's why facilitating data entry with default values is so important. You don't need to bother answering this, just a thought for your consideration. --Lcc 12:38, 31 July 2010 (UTC)

It is quite handy, though, to turn data on the screen into data in gramps. The part that I would be worried about is the constantly changing webpages that will require the screenscrappers to adapt. And the webpages will change, because, as you say, they don't want to make it easy---they are the competition. But having a well-defined API for such moving back and forth seems like a good thing, no? --Dsblank 12:58, 31 July 2010 (UTC)

Yes, these are two different approaches to the same problem, perhaps both valid. On the one hand, the approach being discussed currently makes users depend on developers constantly updating the scrappers---quite constantly, and gives great results. The default values approach on the other hand gives not so great results, but is much much more stable. Users depend on no one but themselves. Regards. --Lcc 13:04, 31 July 2010 (UTC)

I see your point: you would like good defaults for as many fields as makes sense, yes? Would that default always be the same thing? Or based on some context? Last used? Which fields? Have you described a proposal for such ideas? Sounds interesting. --Dsblank 15:34, 31 July 2010 (UTC)

Yes, we have discussed it quite some in Gramps-dev, I was going to implement it, but then I tried waiting for hooks with which this could be a plugin rather than a patch. Anyway it'd be nice if someone else would become interested in doing this (I don't mean just you, anyone). My current understanding is that setable defaults are the best option. Quoting myself: ``It could go under Preferences. A Preferences tab: "Default values". Then a checkbox: "Use default values". If it is checked, the Add/Share buttons below become available, with a default place, a default source, etc.'' [2] --Lcc 17:48, 31 July 2010 (UTC)

Your welcome

Re:PS - Thanks Gioto and lcc... the GEPS overview page [2 looks great!], Your welcome.

Would be possible for the developers to look over the summary and update it as much as possible to reflect the current state? Thank you
Gioto 17:04, 13 October 2011 (MST)