Sikuli IDE deletes PNG files, whose filename strings cannot be found in the script, when saving the script

This is not a bug

To be clear, when I said that this is happening by design, that does not mean that the behavior is correct.

The algorithm seems to have been designed with the assumption that any PNG file in the script directory must have come through interactions with the IDE. The IDE creates a large number of temporary PNG files during use (most of them seem to occur when OCR is involved), and it makes sense to have a mechanism to clean up any image file that the user didn't incorporate into their script.

The *bug* is that the algorithm assumes that any filename not explicitly matched in the python file is one of these temp images that should be cleaned away.

A possible workaround for this would be to designate a subdirectory where this cleanup mechanism does not run, and where sikuli can still use the imagery. What do you think about that?

Sorry, my fault, I changed your bug to a question, and then mixed up the comments.

With the now invalid bug I asked you to post a new request bug, to not mix things up.

But only for the records:
Something that is so by design, can never be a bug. It can only motivate you to add a request to the developers ;-)

BTW:
- The images, that are deleted are not the "temporary" ones. Only images whose filenames are no longer found as strings in the script are deleted at save time.

- subdirectory
This is possible already now:
import os
imageDir = getBundlePath() # the script path
imageSubDir = myImages # folder: script.sikuli/myImages
addImagePath(os.path.join(imageDir, imageSubDir)

from now on, Sikuli will find the images in subDir too.
image

Thanks for the workaround. I'll give that a try.

BTW, "Something that is so by design, can never be a bug. It can only motivate you to add a request to the developers ;-)"

Maybe this is a philosophical issue, but as a software engineer, I believe that a bug can be by design if that design didn't take real-world use cases into account. The bug is *in* the design, if you will.

Also, I may have been mistaken in calling those images "temporary." I called them that because most of them seemed to be an artifact of the OCR process. Capturing an image that contained no text would yield a single epoch-timestamp-named image file, but capturing an image that conained text would generate maybe 20 image files, most of which I assumed to be temp files written by the OCR engine, and one of which was the actual image thumbnail, named based on the detected text.

--- The bug is *in* the design, if you will.
Fully agreed. Looking from this point of view, there are still many more design bugs in this on the other hand neat piece of software ;-)

--- seemed to be an artifact of the OCR process
When Sikuli started, the captured images where all named with the timestamps.
Starting with Sikuli X and the availability of OCR, there are 3 options selectable in the IDE settings
1. trying to excerpt some text from the image and use it as name (the standard)
2. name the images yourself with a popup pre-filled with the name from 1 (my preferred option)
3. the old one with the timestamp

option 1 has the problem, that different captures might yield the same filename, so the IDE adds -n to the filename. This additionally happens every time, when you grab a new image for an existing thumbnail, since it is most probable, that it generates the same filename.

Since most people grab the same image multiple times in a find-click-wait workflow, instead of storing/using a match or getLastMatch(), you might get many filenames "some text-xx.png". Some of them are still used, some of them might get obsolete.

The workaround worked after fixing up some syntax issues :) (Need a closed paren for the addImagePath line, and need to put the directory name in quotes.)

For now, I think this is an acceptable workaround. Some redesign would be required to solve this any other way.