On Tuesday, March 26, 2013 12:38:35 PM UTC+1, Chris Angelico wrote:
> ...
> Fundamental point: As I understand the API, it doesn't *actually* tie
> to a window. You don't locate the Notepad window and send it keys -
> you switch focus to Notepad and then send keys to the whole system. Is
> this correct? I'm basing my understanding on this paragraph from your
> original post:
> 
> > We do not (yet) have a functionality that allows you to explicitly switch 
> > to a
> > specific window. Such a functionality would for instance make it possible to
> > open two Notepad windows using the start(...) command, and copy text
> > between them.
> 
> If so, then all of the method-based options are effectively lying,
> because they imply a binding that's not there. The actual sequence of
> actions includes imperatives of "switch to some other window", so I
> think that's what the API should reflect. Otherwise, there's risk that
> something will get horribly horribly confused between the programmer's
> brain and the end result (which could happen on either side of your
> code).

As I just wrote in my reply to Dave, internally we know very well which window 
an action is to be performed in. This window is the window that'd be in the 
foreground after the previous action, if nothing interferes with the system 
while the script is being executed. A common exception is when you enter 
commands in the interactive interpreter: say you write

    >>> start("Notepad")

The Notepad window opens, but for you to enter the next command, you have to 
switch back to the interpreter window. If you do that, and enter

    >>> write("Hello World")

then we remember that you were previously working with the Notepad window and 
activate this window before performing the key strokes to type "Hello World".

> But if you can unambiguously identify a running instance of something
> and switch to it, then a method on the object that start() returns
> would be absolutely correct. So I'd be looking at either your second
> or fourth options from the original post.

Those are also my favorites at the moment :)

Michael
www.getautoma.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Reply via email to