I think it’s great that there is a built-in option that’s being worked on. One suggestion I would have is to make it handle larger family trees a bit smoother. Right now it’s difficult to view a large portion of the tree, and transitioning across users is done in a very old-school way (click on icon, then click on “set as active”) rather than just clicking once and having the view shift naturally.
Problems are expected for first use of such tools. Don’t worry about that.
This is one of the big flaws of the Gramps addon management. It is too doggone hard to validate the project path!!! (see feature request 13069 : [5.3 Addon Manager] Add ‘valid’ indicator for ‘project’ paths) When it fails to find a usable addons-en.json (or addons.json fallback) file, then you have ZERO feedback where the problem lies.
From what @dsblank has said before, you have to use the following domain to keep the GitHub servers from wrapping the JSON with special content. https://raw.githubusercontent.com
But what REALLY worries me is the ZIP that I downloaded. Extracting the folder gives me something that I can access when I know the exact path or via search. But that is hidden during browsing with the File Manager
from gi import require_version
require_version("Rsvg", "2.0")
from gi.repository import Gdk, Gtk, Rsvg
I thought this requirement is satisfied everywhere. I’m not sure how to fix this on your side. I didn’t get this error on my Ubuntu and Windows test machines.
Do you mean performance / computational cost to build up the tree? This is definitely on my TODO list.
You can configure what single and double clicks do (in the “Interaction” tab in the config window), including setting a person as the active person.
By smooth shifting, do you mean to move the person you just set to active from the position it had in the previous tree view to the center. Currently it “jumps” to the center when the new tree view loads.
I cannot really comment on this, as the ZIP is automatically created by GitHub from the files in the current branch (the files which you can see on the website).
Do you mean that you cannot search files while they are still in the ZIP archive? I guess your File Manager’s indexing skips contents of a ZIP file in that case. (I’m not sure if I understand you correctly.)
That’s a great gramplet.
Thanks for that.
Why do the connecting lines between the generations get longer with each generation? Can you reduce the distances in the upper generations a bit?
Can you please insert a line break for the names?
For longer names, the first names are otherwise abbreviated.
Then there’s an error. If I tick the box for Person under “Number of other families” in the badges settings and then randomly click on the symbol in the tree, the mouse pointer gets stuck on it and can no longer be removed.
The following error message appears:
247604: ERROR: grampsapp.py: line 188: Unhandled exception
Traceback (most recent call last):
File “C:\Users\Woody\AppData\Local\gramps\gramps52\plugins\FamilyTreeView-main\src\family_tree_view_canvas_manager.py”, line 412, in
group.connect(“button-press-event”, lambda *_: badge_info"click_callback")
That’s intended behaviour assuming there are no people missing in each generation. Since the number of ancestors doubles each generation, there need to be many lines connecting two generations if the generation is greater than ca. 7. Since those lines should not overlap and the tree gets wider quickly with each generation, extra space is needed to be able to draw the horizontal part of each connection.
It’s a known problem that this looks silly if there are not all the ancestors with their connections that the extra space accounts for. I plan to extract the required space during the internal dry-run based on the actual ancestors present in the data base.
The abbreviation should be a feature for long names (since the box size and thus available space is fixed), and in all cases I tested, the results were good or ok.
Could you please provide an example of a name that produces unsatisfactory output? (A screenshot of the name editor and the visualization in the tree is probably the easiest). That way I could reproduce it and investigate how to improve it. Linebreaks within names (not at hyphens or spaces) can be quite tricky due to probably complex hyphenation rules.
Good catch! I’ll try to resolve this issue in the next update.
@Woody
I just tried to reproduce this and I don’t get the error (tested on Ubuntu and Windows). Also, this error should not occur since the code line above the one in your error message checks exactly for the existence of the key:
if "click_callback" in badge_info:
group.connect("button-press-event", lambda *_: badge_info["click_callback"]())
Could you please open an issue on GitHub? (I don’t want to spam this thread while investigating this).
OK, thank you. These are not complicated names or anything. It looks more like a line height calculation problem, since the second line isn’t used. Most likely, this is due to screen size/resolution, scaling or font size or something like that. Could you please open a GitHub issue to investigate this? (same reason)
I installed FamilyTreeView. It looks very nice, but has a few limitations I immediately noticed. Here are a few suggestions.
It seems to be limited to 2 generations above or under the active person. Is there a way to add more generations?
I can open the panel with a left or right-click, then “open panel”. Since the left and right-click do the same thing anyway, I think it would be much nicer to open the panel directly on a left-click, and keep the current behavior on a right-click.
The buttons at the bottom of the panel that shows when you click on a person are not always located at the bottom. If there are no information, the buttons can be placed in the middle, which is fine, but if there are a lot of text, the buttons will be outside the window and cannot be clicked:
In the timeline, I’m not sure what the difference between primary and all events is. It always shows the same events.
For some people the timeline looks silly. It looks like all the dates are written at the same position. I think this is because I have an event with an invalid date (this is what I found to denote a negative event “did definitely not happen”). Maybe it’s interpreted as gregorian year 1 (0?), then all other events are shown at the same place.
Also note the “profession” (occupation). In my genealogy, I use the data field of the event to note the occupation name, but it doesn’t show in the timeline. Am I doing this wrong? Maybe the occupation name should go in another field?
I could be nice to be able to open the edit window for events shown in the timeline, and maybe have a button to add a new event to the person, without having to open the person’s edit window.
The close button of the side panel is missing an icon here (using the flatpak version. There are no error messages on the console).
Thank you for your positive and thorough feedback!
In the config window of FamilyTreeView (icon to the right of the house icon at the top), you can increase the number of ancestors and/or descendants. Note that the visualization is not yet optimized for a large number of ancestors and/or descendants (see the TODO list on Github as well as the discussion above).
I plan to implement a context menu on left click, but I can also add an option to open the panel instead of the context menu. Currently you can configure what happens on single and double right clicks, so maybe you can configure one of those to open the panel directly if that improves your workflow.
Yea, this is a known issue (it’s on the TODO list on GitHub). I haven’t found a solution to adjust the info box size to fit the content so it currently has a fixed size and if the content is too large, it overflows. If anyone knows Gtk and/or GooCanvas better than me, I’m definitely open to suggestions and pull requests.
In this case, the person is not associated with events that are not primary events of that person (i.e. all events are primary events). Maybe I should hide this option in the drop-down menu if it doesn’t make a difference.
I had this several times and fixed a few of the causes. Obviously I didn’t catch all the edge cases. You are right about the cause: The date is interpreted as 0 in the calendar used for the timeline. Could you provide more information about the event and especially the date (e.g. screenshots) so that I can reproduce this and fix it?
That’s a good catch. I’ll look into this.
I think you are doing it right. There is definitely potential to show more information here. I’ll look into this.
That is a good idea, maybe I will add a context menu with an entry to open the edit window.
This will cause FamilyTreeView to actually make changes to the db itself (same for the add relative button which does not work yet). It is a good idea, but I think this will require some diligence and therefore time.
I always struggle with using the right icon in Gtk. Maybe someone else knows a reliable icon ID for a close button?
Thank you very much. If you are interested in working on a translation for this addon, you can open an issue on GitHub. I’m not used to how translation works in Gramps but it’s on my TODO list.
True, but I can’t find a method to get the name of the place on a specific date. I need to dig into Gramps’ UI code to find out how this is usually done.
I completely forgot to test with other themes. Since I’m not used to this topic at all, this will take some time to get fixed (by me).
Thanks, I’ll try that when I look at supporting different themes.
librsvg2 is a requirement for building Gramps and accoring to the wiki, you should be able to install it with this (under Debian/Ubuntu and to be able to build Gramps):
sudo apt-get install librsvg2-common
Have you tried this? Does it work? You can also open a GitHub issue if the problem persists.
@Woody
I’ve implemented an alternative distance calculation for ancestor generations that bases the distance between generations on the number of connections to draw between the generations. It’s not 100% perfect, but it’s much better than the previous implementation.
You need to update FamilyTreeView (v0.1.5) and enable it in the config window in the experimental tab.
Once this has been tested more, I will make it the default and remove the old calculation. Therefore, I would appreciate your (and everyone else’s) feedback on this feature.
