Syntax error when running key-mon

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Installing key-mon from the .deb *or* from source (tar.gz) on Debian using 
sudo python setup.py install
2. Trying to run key-mon from the command line

When doing so, I receive the following error message:

<BEGIN ERROR MESSAGE>

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib/python2.5/site-packages/keymon/key_mon.py", line 39, in <module>
    import options
  File "/usr/lib/python2.5/site-packages/keymon/options.py", line 97
    dest=self._dest, type=self._type, default=self._default,
       ^
SyntaxError: invalid syntax

<END ERROR MESSAGE>

I have all dependencies (python-gtk2, python-xlib, librsvg2-common) installed - 
what could be the issue here?

Thanks,
Florian

Original issue reported on code.google.com by fhollerweger01@qub.ac.uk on 7 Sep 2010 at 9:07

[GoogleCodeExporter]

I'm on vacation, I took a quick look, but I couldn't reproduce the bug.  It 
might be that I'm doing something that's not correct in Python2.5.   
Unfortunately, I'm on my way out for a 3 day excursion to Rio so I'll be able 
to fix this only Sunday or Monday.

Original comment by sc...@forusers.com on 9 Sep 2010 at 1:13

[GoogleCodeExporter]

Should be fixed now, sorry for the delay.

Original comment by scottaki...@gmail.com on 19 Sep 2010 at 8:11

• Changed state: Fixed

[GoogleCodeExporter]

I had the same issue with 1.3.1. I'm running Fedora 10 (old, sic!) which 
supplies python 2.5.2.

But I'm still seeing the same issue with key-mon-1.4:

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib/python2.5/site-packages/keymon/key_mon.py", line 39, in <module>
    import options
  File "/usr/lib/python2.5/site-packages/keymon/options.py", line 97
    dest=self._dest, type=self._type, default=self._default,
       ^
SyntaxError: invalid syntax

