In selection dialogs, allow to directly input a Gramps ID #1431
Conversation
This commit adds an input dialog to the dialog module. This dialog allows to prompt the user for a simple string input.
When a selector is focused, presso Ctrl-O to trigger an input dialog and insert a Gramps ID directly. The Gramps ID, if valid, will be used to populate the reference, bypassing the usual tree model loading mechanism of selection dialogs. This is a proof-of-concept commit. At a minimum, the feature should be made available as a button on selector dialogs, as currently the only way to access it is to know the "magic shortcut" Ctrl-O.
|
The 'OK' button seems like it should actually be an action (such as 'Edit') label ... since 'OK' is usually committing to the database and this dialog is not committing any change. This assumes that pressing 'Ok' currently opens the object editor for that ID. 3 additional possibilities:
|
|
Hi!
Sorry, I'm not sure what you mean by this.
This would be on Edit views, right? Yes, it might be a good idea. I'll check out how hard it would be to do for all views in bulk, but I suspect every single view will need to be changed manually (and then possibly share some code)
As far as I can see this is currently not supported by EmbedLists, which expect a single object (example: CitationEmbedList) Are there any EmbedLists or in general any other instances where Selectors are used, where the user might want to select multiple objects? In general, it's not wrong to allow the user to e.g. share multiple objects at a time, but this is not currently supported (at least not in general, see previous CitationEmbedList example) and it would be a different change/feature. Nontheless, if any such instances do exist already, I would be happy to change this PR to add support for comma-separated ID lists.
This is also a good idea, but imho a different feature than this. Although, a simplified version of this feature that would possibly be a bit easier to implement is, when a Selector is spawned, to pre-select the most recently selected object of that type. That would also pretty much nullify my use case, although maybe different people would still be happy to have the ability to input Gramps IDs directly. In general, zooming out a bit (I have addressed this in more detail in the bug report), the argument of a complete overhaul of the Selector system could be made - with a better search/filter bar, this Ctrl-O feature could be made without entirely, without loosing functionality, and also your recently-used idea could be integrated into it. |
|
As far as the clipboard button goes, ideed it would require changing every single edit view. While it is a good idea, I think it is out of scope for this PR. |
If this is going to augment the "Select Object" dialogs, then the action is to "Select" the object with that Gramps ID. So the button currently labeled "Ok" should be re-labeled as "Select" But the feature to directly key in a Gramps ID is something that already exists in the Filter GUI and most of the custom filter editing dialogs. Right? Is this dialog going to be tied to everywhere that a Share icon currently exists? Or maybe an "Alt" modified click on the Share icons. (Such a modifier would make a "Share" icon suddenly more useful enhancement for adding objects to the clipboard without the overhead of swapping to a different... and possibly filtered... Category view.) An "Alt" modifer-click might make more sense because a generalized Ctrl-O keybinding could be ambiguous for dialogs having multiple Share icons. |
Ah. I thing I see where the mix up is. Apologies, I probably didn't explain myself very well. This new dialog I've introduced can only be triggered from a Selector. So you would first activate the existing Share option in whatever dialog you find yourself in. That causes a selector to pop up, as usual. Then, from this Selector, you can now use the Alt-O shortcut to get the Gramps ID selection pop-up. This is what I have added. In other words, the feature allows you to perform the selection action as inputting a Gramps ID directly. But this PR does not implement it as a separate feature - it's an extension to the existing Selector feature/system. Now, I also see where the Alt-O confusion comes from: I picked Alt-O for the simple reason that it's already the shortcut to use the Share feature in Editors which have a notebook. You can try this for yourself: open any Person, put the focus in any tab of the notebook (e.g. click on any event to put the focus in the event list), and press Alt-O. This activates the Share feature. What I have added, is that you can then press Alt-O a second time to be able to directly input a Gramps ID instead of using the Selector dialog in the usual way. As I've discussed in the linked bug report, this is part of a collection of ideas I had to enable Gramps to be used without moving your hands from the keyboard. This is an especially important use case for me because I get wrist problems and so it's an accessibilty thing for me. As I mention in the bug report, I would be happy to explore this and other ideas further, as well as refactoring the Selector system more in general. EDIT: to clarify, I agree with most of your observations. My implementation works this way mostly for consistency with the existing Alt-O shortcut, but the original shortcut is not very good, not user-configurable, and undocumented in the first place, so everything is open to (a possibly broader) discussion! |
I agree. We should try to make Gramps accessible for people who like to use a keyboard rather than a mouse. This PR is a good idea. There is an existing dialog which is used in views to jump to a Gramps ID. Can we reuse it instead of creating a new one? The best place to discuss your other ideas would be on the gramps-devel mailing list. |
Do you mean the "search mode textbox" feature associated with the Ctrl-F keybinding described in the wiki at: https://gramps-project.org/wiki/index.php/Gramps_5.1_Wiki_Manual_-_Navigation#Finding_records (Well, 'mentioned' might be better than 'described') Note that the "search mode textbox" is VERY unreliable in the Tree view modes. It predictably searches in the selected Sort column for the flat list view modes. But in the Tree modes, that sub-sorting doesn't work predictably and the "search mode textbox" feature seems to do nothing until it times out. That the feature is based on the active Sort column is unclear. (Perhaps the "search mode textbox" label should include the sort column label before the Magnifying glass as a feedback mechanism.) The sort criteria defaults to the first column. Changing to the Gramps ID column requires mousing. Which defeats the keyboard only objective. And this feature has a timeout that makes this feature nearly unusable in large trees. It often times out before completing the search. (It might be that it is trying to be TOO responsive and seeking on every keystroke but not returning control so the text box cannot Display the next keystroke until the seek is complete. It needs to be interruptible... so that another keystroke aborts the previous seek, adds the keystroke and starts a new seek. But also with a delay ... perhaps a 1/2 second... so that the seek doesn't start while the full search term is still being typed.) |
The search feature was indeed my first attempt (as a user) when I was attempting to find keyboard-only solutions for my use case, and I quickly found out that indeed it only works on the sorting column. While it is a predictable mode of operation, I think it is a limitation that should ideally be removed - if not in general, at least in a new and revamped Selector system.
I have also observed this. The database code is not among the code I have investigated for this PR, but I get kind of an obvious question here: why do the tree views (or maybe all views in general) filter on the data by manually applying filters to each rows instead of using the filtering features that are supported in SQLite for the explicitly indexed fields (e.g. name and surname for Person)? Is it just technical debt from when the backend was XML? Nonetheless, even if tighter integration with the backend is not desirable, there are data structures that can perform this kind of filtering very quickly by building in-memory indices at runtime. I'm also subscribing to the mailing list as suggested, to hopefully start a broader discussion about this and other potential improvements. As I've been using Gramps for the past couple years, I would be happy to contribute to the project. |
No. I was referring to the "Jump to by Gramps ID" feature in views associated with the Ctrl-J keybinding.
Unfortunately, at the moment it is embedded in the navigation view at line 330. We should probably reuse this code rather than creating a similar version. Likewise, it seems sensible to use the existing Ctrl-J keybinding used in the views. |
Oh. I had not used that one. Strange that the only category where the feature fails to match a valid ID is the Families category. (Although some other categories appropriately ignore the keybinding: Dashboard, Geography and Chris Horn's experimental Tag CardView.) Filed Bug 0012882: Jump to Gramps ID functionality does not find IDs in Families category (It wasn't clear that it only accepts ID from current view. The Statusbar merely reports "Error: <whatever ID> is not a valid Gramps ID" when it REALLY means that it is not a valid <category> ID. ) It would be more useful if it Jumped Categories too if the ID was a mismatch for the currently category. (Similar to the way CardView jumps categories.) |
|
See PR #1432 for the families |
This has originated from: https://gramps-project.org/bugs/view.php?id=12820
Basically, this patch set is a proof of concept for a feature allowing users to directly input a Gramps ID when making an object selection. I am posting this here at this time to get some additional feedback. Should I also post this on the forum?
Currently, this works by pressing Ctrl-O (the same shortcut for the Share function of notebooks) when a selector dialog is focused, and an input dialog will allow you to enter a Gramps ID.
As commented in the second commit, to reach a more workable implementation, some kind of sign that this exists should be introduced in the selector dialogs. For example, a square button with an icon.