Comment 3 for bug 1434434

@Denis & Eugene
thanks for your valuable input.
additional aspect: there are surely different requirements for the use in a visual testing environment or for some automation.

For automation purposes you need reliable scripts, that even take care for some special situations, without crashing.
In testing it is ok, to just let a test fail, if something is not as it should be.

Automation scripts usually are tailored to solve a specific problem, usually for a fixed environment.
In testing today, the tests have to cover many system and rendering (mainly with browsers) environments.

In automation you want to be sure, that after some workflow step is processed, the intended operational result is achieved.
in testing usually the sequence is: when I do this, the GUI should look like that afterwards. And GUI testing often is separated from operational, data related testing (for which testers will surely not use a tool like SikuliX).

So a SikuliX recorder should surely support a sophisticated image capturing (naming, organising, optimisation, variants, ...).
With a little effort, this is possible already today:
- use the capture hotkey, which in most cases allows to capture the GUI elements in a way, as they are shown at runtime
- switch on the manual naming, so you can implement a naming convention from beginning
- separate code from images (code in one .sikuli, images, patterns and other image related information in other .sikuli), so you can decide at runtime which one to use via import

In my opinion it would be a step in the right direction, to force the user, to first decide for the element's name and some attributes (only image and/or an element that might be acted on by mouse and/or keyboard, possible clickpoint relation to other images already in the stock, ....) and then capture the image and store it in an organised way (image groups).