Hi, after painstaking trial-end-error (you really don't want to press all the function keys that control brightness in an automated way!), I have this:
t000_54 = [97, 115, 100, 102, 104, 103, 122, 120, 99, 118, 164, 98, 113, 119, 101, 114, 121, 116, 49, 50, 51, 52, 54, 53, 61, 57, 55, 45, 56, 48, 93, 111, 117, 91, 105, 112, 13, 108, 106, 39, 107, 59, 92, 44, 47, 110, 109, 46, 9, 32, 96, 8, 13, 27]
t054_65 = [None] * 11
t065_68 = [46, 316, 42]
t068_69 = [None]
t069_73 = [43, 314, 27, 317]
t073_75 = [None] * 2
t075_79 = [47, 13, 315, 45]
t079_81 = [None] * 2
t081_90 = [61, 48, 49, 50, 51, 52, 53, 54, 55]
t090_91 = [None]
t091_93 = [56, 57]
t093_96 = [None] * 3
t096_100 = [344, 345, 346, 342]
t100_101 = [None] # F8
t101_102 = [None] # F9
t102_103 = [None]
t103_104 = [None] # perhaps f11
t104_105 = [None] # perhaps f11
t105_107 = [352, 16]
t107_108 = [None] # F2
t108_109 = [16]
t109_110 = [None]
t110_111 = [16]
t111_112 = [None]
t112_113 = [16]
t113_114 = [None]
t114_115 = [323]
t115_127 = [313, 366, 127, 343, 312, 341, 367, 340, 314, 316, 317, 315]
tables = [k for k in locals().keys() if k.startswith('t')]
tables.sort()
master_table =
for t in tables:
master_table.extend(locals()[t])
reverse_table = {}
for idx, code in enumerate(master_table):
if code is not None:
try:
reverse_table[unichr(code)] = idx
except:
print 'idx, code %s, %s not unichrable' % (idx, code)
else:
print 'idx %s is None' % idx
from pprint import pprint
pprint(reverse_table)
Which at least contains most ASCII characters. Generated using a US layout:
{u'\x08': 51,
u'\t': 48,
u'\r': 76,
u'\x10': 112,
u'\x1b': 71,
u' ': 49,
u"'": 39,
u'*': 67,
u'+': 69,
u',': 43,
u'-': 78,
u'.': 65,
u'/': 75,
u'0': 82,
u'1': 83,
u'2': 84,
u'3': 85,
u'4': 86,
u'5': 87,
u'6': 88,
u'7': 89,
u'8': 91,
u'9': 92,
u';': 41,
u'=': 81,
u'[': 33,
u'\\': 42,
u']': 30,
u'`': 50,
u'a': 0,
u'b': 11,
u'c': 8,
u'd': 2,
u'e': 14,
u'f': 3,
u'g': 5,
u'h': 4,
u'i': 34,
u'j': 38,
u'k': 40,
u'l': 37,
u'm': 46,
u'n': 45,
u'o': 31,
u'p': 35,
u'q': 12,
u'r': 15,
u's': 1,
u't': 17,
u'u': 32,
u'v': 9,
u'w': 13,
u'x': 7,
u'y': 16,
u'z': 6,
u'\x7f': 117,
u'\xa4': 10,
u'\u0138': 119,
u'\u0139': 115,
u'\u013a': 123,
u'\u013b': 126,
u'\u013c': 124,
u'\u013d': 125,
u'\u0143': 114,
u'\u0154': 122,
u'\u0155': 120,
u'\u0156': 99,
u'\u0157': 118,
u'\u0158': 96,
u'\u0159': 97,
u'\u015a': 98,
u'\u0160': 105,
u'\u016e': 116,
u'\u016f': 121}
These are all keycodes as captured by the OnChar event, as wired up in tests/testButton.py. There is a also a number of other events that are not captured at all, and will need even more trial and error to decode. The fact that the function keys are "special" on my MacBook doesn't help.
Hopefully this is going to be helpful.
Orestis
···
--
orestis@orestis.gr
On 19 Jan 2009, at 01:03, Kevin Ollivier wrote:
Hi Orestis,
On Jan 18, 2009, at 3:54 PM, Orestis Markou wrote:
That worked perfectly. I actually used bakefile 0.2.3 (available from MacPorts). Swig built cleanly and so did UIEventSimulator. I noticed that SendText isn't actually implemented, although it failed because it expected a wxString (?). Also, for some reason, the keypress/keychar functions always send 'a'. You can see it by changing your test to send and expect 'd'.
Looks like we need a way to map ASCII keys to 'virtual' key codes. What seems odd is that these codes are pretty much constant, but there isn't any mapping currently. There's an app that prints them, though, so I think I just need to alter it to spit them out to a sort of header file.
Anyway, thanks a lot! Am I correct to assume that _eventsim.so, libeventsim.dylib and eventsim.py are the only outputs? I'd like to check them in to my repo so I don't have to build them every time.
yes, that should be the case.
It also occurred to me that for win32, the relevant functions are probably exposed through the pywin32 extensions. I'll have a look tomorrow and send you the relevant info.
yes, it looks like they are. 
Thanks,
Kevin
Cheers,
Orestis
--
orestis@orestis.gr
http://orestis.gr/
On 18 Jan 2009, at 23:10, Kevin Ollivier wrote:
Hi Orestis,
On Jan 18, 2009, at 2:50 PM, Orestis Markou wrote:
I'll try building my own wxpython/wxwidgets. It seems like it's documented enough, hopefully I'll have no problems. How is UIEventSim built?
You actually shouldn't need to build your own wxWidgets/wxPython. As long as you have the wx-config for your wxPython on the PATH, it should build okay. Note that right now you also need Bakefile (I'd recommend getting 0.2.4 as 0.2.5 has an annoying assert that seems to be a false alarm) and the version of SWIG 1.3.29 Robin uses for wxPython, available from here: NameBright - Coming Soon
You will need to build SWIG, but it is pretty much a configure / make / make install deal. Note that both Bakefile and SWIG should be available on your PATH.
Let me know if you run into any snags!
Thanks,
Kevin
--
orestis@orestis.gr
http://orestis.gr/
On 18 Jan 2009, at 22:05, Kevin Ollivier wrote:
Hi Orestis,
On Jan 18, 2009, at 11:48 AM, Orestis Markou wrote:
Hi Kevin,
that looks exactly what I need. I have a Mac so it fits my needs 100%. Is this accessible in any of the release builds of wxPython or do I have to build my own from source?
You have to build from source for now. Once it's complete (i.e. also implemented on Win/Linux), I'm planning on moving it into the wx / wxPython build process so that it will be directly accessible via wxPython.
I will also have to test from Windows but it shouldn't be too hard to implement a similar interface (with some help, I don't have a clue about how wx is implemented), since the Win32 API has methods to create events like that.
mouse_event and keybd_event should allow us to implement these APIs. It shouldn't require too much knowledge about how wx is implemented, though, as you're mostly simulating native key and mouse events. There will probably be special work needed to handle non-ASCII characters, but I think even starting with ASCII support would be a huge plus.
Thanks,
Kevin
Thanks,
Orestis
--
orestis@orestis.gr
http://orestis.gr/
On 18 Jan 2009, at 18:33, Kevin Ollivier wrote:
Hi Ivan, Orestis,
I've actually been working towards a wx(Python) extension to encapsulate these platform methods into a helper library that can be used to improve the wxPython unit tests. The API is designed and should work cross-platform, but I only have the Mac impl. so far.
wxTrac has been migrated to GitHub Issues - wxWidgets
Ivan, did you just write that code sample up or have you created a similar Python binding for Linux?
Thanks,
Kevin
On Jan 18, 2009, at 9:51 AM, Ivan Nazarenko wrote:
My guess is that you do not synthesize keyboards events directly in wx
because you don't need to, since under linux you have the XTest
extension to do just that. The source code is attached. Run setup to
compile keymodule and have the resulting keymodule.so visible (in your
current directory, for instance).
On windows, though, I still haven't had to synthesize them, so I am
not aware how to do it.
Regards.
PS: to use it, open thread different from the user interface, and
from this thread:
import key
...
key.makeev(kc) # get kc from /usr/include/X11/keysymdef.h
That's it. "man XTestFakeKeyEvent" have some info on it.
On 1/18/09, Orestis Markou <orestis@orestis.gr> wrote:
Hello,
from browsing the archives, it seems that simulating events is tricky
and can't be done from wxpython. I can live with that for mouse
events, which are tricky to get right in any case, but keyboard events
would be very handy during testing.
Is there any reasonable way of synthesising and sending a keyboard
event to the application, so that all the codepaths (including focus
etc) are exercised during a test run? Or native events *have* to be
synthesised? I am using the STC widget along some other simple text
ctrls.
Thanks,
Orestis
--
orestis@orestis.gr
http://orestis.gr/
_______________________________________________
wxpython-users mailing list
wxpython-users@lists.wxwidgets.org
http://lists.wxwidgets.org/mailman/listinfo/wxpython-users
<keymodule.c><setup.py>_______________________________________________
wxpython-users mailing list
wxpython-users@lists.wxwidgets.org
http://lists.wxwidgets.org/mailman/listinfo/wxpython-users
_______________________________________________
wxpython-users mailing list
wxpython-users@lists.wxwidgets.org
http://lists.wxwidgets.org/mailman/listinfo/wxpython-users
_______________________________________________
wxpython-users mailing list
wxpython-users@lists.wxwidgets.org
http://lists.wxwidgets.org/mailman/listinfo/wxpython-users
_______________________________________________
wxpython-users mailing list
wxpython-users@lists.wxwidgets.org
http://lists.wxwidgets.org/mailman/listinfo/wxpython-users
_______________________________________________
wxpython-users mailing list
wxpython-users@lists.wxwidgets.org
http://lists.wxwidgets.org/mailman/listinfo/wxpython-users
_______________________________________________
wxpython-users mailing list
wxpython-users@lists.wxwidgets.org
http://lists.wxwidgets.org/mailman/listinfo/wxpython-users
_______________________________________________
wxpython-users mailing list
wxpython-users@lists.wxwidgets.org
http://lists.wxwidgets.org/mailman/listinfo/wxpython-users
_______________________________________________
wxpython-users mailing list
wxpython-users@lists.wxwidgets.org
http://lists.wxwidgets.org/mailman/listinfo/wxpython-users
Unfortunately, from what I can read the Apache 2.0 license compatibility with LGPL 2 (and thus the wxWidgets license) is very murky territory.