From what I was told on IRC (in another python based program's channel), the 
"*args" style function parameter was something added in python 2.7 and 
backported to 2.6. I don't recall what that style parameter was called, and the 
conversation has scrolled out of my buffer. :-(

Original comment by mbst...@googlemail.com on 20 Sep 2010 at 11:50

[GoogleCodeExporter]

Wow, I had fiddled with the source so often trying to fix this. Today, my brain 
was apparently functioning better.

Those arguments are called "sequences". It appears that python 2.5 only accepts 
them at the _end_ of the argument list.

At least the attached patch works for me, swapping "*args" to the end. Could 
you please test for regressions on your systems (especially newer python 
systems) and do a new release if it works? Thanks a lot!

Original comment by mbst...@googlemail.com on 20 Sep 2010 at 12:58

Attachments:

• key-mon-1.4-args.patch

[GoogleCodeExporter]

Sorry, me again.
Now I get a crash using --larger. I think your modifications from 1.3.1 to 1.4 
need to be reverted, at least this one:
-    opts.scale = 0.75
+    opts.options.scale = 0.75
   elif opts.larger:
-    opts.scale = 1.25
+    opts.options.scale = 1.25

Otherwise, I get:

> key-mon --larger
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib/python2.5/site-packages/keymon/key_mon.py", line 730, in main
    opts.options.scale = 1.25
  File "/usr/lib/python2.5/site-packages/keymon/options.py", line 223, in __getattr__
    raise AttributeError('Invalid attribute name: %r' % name)
AttributeError: Invalid attribute name: 'options'

Original comment by mbst...@googlemail.com on 20 Sep 2010 at 1:06

[GoogleCodeExporter]

Reopening this bug since it's not fixed.

Original comment by scottaki...@gmail.com on 20 Sep 2010 at 2:26

• Changed state: Accepted

[GoogleCodeExporter]

Thanks for the patch mbstafs, untested since I still haven't installed 
python2.5 on my machine, but seems to work in 2.6.

I'll be cutting a release soon.

Original comment by scottaki...@gmail.com on 20 Sep 2010 at 11:33

• Changed state: Fixed

[GoogleCodeExporter]

I think some changes you did in changeset 96f0446a505f should not have been 
reverted. In fact I still need them. Without them, 1.4.1 again won't work on 
python 2.5 for me. The attached patch reintroduces them (based on 1.4.1 
codebase).

Sorry. ;-)

Original comment by mbst...@googlemail.com on 22 Sep 2010 at 11:52

Attachments:

• key-mon-1.4.1-value.03.patch

[GoogleCodeExporter]

Whoops, bad merge, sorry about that.

Original comment by sc...@forusers.com on 22 Sep 2010 at 5:08

[GoogleCodeExporter]

One of the "*args" has slipped though and is still used as the first argument 
in key-mon 1.4.2. It needs to be last.

  File "/usr/lib/python2.5/site-packages/keymon/options.py", line 107
    parser.add_option(*args, action='store_true', default=self._default,

Original comment by mbst...@googlemail.com on 23 Sep 2010 at 12:47

[GoogleCodeExporter]

arg! is right.
I didn't realize that was still broken, from a few merges ago.

Original comment by scottkir...@google.com on 23 Sep 2010 at 5:11

[GoogleCodeExporter]

Hi,

Thanks for looking into this. I do not get the original error after installing 
key-mon 1.4.4 with "sudo python setup.py install", and key-mon now starts up 
fine.

*But* neither mouse button nor key presses actually result in any action on 
key-mon's behalf :)

I can conform the following packages are installed on my machine:

librsvg2-common
python-gtk2
python-xlib

I am not sure about the "X.Org record module" or how to check whether it is 
present. Could that be why key-mon doesn't do anything for me?

best,
flo.H

Original comment by fhollerweger01@qub.ac.uk on 23 Oct 2010 at 3:42

[GoogleCodeExporter]

I'll take a look.

Original comment by scottaki...@gmail.com on 26 Oct 2010 at 9:30

• Changed state: Accepted

[GoogleCodeExporter]

Any news on this (see comment 12)? I gave 1.5.1 a shot today, but same 
situation: GUI starts up fine, but key/mouse symbols do not react.

This is 1.5.1 compiled from source on a Debian box with librsvg2-common, 
python-gtk2 and python-xlib installed. Still not sure about that X.Org record 
module, though.

best,
flo.H

Original comment by fhollerweger01@qub.ac.uk on 22 Nov 2010 at 3:08

[GoogleCodeExporter]

Sorry, I haven't been working on this, I'll try and discover how to detect 
wether you have xorg Record module and which systems normally have this.

Original comment by scottaki...@gmail.com on 22 Nov 2010 at 3:49

[GoogleCodeExporter]

@hollerweger01@qub.ac.uk if you have the time there are some things you could 
check for me.

On my machine(s) when I run this grep I get the following:

$ egrep ' LoadModule.*(evdev|record)' /var/log/Xorg.0.log
(II) LoadModule: "record"
(II) LoadModule: "evdev"

Perhaps you don't have the record module?  I've seen on a forum that the 
`record` module was removed for a while because it had some bugs (but is now 
back) Perhaps you are on this version?

Do you have the evdev module listed?  An older version of key-mon used evdev, 
but it didn't work with the wacom tablets, so it was rewritten using `record`.

If that's your problem and this is still an issue for you, it might be possible 
to restore evdev and make it an optional (backup) way of getting the mouse, and 
keyboard information.

---
Another thing you could try is to run xlib.py which is installed with the 
program, when I run the following I get this output when hitting keys:

$ python /usr/share/pyshared/keymon/xlib.py
Press ESCape to quit
Xlib.protocol.request.QueryExtension
Xlib.protocol.request.QueryExtension
type:EV_KEY scancode:28 code:KEY_RETURN value:0
type:EV_KEY scancode:16 code:KEY_Q value:1
qtype:EV_KEY scancode:16 code:KEY_Q value:0
type:EV_KEY scancode:46 code:KEY_C value:1
ctype:EV_KEY scancode:46 code:KEY_C value:0
type:EV_KEY scancode:1 code:KEY_ESCAPE value:1

Original comment by scottaki...@gmail.com on 24 Nov 2010 at 6:55

[GoogleCodeExporter]

I'm closing this bug and opening a new one (Issue 64). because the bugs issue 
is different.
I've copied over the relevant thread to the new issue (sorry for the spam!).

Original comment by scottaki...@gmail.com on 24 Nov 2010 at 6:59

• Changed state: Fixed