Graphic views Charts and Family Lines: how to show dead people as dead?

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Graphic views Charts and Family Lines: how to show dead people as dead?

Chris Wood
The "estimated before xxxx" format still has the drawback of displaying the death date as "d. xxxx" - not obvious that this is just an estimated upper limit and not an actual date.

Personally, I see the border colours as an extra cue, and not particularly obvious visually. And the Family Lines Graph, which I love, and is what I'm using at the moment to produce a printed book, doesn't use different coloured borders.

I think what I want (and I guess suggesting) is just a display option for - in this case - Family Lines Graph, to display the death date as "unknown" (or perhaps user-specified text) under the circumstances I originally mentioned. It wouldn't be changing the database in any way. Is this possible? 


--
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
https://gramps-project.org
Reply | Threaded
Open this post in threaded view
|

Re: Graphic views Charts and Family Lines: how to

GRAMPS - User mailing list


Chris,

You might be able to leverage Gramps' flexibility to do this. It's not something where I can spend the time to experiment... but some questions occur to me.

A lot of programs won't let you move past the data-entry unless data can be validated. Gramps allows invalid dates to be stored. (Probably to allow data in not-yet-supported calendar systems. I've used it for a secondary Role Birth/Death event to store the unsupported "Quaker Date" format data in the past. This added visibility to where recursive Julian/Gregorian date conversions have contaminated the imported GEDcom or Biography sources data.)

What happens to the print out if you manually enter 'unknown' (or '?' for brevity) as the date? Sure, the Gramps interface will highlight it as an invalid date. But that is is irrelevant if your interest is print/reports.

