Hello again people,

Well, the major points which should be tackled in my opinion as a genealogist in
contact with other genealogists: (many genealogists use PAF)

. There must be an option in the DDR for Register-Style numbering

. There must be options in both DDR and in DAR for "Level of Verbosity"


James Francis ROOSEVELT. James Francis was born on 16 Nov 1825 in New York, NY. He died on
1 Apr 1906 in Boston, MA. James Francis was the son of John Richard ROOSEVELT and Anna Maria
RUSSEL. He married Susanna Michelle WHEATFIELD in 1855.


James Francis ROOSEVELT. Born 16 Nov 1825 in New York, NY. Died 1 Apr 1906 in Boston, MA.
Son of John Richard ROOSEVELT and Anna Maria RUSSEL. Married Susanna Michelle WHEATFIELD

Minor fixes:

. The "Name Style" option should be available as a report option and not be a global
GRAMPS-display/report option as is the situation now.

What I can do:

. I can probably edit the DDR and DAR scripts so that they would be NOT-VERBOSE. What
I couldn't do is add options in the GRAMPS code and interface to add that as runtime possibilities.
If that is of your interest, I could send you the modified scripts so that a more engaged developer
could see what is changed and code the options.

Please let me know if you are interested.

Best Regards,
James Friedmann

On Nov 30, 2007 5:59 AM, Benny Malengier < benny.malengier@gmail.com> wrote:

2007/11/30, James Friedmann <jfriedmannj@gmail.com>:
Dear Mr. Benny Malengier,

I'm very grateful for your considerate answer.

Unfortunatelly, I'm not as of today an active member of the open-source community. I restrain myself
to using Debian Stable to get the work I need done. In that sense, I know I'm not a model of participation,
but you can think of me as a highly savy Unix user.

Ever since I started this user phase, I try to stick to Debian Stable. I expect a lot of GRAMPS, it is a
very important program.

The points you make sadden me indeed. It almost seems like every new developer feels he/she can rewrite
the whole thing under the same name as long as nobody complains. That's bad news for common people
who just use it and are not engaged in development, but do expect things to keep a level of coherence.

this is not really the case. As I said, the reports where mostly contributed code. The developers did not want to keep supporting 3 different detailed individual reports, 2 website reports, .... . Our development team is too small for that. It are hard choices, but necessary in order to move forward.

The vanilla Etch Stable version brought me the GEDCOM export bug. Fortunatelly pinning was easy this
time (rare luck), so I could upgrade to the testing version which fixed it. Then I was sad to learn there was a
major bug with reports - the [1], [2], etc. source references simply did not show up in DetAncestralReport.
Fortunately I was able to grab the fix manually from the latest SVN code, but it stunned me how long this
bug persisted, since DDR is now the _single most important descendants report_.

Most developer are actually no genealogists or have no time to use the program themself, nor the reports. Bugs can hence only be solved if reported. The situation is better now, we have some new active members that use GRAMPS a lot. It is OSS though, most people helping out only help with the parts they use themselves.

The old report code was far from perfect, but I had already fixed the old python scripts myself to suit my
taste a little better with hours of work. Thing is, I can't keep using version 1.X.X. forever.. (FTM report is
also gone...)

You should try to stay current with Gramps, and any fixes you do, you should send in as patches.  

It seems to me that the effort to savory the old code is being overlooked, maybe because of so many new
programmers. I feel that is too bad..

(This has nothing to do with you, I know you're just stating the _way things are_. I'm just disappointed).

Indeed. There is not much I can do. Even FTM report is from before my time :-D

The plugin system is really simple. Instead of putting all reports in official GRAMPS, with the problem of then having nobody to maintain the code later, we have moved to third party plugins. Like this the core developers only support some core reports, and users understand better what is out of our responsibility. We can also better evaluate over time how loved a report is, and how dedicated it's author.
You find them here: http://www.gramps-project.org/wiki/index.php?title=Unsupported_Plugins