DescendantSpaceTree addon - initial development

@emyoulation Slight wiki edit to move “Features” into the table of contents.

I’d like to add your suggestions as feature requests after getting the initial version out. Colors are a little tricky, so I might want to just have a “light” or “dark” choice. The colors of the div containing the canvas and graph nodes and edges are in the source webfiles/html/descendant_tree.html and webfiles/js/tree_base.js, or the proto/descendant_tree.html. In the meantime, these can be edited and re-generate the proto/descendant_tree.html file.

I’ve added a section on the wiki page to capture some of these ideas - thanks!

1 Like

Initial version published on gramps60 branch.

2 Likes

added Descendant Space Tree to the 6.0 addons list table.

The addon adapts to 5.2 by just changing the gramps_target_version in the registration.

Could you release a backport?

Great add-on, Thanks!
The link in the help button does not resolve for me to a report-specific wiki page right now. It just goes to the higher level web-page reports spot. It’s publishing as a distinct wiki page may be delayed until this web-scraping nonsense passes, but I thought I’d let you know.
brian

1 Like

Please consider adding:

@gramps-project and @Nick-Hall

Does Cloudflare redirect URLs? Or is something else happening? I have not tried enough Help links from addon Reports to determine if the help_url for the Report category is intercepting and redirecting to the generic location.

The Addon Manager uses the help_url in the wiki link :

https://gramps-project.org/wiki/index.php?title=Addon:DescendantSpaceTree

The Help link when invoking the Report does NOT use the help_url, but uses :

https://gramps-project.org/wiki/index.php?title=Gramps_6.0_Wiki_Manual_-_Reports#Descendant_Space_Tree

which does not exist.

The only Web Reports that have entries in the Reports wiki are the default (non-Addon) Narrated Web, Web Calendar, and Dynamic Web. So any Addon Report (whether Web or Text or …) will exhibit the same behavior.

I suggest you submit a gramps Feature Request for how to handle the Help button for Addons in the Report window.

This is a bug rather than a feature. It is supposed to detect “Addon:” and append that to the index.php instead of redirecting to the generic reports list.

(It is the right time since @SteveY is tweaking instances of help_urls that are incorrectly marked as “translatable” strings.)

Have to check the Tools too. They have a similar hlep_url parsing logic.

Just to follow up. When you make a determination of the scope of the potential bug let me know and I will file the bug report,unless you want to.
brian

There a 5 separate places where the linking needs to be checked:

  • the Help button in the report configuration dialog
  • the Wiki button in the Addon Manager
  • the help button in the Plugin Manager (built-in)
  • the help button in the Plugin Manager Enhanced (add-on)
  • the Help button in the Reports selector (dialog opened from the toolbar button)

If the problem only occurs from the report configuration dialog, then the problem might only be in the addon coding.

Then the 5 tests need to be repeated for another Report and another Tool add-on

I think this is in the base class ReportDialog : gui/plug/report/_reportdialog.py

and impacts all report types. This is not code that is specific to an addon, but in gramps core.

def on_help_clicked(self, *obj): 
    from ...display import display_help, display_url
    if hasattr(self.options, "help_url"):
        display_url(self.options.help_url)
        return
    display_help(URL_REPORT_PAGE, self.report_name.replace(" ", "_"))

The on_help_clicked() function does not have help_url in self.options, so uses the fallback URL_REPORT_PAGE.

1 Like

Just doing a bit of a survey I find that it is a very common phenomenon, but quite spotty.
I chose AncestralCollapsibleTree and it works in the add-on manager reports selector toolbar, but not from the dialog nor from the built-in Plug-in manager.

next I chose DynamicWebReport; It works from the dialog and the Add-on Manager and the reports selector toolbar but not from Built-in plug-in manager.

lastly I chose TimelinePedigreeReport; not working from the dialog nor the built-in Plug-in Manager, nor from the reports selector toolbar but working from add-on manager.

I speculate there might be some ‘hard-coded’ workarounds at work compensating for the core problem(s) and that these workarounds, too, may need some addressing (correction/removal ??)

Finally, I noticed that DescendantsSpaceTree does work from the report-selector toolbar further indicating the issue(s) may not be within the app itself.

I hope this helps a bit.
brian

1 Like

I was wrong it IS an Enhancement Request.

The Addon Manager and Report have been modified to recognize the “Addon:” help_url pattern.

The other spots are going to have to be enhanced and the changes might be more extensive than seem at 1st glance.

In Firefox on Windows (and as far as I know every other browser on Windows) the background of any webpage will not print by default. You have to tick an option in the FF print dialog if you want to print a web page background.

Can anyone else reproduce this..?

  • Display the space tree
  • Make the browser full screen (for me using Firefox on Windows that means press F11)
  • Now click and drag the tree to reposition it in the middle of the (apparently) larger window that shows the tree
  • The tree can’t be moved to the bottom of the window, i.e. the window doesn’t actually get larger when the browser is full screen, it only appears to get bigger. In which case, the background of that bit of the page should be white, not black.

But no matter how you look at or print, it doesn’t render in its best form. If it prints without the background, the connecting lines are pale yellow tubes with black noise.

If you print with the background with an inkject, the paper is so saturated that it becomes wavy.

I am noticing this. Using Firefox on Win10.

If the initial browser window is less than full screen when when clicking on the spacetreee.html file, and then go to full screen (F11) the bottom third of the space is blocked for use by the tree.

Again if the browser window is less than full screen, maximizing the window, the bottom 15% is blocked for use by the tree.

If the window is already maximized before clicking on the spacetreee.html file, the full allotted space is usable by the tree.

The blocked space is proportional to the initial allotted space based upon the size of the initial window. Start with a smaller window, more of the allotted space after maximizing the window becomes unusable by the tree.

The same phenomenon is seen in the right margin of the allotted space.

It might be that the black backdrop is for dark mode and the CSS is not adapting to a light mode setup?

In the following screen shot, I manually edit default infois div background-color from #222 to #eee in the generated .html file.

<table style="height: stretch;">
  <tr>
    <td style="width: 16%; vertical-align: top;">
       <small>
       <div id="log"></div>    
       </small>
    </td>
    <td style="width: 84%; vertical-align: top;">
       <div style="background-color: #222; vertical-align: top; height: calc(100vh - 150px);" id="infovis"></div>    
    </td
  </tr>
</table>

Thank you for confirming it’s not just me.

I’ll take your word, I’ve not tried, but I can imagine printing the background wouldn’t end well :grin: