gramps
gramps copied to clipboard
gramps-project
Make the tabs columns resizable: ResizableTreeView
Fixes #8767
This was related to https://gramps.discourse.group/t/editor-dialogs-not-remembering-table-spacing/1871 and replace the following PR: #1302
Yes, this seems like a good design.
Perhaps in the future we could store other information such as the column order and sort column. If we want to go in this direction then PersistentTreeView may be a better name than ResizableTreeView.
Have you thought about passing a config object and key name in the constructor?
While working on a User problem with surname not grouping correctly, they posted a screen capture to Facebook.
In the Netherlands translation of the Person Editor, note that the "Personal 1" section label in the Events table is cropped with an ellipsis.
Will this modification allow foreign language users to customize to compensate?
Have you thought about passing a config object and key name in the constructor?
Yes, but I don't know how to do that with glade.
Will this modification allow foreign language users to customize to compensate?
Yes, this is the primary purpose as such this implementation. Once you resize the column, this new size will be kept between gramps session.
Will this modification allow foreign language users to customize to compensate? Yes, this is the primary purpose as such this implementation. Once you resize the column, this new size will be kept between gramps session.
With 56 files being changed, is there a recommendation for how to encourage translator beta testers to try this design and give feedback? I doubt many are GitHub savvy. (Although maybe the lead developers know of a few multiple language developers who could be enlisted to test it?)
Polyglots might find some issues... Like how to share default layout widths for each of their installed languages. Or if something odd happens when reconfiguring the language selection.
With 56 files being changed, is there a recommendation for how to encourage translator beta testers to try this design and give feedback?
These changes only affect the size of the columns. Just test only in a language other than English. I did my tests in French so I know that I haven't encountered any problems so far.
Glad to hear that!
Did you test changing Theme settings? Are the customized column scaled when you choose a larger font point size? Or does it scale the default width? And what happens on a font family change?
(My aging eyes need larger fonts as they grow more tired late in the day. So I may change font sizes a couple times in a long session.)
Are the customized column scaled when you choose a larger font point size?
The width of the columns width is independent of the font. If we want to associate the size of the column to the font size, it is a much more complex problem.
Do your font size very different ? The better would be to set your columns size with your larger font and then use your smaller font.
Some things seems to scale dynamically with the font. But that be a misperception because the row height definitely scales.
I probably won't be using this feature because it would be too many steps to reset before doing screen captures to illustrate the wiki.
(I should start using the PortableGramps for the wiki screen captures. There are too many really useful features that I avoid because of that.)
If we change the font or the font size in the Themes plugin, the column width is adapted to this change.
@prculley For this to work, we need to add one line in the themes.py module.
In the font_changed method, add the following line:
self.uistate.emit('font-changed')
I tested this and it works perfectly.
Been putting the new pull through its paces. One issue has shown itself.
Setting the shared media attribute works. When using the referenced media attribute, it first takes on the column width set by shared. But after leaving the referenced attribute tab it reverts to column widths 1 and resets the shared attribute tab columns.
It seems to be isolated to this tab only in the media records.
I can't reproduce this. Can you attach a snapshot to see exactly what you get ?
Steps to reproduce
Step 1: add media
ia
Step 2 Attach to Family gallery
Step 3 share with individual, tag individual. Add attribute
Step 4 After saving, notice changed spacing in both attribute tabs
Hope this helps
I can't reproduce your problem. Can you attach your gramps.ini configuration file or copy only the [spacing] section ?
The Surname columns (Name edit window) are not being saved once the person's record is saved.
Effectively, you have the following: ... emb_mediaattr=[1, 1] ... emb_surname=[1, 1, 1, 1] ...
If you remove them, can you reproduce your problem. I look at if I can reproduce that.
Manually reset to default settings
;;emb_mediaattr=[]
;;emb_surname=[]
The media attribute immediately changed to
emb_mediaattr=[1, 1]
after accessing the person's referenced attribute tab.
For the surname list in the name edit window, the column spacing was normal when initially accessed and normal again when re-accessing the edit window.
emb_surname=[10, 32, 7, 10]
Once the person's record was saved and a new person edit window and name edit was opened it returned this spacing.
emb_surname=[1, 46, 1, 10]
Once Gramps was closed, it returned this spacing.
emb_surname=[1, 1, 1, 1]
Relaunching Gramps and going back to a name edit window the spacing reverts to
emb_surname=[1, 46, 1, 10]
Note: at no time during these test did I attempt to adjust column widths.
Resizing the surname columns sets the column spacing until a new edit windows are launched which sets them to
emb_surname=[1, 1, 1, 1]
Did some more testing.
I made a clean install of GrampsAIO-5.1.4-1_win64 to C;\ (to keep previous install with my modifications.)
Deleted the gramps51 version folder from the user directory.
Made the changes (manually) from PR1306 to the newly installed files.
NOTE: there was no gui\glade\catalog\ folder and its files. I added them.
I am still getting the same results as reported above for media attributes and the surname list in the name edit window.
Could you create a companion Database Repair tool for this new feature?
If there is an unanticipated failure with these preferences, it would be nice to be able to purge all these values from where they are stored ( gramps.ini ?) without having to manually inspect every line.
There were already instances where remembered customizations have made features of Gramps inaccessible until the customization was ripped out.
Here is a "stored Preferences" example (unrelated to the new stored column width) but representative of the "law of unintended consequences." It was related to remembered window position & size. Values could become invalid when the virtual screen size had reduced since the preferences had been stored. They could also become invalid if the preferences called for using portion of the virtual screen that was inaccessible in a multiple screen configuration. This occurred when removing/repositioning a 2ndry screen or by reducing the screen size. (See bug 11831: [GTK]virtual screen size changes can cause inaccessible windows )
Several changes in virtual screen size could potentially make a column width (previously valid with a different screen/dialog layout) become invalid. Until it gets into wide beta, we won't know what weirdness user configurations can create. Nor how such weirdness will interact with the feature.
The gramps.ini has grown to include too many critical configurations to simply delete it when there is a problem. And it has grown dense enough that selectively cleaning it with Notepad++ is a significant task. It may have grown to the point where Preference dialog controlled choices and GUI drag customizations should be in separate files.
It is unclear if changes committed with an external text editor will be applied during a live Gramps session. If you have to close Gramps to commit external repairs, those repair options become much less accessible. In that case, a Internal Gramps repair tool becomes more desirable.
So it would be useful to be able to have either a smart sanity check tool (or quick&dirty dumb purge tool) for the values stored for this feature in the preferences that is effective without restarting Gramps.
A "smart sanity check" might have a bunch of rules. Perhaps it could compare widths against defaults: when a stored value was <25% or more than 300% of the default, that tab width would likely be an insane value; if the width is more than 50% of the overall screen or dialog width, that tab width would likely be an insane value. A smart tool could have the option to purge potentially insane values but keep the rest. This could simplify recovery from a minor corruption.
If such a tool could be designed for expansion, other hard-to-collectively-manage elements could added. Options could allow them to be selectively purgeable. Initially with a quick&dirty dumb purge option and evolving to include options to selectively clean too.
Expansions to such a repair tool could purge: any Gramps window width (alternately or in combination with height) that exceeds the Virtual Screen; any off-screen window origins; non-primary screen locations; any values associated with an no-longer installed add-on; any excessive Sidebar/Bottombar widths/heights; any Gramplet collections for Sidebar/Bottombar.
I don't save widths for columns. I convert the width to characters. It is easier to resize the columns when you change the font size. I can't know the window size. The problem already existed before this PR. The only thing you can do is either to rename or remove the gramps.ini either to remove the "[spacing]" section in gramps.ini
For standard usage, this should never happen.
Could you also implement this change in the add-on "Plugin Manager Enhanced"?
Once Paul accepts the PR, this would give a broad beta testing opportunity before 5.2 goes to general release.
And documenting this particular evolution would allow other add-on developers to use the PR as reference for adapting their own code.
Rebased and removed pylint changes. We can format the code with black later.
This is almost ready. However, I would like to see a few changes to make it easier to use in the future.
If we pass the uistate, a config object and key when instantiating a PersistentTreeView, then very little code will be required outside of the class.
If we pass the uistate, a config object and key when instantiating
it's OK for an embededlist, but not the baseselector which is created with a glade file. I don't know how to add self.uistate from a glade file. This is why I didn't add that in the PersistentTreeView. Do we need to add optional args ?
It was OK but I think I loose your modifications.
I didn't modify anything. I just dropped the merge commit and the pylint changes.
Your new branch FR8767-ter looks good. Just force push it to FR8767-bis to update this PR. Glad to see that you rebased rather than merged.
I'd still like to see the PersistentTreeView as just a drop in replacement for Gtk.TreeView. All related code should be within the class.
In cases where the TreeView is within a glade file, this will cause a slight problem. I'll have a look at the baseselector code tomorrow.
I had a problem with my local repo. why ? network problem ? I cloned again my repo and now it works.