Thanks for your reply Dennis,
the commands sounding like they should be commands to a user is the whole point
of the exercise: In doing so, we hope to make the API accessible also to users
from a less technical background. You are perfectly right that system events
are being generated and passed around, however that is not what these users
care about. Frankly, also I coming from a very technical background don't care
which events are generated and how, as long as it works.
I agree that "key_down"/"key_up" has a nice symmetry to it. Maybe a solution
could also be to use a context manager:
with key_down(SHIFT):
# some action...
Cheers
On Friday, November 23, 2012 11:11:34 PM UTC+1, Dennis Lee Bieber wrote:
> On Thu, 22 Nov 2012 10:00:54 -0800 (PST), Michael Herrmann
>
> <Michael Herrmann> declaimed the following in
>
> gmane.comp.python.general:
>
>
>
> > These names aren't perfect. As Emile rightly pointed out, several tools
> > distinguish between 'press' and 'release' and a user might wonder how to
> > release a key that was pressed using 'press'. That's an ambiguity that is
> > certainly there, however we hope that once the user has at least seen
>
> > press(ENTER)
>
> > it is clear what is meant. Distinguishing between pressing and releasing
> > could we think easily be done with, say
>
> > hold_down(SHIFT)
>
> > ...
>
> > release(SHIFT)
>
> > Another ambiguity of 'press' that I pointed out in my original mail is that
> > it could also be understood as "pressing a button". The current idea is to
> > raise a ValueError if the user supplies a string that is longer than one
> > character:
>
> > >>> press("OK")
>
> > ValueError: 'press' generates keystrokes and can only press single
> > letters at a time. Did you maybe mean click("OK") or press('O', 'K')?
>
> >
>
>
>
> "press", "hold_down", "release" just sound so much like they should
>
> be commands to a /user/ not to a means of programmatically controlling
>
> an interface. A "user" presses a button -- but a program is just
>
> injecting the "event" of a button press into the input processing stream
>
> (it's been decades, but I still think in Amiga terms -- where all input
>
> events routed through one input handler and chained to the programs
>
> wanting to work with raw events... This meant that, but injecting the
>
> event codes before the input handler, a program could make another
>
> program [including the OS] think one had ejected/inserted floppies,
>
> mouse movements, keystrokes)
>
>
>
> "hold_down" and "release" would seem more memorable, and symmetric,
>
> if named "key_down" and "key_up"; and if "press" is limited to single
>
> codes -- "key" [or "keystroke"]
>
>
>
> The closest M$ .Net method is called SendKeys() and works with
>
> strings.
>
> http://msdn.microsoft.com/en-us/library/microsoft.visualstudio.testtools.uitesting.keyboard.sendkeys%28v=vs.100%29.aspx
>
>
>
>
>
>
>
>
>
>
>
> > What do you think of this solution? I hope anybody read this far. I
> > probably shouldn't have written that much but wanted to do justice to your
> > inputs.
>
> >
>
> > Thanks!
>
> >
>
> > Michael
>
> >
>
> > On Tuesday, November 20, 2012 1:18:38 PM UTC+1, Michael Herrmann wrote:
>
> > > Hi,
>
> > >
>
> > >
>
> > >
>
> > > I'm developing a GUI Automation library (http://www.getautoma.com) and am
> > > having difficulty picking a name for the function that simulates key
> > > strokes. I currently have it as 'type' but that clashes with the built-in
> > > function. Example uses of 'type':
>
> > >
>
> > >
>
> > >
>
> > > type(ENTER)
>
> > >
>
> > >
>
> > >
>
> > > type("Hello World!")
>
> > >
>
> > >
>
> > >
>
> > > type(CTRL + 'a')
>
> > >
>
> > >
>
> > >
>
> > > What, in your view, would be the most intuitive alternative name?
>
> > >
>
> > >
>
> > >
>
> > > Here are my thoughts so far: I could call it 'press' but then our GUI
> > > automation tool also allows you to click things and then "press" might be
> > > mistaken for "pressing a button". A less ambiguous alternative is
> > > "type_keys" but that is rather long and doesn't read as well, for
> > > instance in type_keys(ENTER).
>
> > >
>
> > >
>
> > >
>
> > > Thank you very much!
>
> --
>
> Wulfraed Dennis Lee Bieber AF6VN
>
> HTTP://wlfraed.home.netcom.com/
--
http://mail.python.org/mailman/listinfo/python-list
