Path: csiph.com!usenet.pasdenom.info!gegeweb.org!de-l.enfer-du-nord.net!feeder1.enfer-du-nord.net!feeds.phibee-telecom.net!newsfeed.xs4all.nl!newsfeed3.news.xs4all.nl!xs4all!news2.euro.net!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
Newsgroups: comp.lang.python
Date: Sat, 24 Nov 2012 13:07:26 -0800 (PST)
In-Reply-To: <mailman.242.1353708648.29569.python-list@python.org>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=80.109.122.186; posting-account=oknH1QoAAABqzbD_5ziFTvLQsqNk2LbU
References: <3d71f175-164e-494c-a521-2eaa5679b524@googlegroups.com> <818c157c-1395-441d-ad99-955a31b0d523@googlegroups.com> <mailman.242.1353708648.29569.python-list@python.org>
User-Agent: G2/1.0
MIME-Version: 1.0
Subject: Re: 10 sec poll - please reply!
From: Michael Herrmann <michael.herrmann@getautoma.com>
To: comp.lang.python@googlegroups.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: python-list@python.org
Precedence: list
Message-ID: <mailman.259.1353791249.29569.python-list@python.org>
Lines: 188
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:33890

Thanks for your reply Dennis,

the commands sounding like they should be commands to a user is the whole p=
oint 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 sys=
tem events are being generated and passed around, however that is not what =
these users care about. Frankly, also I coming from a very technical backgr=
ound don't care which events are generated and how, as long as it works.=20

I agree that "key_down"/"key_up" has a nice symmetry to it. Maybe a solutio=
n 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
>=20
> <Michael Herrmann> declaimed the following in
>=20
> gmane.comp.python.general:
>=20
>=20
>=20
> > These names aren't perfect. As Emile rightly pointed out, several tools=
 distinguish between 'press' and 'release' and a user might wonder how to r=
elease a key that was pressed using 'press'. That's an ambiguity that is ce=
rtainly there, however we hope that once the user has at least seen
>=20
> > 	press(ENTER)
>=20
> > it is clear what is meant. Distinguishing between pressing and releasin=
g could we think easily be done with, say
>=20
> > 	hold_down(SHIFT)
>=20
> > 	...
>=20
> > 	release(SHIFT)
>=20
> > 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 i=
s to raise a ValueError if the user supplies a string that is longer than o=
ne character:
>=20
> > 	>>> press("OK")
>=20
> > 	ValueError: 'press' generates keystrokes and can only press single let=
ters at a time. Did you maybe mean click("OK") or press('O', 'K')?
>=20
> >=20
>=20
>=20
>=20
> 	"press", "hold_down", "release" just sound so much like they should
>=20
> be commands to a /user/ not to a means of programmatically controlling
>=20
> an interface. A "user" presses a button -- but a program is just
>=20
> injecting the "event" of a button press into the input processing stream
>=20
> (it's been decades, but I still think in Amiga terms -- where all input
>=20
> events routed through one input handler and chained to the programs
>=20
> wanting to work with raw events... This meant that, but injecting the
>=20
> event codes before the input handler, a program could make another
>=20
> program [including the OS] think one had ejected/inserted floppies,
>=20
> mouse movements, keystrokes)
>=20
>=20
>=20
> 	"hold_down" and "release" would seem more memorable, and symmetric,
>=20
> if named "key_down" and "key_up"; and if "press" is limited to single
>=20
> codes -- "key" [or "keystroke"]
>=20
>=20
>=20
> 	The closest M$ .Net method is called SendKeys() and works with
>=20
> strings.
>=20
> http://msdn.microsoft.com/en-us/library/microsoft.visualstudio.testtools.=
uitesting.keyboard.sendkeys%28v=3Dvs.100%29.aspx
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> > What do you think of this solution? I hope anybody read this far. I pro=
bably shouldn't have written that much but wanted to do justice to your inp=
uts.
>=20
> >=20
>=20
> > Thanks!
>=20
> >=20
>=20
> > Michael
>=20
> >=20
>=20
> > On Tuesday, November 20, 2012 1:18:38 PM UTC+1, Michael Herrmann wrote:
>=20
> > > Hi,=20
>=20
> > >=20
>=20
> > >=20
>=20
> > >=20
>=20
> > > I'm developing a GUI Automation library (http://www.getautoma.com) an=
d am having difficulty picking a name for the function that simulates key s=
trokes. I currently have it as 'type' but that clashes with the built-in fu=
nction. Example uses of 'type':=20
>=20
> > >=20
>=20
> > >=20
>=20
> > >=20
>=20
> > > type(ENTER)
>=20
> > >=20
>=20
> > >=20
>=20
> > >=20
>=20
> > > type("Hello World!")
>=20
> > >=20
>=20
> > >=20
>=20
> > >=20
>=20
> > > type(CTRL + 'a')
>=20
> > >=20
>=20
> > >=20
>=20
> > >=20
>=20
> > > What, in your view, would be the most intuitive alternative name?
>=20
> > >=20
>=20
> > >=20
>=20
> > >=20
>=20
> > > 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_key=
s" but that is rather long and doesn't read as well, for instance in type_k=
eys(ENTER).
>=20
> > >=20
>=20
> > >=20
>=20
> > >=20
>=20
> > > Thank you very much!
>=20
> --=20
>=20
> 	Wulfraed                 Dennis Lee Bieber         AF6VN
>=20
>             HTTP://wlfraed.home.netcom.com/