Is there a way to add a multiple selection list box to the menu option for a report? I only found ones for people and places being implemented, but combined with people/place selectors. I’d like to add one where the items (built-in and custom event types) are already in the list to select.
Is it one of the GTK widgets (illustrated list) listed in the sample code part of the developer docs?
By the way, the Profile mode for the Relationship view by @cdhorn is doing broader experimentation in interfacing view mode Configuration options than anything else I’ve seen. Would his work be applicable to Report options?
@emyoulation GTK has a list box widget and there is GTK_SELECTION_MULTIPLE selection mode, but I need help how to make it a menu option for my report. 
1 Like
You’ve piqued my curiosity. You’ve written add-on rules & reports. Would this interface control be usable with a Rule?
For instance, using the Bookmarked Persons as a rule filter has always seemed like an unwieldy option. There’s no fast way to winnow down or repopulate those bookmarks.
But if this extended selection option could be applied to the (admittedly few) Rules that use bookmarked people, then suddenly those rules would become much more granular & useful.
The Relationship path between bookmarked persons is a specific example.
This rule predates Tags. And changing the rule from Bookmarked to Tags might the better choice. But I’m still curious if this extended selection interface would work insetting Rule parameters?
As a logical extension of the question, would a extended selection option allow building more efficient Custom Filters.
As an example, if I want to filter for any of 3 Tags, my custom filter will have 3 rules, one looking for each tag name, where At Least One Rule applies. This does 3 sequential passes. Would an extended selection allow all 3 Tags to be simultaneously searched in a single pass?
Yes you can speed up multi-step custom filters by rewriting the rules used into one rule instead of several ones, but Gramps could even do better than that.
A huge problem for filtering is the way Gramps stores its data right now. Even in the SQLite database most of the data is stored in handle and pickled data_blob pairs instead of using table fields. Loading the data and checking if the filter applies is much slower than just checking against the table fields.
So for a database with let’s say 10k people and appying a filter takes ~3s:
- 3-step custom filter => total time: ~9s
- 1-step filter with rewriten filter rule => total time: ~3s
- SQLite table fields => total time: <1s
And for a database with let’s say 100k people and appying a filter takes ~30s:
- 3-step custom filter => total time: ~90s
- 1-step filter with rewriten filter rule => total time: ~30s
- SQLite table fields => total time: maybe 1-2s ??
1 Like
Well, the plan is to moved from pickled data to JSON. But the project boss says that is more likely to be in 5.3, not the next 5.2 upgrade.
1 Like
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.