From: John <jh...@ea...> - 2010-02-26 03:22:39
|
On 2/25/2010 7:40 AM, Benny Malengier wrote: > As an amateur genealist, for my own use, this seems very advanced. > That does not mean it is bad however. > As a programmer on Gramps, I'd like to know how you see this can be > integrated in Gramps. Remember, most developers don't use other genea > software, so it would not be obvious something important is missing. > So John, would you have the time to flesh out and make clear what in > _Gramps_ has to change? I created an enhancement proposal: > > http://gramps-project.org/wiki/index.php?title=GEPS_018:_Evidence_style_sources I logged in and can see this and see edit links. I'm afraid my proposal text would be rather general. I've only casually looked at gramps in my quest for a native Mac genealogy program that handles Evidence Style. > So, all you need to do, would be to login, and to edit this page with > what is specifically missing, how this can be improved, and what > technical changes it requires. The technical low level stuff somebody > else can do, but the first hurdles are obvious to everybody: eg, how > do you define a source is an Artefact, how do you store some of the > fields you suggest, ... When the end user cites a source for information, they would be prompted with a window where they would select a main type and drill down through subtypes, as in the first few columns of the table presentation I've given. Once it is selected, the user will be prompted for the required (and perhaps optional) fields specific for that type of source reference. Then, when generating a report that contains citations, the mark up needs to be done on the fields according to the specifications in the table method or template method I've provided. (e.g. substitute the variables, italicize, embed with the proper punctuation, etc. Remove optional variables (and their punctuation) if the variable was not input. Remove privacy fields unless a privacy flag is turned on so that things like home addresses and phone numbers of people aren't put in reports unless you "force" it. And the first time a citation is encountered in a report, use the Full version (F). The second and suceeding times use the Short (S) version. And when a bibliography is called for, use the L (List) template for that. The user would select the type of the source, and fill in the fields, for L,F, and S at citation time. The templates I've provided would be in pop up menus for the user to select. The templates would be stored in an internal database, as would the completed citations for storage and retrieval. I assume you already have an internal database that gramps uses. But, these would only be a (good) starting set. Part of the beauty of this parametrization is that the end user can use the language of the mark up in this table or template to define his own source style, punctuation, field quoted or italicized, etc. So in essence, any source output style can be accommodated, and is under full control of the end user. Evidence Style templates can be supplied as a starting set, not the only set. New Evidence Styles can be added, old ones deleted or modified, as the user wishes. So if you generalize source handling like this, I don't see you needing to worry about such a thing ever again. (at least a generation? ;-) ) I urge an export/import feature for at least gramps users to be able to export their defined types and share them with other gramps users. Singly, or in bulk. It would be nice if that could be done under GEDCOM for sharing with other programs, but I doubt that can actually be done robustly. As a first step, letting just gramps users share their work on templates would be enough. And if they are in plain text, as in my template examples, users of other programs could easily read them and put them in any program capable of handling them. I'm afraid this is all just general stuff. I'm not an expert in your code. Is this enough? I'm happy to answer any questions that I can, but perhaps someone who understands what I'm asking for and knows the code can do the GEPS? This parametrization is a gift to anyone who can program it. (thus open on my website). I farmed it along over two years. It did take a lot of time to get to this point. > The development process in Gramps is that once a GEPS is fleshed out, > it should be clear what _technically_ is needed, so programmers can > focus on just coding it to make it happen. Again, help!? > I hope you have time for this. I'm willing to help, but I'm not a Python programmer. (I used Algol, Fortran, Assembler (Univac, IBM, DEC, VAX), C, Unix Shell (Bourne). The newer things I've had some exposure to but can't claim fluency. That's what happens when you move into management. Let me know what more is needed that I can do. Thanks, John > Greetings, > Benny > >> Thanks for consideration, >> John >> >> ------------------------------------------------------------------------------ >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> proactively, and fine-tune applications for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev >> _______________________________________________ >> Gramps-devel mailing list >> Gra...@li... >> https://lists.sourceforge.net/lists/listinfo/gramps-devel >> > |