I’ve created a family with only one person, so I have the [missing] box in the graph, but clicking the box (no matter single, double or right click) doesn’t anything at all (maybe a restart is needed?).
For inspiration for ‘Add Relatives’:
The MacFamilyTree has this pop-up list for adding a relative
I find most useful the context menu items in Graph View (add spouse, add family, etc.) which allow to add almost anything easily without leaving the view. I think you could borrow from it.
With my home person set to the male ancestor at the top of my father’s father’s line AND my active person set to the male ancestor at the top of my father’s mother’s line, FTV shows a tree from the active person down to me, which doesn’t include my home person.
When I then double click on white space in FTV and select ‘scroll to home person’ I get an unhandled exception, presumably because the home person is not shown and so can’t be scrolled to:
396172: ERROR: grampsapp.py: line 188: Unhandled exception Traceback (most recent call last): File "C:\Users\Common\AppData\Roaming\gramps\gramps52\plugins\FamilyTreeView\family_tree_view_widget_manager.py", line 985, in <lambda> self.scroll_to_home_person() File "C:\Users\Common\AppData\Roaming\gramps\gramps52\plugins\FamilyTreeView\family_tree_view_widget_manager.py", line 888, in scroll_to_home_person active_pos = self.position_of_handle[home_person.handle] ~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^ KeyError: 'e187848d8f12681f11dc4d320d6'
Good catch! I actually remember thinking of this case, but apparently forgot to write it down and implement it. I just released an update (v0.1.101) with a fix (also the context menu item is now grayed out in this case).
Thank you again for your fantastic efforts and accomplishment!
It occurred to me while using it today that there may be scope to add ‘custom badges’ which can be operated by custom filters and only selected by the user as needed. This would allow ‘one-off’ conditions to be displayed and worked-on as a single set of similar tasks (allowing more of a focussed effort by the user).
I wonder, though, whether this might need the introduction of a new type of filter category i.e badge filter. I recognize that this probably takes more than I am seeing right now in terms of design effort, but I am pretty sure I would use it all the time so I could visualize/concentrate on a single canvas in front of me, what I need to accomplish today; e.g the families which don’t have a census event just yet! or some other such arbitrary deficit I just noticed.
@Brinycoolie
Thanks for your suggestion! I’ve also thought of this before, but it seems I haven’t put this on my list yet.
Currently there is a “Filter result” badge to highlight the results of the sidebar filter (see here). Unfortunately, this can be extremely slow for complex filters, since the filter is applied to each person individually, not once to all people in the database. This can slow down the building of the tree considerably.
To solve this, I plan to change/enhance the badge interface so that a callback can be run once for each tree rebuild to do general operations like filtering (i.e. applying the filter only once for each tree), and the callbacks for each person are much faster.
As a side note, it would be nice to be able to hash the filter somehow to detect changes. I tried to do this for the sidebar filter, and it seems to work in my tests since the filter is completely recreated when the user changes something in the sidebar, but I wasn’t sure if this was always the case. For example, instead of recreating the whole filter, the filter rules could change without noticing this using a top-level hash. I don’t do this not-so-reliable hashing because it could cause the tree not to be updated even though the filter has been updated. If anyone knows of a reliable way to detect filter changes using a hash or something similar, I’m open to ideas.
I also plan to enhance the badge interface to allow the badge developer to provide settings to the user, e.g.
Change the color of the badge
Select a string/character/icon to display in the badge (e.g. if the main info is not the content of the badge, but that the badge appears for a person/family at all)
Select an item from a drop-down menu
etc.
The badge developer could use a drop-down menu to let the user choose from the list of custom filters. This way, the user could define a filter, select that custom filter from the badge’s drop-down and select a color as well as a character/icon for that badge. This would work once the interface enhancement is implemented.
However, relying on this interface would limit this to only one filter per registered badge. The best solution might be to just implement this directly in FTV, not in a separate registered badge. I’ll add this to my TODO list.
In the latest version (v0.1.103), I added a feature that was originally a high priority: Links to make one of the people listed in the panel (general info on person/family and timeline) as the active person. In my original HTML/CSS/JS implementation I used buttons for this but in Gtk (the GUI toolkit Gramps’ UI is based on) I had to use links (which work but don’t look as nice). The links appear as arrows after the name, the color depends on the theme (in my case they are orange).
Note to other devs: Yesterday PyGObject 3.52.1 was released, which seems to require girepository-2.0, which in turn is not available on some distributions, including Ubuntu 24.04.2 LTS, which I use in the GitHub workflow for packaging. I had to modify my workflow to get it working again. If you get an error message, you may need to make a similar change.
With the FTV panel showing for the Active Person, then in the panel when I click on the link to make the spouse the Active Person then, as expected, the chart updates and the spouse becomes the Active Person.
However, the panel for the new person does not open. I didn’t expect that. I presumed that because I’d used a link in the panel, the panel would also update.
@stuck
This is somewhat intentional, coming from the built-in panel to hide automatically to show the new tree. I agree that it makes sense to show the panel in some situations. I’ll put this on my list.
In the latest version of FamilyTreeView (v0.1.109), I added a feature that has been requested several times (here and here by @Urchello): a way to display dates compactly. The two images below show dates and their compact representation. Please keep in mind that the representation is just a first attempt/draft.
Possible improvements, open questions and discussion:
~ is used for three modifiers (estimated, calculated, about). Are there any ideas for using other symbols that are more intuitive to understand? I was thinking about using the following mathematical symbols (and their meaning in maths):
± (plus-or-minus)
≈ (almost equal to)
≃ (asymptotically equal to)
≅ (approximately equal to)
The problem with all of them will be that it’s not intuitive which symbol means what (maybe not even for those who know the different mathematical meanings of the symbols).
I also feel that “calculated” is more of an indicator of the interpretation of the source(s)/citation(s) of the date, rather than an indicator of the quality of the date. So maybe it is acceptable to ignore “calculated” in the compact date representation?
If “estimated” and “after”/“before” appear together, the combinations ⪆ or ⪅ could be used to save one character (more compact)
I’m not sure if the suffix + and − are intuitive (meaning “from” and “to”). As an alternative, I can think of using … before the date for “to” and after the date for “from”, but I’m not sure that would be more intuitive either. I’m open to your suggestions.
In the current implementation, – is used for a range (“between A and B” → “A – B”) and … for a span (“from A to B” → “A … B”). I think … for a span is not very intuitive, but I cannot think of a better alternative. Maybe – and … should be swapped in their meaning?
The current implementation for the compact date display is just only a draft as far as the symbols used are concerned. As always, please let me know your suggestions.
I also want to let you know that as of v0.1.104 there is a new option (in the Interaction tab) to hide the expanders when printing/exporting, and padding is added when printing/exporting to ensure that everything (e.g. all badges) is exported correctly.
[This post was copied from the original one which was moved to a new topic.]
After @emyoulation suggested using ≤ and ≥ instead of < and > (here) and moving and copying posts a bit (discussing how “before” and “after” are misleading labels), I pushed v0.1.110, which adopts @emyoulation’s suggestions.
As I wrote before, the currently used symbols are only a first draft, so any other ideas or discussions about the used symbols are very welcome.
@Urchello Have you tried the compact date display? In the boxes tab of the config window, you need to check the “compact format” for each event/birth/death box item.
@Urchello
Your first screenshot looks like the “only display year” option (which overrides the compact date format), which is enabled by default for the “Birth and daeath or fallbacks” item type.
Regarding your second screenshot: Are you sure you checked the option for the item types for the “Regular” Boxes Definition like at the end of my previous post? (You have to do this for each item type and each boxes definition individually.)
After upgrading to Gramps-6.0.0 I noticed that FamilyTreeView can’t be added (yet).
I can imagine that porting the addon to the new version might be a challenge and that it will take some time?
Happy to help with testing pre-releases if necessary.
Perhaps you could inspect the .gpr.py files in the FTV repository of @ztlxltl and comment? It seems like these files might be over-complicated with code that the Plugin Registration module provides. And would you recommend consolidating the five plugin registration files into a common .gpr.py file to simplify maintenance?
Pay particular attention to the tests at the beginning of:
