I like the tag feature, but I’m frustrated that there aren’t any tags to begin with and that they have to be created manually. I can think of a few preset tags that could be added for people, such as research status, war veterans and people who held royal or noble titles. I don’t know how you would implement this, but it would save me time.
While we’re on the subject, it would be great to apply tags to all the ancestors and descendants of a person. For example, I could create a tag for everyone in my family tree who descends from a specific person, and then apply it to all of that person’s descendants. This would save me from applying the tag to each person individually, which could take a long time, especially for those with hundreds of descendants.
That could do the Ancestors or Descendants tagging.
You can also Filter one of the “list” views and/or select all or some of the records in that View to choose to apply or remove a tag en masse.
For the example below, the Example.gramps sample tree has been imported and a non-sensical Filter was applied (which finds persons with both an “i” and an “a” in their name, born in a place that contains the word “town” and who have a “Death” event). Then 3 rows were selected from the filtered list. And finally, the “ToDo” was applied to those persons.
I prefer to utilize Tags differently than many other users. I’ll use Attributes for permanent data and Tags for temporary filtering or temporary color coding. Otherwise, the Tag Add/Remove double-entry menu becomes quickly overwhelming.
In this menu, there’s more than a screen-full of “Add” menu items with just “A” through “S”. The rest of “S” through “Z” and the “Remove” menu items for “A” through “Z” will take more than another screen-full.
The problem with creating a set of packaged tags is that there are as many ways to utilize tags as there are Gramps users.
I too tag branches of my tree. I have a set of filters that finds the ancestors of the active person then brings those lines forward. I do this for my four grandparents. Once the filtered list is returned I can select all and apply the tag to everyone at once.
I think that we could just start off with tags based on research status and go from there.
Just in my case, I have many different types of tags; these include people who descend from certain monarchs, specific officeholders, people who owned slaves, etc.
For officials and slaveholders, I find using an “Event” to be preferable. That allows structured recording of places and time-frames and have those be separately searchable characteristics.
There are built-in Events for assuming Nobility titles, Elected office, Military rank, and so forth. I added “Slaveholder” as a custom type. And the event can be ‘shared’ to the enslaved persons with a custom “Enslaved” role. So the crime, offender and victim can be thoroughly linked.
I am in the no Preset Tags camp, the bigger problem really is that Tags
are not handled the same across all views GraphView being one of the
notables
phil
I only use tags for the research status of the profile. This keeps the list short. Long lists are cumbersome. I would likely not use preset tags such as Nobility as I don’t have any in our family. Tags are a workflow tool and there are very many ways to use them.
Tags could represent common situations of lineages or people (strictly speaking, graph) that are culture- and research-independent, e.g. end-of-lineage, no-children, no-couple, died-as-an-infant, living, etc. FamilySearch calls some of these (and more) “Facts”.
I wouldn’t mind if some standard subset of these would be present by default in Gramps. Especially, if these were to be used Gramps-wise, e.g. the different Views should display them (e.g. crossed-out name if person is known to have died without any offspring). In this sense, Gramps’ privacy lock is a specialized tag that already exists.
To do something like this, Tags would probable have to evolve into something like the way named & conditional Styles were implemented in Excel.
Which is an interesting possibility.
Interesting because… instead of being limited to having a visual indicator of only the topmost Tag with the foreground color styling, you could have a stack of stylings.
Boldface, Italics, background color, double-underline, fontsize, fontfamily could all be indicated independently and simultaneously. The information density could be much higher.
To be honest if someone is going to work on Tags then getting the Tag
Selector to be the same in all views ie GraphView, Event View, People View.
Preferably as per the route used when in Person View and click the tag
button which has the benefit of the kku improvements.
Example in Events View there is no right click option to bring up Tag
Selection, Click Tag in Toolbar and what do you get an enormous list
because it attempts to to show all tags twice “Add Tag” X and then
“Remove Tag” X.
Rather generating bigger lists of Tags
phil
If I am not mistaken, these lists (like Attribute custom type lists and Custom Filters) are Category specific. A single list is not an option. So, this allows for a different set of Note Tags than People Tags, resulting in shorter (pre-filtered) menus.
And the Tag Selector dialog is not a table list like the Object Selectors. It is designed for multiple selections/deselections in a single dialog. So it would not not be compatible with the Recent-Items patch that @kku created.
However, I agree that the Add and Remove menu design for Tags could be made less awkward and cluttered.
" If I am not mistaken, these lists (like Attribute custom type lists
and Custom Filters) are Category specific. A single list is not an
option. So, this allows for a different set of Note Tags than People
Tags, resulting in shorter (pre-filtered) menus."
Does not matter when I open Tag Menu Bar Button in the Notes-Gramps view
get exactly the same list in Person View-Gramps view
If I go to Person: and click on Tag I get same list just arranged with
tick box’s
Maybe I have configured some of the Tags wrong but many are used across
multiple Views.
phil
Instead of introducing a static, hard‑coded “default tag list” — which will inevitably create a list object that many users never use and only adds unnecessary bloat maybe something else should be introduces…
This menu would be much more pleasant if the addition and removal of tahs were the subject of two separate sub-menu. I can’t tell you how many times I pressed the wrong option when I saw the tag name without paying attention to the add or remove option.
And since we’re talking about tags, and submenu. If the tag system could recognize the content of the tag, it would be even nicer to make a hierarchical menu.
We could have a tag like “Subject/Subsubject” that would appear in the menu like that:
Tags
|_ Add tag
|__ Subject
|___ Subsubject
|_ Remove tag
|__ Subject
|___ Subsubject
Subject would be an non-selectionable entry in the menu, only the Subsubject entry could be selected
More than one level could be created: “Subject/Subsubject/Subsubsubject”
Tags
|_ Add tag
|__ Subject
|___ Subsubject
|____ Subsubsubject
|_ Remove tag
|__ Subject
|___ Subsubject
|____ Subsubsubject
Slash could be escaped with a backslash: “Subject/Subsubject\/Subthema”
Tags
|_ Add tag
|__ Subject
|___ Subsubject/Subthema
|_ Remove tag
|__ Subject
|___ Subsubject/Subthema
Sorry but the first thing that needs to improved is that no matter which
way you select to add/remove a Tag you are presented with the same
screen for somebody starting from scratch it is quite frankly ridiculous
to have to learn several methods of adding/removing tags let alone
creating or deleting (naming, sorting, colouring) them.
I just wish I had the programming skills to look at this.
phil
