2010/2/26 John <jhy001@...>:
> 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:
> 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
> 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 for the info already, I updated the wiki page with it.
>>> Thanks for consideration,
>>> 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.
>>> Gramps-devel mailing list
> 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.
> Gramps-devel mailing list