sikuli-driver team mailing list archive

[Michael K <785813@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

MacOS 10.6
Sikuli IDE 1.0rc2

The error:

[error] getFocusedWindow requires Accessibility API to be enabled!

Even when running sikuli-ide.sh -s -r <my-script>, this pops up an
interactive dialog offering to open system preferences to enable
Accessibility. The function getFocusedWindow (or App.window()) returns
None after clicking No in the dialog.

It should just return None when -s command line option is specified. The
script may be recorded on a machine with Accessibility enabled and
played back with Accessibility disabled, under an automated test runner
that should under no circumstances block execution indefinitely --
that's the whole purpose of the "-s" command line option.

If it's desirable to have the option to retain the interactive behavior
in some situations even with -s, perhaps a Settings option could be
helpful, but by default it should just return None and let the calling
code deal with it, possibly failing the test, which is a perfectly valid
outcome with -s.

** Affects: sikuli
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Sikuli
Drivers, which is subscribed to Sikuli.
https://bugs.launchpad.net/bugs/785813

Title:
  "requires Accessibility API" exception pops up a blocking dialog with
  -s command line option

Status in Sikuli:
  New

Bug description:
  MacOS 10.6
  Sikuli IDE 1.0rc2

  The error:

  [error] getFocusedWindow requires Accessibility API to be enabled!

  Even when running sikuli-ide.sh -s -r <my-script>, this pops up an
  interactive dialog offering to open system preferences to enable
  Accessibility. The function getFocusedWindow (or App.window()) returns
  None after clicking No in the dialog.

  It should just return None when -s command line option is specified.
  The script may be recorded on a machine with Accessibility enabled and
  played back with Accessibility disabled, under an automated test
  runner that should under no circumstances block execution indefinitely
  -- that's the whole purpose of the "-s" command line option.

  If it's desirable to have the option to retain the interactive
  behavior in some situations even with -s, perhaps a Settings option
  could be helpful, but by default it should just return None and let
  the calling code deal with it, possibly failing the test, which is a
  perfectly valid outcome with -s.