Yes, that is better, thank you.
Although I don’t think 6 visible items is too much. It is also awkward to scroll the list vertically. What do other people think?
1 Like
I replaced 6 for MAXITEMS with 10 now that we have the scrolling window
I like 10 items … possibly with a 6 item scroll window.
10 items because that corresponds with the Go menu limit. (Maybe the 2 features could use the same reference file? That would fix the long-standing problem with the Go menu not including a just created New Object. This oversight severely undermines the value of the Go Menu)
MAXITEMS 12 and 3 in the scroll window. Sometimes the bottom scroll (L ↔ R) hides the bottom item. 3 in the scroll keeps 2 always visible.
Whatever method is found to avoid hiding the bottom item should be applied to the views too. (possibly add a dummy last row after sorting?)
see 0013363 : The last row is hidden by horizontal scrollbar everywhere in the app
All True. But as of today, having a 3 line scroll guarantees at least 2 are always seen and if/when the bottom scroll is solved a 3 line scroll is not too many.
A 3 row vertical scrollbox seems too small. The lack of visual context converts the GUI from feeling like a ‘scroll’ to feeling like a ‘page’ or a ‘jump’. It is too disorienting.
This is a Gtk standard and not a gramps problem.
If you want a correct display, enlarge your window.
Gtk cannot change the height of the current window, so it uses the bottom to display the scroll bar and thus we have this last line which can be unreadable.
If you don’t want this, you can actually use GTK_OVERLAY_SCROLLING=0
I figured it was a Gtk issue. But the Gramps developers have compensated for widgets that didn’t mesh well before.
That’s why I suggested a blank dummy line as a workaround. It should make the last REAL row fully accessible without real impact on anything else.
If the oddity of double-clicking a row not being compatible with opening an object editor causes a problem, maybe it could open a new object dialog?
Impossible to do. How can we add a blank line in a scrolled list with hundred of rows.
The best would be to implement our own GtkScrollable, or perhaps by creating a GtkOverlay and putting a GtkScrollbar on top of the GtkScrollableWindow and mapping those scrollbar actions to the window.
very difficult.
I suggested the same. The last empty line will fix the problem.
1 Like
I now put an intermediate Gtk.VBox between the ScrolledWindow and the TreeView and added some padding. This seems to help with the “last row problem”:
sw = Gtk.ScrolledWindow()
sw.set_policy(Gtk.PolicyType.AUTOMATIC, Gtk.PolicyType.AUTOMATIC)
sw.set_max_content_width(3)
vbox = Gtk.VBox()
vbox.pack_start(tree, False, False, padding=15)
sw.add(vbox)
recent_box.add(header)
recent_box.add(sw)
recent_box.show_all()
Also increased the height of the window and increased MAXITEMS to 10.
By the way, what is the purpose of the set_max_content_width(3) call?
2 Likes
These are the maximum visible items in the scroll window.
If you set 4, you will have four lines visible.
1 Like
Post from Geneanet: Re: version 6.0.0 by glopglop » 27 Mar 2025 04:39
If you’re using the experimental recent-item addon,
This one no longer works in Gramps 6.0.0, and I have a feeling we won’t have an equivalent for now.The author won’t be porting it because he ultimately thinks it’s necessary to do things differently.
So this is something to consider before migrating.
@kku Would you consider revising for 6.0 ? Even though you might be right about using a different approach. But that wouldn’t be until 6.1 at the earliest.
After using for any length of time, the lack of this feature in 6.0 is a compelling reason to not upgrade. It makes that big of a difference during data entry within family groups.
There needs to be a workaround for the current version.
Could the approaches of both @kku and @SNoiraud be installed and allow switching between? There seem to be differences in potential value. And the comparative workflow improvements are hard to gauge without “use” testing. Maybe it is possible to implement the best of each?
(I suspect that the reason Serge’s approach has had so few comments is the difference between a patch and an add-on. From the description, there are added benefits. But patches are scarier to users and harder to revert. So an add-on gains much acclaim while a patch has little notice. This validates the wisdom of the add-on concept.)
I will update “recent-items” to work with 6.0. Might take a few days.
4 Likes
Thank you very much! The prospect will make many people happier.
1 Like
I agree with Brian.
“recent-items” is really a great addition to Gramps and thank you very much Kari for this addon.
I m impatient to see it in 6.0 but i will be patient.
As we said in France
“tout vient a point a qui sait attendre”
Concerning my post on geneanet most of the user there are non technical and don’t know how some problem are difficult to solve.
And i knew that some use your addon.
Then it was an advice to consider the pro and cons of the migration to 6.0.0.
2 Likes
It seems…
More global, this could match and close many bug reports listed into:
I did not test the “Recent” sub-menu addon (yet).
During experimentations (GEPS41) and after decrypting my comments (I like breadcrumb trail for history and get a way back!), maybe one or two improvements could be added (explorer ?) on core gramps or on this addon.
- to get a group of recent items. Only for display. When will ‘recent’ start and finish ? After one year, we may get a complete list without filtering… I thought on a simple:
last = today
group1 = from today to 1 week back
group2 = from today to 2 weeks back
group3 = from today to 1 month back
group4 = from today to 6 months back
group5 = more than 6 months back
- to make focus on the recent object (if exists) into the Selector.
Something like:
active_handle = uistate.get_active(self.object)
...
BaseSelector.__init__(self, dbstate, uistate, track, sfilter,
skip, show_search_bar, active_handle, expand)
It sounds not natural, but during a large edition session, we know that we often make the same records active (cross objects). Also, even not fully exact, we know that already matching a correct surname for individuals (or families), to get a shared event (or very close), to get a citation into a source, or just the place hierarchy might already make the selection action much (more?) faster.
1 Like
Without @kku “recent-items,” it’s much more cumbersome to enter data in Gramps. I’m glad you’re upgrading it for Gramps 6 as well.
I think it should be a permanent feature of Gramps.
2 Likes
A “recent-items” improvement to the Object Selectors AND the Go menu would be quite welcome.
The Go Menu is probably under-utilized because it seems quirky. (Last Active objects are added to the menu but newly created objects and objects modified via object editors are not added.) The recent-items menu is more consistent and predictable.
Some harmonizing these 2 features seems appropriate. It would simplify maintenance to have only a shared code module and cached list of recent objects too.
A frank discussion of the benefits/drawbacks of both Kari’s and Serge’s proposals is probably the next step? Can a combination completely fulfull GEPS 41 and close it out in the Gramps 6.1 version?