Hi AR, here's a late reply...

To refresh my bad memory, I just reread the whole thread here:

        http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=401110

...and need to retract something:

        Summing up:  Marriage selection is broken or hasn't been coded yet.

In hindsight that's too broad -- marriage was coded and worked as
designed.  Sorry about that unfair summation.

On Fri, 01 Dec 2006 12:03:08 -0800
Alex Roitman <[EMAIL PROTECTED]> wrote:

> ...You have an active person:
> the person whose name is on top of the Relationship view. Then you
> e.g. add a relationship. This invokes the Family Editor dialog.

I started this bug with 'gramps' v2.2.2-1, but since then have upgraded
to v2.2.3-1; it's been improved, so I'm a little wobbly on which
features have been changed from last month.  

For instance, I don't recall the context sensitive "Add Spouse" button
in the main toolbar before, or that wording.  I'd hate to think I
missed that before.

Anyway, with the new v2.2.3 my earlier steps from 11/30/06 don't work:

        Start 'gramps', select person, then 'Relationships' in Sidebar, then
        the '+' icon next to Family.  "Family Editor" pops up, set 'Type:' to
        Married, and then...

How I now get a similar result:  select person, then
'Relationships' in Sidebar, then the 'Add Spouse' in main toolbar.  I'm
assuming those new steps bring us to (or very near) the same place.

> Assuming the active person was male, the dialog will look like this:
> http://www.gramps-project.org/gramps-manual/2.2/en/resources/edit-family.png

The v2.2.3 version looks mostly like that, but with 'Add Spouse' its
heading has changed from "Family Editor" to "New Family".

"New Family" seems questionable, unless a family is arbitrarily defined as
two persons married to each other.  The customary usage of "family"
usually connotes more than one generation, as well as close proximity,
either of which are sometimes not the case.  "New Spouse" would be better.

> (if active person was female then in the dialog Father will
> be empty with + and select buttons, and Mother will have
> a - button, accordingly).
> 
> Do you find the screenshot confusing? It clearly has Father
> with data and Mother with +/select buttons and no data.

It's still confusing:  not all marriages result in the persons being
Father and Mother, some unions are childless.   "Husband" and "Wife"
would be better.

> ...I also don't see how Children
> enter into this: their set of buttons are clearly separate,
> under the Chidren tab...

That set of tabs looks powerful, but is visually very busy.  I don't
follow why an 'add spouse' box even needs add children functions.  A
separate function for adding kids seems more practical.  It could
also allow for unmarried parents.

I'm not sure what to name such a function.  'Add Child'?  How to,
then... conceive, or adopt, I guess.


PS:  A ramble around a related puzzle.

I live in Massachusetts, where our government has lately experimented
with innovative "civil unions".  In such cases "Husband and Wife" could
be inaccurate.  I'd be willing to to let that one slide, but worry that
some people may need the accuracy.

Then there are marriage forms and quasi-forms like Polygamy and
Polyandry, and concubinage, and various foreign categories about which
I've a vague inkling of certain languages having rich vocabularies for;
I'd expect all such forms to share the common property of having
different topologies than what we'd call marriages.

Millions of people out there might need those categories, if they live
in or descend from them.   OTOH, I'm fearful of bias -- in this case
it'd be an anthropological "Anything Goes" bias, versus the traditional
family of genealogy.  Really how to draw a family tree and what to call
people has often been a violently political issue, or so taboo that customs
become unspeakable and are taken for granted.

Imaginary solution that may be impractical to implement, what with the
new file formats or metadata involved:  have definable unions and
families with variant topologies, as well as definable vocabularies of
labels for the variant topologies, define a bunch of them accurately,
and then variously group those into 'skins' or 'themes', so that that
the 'Catholic' theme would include only topologies and terms that were
recognized by the Catholic Church, and 'anthropological' would be a
larger and very tolerant set, while a 'King Tut' theme would allow for
consanguineous royal marriages in ancient times, etc.

Fringe benefit of that solution, also tricky to implement:  there could
be one-way transformation/translation algorithms that input data
based on one theme and output another theme.  So if there was data set
created under the 'anthropological' theme, and that was translated to a
'Christian Fundamentalist' theme, the latter theme would assign its own
vocabulary like 'bastards', 'heathens', etc.  At first glance it may
seem meretricious to pander to bigots.  Yet historically there
are so many variations of what's good and bad, that it would be
enlightening and educational.  To take a Massachusetts example, if we
translated a 2006 'civil union' family to a 1690 'Puritan' family, the
2006 family would acquire many terrible names, but vice-versa, the 1690
family in 2006 would be doubtless then be laden with terms condemning
what would be viewed as child-marriage, or worse.

Topologies could also include sordid "who's had who" or "kiss and tell"
themes, invaluable to fans of celebrity gossip.  A vile and potential
source of revenue; imagine the milestones -- the first free software
project to be sponsored by the National Enquirer, later the first to
be sued into oblivion...



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to