10 sec poll - please reply!

Michael Herrmann michael.herrmann at getautoma.com
Sat Nov 24 22:07:26 CET 2012


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/


More information about the Python-list mailing list