gramps
gramps copied to clipboard
gramps-project
Enable window tracking for ConfigureDialog
This PR modifies the ConfigureDialog and ViewConfigureDialog classes to allow window tracking data to be passed in and adds a parm to ViewConfigureDialog to enable use as a branch rather than leaf.
I required these modifications for the view I have been experimenting with and am currently keeping separate modified copies of these two classes which it would be best not to do.
@cdhorn I'm getting Windows menu entries such as:
"Configure People - People Tree View View..." "Configure Places - Place Tree View View..."
Sorry for delay in responding to this Nick, I am getting reoriented after a hiatus and will try to take a look at this tomorrow.
No problem. I've been busy recently myself. I'll get back to looking at more pull requests shortly.
@Nick-Hall this "View View" is an issue in the existing code today. Some views have View in their window title and some do not. When opening a configuration dialog for a view the code appends View to the title to generate the descriptor for the Windows menu.
If you would like I can remove that and add View to the titles of all the views that do not include it, or leave that and pull View out of the titles of those that have it. Note this affects the add on views as well.
You're thoughts?
Can we insert the distinction between the terms "view category" (or is that "category view") and "view mode" into this conversation?
Gramps has a few places where such important distinctions get blurred. (Like where Filters & Rules have become blurred. There are add-on Rules that are labeled as Filters. But custom filters are a different piece, stored differently. And maybe add-on filters... built on a differently optimized library... are possible future item too.)
@Nick-Hall please review my comment above if you missed it. I would argue since this PR does not change the existing behaviour that should be treated as a separate issue and would ask that you consider this as is. Please let me know your thoughts. Thanks.
I agree that the renaming of existing views should be treated as a separate issue.
Allowing the configuration dialog to be a branch rather than a leaf is a concern. Our users are always complaining about our nested windows. I don't really want to introduce any more.
Potentially there may be a need for a hierarchy of settings in the future. This will probably be best handled by extending the capability of our existing window rather than nesting windows.
I use a copy of this class with these changes in my CardView, and was hoping to avoid needing to keep a one off for that purpose.
Sorry. I'm not willing to go down the nested configure dialogs route. I think that there is a better solution.