I’m cleaning up my database after an import of a GEDCOM file where I inserted a string (“xxxxxx”) into the name field to make sure that I could find all the new people easily.
What I’m doing is finding the xxxxxx people (and PS Gramps keeps finding people that used to have that string, but don’t anymore!), and then showing them in a chart, so I’m sure it’s safe, then deleting the xxxxxx from their name. As I do that, it sometimes happens that the chart will jump to another place. I think what happens is that I delete the last person with xxxxxx from that particular view and Gramps reverts to the last place it used, as if it were using the name to locate the chart, not the ID.
Next time, set the Preferences to add tag in import. After importing, Organize the Tags to move the new Tag to the top of the Priorities and change the Color to something other than Black.
At that point, the new Records will be easily visible in the list views. (You can clear the Tags manually editting each record or just delete the entire Tag.)
What you’re probably seeing is the View re-sorting the ‘just edited’ active record and the focus of the view scrolling to keep that active record visible.
That behavior used to drive me crazy when I would clean a list for some criteria. The list would always be sorted on that criteria I was cleaning.
I came up with 2 workarounds.
First, the View could become VERY sluggish if the filter was complex. For that case, I’d add a Temporary Tag to the results after applying the Filter. Then switch the Filter to that Temporary Tag instead of the Processing intensive complex filter. So long as the Sort column isn’t the column being edited, the view won’t scroll upon committing a change.
Or, I started selecting the next record in the list before clicking the OK button in the Edit record dialog. That way the edited record could move without dragging the active record focus along with it & scrolling the View.
But when I wrote an enhancement request, a developer pointed out that I could use the Move to previous item in history keybinding or Toolbar icon. That moves the focus back up.
Second, I don’t think that’s what’s happening to me on the chart. I’m not sure what’s causing it, but here’s what happens:
I click on a person in person view, then click on Chart on the left-hand vertical menu (what’s that called anyway?) to reveal that person in the pedigree chart (which is what I have set in Charts).
Double click on that person in the chart to edit them, changing their name by removing those x’s.
Close the person window
Boom. The chart resets to another set of people entirely.
Navigation panel or we just say which View we selected.
As to the problem, something similar happens in the Relationship view but most often when adding a new person. There is a bug filed #0011543 on the issue.
The only clue I have is, which person was the last one you navigated to in either of the People views (People or Grouped People)? It seems that when there is a jump to another person like this, it jumps to that person. I have not fully explored the issue to confirm what I am seeing.
In a Charts view, there can be more people visible to jump to.
I never do any editing in any of the chart views so have never experienced any odd behavior there.
I found the terminology to be important for searching the manual. That’s why there’s a Visual Guide to the Interface.
Also, the Gramps Glossary can be helpful for finding the introduction to a Feature. We’ve been adding more hotlinking to let us use it as an index. (Because the search gives FAR too many possible pages… including pages in other languages and for previous Gramps versions.)
In my case it jumps to people who were not visible.
I’m just surprised it would jump at all. I guess it has to refresh the name, but something else must be going on. I’ll admit to not understanding how Gramps decides who to show when you go to Chart view, but clearly it’s something to do with this.
I’ve said this before, but since it’s not possible to search just the wiki (or I haven’t figured out how to do that), I dread going to it to find out info. (OK, “dread” is a little exaggerated, but I do think twice.)
Agreed that it is too messy to search effectively.
I’ve proposed a few things to suppress false positives. But they all entail modifying the archived obsolete pages with a Magic Word template. That’d be a LOT of work.
Does anyone know any SEO (Search Engine Optimization) tricks to give precedence to our 30-ish main wiki chapters for the current version & English?
Can’t. Those pages are linked from the Help in the program and in many Gramplets. Both can be version specific & language specific forms.
So, even if 5.1.3 is the current version of Gramps, we cannot archive all the older version wiki pages. Doing so would break the Gramps Help for any user staying with an older version. (Sometimes users will not update because of OS incompatibilities, having customized the older Gramps modules, inertia, or any number of reasons.)
Well, maybe just dump the older versions and archive them somehow (which they should be anyway)? Accessing old help files from within an app is a developer problem that’s being made a user problem.
I’m a fairly sophisticated user and the fact that searching on the webpage normally gets me multiple foreign-language pages and usually no relevant wiki pages means it’s de-facto broken as is, even if there’s some voodoo I can put into the search box to get it to work. I shouldn’t have to. Searching the wiki should be easy. As wikipedia says ‘wiki is a Hawaiian word meaning “quick.”’ The gramps wiki is far from that.
By definition, the wiki is a user problem because it is user built & maintained. As an Open Source project, we don’t have professional wiki Developers… or even program Developers. We’re all Users contributing our efforts.
And the ‘wiki’ part was in reference to quickly built webpage content, without compiling or needing lotsa web tools. It has nothing to do with quick USE. In fact, Wikis are usually the opposite because they grow organically & haphazardly.
OK, I’ve figured this out, for at least some of the jumping. Here’s the bug report. And here’s part of what I wrote there:
To recreate the bug:
Have some kind of filter in the Person view so that not everyone is showing.
Select person one in the Person view.
Switch to Graph View with person one now in the center.
Double click person one to edit.
Edit person one so that they no longer meet the filter criteria in Person view.
Close edit window to find person two now at the center of the graph view.
What happened?
Person two was the next person in the filtered Person view list. When I edited person one, they disappeared from the Person list and person two was next in the list and therefore apparently became the active person.
So the way the active person is selected, being removed from a filtered Person view means you cease to be active, even when the Person view isn’t visible. In other words, the active person is determined by who’s selected in the Person view, even when that view is invisible.
That seems like a bug to me. The active person should stay active even when they’re being edited. I fear that having the selected Person-view person be the active person (and vice versa, the active person must be selected in the Person view) may be hard to change.
You can get the same type of behavior when filtering IDs in person view then changing the person ID in relationship view. Active person disappear from relationship view when you close it and jump to the next filtered person.
I think it’s the same behavior in any view when what you change is a criteria of the filter