store selected persons and options for future updates of complex diagrams

[schuco]

To get informative and clearly arranged diagrams it often needs a lot of effort to select proper individuals to be included, to set stops at certain individuals and to find out, how many generations to use, if or not sibs or cousins should be included.

If you have gained more data in the genealogy after a while, you may want to repeat or update the diagram.

To avoid compiling information for GVExport from the scratch again, I copy the XREFs from the input fields in "include anyone related to" and "stop processing on" and also take a note on the max. generations and other options. At present I paste these info into a table in "My page" where I can copy and paste it again. Alternatively I append the string with XREFs to the name of the downloaded file.

In future there might be an option to export and import settings for certain diagrams built into GVExport directly.

[Neriderc]

When I use GVExport, the settings are all saved between uses. So if I have selected some individuals to start from or selected to include siblings or any other settings, when I come back the next day all of that is remembered. This is not new, the previous repository version also did this.

Are you talking about being able to download a file of settings to be imported later, so that you can switch between multiple saved configurations? Because as you describe it, it seems the saved settings should meet your use case.

[schuco]

@Neriderc Are you talking about being able to download a file of settings to be imported later, so that you can switch between multiple saved configurations? Because as you describe it, it seems the saved settings should meet your use case.

That is what I mean. Not only in my case users will get more data on their family. So after a while they may want to update an extended family tree without starting selecting persons to be included again.

[Neriderc]

Ok, that sounds feasible. We could save all the saves values in JSON format in a file, then load it all when imported. Given much of this save/load stuff already exists, I don't think it would be too difficult.

