Just noticed that United States on the timeline view map on my PC is displayed in both German and English as "Vereinigte Staaten von Amerika United States"

... to be able to use it on mobile.

Hi,
What is the username and password supposed to be? I didn't set up a username or password for the frontend and don't know what to do. Is the username and password for sqlite? This is the Gramps-webapi and Gramps.js in a Ubuntu20.04 server in a VM for testing purposes. Apache2 server, no certificate set up yet because I'm testing it on my computer.

When a new version of the frontend (of the service worker) is available, it would be great to have a "new version available" notification. However I'm not sure how to do it.

Also, it would be really cool to select objects to link by typing "@" like in many other tools.

Following the readme, I get the following error, web-dev-server is not supported on all platform

# npm i
npm ERR! code EBADPLATFORM
npm ERR! notsup Unsupported platform for [email protected]: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})
npm ERR! notsup Valid OS:    darwin
npm ERR! notsup Valid Arch:  any
npm ERR! notsup Actual OS:   linux
npm ERR! notsup Actual Arch: x64

# npm run start

> [email protected] start /app/Gramps.js
> web-dev-server --app-index index.html --node-resolve --open --watch

sh: web-dev-server: not found

Getting a weird display (on an Android phone In Chrome) after setting home person to I0044 and scrolling...

This is in landscape mode but portrait is similar.

I find it very annoying that my browsers don't auto-fill username and password on the login page. Should try a workaround like this: home-assistant/frontend#9369

Hello,
Instead of a specific version of Node, could we use the LTS version for long term support.
Nodejs v15 is not part of the LTS process and is already deprecated.
Source: https://nodejs.org/en/about/releases/

Hello,

I've noticed that some columns are not sortable in the lists view.
Even though it looks like those are simple text based columns like others which are already sortable.

Not sortable for me are:

• People → Given name
• Families → Mother
• Citations → Source: Title

Let me know if this is indeed something that should be fixed. I might give it a try then.

https://lit.dev/docs/releases/upgrade/

This is more of a strategic question than a technical issue, but I'd like to kick off a discussion about how we should evolve Gramps.js & the Gramps Web API in the next, say, 1-2 years. As described in this post, I think the projects have made really good progress in the last months, approaching a point where they become a broadly usable web app for collaborative genealogy.

I think it was a good choice having an app-agnostic and Python-based web API with as much reuse of Gramps library code as possible, and a pure Javascript frontend based on web components. This makes it much easier to spawn new projects if someone feels like it (a mobile app with the web API as backend, a different frontend reusing some of the web components, ...), or to get rid of some parts when it turns out they are not needed anymore.

However, from forum/issue discussions and from trying to come up with an understandable documentation, I am getting the impression it is really hard for users to understand how it all fits together. And it would be a pity scaring off potential users by requiring them to delve into architectural issues they shouldn't care about.

So, while I wouldn't change anything about the project layout, I would suggest some changes in presenting the project(s).

• We can give a name to the collaborative genealogy web app that is Gramps Web API as backend and Gramps.js as frontend. Let me use the placeholder XXX for this name since I don't have a good idea right now.
• In the description of the Web API, we can write that it's "a RESTful web API powering XXX as backend" or something along these lines
• Gramps.js would then be described as "the XXX frontend", perhaps even renaming it
• Gramps.js would be moved under the gramps-project Github organization to more easily move issues between the two
• The Web API documentation page would be extended by a section on Gramps.js, also moving it to a separate repository

Apart from simplifying documentation, having a single name for the app would also allow to do some things that would make it easier for potential users to find and adopt the app:

• Add it to the Wikpedia Comparison of web-based genealogy software, where IMO webtrees is the only serious contender (which is a great project, with advantages and disadvantages compared to XXX, but also slightly different use cases)
• Set up 1 click hosting for XXX, e.g. as one of my favourite open source self-hosted apps, PhotoPrism is doing with DigitalOcean. Don't know yet how to set this up, but it would allow users to host the app without worrying about setting up Docker.
• ...

Thoughts?

@Nick-Hall, @cdhorn, ...

Gramps.js supports more than 30 languages thanks to Gramps. However, there are some web app specific strings that do not exist in Gramps and these are currently hard-coded:
https://github.com/DavidMStraub/Gramps.js/blob/main/src/strings.js#L5-L26

Selfishly, I only put the German translations so far.

We should improve this.

To clarify:

• Where best to store them? JSON, .js, .po?
• Can we use a non-code translation service? Perhaps even Weblate along with Gramps? (@Nick-Hall)

... including a map view.

Almost finished, merging blocked by gramps-project/gramps-web-api#230

... on all primary objects.

https://github.com/material-components/material-web/releases

... like for the demo:

Hi.

Could we have a demo instance like it's in the old days?

I see this line. But I just get the blank page.

Thank you for maintaining GrampsWeb. It is been a while. Surprised that it's already under the official gramps organization. Kudos!

Btw, I can't find the context. where the conversation starts. asking it to be adopted by the official. I just find this issue. Or maybe you are already a member of the gramps project?

This is currently not possible with Gramps' hourgalss view.

When viewing the Associatons tab for a Person, I expected to see a table listing the association. For example,

Instead a JSON string is shown.

Congratulations on this work it looks really good. I'm planning to adopt it as a way to distribute the family tree work I have done for family!

I though do have a feature to ask for: would it be possible to show the family tree vertically rather the horizontally? Meaning that the the tree grows from the top to the bottom of the screen? This would be important as an option as when (some) people of previous generations look at it they find it more handy to do it in a vertical fashion.

Perhaps also increase the # of generations?

I am using the Forms Gramplet to capture Census Data. The Gramplet creates a single event that is shared among all household members. However, details about a specific household member are stored in the Event Reference Attributes (see image). The attributes are not visible in gramps.js. I believe these attributes are stored in the person data and not the event data.

I would be a nice enhancement is these attributes could be seen in gramps.js.

Thanks,
Bruce

Now that the web API is reporting a proper version (gramps-project/gramps-web-api#231), Gramps.js should check if it is compatible with it and complain if not.

... at least on all primary objects.

It is not possible to login if the search index is not available as selection of a home person is mandatory.

Issue
When Gramps.js displays Event references the description shows the Event Type and Date. This makes it hard to understand to whom the event relates.

Enhancement
I think it would be preferable to display the Description field from the API, if it has a value: For example:
Event Type - Description - Date
Birth - Birth of Jackson, Dorothy Bessie - 1899-11-12

If the field is null, the display: Event Type - Principal Name - Date (if this is too much load because of extra API calls that probably leave as is).

Api result for first birth event
{"attribute_list": [], "change": 1612226646, "citation_list": ["e8d8b189339242de211646a8011"], "date": {"calendar": 0, "dateval": [12, 11, 1899, false], "format": null, "modifier": 0, "newyear": 0, "quality": 0, "sortval": 2414971, "text": "12 Nov 1899", "year": 1899}, "description": "Birth of Jackson, Dorothy Bessie", "gramps_id": "E0007", "handle": "e530e29bb601a88149f5b58bef5", "media_list": [{"attribute_list": [], "citation_list": [], "note_list": [], "private": false, "rect": [], "ref": "ea9c1ee5cc51dadcbb222a3d83b"}], "note_list": [], "place": "e530e29f70828efab3e020d11c2", "private": false, "tag_list": [], "type": "Birth"}

See gramps-project/gramps-web-api#190.

Currently the check for mid-air collisions implemented in the Web API using ETags is not used, which is potentially dangerous.

... e.g. to tag people in photos.

For me personally, this has low priority, but should of course be added for completeness.