I think filtering would be rather complex since it would have to be implemented in dozens of parts of the code. Thankfully, Gramp has a feature that, in my opinion, is better suited as a “universal” filter, which would affect people, families and events: “Proxy Databases.” Fortunately, FTV already supports these with its “Presentation Mode.”
However, to achieve an “as-of date” visualization, a dedicated proxy would need to be implemented to check the dates of events of people and families, as well as handle edge cases, such as range dates and missing dates. The advantage of a dedicated “as-of date” proxy would also allow other views, reports etc. to easily support it to create outputs based on the specified date. Wherever there is proxy support (often labeled as a “living people” option), adding support for the new proxy should be easy.
P.S. According to my TODO list, you suggested this feature here back in December of last year. Now that filter support and the Presentation Mode have been implemented, it’s worth revisiting these types of feature requests. So, it’s appreciated when old ideas are brought back for discussion!
Both the GraphView and FamilyTreeView use GooCanvas which is now obsolete. It is unmaintained and not available in Gtk 4. As such I don’t think that either of these addons are candidates for inclusion in Gramps core without conversion to a newer supported technology.
FamilyTreeView could be included in the third-party addons repository for greater exposure. GooCanvas is available in our Snap, Flatpak, Windows AIO and Mac bundle.
If there is interest in moving FamilyTreeView into core Gramps, then I am certainly willing to suggest an integration path.
Today I created a new wiki page “Addon:FamilyTreeView” and started editing this page.
From my point of view the FamilyTreeView is the most important addon, but it has not been documented.
I created headings for the different parts I wanted to document, like installation, configuration and usage.
This was only at start.
Now someone has deleted all except for a screen dump.
This addon is unreleased and does not point to the wiki, the developer will decide when it will be added to wiki, so for now I’ve adjusted the documentation to point to his development page.
Yes, wiki pages on new (and changing) addons or new releases can be very challenging. After several frustrating sessions of wiki-contributors working at cross purposes, I put together a “work in progress” template that asked other contributors to refrain from editing until a specific date. (Our issues were that people tweaking the text for grammar were reverting the major edits fleshing out the rough outline.)
We didn’t ask if @csam hasn’t already been in contact with @ztlxltl about creating an Addon: wiki landing page for the gpr.py file. That’s one of the preparatory steps for a general release.
Wikicontributors often offer to relieve the developer of learning mediawiki markup idiosyncrasies. We can adapt the GitHub README.md docs.
Because the “recent changes” special page draws the attention of all wikicontributor, it often creates a situation where people work at cross-purposes… each with the best of intentions. I found it necessary to add a “work in progress” notification box while fleshing out an outline. This lets other contributors avoid messing up a roughing in of a new wiki page.
{{man warn|1=🚧 Work In Progress|2=This wikipage is an outline from a template being roughed in. Please don't edit '''''just yet'''''. Instead, contribute suggestions on the Discussion page. <br /><br />This page is not planned be linked to a public page until about {{safesubst<noinclude/>:CURRENTDAY}} {{safesubst<noinclude/>:CURRENTMONTHNAMEGEN}} {{safesubst<noinclude/>:CURRENTYEAR}}. <br /><br />If this notice remains after that date, please feel welcome to remove this notice and consider the content 'fair game' for unlimited editing.}}
Thank you for your efforts in documenting FTV. I’m open to accepting help with this.
But: Providing a wiki page that that isn’t clearly identified as a draft requires regularly updating the page. Since FTV has many options, keeping the documentation of those options up to date and complete will require a lot of work. People may become confused if the wiki page is not up to date in case the development is faster than updating the wiki page. Also, a finished-looking wiki page may suggest that the addon is finished and stable. However, it is definitely not finished yet. Any update may cause it to become (more) unstable, as there are currently no Pull Requests with reviews in order to publish new features early for testing of new beta versions.
Some things can be documented now because they won’t change much. However, there will be some things that will change in the future. It doesn’t make much sense to write detailed and comprehensive documentation yet, but if you are motivated you can write the documentation somewhere else (e.g. on a Users page or in a file on your computer). Once no more major changes are planned, your prepared draft documentation can be copied over to the main page, which will then also be linked in the addon. If you create a Users page on the wiki, make sure to add a warning that your version is a draft.
From my point of view, what is actually doable right now is adding a section to the wiki page that lists solutions to problems, answering questions like “Which configurations do I need to change to achieve …?” This is somewhat the opposite to the usual way of documenting configurations, which answer questions like “What happens when I change this configuration?”. I think it’s much more efficient in terms of the effort required to document (and update) it and the value for the user. As long as the main wiki page clearly states that the addon and the wiki page are works in progress, this would be okay in my opinion.
Because the 2 threads for the FamilyTreeView are absolutely HUGE (over 250 postings in each) having a Wiki article that talks about installation would be helpful.
Key points for avoiding manual installation:
installing pre-requistite
Using the Addon Manager’s Projects tab for adding the path to curated FTV addon collection (for both Gramps 5.2 and 6.0)
Yes, you are right. The method using the Addon Manager could be explained, as long as it’s clearly stated that the addon shouldn’t be considered stable yet.
I hope I can release the next big update soon. That would be a good point at which to start a new thread.
As the content of your previous revision seems only hidden, page was not deleted, maybe just currently modified?
FamilyTreeView is installed via the Addon Manager. However, since FamilyTreeView has not yet been released as an official add-on, installation requires to create a new project in the Addon Manager.
Open the Addon Manager and select the Projects tab.
Click the [+] to add a new project
In the New Project window name the project "FamilyTreeView" and in the URL field enter "https://raw.githubusercontent.com/ztlxltl/FamilyTreeView/dist/gramps60"
Click [OK] to save the new project
In the project list be sure to check the FamilyTreeView checkbox
Select the Addons tab
In the Filters line change the second drop-down box to "FamilyTreeView" and change the last drop-down box to "All statuses"
Click [install] on the FamilyTreeView line. Note that all listed modules will automatically be installed.
Close the Addon Manager
You might also want to install the Graph View addon. When Graph View is installed FamilyTreeView will automatically use Graph View's search bar.
This public discussion has opened the path to change policy on pruning wiki addon pages. And has public endorsement of the addon author. (Underlining that developer endorsement for collaborative documenting pre-release feature. The endorsement establishes which WikiContributor is the “lead”.)
The content has not been deleted. We showed how the content can be recovered from the history and established boundaries so that it won’t be deleted in the same way.
However, since you didn’t remove the content, it seems fair that you not be responsible for restoring it. If you like, I can go in sometime in the next hour to do so. (It is important to coordinate such efforts because MediaWiki doesn’t have document check-in/check-out management. It is all too easy to work at cross purposes.)
I see that had already been done yesterday. Thanks @gramps-project ! The site is currently in the process of backup. You should be able to work on the Addon page again shortly.
Millions of MediaWiki users don‘t miss a check-in/check-out function. It is perfect as it is. Deleting content provided by others isn‘t good style. Restore it, please. Then it can be optimized. It doesn’t matter if it is released or not. Add a remark on the beginning of the wiki page „not released up to now!“
Since I started using Gramps 6.0.7 and Family Tree View, I’ve been getting this error message.
2915792: ERROR: grampsapp.py: line 188: Unhandled exception
Traceback (most recent call last):
File “C:\Program Files\GrampsAIO64-6.0.7\gramps\gui\widgets\persistenttreeview.py”, line 90, in save_column_info
if self.config_name == “undefined”:
^^^^^^^^^^^^^^^^
AttributeError: ‘PersistentTreeView’ object has no attribute ‘config_name’. Did you mean: ‘set_config_name’?
This happened when I accessed a person mask via FTV and edited a location there.