What do you think would be a good way to display the options? There are already many options, and one of my concerns is cluttering up the form. It has been suggested that we move some options (as well as many settings that are not currently in the options form) to the control panel for administrators (see issue #51). I think perhaps this is not the place for this functionality, as it would not just be for administrators, it would be useful for all users.

Perhaps we should consider adding an "Advanced settings" section, that is hidden until you click on it to expand it? This could be a candidate for a section like this. I'd be happy to hear some other options for how to approach this :)

[schuco]

@Neriderc Perhaps we should consider adding an "Advanced settings" section, that is hidden until you click on it to expand it? This could be a candidate for a section like this. I'd be happy to hear some other options for how to approach this :)

Advanced settings hidden until click would be good. I just contacted @hartenthaler in German language with a manual to produce printouts which I have written in German. There I show that some options, seemingly of minor interest, may have important use. So DPI can be used to gain certain page height of diagrams in pdf output. This is important when you upload a pdf-file to plotter shops which have a restriction on diagram height already in the uploaded file. Also MCLIMIT may be useful in few cases to gain a desired order in diagrams. More hidden options could be colors for male, female and unrelated. Generally I would like to have as many user options as possible. The options to be set by the administrator should be the same and not more than for the user. But they will be important to get desired starting values after reset.

A final remark: The option for the color for nonrelated individuals should be put in the section for appearance of the diagram as it has no influence on what is included into the diagram.

[hartenthaler]

There are two parts

• remember the options (generations, siblings, ...)
• remember the start/stop persons and/or the content of the clippings cart

I think that both things are really complex.

First: store the information in the webtrees database or store it as a downloaded file? In the database, you have still control over it, in the file not. If you change in the future parameters like removing the option "cousins" and adding a new option "anyone", you have to modify the saved data structures, so you have to add a version control system for GVExport and roll up/back functions in order to modify the stored structures from a version to another one. Doable but not easy.

Second: storing the needed XREFs is easy, but what should happen if the XREFs are not there anymore when you like to reuse the stored information? For example, a person could be deleted in the meantime. XREFs are intended to be temporary internal IDs. The GEDCOM standards say that they can be changed anytime by an application, for example during import or export or when combining two trees into one. It would be a bad practice to store them externally. You can maybe add user-defined references instead XREF to all needed INDI/FAM/OBJE records, but again this is complex. And you need an identity of the tree to which the stored persons/families/media objects are related, but I don't know a unique persistent tree ID. And you should handle the information stored in the clippings cart in the same way as the stored information using start/stop/partner/sibling/... information.

So I can see the use case, but to make it work, it will be very complex.

About your final remark, @schuco: the reason why the "color for nonrelated individuals" is where it is, was that this option makes no sense if the information about the persons/families comes from the clippings cart. Then this option should be greyed-out - as all the other options in the first part of the menu.

[Neriderc]

You make some great points. I think while storing internally in the database does give you more control, I think that the task of maintaining it becomes quite complicated.

In the case of an external file, I was thinking that we save current settings. When it comes to loading, we ignore any that do not match something we are looking for. If a loaded file does not contain a value for something we expect, then the default value is used. This way if you load a file that was generated many versions ago, many options may be set to default if they no longer are relevant but this still lets us load options that are still relevant. Effectively, by storing externally we can absolve ourselves of the responsibility of maintaining the data through module versions.

In the case of XREFs that are no longer valid, this is a great point. GVExport does not currently handle this well. If an invalid XREF is included, there will be an error (that is not forthcoming on what the issue is). If we update this to handle the problem better (error message saying which XREF was not found) then it would be reasonably simple for the user to resolve. Alternatively, we could automatically remove the invalid XREF. I'm a bit more hesitant about this as we do not currently have a way to inform the user that we have done this, and removing an item silently does not seem like good practice. In #142 we now ignore invalid XREFs, and in #146 we now notify the user, so this is no longer a problem.

[Neriderc]

Leaving a comment here as a note to self. I'd like to update the way cookies are stored to use JSON format. Once this is implemented, this item becomes pretty straightforward. The cookie is basically the same thing - a file that stores the settings. We would then only need to provide a way to download a file and upload a file using this format.

Actually, @schuco, would you prefer downloading a file or would "save slots" be better, like video games used to have. So you would have say 3 save slots 1 through 3,. Click the save button on slot 1, and settings would be saved there. You could then change settings to other things, and when you want you could click the load button on slot 1 to return the settings back to what they were when you clicked save. Slots 2 and three would work the same, so you could have 3 sets of saved settings plus whatever the current settings are set to.

That seems like a quicker way to switch between settings. Visually I'm not quite sure how it would be laid out, but from the technical side it would be pretty straightforward I would think.

Let me know what you think :slightly_smiling_face:

[schuco]

would you prefer downloading a file or would "save slots" be better As I understand "save slots" you could store maximal 3 settings of selected persons whereas you would have no limit downloading files. Therefore I would clearly prefere downloading files. The main scenario where I would use the option to store settings is as follows: In manuscripts describing certain parts of my family I try to produce most informative and concentrated diagrams, displaying only important paths and persons and exluding less informative parts. From time to time I update the manuscripts after I gained new data. Then it is useful to repeat the GVE diagram with the same or at least similar settings. At the moment for that purpose I use to store different lists with XREFs to get the diagram for a certain family part. Your idea to store not only the list of XREFs but also the complete setting for the diagram would be perfect.

[Neriderc]

A third idea, though perhaps a little more complicated to implement: a list of saved settings.

Think of how the person select works now. Instead of selecting a person, you would just have a Save button and a place to enter a name. The saved settings get added to the list, and clicking one would restore those settings. Clicking the X would delete those settings.

The file thing should be pretty simple so I'm happy to do both, I'm just thinking it might be nice to have a way to quickly switch between settings.

For your use case, the file may still be a better option. We save settings in a browser cookie currently, if you cleared your cookies then the settings would be lost. A file solves this by letting you store the file somewhere lomg term, but also webtrees offers ways to save module data in the database so perhaps that should be explored.

But there's no point in building something that won't be used so if the file option is what you'd prefer then that's fine. It's also much easier to build 🙂

[schuco]

I can well imagine that your third idea, list of settings, will be quite useful. For example if you want to present to a family member the complicated structure of your family, where more than one starting person are involved. Instead of compiling this list you could easily get it from the list. But your comment is valid: will it be used very often? For my case I would certainly prefere some settings for the list as described above instead of saving files. But would there be many more users thinking this way?

[Neriderc]

I'll have a think about the best way to implement it. I expect it will be reasonably straightforward. The hardest thing is working out where to put it on the user interface! People to be included, Appearance, Output - none of these really fit. I'm tempted to put it in the Output settings section (since it's shortest), and hide it behind an advanced section since this isn't something we would want brand new users to see. Maybe there's something better to call that section that covers both output and saving settings? Maybe something like "File settings"?

[schuco]

File settings!

[hartenthaler]

What I have done already with GVExport is what @schuco has described: preparing diagrams for special situations in the tree to be added to a genealogical report as an image (for example a married couple that is related via distant ancestors). Storing such diagrams would allow me to update them for a new release of the report in the future.

New idea: sometimes I draw diagrams showing distant relations in my tree using Microsoft Visio. for example how I'm "related" to Dr Martin Luther (Protestant Reformation) or Johann Wolfgang Goethe or Shakespeare. Several steps in between are not so important, but there are essential gateway persons in such a path. So I just got the idea to use GVExport instead of MS-Visio in the future to draw such diagrams. But then I need a new category beside start and stop persons: "hide persons". A "hide person" is a person that is shown as a small box, but without any information (no name, no image, ...). The hide persons are selected in a menu like the menus to select start and stop persons. Maybe an additional option could be: if there are several hide persons in a sequence in a path in the diagram they are aggregated to one box showing the number of steps in between.

Geni has such a function in one dimension. It would be nice if I could use GVExport in two dimensions for such long-distance diagrams.

Another example is one of my Visio drawings (the small circles are showing the number of "steps" from one gateway person to the next one):

What do you think?

[Neriderc]

Hmm. I think one difference is that GVExport uses one row/column for each generation. If there were hidden people, it's not really clear how they would be displayed. Your Visio diagram doesn't have that limitation as you've grouped them in ways that make sense to you, but automatically generating such a diagram may prove a challenge.

Do you have ideas on how it might be done?

[hartenthaler]

You are right. My Visio diagram is ignoring generations and is ignoring relations by blood/marriage. This is different to GVExport. When using the concept of GVExport and only make the boxes of "hidden" persons very small and empty will result in a diagram that will look like straw bales.

Forget this idea.

[Neriderc]

I think perhaps for this to work, it would need to be a "physics" based diagram, where items are links and can push each other out of the way to make room. I don't think it's something that Graphviz makes very easy, but perhaps a module like TAM or Linage would make this easier.

[Neriderc]

I have added the functionality to save the current settings to a file, and load settings from a file.

Saving settings in a list within Graphviz is separate and will be done in #299

I found quite a few issues where loading settings left some things in the incorrect state (e.g. loaded setting to enable blood relationship arrow colours, but colour settings remained hidden). I think I've got it all working now but please let me know if something isn't working quite right.