fonol / anki-search-inside-add-card

An add-on providing full-text-search and PDF reading functionality to Anki's Add card dialog
https://ankiweb.net/shared/info/1781298089
GNU Affero General Public License v3.0
179 stars 24 forks source link

Selection able to add only to close card type #217

Open ThrashAbaddon opened 3 years ago

ThrashAbaddon commented 3 years ago

Hello,

First of all, I would like to say thank you for creating this useful plugin. 👍

I have a couple of questions. Sorry for opening an issue for that but I couldn't find any other way to contact you. Maybe github discussions feature could come in handy for these types of things.

Anyhow, my question, is there a way for selection in pdf not to get recognized as input for close card but as input for currently active card type?

I don't use close cards at all but instead only specific questions with basic card that help me pinpoint the context of what is being asked. I've attached a video below so you can see my struggles with the current workflow:

https://user-images.githubusercontent.com/7493180/108594742-0875aa00-737c-11eb-93ab-9552942d29bd.mp4

As you can see in the video I'm using basic card type image

which requires at least two-step selection, first the question, and then the answer. I would expect that for the first selection (when the front of the card is empty) we can see this window asking the user to send the current selection to the front field.

image

After clicking 'Front' button in the window the selection is added to the front field of the card.

The next selection (text or image) opens up a new window

image

where if the user clicks 'Back' the selection is added to the back field of the card.

Maybe something like this is already available but I totally missed it. 🦆

Have a nice day, Daniel

fonol commented 3 years ago

Hi Daniel, Sending unchanged text to fields has been requested multiple times already in some form or another (e.g. lately https://github.com/fonol/anki-search-inside-add-card/issues/208), and I myself could also use that. I don't have a satisfying solution though. I cannot know what the fields that the text should be sent to are named like, so I somehow have to let you send to any field. Which would require some form of selection of which field to send to, be it a dropdown or something like that, which I imagine wouldn't be noticeably faster than a simple Ctrl+C -> Ctrl+V :/. Another idea I had would be to have shortcuts like Ctrl+[1-9] to send the selected text to fields no. 1 to 9. That would be a tad bit more convenient than copy paste I suppose, but it would also mean another shortcut entirely without graphical counterpart, which I'd like to avoid (I reckon most users wouldn't discover the functionality).

p4nix commented 3 years ago

Why not a combination of the two? If you press the shortcut for sending text->field (or a respective button additionally), a small menu appears which asks for which field to send to. The field can also be selected by pressing in the number. Should be quite fast once engrained in muscle memory and still offer the function to point&click-users. Perhaps it is also possible to preselect the latest selected field (for the few crazy users with 9+ fields).

I would like this function combined with an option to also highlight the according text in a preset colour (could be done in the same menu, and auto-selected).

Workflow would be: Shortcut (or button) -> pop-up menu -> press 1 - 9 (or select field with mouse), or [Enter] for preselected field, also, you are able to set a colour (or none) for highlight, an option which will be retained -> voila, text appended to selected field.

If you tell me what you think about this kind of implementation, I will try to code it into. Would you prefer the menu to be web (like the other stuff in the PDF viewer) or QT (which wouldn't really follow the 'design guidelines' lol)?

fonol commented 3 years ago

It sounds nice to me. I wonder if the button should be in the tooltip or somewhere else. I might actually prefer somewhere on the side or bottom, as it would allow to use the functionality with the tooltip turned off and it would be easier to integrate in the markdown viewer as well.

Would you prefer the menu to be web (like the other stuff in the PDF viewer) or QT?

I'd personally prefer Qt, simply for the reason that you can 'start at zero' concerning the hotkeys. In the webview, you'd have to keep all existing shortcuts in mind plus the ones of other editor-altering add-ons. Of course the actual CTRL+[1-9] shortcut would end up in the webview anyway, but in a Qt dialog you could also add shortcuts to select a highlight color. And concerning the design guidelines, I guess that ship has sailed a long time ago^^.

If you tell me what you think about this kind of implementation, I will try to code it into.

Thanks that's nice, I got some free time these days too, so I wouldn't mind doing it either, but if you are already motivated I won't step in your way!