(The error handler might also cause the people with invalid dates to be effectively choked out of the statistics calculations. That might mask Peter's "oldest living person" bugbear.)

If it prints ok, a tweak to that add-on to mass insert the '?' (or any other user-specified but invalid placeholder) should be fairly simple.

-Brian

On Wed, Oct 23, 2019 at 2:04, Chris Wood
The "estimated before xxxx" format still has the drawback of displaying the death date as "d. xxxx" - not obvious that this is just an estimated upper limit and not an actual date.

Personally, I see the border colours as an extra cue, and not particularly obvious visually. And the Family Lines Graph, which I love, and is what I'm using at the moment to produce a printed book, doesn't use different coloured borders.

I think what I want (and I guess suggesting) is just a display option for - in this case - Family Lines Graph, to display the death date as "unknown" (or perhaps user-specified text) under the circumstances I originally mentioned. It wouldn't be changing the database in any way. Is this possible? 
--
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
https://gramps-project.org


--
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
https://gramps-project.org

Untitled Download Attachment
Untitled (206 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Graphic views Charts and Family Lines: how to

StoltHD
I still think there should have been a multi choice Living - Dead - Unknown...

Legacy Familytree uses 3 radiobuttons, and even though many software use a custom TAG, there is a "1 DEAT Y" -tag in gedcom, isn't it?

For me, i dont care about gedcom, its a really bad and limited format made for the purpose of the LDS research... but for others its important that there is a TAG that is implemented in the gedcom standard...

Jaran

ons. 23. okt. 2019 kl. 12:36 skrev Emyoulation--- via Gramps-users <[hidden email]>:


Chris,

You might be able to leverage Gramps' flexibility to do this. It's not something where I can spend the time to experiment... but some questions occur to me.

A lot of programs won't let you move past the data-entry unless data can be validated. Gramps allows invalid dates to be stored. (Probably to allow data in not-yet-supported calendar systems. I've used it for a secondary Role Birth/Death event to store the unsupported "Quaker Date" format data in the past. This added visibility to where recursive Julian/Gregorian date conversions have contaminated the imported GEDcom or Biography sources data.)

What happens to the print out if you manually enter 'unknown' (or '?' for brevity) as the date? Sure, the Gramps interface will highlight it as an invalid date. But that is is irrelevant if your interest is print/reports.

(The error handler might also cause the people with invalid dates to be effectively choked out of the statistics calculations. That might mask Peter's "oldest living person" bugbear.)

If it prints ok, a tweak to that add-on to mass insert the '?' (or any other user-specified but invalid placeholder) should be fairly simple.

-Brian

On Wed, Oct 23, 2019 at 2:04, Chris Wood
The "estimated before xxxx" format still has the drawback of displaying the death date as "d. xxxx" - not obvious that this is just an estimated upper limit and not an actual date.

Personally, I see the border colours as an extra cue, and not particularly obvious visually. And the Family Lines Graph, which I love, and is what I'm using at the moment to produce a printed book, doesn't use different coloured borders.

I think what I want (and I guess suggesting) is just a display option for - in this case - Family Lines Graph, to display the death date as "unknown" (or perhaps user-specified text) under the circumstances I originally mentioned. It wouldn't be changing the database in any way. Is this possible? 
--
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
https://gramps-project.org
--
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
https://gramps-project.org


--
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
https://gramps-project.org
Reply | Threaded
Open this post in threaded view
|

Re: Graphic views Charts and Family Lines: how to

Peter Merchant

As per Brian's suggestion, I have replaced the death date with a '?'.  I'm happy with this. Over the years I have worked on any invalid dates as they are always in Bold print, but I can live with this.  It satisfies the Record gramplet function. As to other things such as reports/exports etc, I'll wait and see. 

Peter


(The error handler might also cause the people with invalid dates to be effectively choked out of the statistics calculations. That might mask Peter's "oldest living person" bugbear.)



--
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
https://gramps-project.org
Reply | Threaded
Open this post in threaded view
|

Re: Graphic views Charts and Family Lines: how to

GRAMPS - User mailing list
In reply to this post by StoltHD

Hi All

Suspect that the first thing any developer would do when you pushed the
radio button is create a Death Event for consistency through the rest of
the program therefore why have the radio button.
Interesting thoughts but seems like most people work around this anyway

Regards
Phil
MLFHS 12583
Dumfries
On 23/10/2019 16:27, StoltHD wrote:

> I still think there should have been a multi choice Living - Dead -
> Unknown...
>
> Legacy Familytree uses 3 radiobuttons, and even though many software use a
> custom TAG, there is a "1 DEAT Y" -tag in gedcom, isn't it?
>
> For me, i dont care about gedcom, its a really bad and limited format made
> for the purpose of the LDS research... but for others its important that
> there is a TAG that is implemented in the gedcom standard...
>
> Jaran
>
> ons. 23. okt. 2019 kl. 12:36 skrev Emyoulation--- via Gramps-users <
> [hidden email]>:
>
>>
>>
>> Chris,
>>
>> You might be able to leverage Gramps' flexibility to do this. It's not
>> something where I can spend the time to experiment... but some questions
>> occur to me.
>>
>> A lot of programs won't let you move past the data-entry unless data can
>> be validated. Gramps allows invalid dates to be stored. (Probably to allow data
>> in not-yet-supported calendar systems. I've used it for a secondary Role
>> Birth/Death event to store the unsupported "Quaker Date" format data in the
>> past. This added visibility to where recursive Julian/Gregorian date
>> conversions have contaminated the imported GEDcom or Biography sources
>> data.)
>>
>> What happens to the print out if you manually enter 'unknown' (or '?' for
>> brevity) as the date? Sure, the Gramps interface will highlight it as an
>> invalid date. But that is is irrelevant if your interest is print/reports.
>>
>> (The error handler might also cause the people with invalid dates to be
>> effectively choked out of the statistics calculations. That might mask
>> Peter's "oldest living person" bugbear.)
>>
>> If it prints ok, a tweak to that add-on to mass insert the '?' (or any
>> other user-specified but invalid placeholder) should be fairly simple.
>>
>> -Brian
>>
>> On Wed, Oct 23, 2019 at 2:04, Chris Wood
>> <[hidden email]> wrote:
>> The "estimated before xxxx" format still has the drawback of displaying
>> the death date as "d. xxxx" - not obvious that this is just an estimated
>> upper limit and not an actual date.
>>
>> Personally, I see the border colours as an extra cue, and not particularly
>> obvious visually. And the Family Lines Graph, which I love, and is what I'm
>> using at the moment to produce a printed book, doesn't use different
>> coloured borders.
>>
>> I think what I want (and I guess suggesting) is just a display option for
>> - in this case - Family Lines Graph, to display the death date as "unknown"
>> (or perhaps user-specified text) under the circumstances I originally
>> mentioned. It wouldn't be changing the database in any way. Is this
>> possible?
>> --
>> Gramps-users mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/gramps-users
>> https://gramps-project.org
>>
>> --
>> Gramps-users mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/gramps-users
>> https://gramps-project.org
>
>
>


--
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
https://gramps-project.org
Reply | Threaded
Open this post in threaded view
|

Re: Graphic views Charts and Family Lines: how to

StoltHD
Phil, why so negative to others suggestions?


This is a FLAG on the DEAT tag, and a simplified metod to tell that a person is known to be death, but you have no other data. Gedcom tag with flag is "1 DEAT Y" and it do not need any trailing lines.

How the FLAG on the TAG actually get registered in the database is of no consern for the users, but it is an easy way to just register that the person IS dead, but that there are no known dates, places or other information about this. Yes it might be that it only creates a Death Event, but again, this is to make it easy for a user to register a person as dead without any data...
One click instead of 3 steps to create the empty event.

In Gramps code it will only be a call to a already excisting function...


AND it can be understud by Gramps that if the flag is not set or it is set to Living (This can be an LIVING attribute), and there are no death Event, the person is living, even if that person is over the sat max age for living

REF Page 34-35 , THE GEDCOM STANDARDDRAFT Release 5.5.1, http://phpgedview.sourceforge.net/ged551-5.pdf :
The occurrence of an event is asserted by the presence of either a DATE tag and value or a PLACe
tag and value in the event structure. When neither the date value nor the place value are known thena Y(es) value on the parent event tag line is required to assert that the event happened. For exampleeach of the following GEDCOM structures assert that a death happened:1 DEAT Y 1 DEAT2 DATE 2 OCT 19371 DEAT2 PLAC Cove, Cache, Utah



Jaran

ons. 23. okt. 2019 kl. 18:38 skrev phil wharram via Gramps-users <[hidden email]>:

Hi All

Suspect that the first thing any developer would do when you pushed the
radio button is create a Death Event for consistency through the rest of
the program therefore why have the radio button.
Interesting thoughts but seems like most people work around this anyway

Regards
Phil
MLFHS 12583
Dumfries
On 23/10/2019 16:27, StoltHD wrote:
> I still think there should have been a multi choice Living - Dead -
> Unknown...
>
> Legacy Familytree uses 3 radiobuttons, and even though many software use a
> custom TAG, there is a "1 DEAT Y" -tag in gedcom, isn't it?
>
> For me, i dont care about gedcom, its a really bad and limited format made
> for the purpose of the LDS research... but for others its important that
> there is a TAG that is implemented in the gedcom standard...
>
> Jaran
>
> ons. 23. okt. 2019 kl. 12:36 skrev Emyoulation--- via Gramps-users <
> [hidden email]>:
>
>>
>>
>> Chris,
>>
>> You might be able to leverage Gramps' flexibility to do this. It's not
>> something where I can spend the time to experiment... but some questions
>> occur to me.
>>
>> A lot of programs won't let you move past the data-entry unless data can
>> be validated. Gramps allows invalid dates to be stored. (Probably to allow data
>> in not-yet-supported calendar systems. I've used it for a secondary Role
>> Birth/Death event to store the unsupported "Quaker Date" format data in the
>> past. This added visibility to where recursive Julian/Gregorian date
>> conversions have contaminated the imported GEDcom or Biography sources
>> data.)
>>
>> What happens to the print out if you manually enter 'unknown' (or '?' for
>> brevity) as the date? Sure, the Gramps interface will highlight it as an
>> invalid date. But that is is irrelevant if your interest is print/reports.
>>
>> (The error handler might also cause the people with invalid dates to be
>> effectively choked out of the statistics calculations. That might mask
>> Peter's "oldest living person" bugbear.)
>>
>> If it prints ok, a tweak to that add-on to mass insert the '?' (or any
>> other user-specified but invalid placeholder) should be fairly simple.
>>
>> -Brian
>>
>> On Wed, Oct 23, 2019 at 2:04, Chris Wood
>> <[hidden email]> wrote:
>> The "estimated before xxxx" format still has the drawback of displaying
>> the death date as "d. xxxx" - not obvious that this is just an estimated
>> upper limit and not an actual date.
>>
>> Personally, I see the border colours as an extra cue, and not particularly
>> obvious visually. And the Family Lines Graph, which I love, and is what I'm
>> using at the moment to produce a printed book, doesn't use different
>> coloured borders.
>>
>> I think what I want (and I guess suggesting) is just a display option for
>> - in this case - Family Lines Graph, to display the death date as "unknown"
>> (or perhaps user-specified text) under the circumstances I originally
>> mentioned. It wouldn't be changing the database in any way. Is this
>> possible?
>> --
>> Gramps-users mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/gramps-users
>> https://gramps-project.org
>>
>> --
>> Gramps-users mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/gramps-users
>> https://gramps-project.org
>
>
>


--
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
https://gramps-project.org


--
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
https://gramps-project.org
Reply | Threaded
Open this post in threaded view
|

Re: Graphic views Charts and Family Lines: how to

ceperman
In reply to this post by GRAMPS - User mailing list
I’ve been away and unable to join back in until now…

I appreciate all the comments. As far as artificial deaths dates are
concerned, I don’t like doing something just because it works when it wasn’t
designed to do that. Back when I was a software developer it would have been
called using a “feechure”, and considered a bad thing to do. Putting
artificial values into the date field seems like I’d be polluting my
database, and my use of Gramps is too narrow for me to judge what wider
effect it may have.

From what folks have said, there already exists ways that allow reporting
software to determine that someone is probably dead (the max alive age) or
definitely dead (a death event exists), even if the date is unknown. Surely
then this is just a matter of the reporting software using these ways of
determining death without resorting to “tricks”, and hopefully, some user
option of how to report it.

If this means making a feature request, I’m happy to do that if someone
could tell me how, and there’s any chance of it being successful.

-Chris

PS sorry I seem to have created duplicate threads to discuss this


GRAMPS - User mailing list wrote

> Chris,
> You might be able to leverage Gramps' flexibility to do this. It's not
> something where I can spend the time to experiment... but some questions
> occur to me.
> A lot of programs won't let you move past the data-entry unless data can
> be validated. Gramps allows invalid dates to be stored. (Probably to
> allow data in not-yet-supported calendar systems. I've used it for a
> secondary Role Birth/Death event to store the unsupported "Quaker Date"
> format data in the past. This added visibility to where recursive
> Julian/Gregorian date conversions have contaminated the imported GEDcom or
> Biography sources data.)
> What happens to the print out if you manually enter 'unknown' (or '?' for
> brevity) as the date? Sure, the Gramps interface will highlight it as an
> invalid date. But that is is irrelevant if your interest is print/reports.
> (The error handler might also cause the people with invalid dates to be
> effectively choked out of the statistics calculations. That might mask
> Peter's "oldest living person" bugbear.)
> If it prints ok, a tweak to that add-on to mass insert the '?' (or any
> other user-specified but invalid placeholder) should be fairly simple.
> -Brian
>  
>   On Wed, Oct 23, 2019 at 2:04, Chris Wood&lt;

> chriswoodgb@

> &gt; wrote:   The "estimated before xxxx" format still has the drawback of
> displaying the death date as "d. xxxx" - not obvious that this is just an
> estimated upper limit and not an actual date.
>
> Personally, I see the border colours as an extra cue, and not particularly
> obvious visually. And the Family Lines Graph, which I love, and is what
> I'm using at the moment to produce a printed book, doesn't use different
> coloured borders.
>
> I think what I want (and I guess suggesting) is just a display option for
> - in this case - Family Lines Graph, to display the death date as
> "unknown" (or perhaps user-specified text) under the circumstances I
> originally mentioned. It wouldn't be changing the database in any way. Is
> this possible? 
> --
> Gramps-users mailing list

> Gramps-users@.sourceforge

> https://lists.sourceforge.net/lists/listinfo/gramps-users
> https://gramps-project.org 
>
>
> --
> Gramps-users mailing list

> Gramps-users@.sourceforge

> https://lists.sourceforge.net/lists/listinfo/gramps-users
> https://gramps-project.org
>
> Untitled
> &lt;http://gramps.1791082.n4.nabble.com/attachment/4686349/0/Untitled&gt;
> Untitled (206 bytes)
> &lt;http://gramps.1791082.n4.nabble.com/attachment/4686349/1/Untitled&gt;





--
Sent from: http://gramps.1791082.n4.nabble.com/GRAMPS-User-f1807095.html


--
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
https://gramps-project.org
Reply | Threaded
Open this post in threaded view
|

Re: Graphic views Charts and Family Lines: ho

GRAMPS - User mailing list
Chris,

You need to understand that open source isn't like commercial or Enterprise software engineering. There isn't a marketing or executive staff steering this with a roadmap & a budget.

There's more opportunistic evolution than structured design in this style of development. Since no one gets paid for development, a feature request only get traction if the idea piques the interest of a volunteer coder.  They might do a proof-of-concept as an experimental Gramplet or flesh-out a coherent design through discussion first. Their time, their choice.

The Gramps open source community has opted to follow the Benevolent Dictator architecture model but is wide open to volunteers. So, as ours beloved benevolent dictator, Nick gets veto power but design control with a volunteer team is like herding cats.  (You might have noticed that he posted a 'seems reasonable' endorsement to the idea of tweaking for adding an 'unknown' to the date handler.)  To abuse the T.S.Elliott for an analogy of volunteers being like cats: "For he will do, As he do do, And there's no doing anything about it!"

And we embrace that there are many approaches to most objectives.  So when we discover a new funtionality as a side-effect, the first thought is to explore how to exploit it fully while checking that it won't cause conflicts. 

Sometimes the opportunistic features even turn out to be more usable than the designed ones. 

This might be a bit frustrating for OCD types who believe in rules about the RIGHT way. But it has been working for us.

-Brian

On Sat, Oct 26, 2019 at 12:50, ceperman
I’ve been away and unable to join back in until now…

I appreciate all the comments. As far as artificial deaths dates are
concerned, I don’t like doing something just because it works when it wasn’t
designed to do that. Back when I was a software developer it would have been
called using a “feechure”, and considered a bad thing to do. Putting
artificial values into the date field seems like I’d be polluting my
database, and my use of Gramps is too narrow for me to judge what wider
effect it may have.

From what folks have said, there already exists ways that allow reporting
software to determine that someone is probably dead (the max alive age) or
definitely dead (a death event exists), even if the date is unknown. Surely
then this is just a matter of the reporting software using these ways of
determining death without resorting to “tricks”, and hopefully, some user
option of how to report it.

If this means making a feature request, I’m happy to do that if someone
could tell me how, and there’s any chance of it being successful.

-Chris

PS sorry I seem to have created duplicate threads to discuss this


GRAMPS - User mailing list wrote

> Chris,
> You might be able to leverage Gramps' flexibility to do this. It's not
> something where I can spend the time to experiment... but some questions
> occur to me.
> A lot of programs won't let you move past the data-entry unless data can
> be validated. Gramps allows invalid dates to be stored. (Probably to
> allow data in not-yet-supported calendar systems. I've used it for a
> secondary Role Birth/Death event to store the unsupported "Quaker Date"
> format data in the past. This added visibility to where recursive
> Julian/Gregorian date conversions have contaminated the imported GEDcom or
> Biography sources data.)
> What happens to the print out if you manually enter 'unknown' (or '?' for
> brevity) as the date? Sure, the Gramps interface will highlight it as an
> invalid date. But that is is irrelevant if your interest is print/reports.
> (The error handler might also cause the people with invalid dates to be
> effectively choked out of the statistics calculations. That might mask
> Peter's "oldest living person" bugbear.)
> If it prints ok, a tweak to that add-on to mass insert the '?' (or any
> other user-specified but invalid placeholder) should be fairly simple.
> -Brian

>  On Wed, Oct 23, 2019 at 2:04, Chris Wood&lt;

> chriswoodgb@

> &gt; wrote:  The "estimated before xxxx" format still has the drawback of
> displaying the death date as "d. xxxx" - not obvious that this is just an
> estimated upper limit and not an actual date.
>
> Personally, I see the border colours as an extra cue, and not particularly
> obvious visually. And the Family Lines Graph, which I love, and is what
> I'm using at the moment to produce a printed book, doesn't use different
> coloured borders.
>
> I think what I want (and I guess suggesting) is just a display option for
> - in this case - Family Lines Graph, to display the death date as
> "unknown" (or perhaps user-specified text) under the circumstances I
> originally mentioned. It wouldn't be changing the database in any way. Is
> this possible? 
> --
> Gramps-users mailing list

> [hidden email]

> https://lists.sourceforge.net/lists/listinfo/gramps-users
> https://gramps-project.org
>
>
> --
> Gramps-users mailing list

> [hidden email]

> https://lists.sourceforge.net/lists/listinfo/gramps-users
> https://gramps-project.org
>
> Untitled
> &lt;<a shape="rect" href="http://gramps.1791082.n4.nabble.com/attachment/4686349/0/Untitled>" target="_blank">http://gramps.1791082.n4.nabble.com/attachment/4686349/0/Untitled>
> Untitled (206 bytes)
> &lt;<a shape="rect" href="http://gramps.1791082.n4.nabble.com/attachment/4686349/1/Untitled>" target="_blank">http://gramps.1791082.n4.nabble.com/attachment/4686349/1/Untitled>





--
Sent from: http://gramps.1791082.n4.nabble.com/GRAMPS-User-f1807095.html


--
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
https://gramps-project.org
Reply | Threaded
Open this post in threaded view
|

Re: Graphic views Charts and Family Lines: ho

ceperman
GRAMPS - User mailing list wrote

> Chris,
> You need to understand that open source isn't like commercial or
> Enterprise software engineering. There isn't a marketing or executive
> staff steering this with a roadmap & a budget.
> There's more opportunistic evolution than structured design in this style
> of development. Since no one gets paid for development, a feature request
> only get traction if the idea piques the interest of a volunteer coder. 
> They might do a proof-of-concept as an experimental Gramplet or flesh-out
> a coherent design through discussion first. Their time, their choice.
> The Gramps open source community has opted to follow the Benevolent
> Dictator architecture model but is wide open to volunteers. So, as ours
> beloved benevolent dictator, Nick gets veto power but design control with
> a volunteer team is like herding cats.  (You might have noticed that he
> posted a 'seems reasonable' endorsement to the idea of tweaking for adding
> an 'unknown' to the date handler.)  To abuse the T.S.Elliott for an
> analogy of volunteers being like cats: "For he will do, As he do do, And
> there's no doing anything about it!"
> And we embrace that there are many approaches to most objectives.  So when
> we discover a new funtionality as a side-effect, the first thought is to
> explore how to exploit it fully while checking that it won't cause
> conflicts. 
> Sometimes the opportunistic features even turn out to be more usable than
> the designed ones. 
> This might be a bit frustrating for OCD types who believe in rules about
> the RIGHT way. But it has been working for us.
> -Brian
>
> --
> Gramps-users mailing list

> Gramps-users@.sourceforge

> https://lists.sourceforge.net/lists/listinfo/gramps-users
> https://gramps-project.org

I can't disagree with any of that (and BTW I have no experience of
Enterprise software engineering). I'm merely saying that using a function
for something it wasn't really designed for but happens to work may well
come back to bite you in future. But if it's the only way to get something
working today then perhaps there's no choice.
Thanks for educating me on who Nick is. His endorsement is clearly valuable!

Chris



--
Sent from: http://gramps.1791082.n4.nabble.com/GRAMPS-User-f1807095.html


--
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
https://gramps-project.org