Keyboard shortcut to find images by name in registry?

From SuperMemopedia
Jump to: navigation, search

Question

What is the keyboard shortcut for the Find feature in the image registry? It seems to be CTRL-F but that only seems to work intermittently -- about half the time when I open the image registry and press CTRL-F I get the Find Elements dialog. This is extremely disruptive because I'm trying to add cards very quickly. I can add a card and apply a template in the space of about two seconds, then select an image component and bring up the image registry from the right-click menu, and then I want to CTRL-F to find the image and hit ENTER. But when I do this, sometimes CTRL-F lets me search for the image, and sometimes CTRL-F brings up the Find Element dialog, and since I'm typing very quickly then when I type in a partial name and hit ENTER expecting SuperMemo to retrieve a list of images it instead sometimes retrieves a list of elements and takes me to the first element in that list. Then I have to open the Contents window and browse until I find the node I had just created, then start over.

Keep in mind this is happening because I'm trying to add cards as fast as possible, but I can't trust the software is working correctly. Maybe I'm using it incorrectly but if so it isn't clear.

Also, since upgrading from 2004 to 16, when applying a template and selecting an image component with the mouse then pressing CTRL-SHIFT-K nothing happens. I have to use the right-click menu to enter the image registry. After I have added an image and navigated to another card, then come back to this card, then I can CTRL-SHIFT-K to bring up the image registry for that component.

Answers

Searching for pictures

Use Ctr+S to search for pictures. You will get them in a subset. You can then search again to narrow your options (if necessary). Click "Insert" and your picture should be in the element. Fast is good. Please keep reporting similar situations. Ctrl+F in the registry is so unimportant than it should perhaps even be removed to prevent confusion?

Comment

I disagree that it should be removed. Instead I vote that CTRL-F be bound to the image search function when in the image repository. CTRL-F is a universal keyboard shortcut and one of the first shortcuts most people learn in most applications. CTRL-F meaning should change based on context. When the image registry is open, is there any purpose to allowing the user to find elements? Given your statements that it seems useless in that context I believe the answer is no. Then the user should be rewarded for using a common keyboard shortcut that means "find something *in this context*" which in this case would mean pressing CTRL-F when the image repository is open would execute an image search. Likewise, when the image repository is not open CTRL-F would execute an element search. Etc. A fundamental principle of application interface design is the Principle of Least Surprise: https://en.wikipedia.org/wiki/Principle_of_least_astonishment <-- CTRL-F executing element search while image repository is open violates this principle, and blocking CTRL-F while in image repository also violates this principle. Unless there are a great many users who use CTRL-S constantly? Which I doubt is the case. And even so, how many would prefer to use CTRL-F in a context-dependent manner and free up another keyboard shortcut for some other purpose?

Ctrl+Shift+K

If you click on the image, it should enter the dragging mode. Ctrl+Shift+K should then work. If it doesn't, it sounds like a bug? Or interference from other components (e.g. taking over focus on activate on mouse move?).

Comment

I can confirm that clicking on the image does not place it in dragging mode. Clicking on the image and then pressing CTRL+SHIFT+K does not open the image registry -- it does nothing. Just in case this is a bug I'm including the below steps I follow that consistently trigger this behavior.

Steps:

  1. Create new element with ALT+A
  2. CTRL+SHIFT+M to switch to a different template -- type in first letter of template name, then use down arrow key + ENTER to select the template to apply.
  3. Once returned to the new blank element with the template applied, left-click with mouse on the image component then press CTRL+SHIFT+K
  4. Expected Behavior: Opens image repository
  5. Actual Behavior: Nothing happens

There is no overlapping image components. Here is a picture of a blank template that is affected by this: http://imgur.com/uhY3cDv

The image component is the large one to the right. At some point the template started using the top image in the right image component, not sure why that happened but since I pick a different image each time or paste in a new one that particular issue is not really a problem, just an annoyance.

Additional Bug?

I just now ran into an issue where all of the elements that use another template were just altered. The template contains two HTML and two image components, so I can ask a question and show an image during the question phase, and then reveal the answer and related image during the answer phase. The image components were moved around for all of them, one of the image components was resized to be almost as large as the entire browser window, and the other image component was resized much smaller than normal and moved partially behind an HTML component. **I did not change anything in the template, and did not resize the components in an element.** All I did was create a new element, CTRL+SHIFT+M to apply the template, then select and paste new images into the image components and type in a question and answer. After doing this successfully for two or three elements in a row, suddenly the next element I created from that template had its components shifted around. It happened automatically.

Also, when I went back to review other elements using that template, about half of the elements using that template (not all, only about half) had replaced the original image in one of the image components with a "header" image I've been using on all the templates for this category. There was no warning from SuperMemo that this was happening, it just happened automatically. I will have to go back through all of my elements for this template and try to figure out which image was supposed to be in which element, and re-link them.

This is extremely frustrating. So far my experience with SuperMemo has been to get "into the groove" with adding elements, and then suddenly have SuperMemo suddenly change something without my knowledge, expectation, or consent. This means I spend half my time wrestling with the software instead of learning.

    • Update**

The changes were more widespread than just that template. Multiple templates had their components rearranged, or deleted! I had a standard template for all basic items in this category, the template contained a small image component and two large HTML components. Now the template has only one small HTML component, the small image component was moved and resized much larger, and a second image component was added! This happened in several different templates with no explanation, no warning, and no chance to cancel! I'm cleaning it up but it is very cumbersome and tedious. I have spent half of my study time today trying to fix SuperMemo errors. :(

Warning!

Which version of SuperMemo? If you edited templates in the registry, this could have been the effect of a bug! See: Template Registry Problem

Templates can be edited back to their original setting, however, if you have a version affected by the bug, this would be the fastest solution:

  • restore your backup
  • edit templates in elements (not in the registry)

Response

I am using SuperMemo 16.1 downloaded last week, build date of April 2015. The linked page does not state what versions are affected but I'm assuming since it was discovered after the build date that it may have been updated in SuperMemo 17? I paid for SuperMemo 17 but haven't migrated yet as I am comfortable working with categories and don't want to learn the new Concepts feature until my class is over when I will have more time to experiment.