Gramps Web Sync GUI is misleading

[emyoulation]

There is really only 1 interactive user step in the Gramps Web Sync: The Login server, username and password datafield entries.

One expects that the "Next" button will advance to the "Progress Information" step for more interaction. But Next triggers the sync and the remaining 6 steps are actually progress bar stages. At the Login step, the "Next" button should be labeled "Sync"

Some additional interactive steps might be nice for the future.

For instance:

• a Person Filter might be selected (assuming this is a XML sync and not a Database sync)
• a Betty sync might be integrated
• An option to read the "Narrated Web Site Report" configuration Page Generation .INI settings might be offered (with editable Note and Media selections) to allow Gramps Web to create a customized home page.

[DavidMStraub]

There is really only 1 interactive user step in the Gramps Web Sync: The Login server, username and password datafield entries.

That's not quite true. It's important that the user is able to review the changes* and abort the tool. For instance, it could be that another user deleted something in Grams Web and the owner only realizes it during the sync. Without the option to abort, it would be deleted locally automatically

One could add a checkbox to never ask for confirmation to speed things up.

* It's of course bad that only the Gramps ID is displayed. What would be needed is something like the diff shown by the import merge tool, but I didn't have the energy to implement it.

One expects that the "Next" button will advance to the "Progress Information" step for more interaction. But Next triggers the sync and the remaining 6 steps are actually progress bar stages. At the Login step, the "Next" button should be labeled "Sync"

I agree that the UI is pretty bad but honestly I hate Gtk GUI development. I did this because I needed it, but I really need somebody else to improve this. Now that it does the job, I prefer focusing my efforts on improving Gramps Web itself.

a Person Filter might be selected (assuming this is a XML sync and not a Database sync)

Since it's a two-way sync, it only makes sense for 1:1 replication. For filtering, it would be better to do an import merge.

a Betty sync might be integrated

Interesting, I had no idea about Betty, looks nice. But I don't know what you mean by sync. It seems to be a static site generator.

An option to read the "Narrated Web Site Report" configuration Page Generation .INI settings might be offered (with editable Note and Media selections) to allow Gramps Web to create a customized home page.

Something like that could be useful, but using INI files is not a good approach when using Gramps Web API as backend. It would be better using something that is stored in the database, like tags.

[emyoulation]

a Betty sync might be integrated

Interesting, I had no idea about Betty, looks nice. But I don't know what you mean by sync. It seems to be a static site generator.

Betty leverages an XML upload to a server. Then it dynamically generates content from that data. So a FILTERED uplink sync (based on the last EXPORT?) would be useful. It only allows Browsing, no editing. The only downlink sync functionality would be recovery if you lost your local file or were pulling down a local copy when visiting a relative. (Not sure downlink sync is useful enough to deal with the problems where the destination doesn't already exist and paths have not been validated.)

An option to read the "Narrated Web Site Report" configuration Page Generation .INI settings might be offered (with editable Note and Media selections) to allow Gramps Web to create a customized home page.

Something like that could be useful, but using INI files is not a good approach when using Gramps Web API as backend. It would be better using something that is stored in the database, like tags.

I was mostly considering that the functionality already exists in the core application. So adding in another GUI for a similar functionality for the same User subset would create a bit of confusion. I also do think that the .ini approach that Serge adopted for Narrated Web Report is NOT the optimal choice. But it was straightforward. Chris Horn (Dashboard CardView) and Kari Kujansuu (Isotammi XML Export) have designated other approaches for communicating the Tree descriptors via specific reserved Note types. Serge does the same for other parts of the Narrated Web Report.

[emyoulation]

• It's of course bad that only the Gramps ID is displayed. What would be needed is something like the diff shown by the import merge tool, but I didn't have the energy to implement it

I am curious. The Introduction" on the Sync addon suggests using the Import Merge Tool instead if there are significant changes.

But how do you get a clone of the online Gramps Web database to run against the local copy? (Assuming THAT ONLINE is where the significant number of changes were made.) Does the Tree stay in XML so you can just download it via FTP? Or does it convert to a database engine file like Gramps does?

[DavidMStraub]

Betty leverages an XML upload to a server. Then it dynamically generates content from that data. So a FILTERED uplink sync (based on the last EXPORT?) would be useful. It only allows Browsing, no editing. The only downlink sync functionality would be recovery if you lost your local file or were pulling down a local copy when visiting a relative. (Not sure downlink sync is useful enough to deal with the problems where the destination doesn't already exist and paths have not been validated.)

Export is already possible. https://gramps-project.github.io/gramps-webapi/#/exporters/getExportFile It would be straightforward to implement a script on the server running Betty that regularly generates an XML export.

The Introduction on the Sync addon suggests using the Import Merge Tool instead if there are significant changes.

No, it suggests using Import Merge "with a large number of changes on both sides that need manual attention for merging" (emphasis mine). It's like if you use Dropbox, stop syncing, then change 20 files both locally and remotely, and then start syncing again. This can be easily avoided in practice by syncing before and every after desktop session where significant changes are made.

But how do you get a clone of the online Gramps Web database to run against the local copy?

With this button...