@stuck
Yes, you are right, this is on my main todo list (which is still huge). Because the new box configuration feature is so complex, I used a separate list (“my todo list for this feature”) to keep track of all the box items, item options, bugs, etc. that still needed to be implemented/fixed before the update was released. That’s also why it took several weeks to finalize.
Since it seems to be important for you and @emyoulation, I’ll try to implement it today.
@Woody
FTV is not translated yet (which is on my todo list). But according to this discussion, you should be able to install any addon even if the translation for your language is not available:
Please note that this could be an issue with the addon manager:
According to the screenshots, there are many users who use different languages who haven’t reported these problems with the installation, so the problem may be somewhat specific.
If you are only experiencing this problem with FTV and no other addons that are also missing the German translation file, you can open a GitHub issue and we can try to narrow down the cause. Maybe your setup represents an edge case that the addon should handle and FTV doesn’t.
Still impressed by the improvements in v0.1.65 and v0.1.66 that trigger new expectations
Maybe I’ve missed a setting somewhere, or maybe there’s an add-on, or maybe it’s impossible, but it would be a nice option if names could be rendered in bold font (as I try to show in attached manipulated pic).
I think there is a misunderstanding here. You should not change the code.
The code in your screenshot on line 226 shows that it always adds “en” (English) to the list of languages that Gramps looks for. If there is no language file for your preferred language, Gramps should always try to get the English version of the addon. I’m not sure why you get the error, since the English language file is available for FTV.
Maybe it’s best if you create a new issue so I can help you investigate the issue without spamming everyone who gets notifications from this thread.
Please check the last filter in the Addon Manager. It defaults to “Stable” while FamilyTreeView is “Beta”. So you should select “Beta” or “All statuses” in order to view it.
Since the last version discussed here (v0.1.67), there has been some progress over the past week. Those who have been following the issues on Github may have noticed that @emyoulation has been testing some experimental features this week.
List of enhancements and bug fixes between v0.1.67 and v0.1.80 (=latest):
A progress popup to show the progress while building the tree. The cancel button stops building the tree and displays the unfinished tree.
Gramps should no longer freeze when FTV builds the tree.
New experimental option to prune parts of the tree based on the sidebar filter. This allows you to create custom diagrams using Gramps’ versatile filter system.
An example using the “Relationship path between <persons>” filter:
(The option “Gray out people who do not match the sidebar filter” is also used in this screenshot.)
Information about the number of visualized people is displayed in the lower right corner in the format <people in tree>/<people in db>. If a filter is applied, it also shows how many of the filter results are visible in the tree.
(The tree shows 44 people, there are 29068 people in the database, the filter matches 23 people in the database and all 23 are visible in the tree.)
Improvements to filter performance and error handling.
(The filter badge is still very slow. To speed up this badge, the badge interface needs to be reworked. Currently it is not recommended to use this badge with complex filters and large trees (e.g. many generations).)
New person box item types:
Relationship to active person or home person (e.g. father, mother, son, daughter, etc.)
Generation number
Ahnentafel number
New configs to change the line width of connections and box outlines.
Performance improvement. FTV seemed to rebuild the tree even when it wasn’t visible. This is now fixed.
The minimap now stays collapsed when the tree rebuilds.
Person Filter Editor is accessible from the Edit menu.
The adaptive ancestor generation algorithm is now enabled by default (e.g. for new installations).
There are some known issues:
Sometimes the tree isn’t centered on the active person. This happens randomly so it’s hard to debug.
If the current active person is not in the filter results, it would be nice to have a list of filter results to jump to make one of them the active person.
I’ve only tinkered with v0.1.80 for a few mins but it seems that the tree fails to centre on the active person when a filter is set, and when a filter is active it places the active person in the top left corner.
For example, if I set my oldest known ancestor as both home and active then the tree looks OK, that person is centred. If I then apply a simple ‘gender=male’ filter, using the Filter Gramplet in the left hand panel, then when the tree rebuilds it places the home & active person in the top left.
If I then click reset and find in the filter Gramplet then, when the tree rebuilds, it puts the active/home person back in the centre.
A solution for that is still being discussed. A couple approaches will probably be piloted.
My current workaround is to used the same filter in the flat list Person view. And use it to change the Active Person focus.
I also discovered that the Filtering can become VASTLY more efficient if you make a Filter that uses a list of Person IDs instead of the custom filter. This is most appropriate with a tiny set like the cousins example. (In a tree with 29K people, the search time went from 8.79 seconds to 1.66 seconds)
It is a bit involved… but worth the effort if you will be exploring in a huge tree:
copy the results from the filter to the clipboard, select all in the clipboard, use the context menu to create a Custom Filter from the clipboard list, edit the rule to copy the list, cancel the custom filter, clear the Charts Filter gramplet, paste the list into the ID field, select the “Use regular expressions”, Find
The list of 27 IDs for my test looked like: ^I000206$|^I000207$|^I000210$|^I000320$|^I000388$|^I000389$|^I000390$|^I000391$|^I000392$|^I001725$|^I001729$|^I001748$|^I001877$|^I012588$|^I015524$|^I017759$|^I017761$|^I022095$|^I023283$|^I023285$|^I023287$|^I033894$|^I033896$|^I033900$|^I033910$|^I033915$|^I033921$
(The colors were made more pale in Edit → Preferences → Colors, Names were made Bold, and the “Compact” Box outlines were changed to 0.5px hairlines instead of 2px in the View → Configure…)
@emyoulation
I think @stuck is referring to a different issue than you. (Please correct me if I’m wrong!)
My understanding is that @stuck is talking about the active person being in the top left of the visible part of the canvas. The whole tree needs to be scrolled a bit down and a bit to the right to properly center the active person in the middle of the visible part of the canvas (i.e. the first item in the “known issues” in my post earlier today). @emyoulation is referring to the second “known issue” in my post (i.e. the active person is not ideal to visualize the filter result).
I have been trying to find a fix for this for several hours. The only way to get it to work (apparently reliably) was to implement a not-so-elegant workaround. (@stuck please test v0.1.81)
I would love to get help from someone who knows Gtk/GLib better than me to debug the problem and come up with a better solution: