* Drag and Drop between projects

For existing requests please see The Wish List
Post Reply
avatar
mezentia
Famous
Posts: 141
Joined: 12 Jan 2007 21:14
Family Historian: V6.2
Location: Stourbridge

Drag and Drop between projects

Post by mezentia » 08 Jan 2019 15:27

I have projects that work in pairs, one is for the principal family research, and a second where I keep information about people with the same surnames that I'm researching but with whom there is as yet no family connection that I have discovered to the people in the principal tree. I also have some instances where I have had to make part of my main research into an orphan tree within the project, and it would be useful to be able to move these to the second project so that the principal project contains only details of people whose connections are considered to be reliable.

I have used the tree splitter before now, but it's one of those things that gets used rarely, and therefore is a bit of a pain to get right each time it's needed.

What would be of enormous use would be the ability to select one or more related individuals and then use conventional cut/copy and paste to copy or move them to another, existing project, complete with all associated notes, sources, etc. Furthermore, the directory structure for any media so copied/moved should be retained in the project folder where the information is being copied to.

When moving an individual between trees in this manner, sources or media that are cited for people other than those being moved should be left intact.

User avatar
tatewise
Megastar
Posts: 16884
Joined: 25 May 2010 11:00
Family Historian: V6.2
Location: Torbay, Devon, UK
Contact:

Re: Drag and Drop between projects

Post by tatewise » 08 Jan 2019 19:48

The first question is why not keep all the unrelated 'orphan' trees in the one master Project?
They do little harm there, are readily differentiated by Pool number, and won't appear in main tree Diagrams and Ancestor/Descendant Reports.

The trickiest part of any cut/copy process is selecting the records to be included.
That starts with the Individual records, but must also involve choices about all associated records such as Family, Note, Source, Place & Media records and linked Media files.
You want to include all such associated records, but others may not, so it is unclear how that would be catered for with cut/copy.
Whereas, the existing File > Import/Export > Export > GEDCOM file offers many ways of selecting Individual records and choosing which associated records are required.

When it comes to pasting, in your scenario it seems that few if any Individual records would match up, but what about matching Note, Source, Repository, Place & Media records, as well as Media files?
That is where File > Merge/Compare Files comes into play.

Managing the Media file & folder structure has its own complexities, especially if the two Projects involved don't share the same folder structure.

My feeling is that in complex databases such as FH, a cut/copy & paste or drag & drop is much more complex and fraught with dangers that don't apply where single objects are involved.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry

avatar
mezentia
Famous
Posts: 141
Joined: 12 Jan 2007 21:14
Family Historian: V6.2
Location: Stourbridge

Re: Drag and Drop between projects

Post by mezentia » 12 Nov 2019 14:09

I had forgotten about this, so I apologise for the very late reply.

I don't like orphans in my main research trees, either individuals or sub-trees with no links to my main research - they clutters up me tree and they often get forgotten about, irrespective of whether or not they appear in trees, diagrams or whatever, or can be differentiated by pool number. For me it's really a question of being tidy: if people can't be linked directly to someone in my tree, what are they doing there in the first place? As a result, and particularly when researching pre-civil registration ancestors, I will create a separate project for either a one-name or one-place piece of research. This tends to be much smaller and allows placing all the people on a single diagram to try and piece together the various families and their potential relationships. Having found a person or people that I can then place into one of my main trees it would be nice to simply drag and drop, rather than manually copy every fact, source, etc., and avoids all the (relative) complexities of splitting and merging trees. I appreciate that media folder structures could cause a problem, but then I do tend to maintain a standard folder structure for each project. I'm sure that with a small amount of effort a folder to folder equivalence could be defined?

I suppose it all boils down to how one organises their research.

User avatar
tatewise
Megastar
Posts: 16884
Joined: 25 May 2010 11:00
Family Historian: V6.2
Location: Torbay, Devon, UK
Contact:

Re: Drag and Drop between projects

Post by tatewise » 12 Nov 2019 14:43

That still does not answer how you would expect such drag and drop to work in practice.

How would the data to be dragged be chosen from the source Project?
c.f. File > Import/Export > Export > GEDCOM file options for various records, etc.

How would the dropped data be synchronised with the target Project?
c.f. File > Merge/Compare Files options for matching records and fields.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry

User avatar
davidf
Famous
Posts: 235
Joined: 17 Jan 2009 19:14
Family Historian: V6.2

Re: Drag and Drop between projects

Post by davidf » 13 Nov 2019 00:50

Roots Magic can do drag and drop according to their website (https://www.rootsmagic.com/RootsMagic/Features.aspx). So there must be a way to do some of this functionality.

The conceptual design is probably relatively simple but the actual system design would be complex.

In most cases I would image that you would want to select a number of individuals either in a diagram or from the records window, and then drag them.

But what gets dragged with them? Parents, Spouses and Children (even if not selected)? But if you drag them as well what about the Parents of the Parents/Spouses and their other children etc. etc.! There has to be a limit. So if an individual is not included in the drag do their records not get included; in which case what happens in the destination project? Do you create "placeholder" individuals to indicate at least the first degree relatives exist - or do you create nothing?

Possibly this is user configurable in preferences "When dragging include all [x] degree relatives". Do you then allow [x] to be varied for each drop (a pop-up box that appears (once you have "dropped" - your mouse is a bit busy until then!)?

Once you know the individuals being dragged, presumably you also include in the drag all necessary citations/sources/repositories, and all media associated with those individuals. Presumably the destination project also has to recognise all custom facts from the source project and create any required.

I would presume that a drag and drop should actually be a copy rather than a move (you definitely don't want to move sources and media that may support other individuals). If you want a move you can do a delete from source afterwards - that is more secure in case you louse it up. Would you want an "undo" function?

Drag and drop of other records (e.g. sources - useful when creating a new project to try and create a set of sources (lumping!) with consistent names) would be easier - but you would have to include repositories etc. Definitely copy rather than move!

To implement this you probably want to use existing functionality. So your "drag" would select options to include in an export to an intermediate (system) file, and your "drop" would identify the destination project and merge the intermediate (system) file into the destination project (with or without the matching prompt and dialogue?).

[What about "drag and drop" within a project (effectively merge by drag)? How would this work with multiple people? (I don't like to think about that). But I would quite like to be able to stack people in a diagram and then select the stack (possibly by mouse selecting an area to define "the stack") and then "merge".]
David
Running FH 6.2.7. Under Wine on Linux (Lubuntu 18.04 LTS)

User avatar
tatewise
Megastar
Posts: 16884
Joined: 25 May 2010 11:00
Family Historian: V6.2
Location: Torbay, Devon, UK
Contact:

Re: Drag and Drop between projects

Post by tatewise » 13 Nov 2019 10:45

David, there are a lot of possibly, presumably & probably caveats in there!

The RootsMagic help page for Dragging and dropping people explains that the Drag and Drop dialogue asks you to choose from 8 options to select who to drag, which is similar to the FH Export > GEDCOM File dialogue Select option. RootsMagic offers fewer options, and only for people records. The FH options can usually be left at their defaults, so just as straight forward to use.

There is an option in RootsMagic to say the source drag person and target drop person are the same.

When you drop in RootsMagic it asks you to confirm the relationship between the drag and drop people.
It also has a great many Duplicate Merge features, that are similar to the FH Merge features.

So IMHO, drag and drop does not offer much advantage as there are still many options that need to be selected just like the FH export and merge, and I would rather that Calico Pie spent their time & effort on more useful features.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry

User avatar
davidf
Famous
Posts: 235
Joined: 17 Jan 2009 19:14
Family Historian: V6.2

Re: Drag and Drop between projects

Post by davidf » 13 Nov 2019 13:38

Mike
tatewise wrote:
13 Nov 2019 10:45
... I would rather that Calico Pie spent their time & effort on more useful features.
Thanks for the info about RM and how they handle drag and drop.
mezentia wrote:
12 Nov 2019 14:09
I suppose it all boils down to how one organises their research.
I work on a 15" lap-top (albeit with a relatively good resolution 1920x1080) which is fine if you are just chasing up and down a tree. But when I get to family reconstruction, it gets messy because you cannot see enough and I find it easier to keep separate projects reflecting different sub-projects so that I only see "relevant" individuals. I then tend to follow mezentia's approach.
mezentia wrote:
12 Nov 2019 14:09
... I will create a separate project for either a one-name or one-place piece of research. This tends to be much smaller and allows placing all the people on a single diagram to try and piece together the various families and their potential relationships. Having found a person or people that I can then place into one of my main trees it would be nice to simply drag and drop, rather than manually copy every fact, source, etc., and avoids all the (relative) complexities of splitting and merging trees.
So if I am doing a review of one surname in say Cumberland, I will have a "show all" diagram open showing about five disconnected but fairly small family trees. This is just about manageable; but if I find a family group does fit onto one of my main trees, I would like to be able move or copy the group to that tree.

This is I accept possible by exporting based on pool number and then merging (but without matching any individuals) into the main tree. You then open the main tree in a diagram and then add in the new family group and shuffle round to get the two families (spatially) close together, identify the overlapping individuals/families and then merging those individuals/families. I find identifying duplicates to merge far easier (and more reliable) on a diagram than on say a records list (which is why I tend to avoid merging individuals when merging files). This is partly because of the way my mind works, but also because if you are working in a list and opening up the detail to verify the identification of individuals/families I tend to run out of screen space!
David
Running FH 6.2.7. Under Wine on Linux (Lubuntu 18.04 LTS)

avatar
mezentia
Famous
Posts: 141
Joined: 12 Jan 2007 21:14
Family Historian: V6.2
Location: Stourbridge

Re: Drag and Drop between projects

Post by mezentia » 13 Nov 2019 22:55

I must admit that when working on my tree I have the luxury of two 27" monitors, one 1920x1200 and the other 2650x1440 so screen space is not an issue (that's not to say I wouldn't like to replace the lower resolution monitor with another at 2650x1440!).

My concept of drag and drop between projects is really quite simple. I select one or more people from, say, a tree diagram displaying people in one project and drag them over to another tree diagram in a different project. New individual records are created for those being copied, and all sources are copied to new source records and associated media and media records are copied using an identical file structure from the media folder one project to the media folder in the other. Any amendments to relationships can then be carried out as one would normally.

It occurs to me that this would also be a convenient way of splitting out a branch or subset of a family to a separate, new, project, and possibly less cumbersome than some existing methods.

I'm sure that not everyone will agree with me about the usefulness of this feature, just as I don't always see the benefits of some other items wished for here, and I'm sure we can debate the relative merits of every item on the wish list until the cows come home and never come to any agreement. This was just an idea of mine that I thought might make life simpler and easier for the average end user; I'm well aware that the perceived complextity of FH does deter some people from using it. It's something I would use should it ever get implemented.

User avatar
tatewise
Megastar
Posts: 16884
Joined: 25 May 2010 11:00
Family Historian: V6.2
Location: Torbay, Devon, UK
Contact:

Re: Drag and Drop between projects

Post by tatewise » 13 Nov 2019 23:42

Yes it sounds simple, but playing devil's advocate, depending on what type of tree diagram you select from, it poses questions about who you really want to copy.
For example, if using a Descendants Diagram and selecting a family group of parents & children some of whom are married, should the parents of the spouses be included or not?
Similarly if selecting from an Ancestors Diagram should siblings of the chosen people be included?
Even selecting everyone shown on an All Relatives Diagram does not necessarily include everybody in the same relationship pool, so some distant relatives may get unwittingly omitted.

That is why I would favour the RootsMagic approach of just selecting one person and then choosing which relatives to include. Although, RootsMagic does also offer the arbitrary list of people option similar to the FH Export GEDCOM.

When dropping onto the target Project what should happen to similar/identical Source, Repository, Note, and Place records? If there is not some form of auto-assisted merging there could be a great many tedious manual record merges to be done. Consider 'lumper' Source records that really should be merged.

The paradox is that a simple drag & drop might be fairly easy to implement but would only satisfy a few people in a limited number of scenarios. Whereas, a drag & drop that catered for many more scenarios would be much more difficult to implement. Anyway, such a feature only gets used infrequently, so does not significantly improve efficiency.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry

User avatar
davidf
Famous
Posts: 235
Joined: 17 Jan 2009 19:14
Family Historian: V6.2

Re: Drag and Drop between projects

Post by davidf » 14 Nov 2019 15:31

tatewise wrote:
13 Nov 2019 23:42
... Anyway, such a feature only gets used infrequently, so does not significantly improve efficiency.
Well such a feature does not get used at all, because it is not there!

It may only be infrequently used for you, but others with different workflows (particularly those that involve family reconstruction - a major part of many "One-name" studies) may find being able to rapidly move small trees from one project to another exceedingly useful.

In such a workflow (purely for example) a lot of your questions (that I tried earlier to dig around) get answered.

Consider a (UK) one-name study. You may have your own confirmed tree in a distinct project and other major (but unconnected) trees in their own distinct projects. One way forward is to try to reconstruct families sharing that surname over say the 1841-1911 Census for a county or a registration area. This keeps the numbers of individuals and families manageable and provided you are careful about strays out and strays in you can often build up a number of family trees each of a few generations at which point the light may dawn and you realise that a particular tree does attach either to your own tree or to another substantial tree.

If doing a one-name study for say East Canada you may build a number of small trees and then realise that the head of a family is actually one of your "missing" from a UK tree because he or she emigrated.

In these sort of circumstances drag and drop is considerably easier (you are dragging an entire pool, and you are dropping it unmatched into the target project and then manually merging the migrant's two records) and I suspect would be frequently used by people employing these sorts of workflows (me being one of them).

As a "lumper" merging of source records can be done easily because:
  • There are fewer of them (in the East Canada case above there is little of no overlap unless this is the second migrant family being dropped back into their "home" tree)
  • With lumped sources it is easy to recognise duplicates "1861 England Census" and "1861 England and Wales Census" are clearly similar and you only have to consider whether you wish to distinguish between Census records on Ancestry, or on FMP, or from FHS CDs etc..
If you are doing "classical" family tree work - working on one tree "from what you know" outwards to "what you don't know", clearly this feature is of little interest.
David
Running FH 6.2.7. Under Wine on Linux (Lubuntu 18.04 LTS)

User avatar
tatewise
Megastar
Posts: 16884
Joined: 25 May 2010 11:00
Family Historian: V6.2
Location: Torbay, Devon, UK
Contact:

Re: Drag and Drop between projects

Post by tatewise » 06 Dec 2019 12:10

I was contemplating how to word a Wish List entry for Drag and Drop between Projects, but am struggling with some of the technicalities. Can you help me?

I think the consensus of opinion is to allow any subset of Records in the source Project to be selected.
Then Drag & Drop would copy those Records and all linked Records & Media to the target Project, but without any synchronisation with target Records.

That raises significant questions, one of which I've asked before, but cannot recall a satisfactory answer.
  1. For Drag & Drop to work, both source and target Projects must be visible on screen together. Yes or No?
    If Yes, is that achieved by opening FH twice with a different Project open in each instance?
    Or is there some other method you had in mind?
  2. The Drag & Drop will copy the selected Records and all linked Records & Media. Yes or No?
    It has been agreed that all linked Source, Repository, Media, Note & Place records are included.
    But what about linked Family records and Individual records linked to them, that may not be selected?
    If the 'all linked Records & Media' condition was fulfilled completely then only entire Pools would get copied.
    So presumably only Family records linked to at least one selected Individual would be included, and all the other Individual links (HUSB, WIFE, CHIL) in the Family record would get excluded? Yes or No?
  3. Place records dropped into the target Project pose a problem if Place records with the same name already exist.
    The condition that Records are copied 'without any synchronisation with target Records' cannot be met.
    That is because Place records are linked by name and not by Record Id.
    So if two identically named Place records have conflicting Lat/Long, Substitute, Media, Note fields what happens?
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry

User avatar
davidf
Famous
Posts: 235
Joined: 17 Jan 2009 19:14
Family Historian: V6.2

Re: Drag and Drop between projects

Post by davidf » 06 Dec 2019 14:44

tatewise wrote:
06 Dec 2019 12:10
I was contemplating how to word a Wish List entry for Drag and Drop between Projects, but am struggling with some of the technicalities. Can you help me?

I think the consensus of opinion is to allow any subset of Records in the source Project to be selected.
Then Drag & Drop would copy those Records and all linked Records & Media to the target Project, but without any synchronisation with target Records.

That raises significant questions, one of which I've asked before, but cannot recall a satisfactory answer.
  • Any subset of records? - yes, including for instance dragging a selection of source records from an existing project into a new project (splitters probably won't see the need! - but for Lumpers being able to be consistent between say 1851 E&W Census or England and Wales 1851 Census is useful!)
  • Copy - yes
  • All linked Records and Media - yes (as in sources/repositories/media/shared notes) see later re other individuals
  • Without Synchronisation (i.e. matching and optionally merging duplicate sources etc.?) - for simplicity of programming we probably have to say "yes"; offering up merge dialogues after each drag and drop is probably too intrusive
tatewise wrote:
06 Dec 2019 12:10
1. For Drag & Drop to work, both source and target Projects must be visible on screen together. Yes or No?
  • I think so, how difficult would it be to drag onto a running program button in a task bar representing a minimised version of FH?
  • I think most would anticipate dragging from a diagram (but why not a record list or even a query list? - see comment about drag and drop of sources above!)
tatewise wrote:
06 Dec 2019 12:10
If Yes, is that achieved by opening FH twice with a different Project open in each instance?
  • Presumably, I don't think it is feasible (or needed?) to be able to drag onto a GEDCOM or project icon visible in say File manager.
tatewise wrote:
06 Dec 2019 12:10
Or is there some other method you had in mind?
  • Every time I click on the FH icon it opens to a Project Window - from which I then select the project to open. There is presumably a structural reason as to why the Project Window closes when a project is opened - because the Project Window is a dialogue of the running FH. If the Project Window was a separate launcher program, this would open alternative drag and drop options - including into projects that are not open. I think that is too big a leap!
tatewise wrote:
06 Dec 2019 12:10
2. The Drag & Drop will copy the selected Records and all linked Records & Media. Yes or No?
  • Yes for all associated source/repository/media/shared notes/places
  • Do addresses/occupations and other data which are workable through the Work with Data menu just sort themselves out through the dropping of an individuals facts?
  • For other linked records (parents, children, witnesses?, associated people) is where specification becomes tricky!
tatewise wrote:
06 Dec 2019 12:10
It has been agreed that all linked Source, Repository, Media, Note & Place records are included.
  • Yes
tatewise wrote:
06 Dec 2019 12:10
But what about linked Family records and Individual records linked to them, that may not be selected?
  • If you are selecting from a diagram by Ctrl-clicking, the implication is that you don't - the alternative is either "whole pool" (as below) or something that gets horrendously complex (we have previously pondered an option to select x degrees of relationship from those selected)
  • Question: What happens in the target project if you drag say an individual in, but not their parents? Should the target project create a "blank" pair of individuals with a note saying "this person exists in [Source Project]"
  • Witnesses and Associated People presumably "jump the pool"? Should they just convert into Name Only?
tatewise wrote:
06 Dec 2019 12:10
If the 'all linked Records & Media' condition was fulfilled completely then only entire Pools would get copied.
  • That would, if necessary, be a logical restriction which would still be of benefit
tatewise wrote:
06 Dec 2019 12:10
So presumably only Family records linked to at least one selected Individual would be included, and all the other Individual links (HUSB, WIFE, CHIL) in the Family record would get excluded? Yes or No?
  • We have to come down to one of
    • Drags the pool
    • Drags selected individuals/couples only
    • Drags selected individuals/couples and a "preference set(?)" [x] further degrees of relations (defaults to 0 which would be the same as the previous option)
  • Any of the above would be of use
tatewise wrote:
06 Dec 2019 12:10
3. Place records dropped into the target Project pose a problem if Place records with the same name already exist.
The condition that Records are copied 'without any synchronisation with target Records' cannot be met.
That is because Place records are linked by name and not by Record Id.
So if two identically named Place records have conflicting Lat/Long, Substitute, Media, Note fields what happens?
  • I think that has to be sorted as part of a separate housekeeping project (possibly query assisted)
Other
  • I think some may be anticipating ctrl-click selecting a group of individuals in a diagram (or record list) and then dragging them and dropping them onto an individual in the destination project, whereby the last ctrl-click selected individual is merged with the "dropped on" individual. I think that offers too much scope for "really screwing up" and should be resisted. You drag and drop close to the common individual and then merge as a separate exercise.
  • Do we want some form of "audit trail" such as a note attached to the dropped records saying that they have been "dragged from project [x]"?
  • We presumably need to maintain the selection of records in the source project to enable a possible delete after the drag and drop. If only directly selected records are dragged, this is easy; if other linked records get automatically selected, there is a possibility that the user does not realise what records are being offered up for deletion - which is dangerous!

    There are quite a few devils in these details! :twisted:
David
Running FH 6.2.7. Under Wine on Linux (Lubuntu 18.04 LTS)

User avatar
tatewise
Megastar
Posts: 16884
Joined: 25 May 2010 11:00
Family Historian: V6.2
Location: Torbay, Devon, UK
Contact:

Re: Drag and Drop between projects

Post by tatewise » 06 Dec 2019 16:22

Thanks for the prompt replies, most of which confirm my thinking, but also expose some new wrinkles.
I will deal with the simpler issues first and move on the more complex later.

The reason the Project Window opens when you open FH is that you have not defined a Default Project.
Most users only have one main Project and that is their default which opens automatically on opening FH.
Having a non-modal Project Window that floats like the Property Box might offer interesting possibilities.

Tools > Work with Data lists (Places, Addresses, Occupations, etc) are NOT separate lists, but simply compiled from data in the Project, so they will sort themselves out.

Place records cannot be sorted out as part of a separate housekeeping exercise. They must be resolved the instant they Drop into the target Project. Maybe an answer is to give such duplicated Place names a suffix such as (2) in the same way duplicated file names gain a suffix when added to a folder. Then they can be Merged or Renamed later.
BTW: Suffixes might get added when Drag & Drop linked Media files have duplicate file names.

I suspect the best "audit trail" is to add all the records to a Named List in both the source and target Projects.
That solves he problem of identifying which records are candidates for deletion in the source Project.
( BTW: Not all record types have the ability to add a Note or a Source to identify them. )

As well as Family links, you have correctly identified other Individual records linked via Fact Witness, Alias & Association plus Submitter record, which only complicates matters further. With the exception of Fact Witness links, none of them can be converted to Name Only format. As you correctly say, those links can jump from Pool to Pool and do not merge Pools.

So that poses two questions:
  1. Which of such linked but not selected Individual records are included/excluded by the Drag?
    Even an option to Drag entire Pool would not resolve links that jump from Pool to Pool.
    Export > GEDCOM File deletes all such links, except for Submitter and optionally Family records with one link.
    So perhaps Drag & Drop should do the same, but with the Family record case as a Preferences setting? Yes or No?
  2. How are such links to excluded Individual records handled by the Drop?
    If the Export > GEDCOM File strategy is followed then there are no such links remaining for the Drop.
    If the link pointers are deleted but the tags retained, perhaps dummy Individual records could be created.
    That would include Father, Mother, Husband, Wife, Child, Witness, Alias & Association entries.
I kept saying there are quite a few devils in these details but the tricky points were not resolved.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry

User avatar
davidf
Famous
Posts: 235
Joined: 17 Jan 2009 19:14
Family Historian: V6.2

Re: Drag and Drop between projects

Post by davidf » 06 Dec 2019 21:29

tatewise wrote:
06 Dec 2019 16:22
Place records cannot be sorted out as part of a separate housekeeping exercise. They must be resolved the instant they Drop into the target Project. Maybe an answer is to give such duplicated Place names a suffix such as (2) in the same way duplicated file names gain a suffix when added to a folder. Then they can be Merged or Renamed later.
  • That is what I actually had in mind as a housekeeping exercise - good old manual work!
  • If you were contemplating that we need to account for Dragging "Place:London" from a Canadian Project into a UK project might cause problems, I agree! Suffixing is probably the way to go.
  • (If FH managed projects as a Library of Projects each with their own ID, the suffix could be the ID of the source project - although "London" in project X would not necessarily be persistent!)
  • I am a little worried that you could generate a lot of suffixes in a session of dragging and dropping family groups from a "family recreation" project into "your main ancestral line" project. Between each drag the definition of a Place might change - so you should really have a new suffix for each drag. So in the target you scan each place, determine its highest suffix if any (some may in the meanwhile have been merged out of existence) and increment the maximum by one?
tatewise wrote:
06 Dec 2019 16:22
I suspect the best "audit trail" is to add all the records to a Named List in both the source and target Projects.
That solves the problem of identifying which records are candidates for deletion in the source Project.
( BTW: Not all record types have the ability to add a Note or a Source to identify them. )
  • Yes I think that is a good way forward - the name of the named list can contain a time stamp.
  • Is it also relatively easy to put the name of the corresponding project into the list name?
tatewise wrote:
06 Dec 2019 16:22
As well as Family links, you have correctly identified other Individual records linked via Fact Witness, Alias & Association plus Submitter record, which only complicates matters further. With the exception of Fact Witness links, none of them can be converted to Name Only format. As you correctly say, those links can jump from Pool to Pool and do not merge Pools.

So that poses two questions:

1. Which of such linked but not selected Individual records are included/excluded by the Drag?
Even an option to Drag entire Pool would not resolve links that jump from Pool to Pool.
Export > GEDCOM File deletes all such links, except for Submitter and optionally Family records with one link.
So perhaps Drag & Drop should do the same, but with the Family record case as a Preferences setting? Yes or No?
  • That would if necessary be OK for me and the way I would anticipate using it.
  • Witnesses in the Source file will by definition be Name Only if they refer to someone in the target file, so should transfer.
  • If they are individuals who jump the pool within the Source File, dragging won't delete them in the source file (so nothing is lost until you delete the dragged files); it would be "nice" if they changed to Name Only when dropped into the target file.
  • Currently deleting someone who is a witness removes any reference to the witnessing rather than turns the witness to name only - so we are no worse off. (Whether deleting witness individuals should cause the witnessing to convert to name only is a totally separate discussion.)
  • Family record case as a Preferences setting? Yes, defaulting to 0.
tatewise wrote:
06 Dec 2019 16:22
2. How are such links to excluded Individual records handled by the Drop?
If the Export > GEDCOM File strategy is followed then there are no such links remaining for the Drop.
If the link pointers are deleted but the tags retained, perhaps dummy Individual records could be created.
That would include Father, Mother, Husband, Wife, Child, Witness, Alias & Association entries.
  • I think creating dummy records is probably the way to go; their ID would take you back to a named list so you would know (or could find out*) that a particular dummy refers to an individual in Project X who was not part of the drag.
  • * would we need a plugin to ascertain what named lists a dummy individual appears in? It's not functionality I use much and I can't see any easy way to see all lists that feature a particular record.
tatewise wrote:
06 Dec 2019 16:22
I kept saying there are quite a few devils in these details but the tricky points were not resolved.
:twisted:
David
Running FH 6.2.7. Under Wine on Linux (Lubuntu 18.04 LTS)

User avatar
tatewise
Megastar
Posts: 16884
Joined: 25 May 2010 11:00
Family Historian: V6.2
Location: Torbay, Devon, UK
Contact:

Re: Drag and Drop between projects

Post by tatewise » 06 Dec 2019 22:44

OK, we are nudging nearer a workable solution, but you are the only interested party contributing, and I would want at least one other user to voice their opinions.

I think we can leave the details of the Place name suffix to Calico Pie.
Yes, if the user performs multiple Drag & Drop there may be many Place records that only differ by the suffix.
Agreed, using the source Project Name/Id as the suffix won't work if there are multiple Drag & Drop from that source. It does not matter whether the Place records have changed in between, because the Drop is NOT inspecting the duplicates to see if they can be synchronised ~ remember we have decided NO synchronisation.
Anyway, all those Place records, whether with a suffix or not, will be listed in the appropriate time-stamped Named List along with all the other dropped records.

I think we can leave the details of the Named List naming to Calico Pie, but including a time-stamp is good idea.

For the Drag, you keep focussing on Witnesses to the exclusion of all other types of linked Individuals.
When deleting Dragged records listed in the Named List that is all that will get deleted (as per current functionality).
All the excluded/unlisted linked records such as Witnesses, Husbands, Wives, Children or Associates will be retained.

I am starting to think that creating dummy records (or not) at the Drop should be a Preferences option.
Remember there could be a great many such as Witnesses, Husbands, Wives, etc, etc...
Yes, they would be listed in the Named List and we need an easy way to discover which Named List.
Currently, it is almost impossible to discover which Named List lists a nominated record; even with a Plugin. Believe me I've tried, and the only solution involves reading the GEDCOM file. So that needs improving.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry

User avatar
davidf
Famous
Posts: 235
Joined: 17 Jan 2009 19:14
Family Historian: V6.2

Re: Drag and Drop between projects

Post by davidf » 07 Dec 2019 00:05

tatewise wrote:
06 Dec 2019 22:44
OK, we are nudging nearer a workable solution, but you are the only interested party contributing, and I would want at least one other user to voice their opinions.
I was waiting for you to say that!
tatewise wrote:
06 Dec 2019 22:44
I think we can leave the details of the Place name suffix to Calico Pie.
Yes, if the user performs multiple Drag & Drop there may be many Place records that only differ by the suffix.
Agreed, using the source Project Name/Id as the suffix won't work if there are multiple Drag & Drop from that source. It does not matter whether the Place records have changed in between, because the Drop is NOT inspecting the duplicates to see if they can be synchronised ~ remember we have decided NO synchronisation.
Anyway, all those Place records, whether with a suffix or not, will be listed in the appropriate time-stamped Named List along with all the other dropped records.
OK, but if you have a Place, say "Edmonton" in your Source and you drag it to a Target, it will get named "Edmonton(2)", per your suggestion. If that place (not fully defined) is duplicated in the Source, (say "Edmonton (Alberta)" and "Edmonton (London,UK)") for some reason or is redefined (sorting out ambiguities between two apparent duplicate places in the source say), are you suggesting the next drag of Edmonton should also necessarily also be Edmonton(2) and appear as a duplicate of the first drag?
tatewise wrote:
06 Dec 2019 22:44
I think we can leave the details of the Named List naming to Calico Pie, but including a time-stamp is good idea.

For the Drag, you keep focussing on Witnesses to the exclusion of all other types of linked Individuals.
When deleting Dragged records listed in the Named List that is all that will get deleted (as per current functionality).
All the excluded/unlisted linked records such as Witnesses, Husbands, Wives, Children or Associates will be retained.
I only focus on Witnesses because that is a form of linked individual that I have been trying to get my mind around!
tatewise wrote:
06 Dec 2019 22:44
I am starting to think that creating dummy records (or not) at the Drop should be a Preferences option.
Yes, but then do you have check boxes to determine whether to for instance show siblings or just parents/spouses/children?
tatewise wrote:
06 Dec 2019 22:44
Remember there could be a great many such as Witnesses, Husbands, Wives, etc, etc...
Yes, they would be listed in the Named List and we need an easy way to discover which Named List.
Currently, it is almost impossible to discover which Named List lists a nominated record; even with a Plugin. Believe me I've tried, and the only solution involves reading the GEDCOM file. So that needs improving.
I had a feeling that would be a gotcha - but is rather important if Named Lists are providing the audit trail.

I await to see if others comment!
David
Running FH 6.2.7. Under Wine on Linux (Lubuntu 18.04 LTS)

User avatar
tatewise
Megastar
Posts: 16884
Joined: 25 May 2010 11:00
Family Historian: V6.2
Location: Torbay, Devon, UK
Contact:

Re: Drag and Drop between projects

Post by tatewise » 07 Dec 2019 00:40

I don't quite follow your Edmonton example.
Yes, if Edmonton is in the source Drag, and Edmonton exists in the target, then the Drop will create Edmonton(2) with all the field values from the source Edmonton.
Now perhaps the source replaces Edmonton with Edmonton, Alberta, CA and Edmonton, London, UK.
If both are included in a Drag, and assuming neither Place name exists in the target, then they will Drop with the same names as the source.
If Edmonton from the source is in another Drag, and assuming Edmonton and Edmonton(2) still exist in the target, then the Drop will create Edmonton(3).

I was thinking the Drop dummy records or not Preference option would be All or None.

Which relatives will produce dummy records depends on which Family records get included.
Remember that depends on a Preference option to omit Family records with only one linked Individual.
If a FAMC link is included then dummy Father, Mother, Sister, Brother records are possible.
If a FAMS link is included then dummy Husband, Wife, Son, Daughter records are possible.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry

User avatar
davidf
Famous
Posts: 235
Joined: 17 Jan 2009 19:14
Family Historian: V6.2

Re: Drag and Drop between projects

Post by davidf » 07 Dec 2019 19:36

Ok, to try and clarify my own thoughts I have been looking at the existing Import functionality particularly with respect to Places.

It is interesting to note that if you repeatedly merge a small GEDCOM into another file electing not to match, FH will create suffixed Places:
Cheltenham, Gloucestershire, England (already existing)
Cheltenham, Gloucestershire, England [2] (first merge)
Cheltenham, Gloucestershire, England [3] (second merge)

If you then merge Cheltenham, Gloucestershire, England [2] and Cheltenham, Gloucestershire, England to Cheltenham, Gloucestershire, England and do another merge, FH creates a new Cheltenham, Gloucestershire, England [2] on the third merge.

Given that this process exists, perhaps it is easiest to follow this process.

Trying to stand back and review this whole exchange ...

The alternative is to design drag and drop so that on dropping, the dragged data is "dropped" into the existing file merge process. From then on it is the classic merge process (but optionally defaulting through all dialogues except the Merge File Dialogue - or possibly all dialogues full stop). If the defaults are set properly in most cases you can complete with one click.

The defaults may be set in Drag and Drop Preferences (either to a value - as below - or to "prompt" as in Classic Merge):
  • Record Matching Options: Do Not Match Any Records (except Sources & Repositories?)
  • Dialogue warning about media links: OK (but see below about media in Merge Options)
That would take you direct to the Merge File Dialogue; you could complete the drop by clicking "Merge", or you could find the "two common individuals" and manually match them before clicking.

In Classic Merge that then takes you to further dialogues which for drag and drop you may also want to set in Drag and Drop Preferences (either to a value - as below - or to "prompt" as in Classic Merge):
  • Merge Summary: Proceed Anyway
  • Merge Options:
    • Copy Linked Multimedia Files: Checked (as recommended)
    • Create New Source Record: Checked*
  • Source Details for Merge: Accept Defaults*
  • Merge Results Dialogue: OK
* Doing this would give you a target audit trail

This simplifies the specification of "drop" (a.k.a. Paste).

I am pondering whether the "drag" (a.k.a. Copy) can be radically simplified to either "selected individual only" or "Pool". I am struggling to think of a time when I would want to do anything but drag and drop a pool. Others may have different scenarios.

In most cases I will have built up a number of small family groups in a working project (Say families with a common surname in Cumberland). If I then realise that the head of one of these family groups is actually a relative, I want to drag the whole family group (=Pool) into my main ancestral file and either merge the common individual or drop the family group into the file and then create the family relationship between the dropped group and my ancestral line. I can see no reason in this scenario why I would not want to drag the whole pool.

I have a situation with my late mother; my family's "public tree" shows her adoptive lineage - which is public (including the fact that she was adopted). I keep in a separate tree her genetic lineage which in respect of her paternal line is not public (her father knew of her existence, but I don't think his wife did and I am pretty certain that her half-brother - who I believe is alive but very elderly - does not know that his father was a bit of a philander or that he had a half-sister). I therefore keep these details in a separate tree to avoid any chance of accidental publication and potentially offending what I believe is a deeply religious family.

In these circumstances to keep my mother's records in sync I would want to drag just my mother's individual record (and associated Sources, Media etc) from the Public Project to the Adoptive Line Project, eliminate duplicate facts, and then drag the her record back from the Adoptive Line Project to the Public Project, and eliminate duplicate facts.

Ideally there would be a way to automatically keep my mother's entry in both trees in sync (a bit like the way you can synchronise spreadsheets such that you can set a cell in one to be be a cell in another), but that would be a totally different enhancement!

I believe some researchers or even family teams of researchers might keep a UK tree which halts at each emigrant and then has separate trees for immigrant families in US, Australia etc. where there are very few (possibly only one) overlapping record.

Does that simplify the specification and does it simplify it so much that it ceases to be of use to others? (It is a pity we cannot "bump" this to draw the attention of others who may have been interested at an earlier stage but ducked out when things got complex.)

I use the words "copy" and "paste" above. For those with limited screen space this may be preferable to drag and drop. Are the two bits of functionality sufficiently similar to be treated as one enhancement? Or am I setting away another hare?
David
Running FH 6.2.7. Under Wine on Linux (Lubuntu 18.04 LTS)

User avatar
tatewise
Megastar
Posts: 16884
Joined: 25 May 2010 11:00
Family Historian: V6.2
Location: Torbay, Devon, UK
Contact:

Re: Drag and Drop between projects

Post by tatewise » 07 Dec 2019 21:47

That is an excellent experiment to show that the suffixing of replicated Place names is already implemented.

Which Place name you end up with after merging depends which one you choose as master.
Anyway, it is every easy to edit the Place name and remove the suffix.

I am not sure that the rest of your suggestions belong in this Drag & Drop scenario.
Possibly a Drag & Drop preference to choose between No Merge or standard Merge File is worthwhile.

Setting default preferences for the Merge File dialogues would be part of a separate proposal.
Then they could be used by both Drop and import a GEDCOM file.

I try and avoid scenarios that are too specific as it can give false impressions.
Any proposal put in the Wish List has got to be feasible for anyone to use with any family tree structure.
Way back I did suggest that the Drag selected just one Individual with options to choose the relatives to be included in a similar way to Roots Magic, but it did not gain much support.

Every time we add a posting it effectively gets bumped.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry

Post Reply