Config for event types and their description in the timeline. (requested by @roptat and @PLegoux)
Select which event types to display in the timeline and which to display the description for. By default, only the description is shown for Occupation and Religion events. If you have ideas about which event types should also have a description by default, I’m open to suggestions.
Improvements and configuration for name abbreviation rules.
I have generalized how abbreviation rules are applied to names. This also provides flexibility. In the new Names page of the FTV’s config dialog you can edit the rules. The rules are applied one after the other. Each rule can also apply multiple times (e.g. multiple given names). You can select which name parts (Given , Surname, Prefix, etc.) the rule should apply to, and whether the name parts should be abbreviated or removed. You can also check to apply the rules starting from the end of the name (e.g. abbreviate/remove last given name first). At the bottom of the window you will see a preview of the rules applied to the example name.
(@PLegoux You can customize the rules to first abbreviate surnames (e.g. delete the rules for given names or move them down in the list).)
If you want to use a different name format in the tree, you can also select a specific name format for FTV that will be used in the tree (and to which the abbreviation rules will apply).
I also improved support for other all-caps name parts (e.g. given names, GIVEN in the format specification) as well as compound names like MaryAnn without a space or hyphen (e.g. MaryAnn Mihychuk, abbreviated as MaryAnn → MaryA. → M.A., also works for GIVEN: MARYANN → MARYA. → M.A.), and I fixed a bug that caused problems with non-latin names (e.g. Chinese surnames).
Revised badge registration interface.
The interface is now much easier to use. There is now a guide on how to create new badges. The old interface is still supported, but support will be dropped in the future.
Option to make FTV the first view.
This new option on the Interaction page of FTV’s config window makes it the first view and therefore the default chart to be displayed.
Various minor improvements
Let me know if you have further ideas for improving these features. I’m open to feedback and bug reports (the latter preferably as a Github issue).
If possible, a Small Caps alternative to All Caps would be elegant. Such a styling would both support the expectations of traditional genealogists and demote well to plain text with normal Capitalization.
Thanks for the suggestion. I think support for small caps would really be a interesting improvement, not only for FTV, but for Gramps as a whole.
In the name format definition, how the name part is written (e.g. surname, Surname or SURNAME) determines whether it is written in all caps or not. This logic is copied by the abbreviation algorithm and applied equivalently.
(The only difference is the handling of prefixes in main surnames, such as Mc in McCarthy, which are recognized and not capitalized in abbreviated names. Gramps’ NameDisplay, on the other hand, capitalizes everything.)
To distinguish whether a name should be written in all caps or small caps would require a distinction in how Surname is written. I can think of a syntax like Surname[sc] to indicate that this particular name part should be written in small caps. BUT: This kind of enhancement should be done in Gramps itself, where the name formats are defined.
Besides that, there could be an option in Gramps’ name format editor to turn all caps into small caps when the option is checked. As long as this is not implemented in Gramps itself, it might be possible to simply add an option for FTV to allow the user to choose to display all caps name parts as small caps instead.
That being said, I’m not sure if it’s possible to format individual words (i.e. name parts) as small caps in Gtk. According to this link, Gtk seems to support small caps as a CSS font-variant value, but I’m not sure if this helps in a word-wise application instead of being applied to a label as a whole.
Thanks for your idea. Unfortunately, I can’t directly control the preview of the search result because FTV reuses the SearchWidget of Graph View. I suggest you open a feature request in Gramps’ bug tracker if you would like to see this enhancement in the SearchWidget.
That said, I would like to draw your attention to the additional information that appears as a tooltip when you hover over an entry in the search results list. This was added with this PR and may meet your needs.
@emyoulation
I just pushed an enhancement (v0.1.32) that adds an option to the names page in FTV’s config window to select how ALL CAPS name parts should be displayed. There are the following options:
all caps (keep as defined)
small caps
petite caps
bold
italic
underline
This not only allows you to display names in small caps instead of all caps in the tree. Even if you don’t like all caps at all, you can use this option to get bold/underlined (or other styles) surnames (or other name parts) in the tree:
Create a name format similar to your usual format but using SURNAME.
Don’t select this format in the Gramps preferences but select it for the tree in the FTV config window.
Select bold from the new drop-down menu.
All surnames (or whatever you’ve chosen to change) will appear in bold (or whatever style you’ve selected) in the tree.
Does it include enhancing the loupe that can be popped up in the bottom left and which shows how much of the complete tree you can see at the current zoom level?
I think it would be helpful if it behaved like the similar loupe on the Life Line Ancestor and Life Line Descendant charts. In those loupes you can click and drag the window in the loupe to navigate around the complete tree.
@emyoulation
Actually I was not aware of this option either. I saw it in the Pango docs and tried it when I had the impression that sometimes uppercase and small caps are not so clearly distinguishable. I kept small caps and included both, since petite caps might be too small for some people. That way everyone could choose which one they prefer.
As a side note: Unfortunately, I had to replace the real small caps and petite caps with fake smaller uppercase letters because the original formatting options do not scale correctly in the canvas and there is a Pango warning. Although the small caps and petite caps are fake, I compared them to the real ones and they look pretty similar (at 100% canvas zoom).
@stuck
Yes, @Gioto is right. I have this feature on my todo list, and clicking and dragging the box in the mini map actually worked in my original HTML/CSS/JS implementation (which, as noted earlier, doesn’t work as universally as the current GooCanvas-based implementation). I didn’t find it that important in practice, so it had a low priority.
Since you’re specifically asking for it now, I’m moving it up the list. Now that you can visualize more generations much better and the visualized tree can grow larger, I also think it is useful.
Umm, as I’ve said before, don’t change your priorities on my behalf. I’m only a (very) casual user of Gramps. I was simply asking if this feature was planned, not for rapid implementation. Now I know it is planned, I’m happy to wait as long (weeks / months) as it takes for it to happen.
Rest assured that I won’t throw out the entire TODO list because of your comments . There are just features that no one has requested (yet) and that I don’t need in my own Gramps workflow. If someone asks for a specific feature, I’ll add it to the list of requested items.
Please do not let my positive feedback on your request discourage you from continuing to report possible improvements, as feedback like yours from the community is very valuable to me.
I’m happy to announce that I have found a working and reliable way to implement the very first feature request submitted in this thread: The option to move the panel into a Gramplet in the sidebar.
@emyoulation
If you add the “FTV Panel” Gramplet next to the FamilyTreeView, the panel will move to the Gramplet (if it is open) and future panel content will be displayed in the Gramplet. Removing the Gramplet will activate the integrated panel again.
I haven’t implemented this yet. I think it might require a separate Gramplet with the keyword navtypes = ["Person"] in the .gpr.py file. Maybe I can implement to link the Gramplet to this navtype conditionally based on where the Gramplet is added to the sidebar, but that is still an open point.
I use the “What’s next” gramplet in the right sidebar. This works very well together with FTV. When I click a person in the What’s next list, the FTV graph is centered on that person. Nice.
But if I have the FTV panel open (which I rarely have) the content of the panel is not changed.
This is because the panel is not linked to the “active person”, which is the “root” person of the currently visualized tree. This allows you to open the panel for all people in the visualized tree, not just the active/“root” person.
When you click a person in the “What’s Next?” Gramplet, the active person changes and the tree is updated. I could implement that the panel updates when the active person changes.
@csam
The latest version (v0.1.34) has a fix for the handling of clicks on the canvas. Can you please check if this problem still occurs with the latest version or if this also fixes the bug you experienced?
Thanks for the feedback. Unfortunately, I can’t reproduce this bug, so it’s hard to fix it. It would be great if you could open a GitHub issue to discuss this bug in detail.
. There are just features that no one has requested (yet) and that I don’t need in my own Gramps workflow. If someone asks for a specific feature, I’ll add it to the list of requested items.