Merge lp:~jeff-licquia/pystromo/saitek into lp:pystromo
Status: | Needs review |
---|---|
Proposed branch: | lp:~jeff-licquia/pystromo/saitek |
Merge into: | lp:pystromo |
Diff against target: |
442 lines (+325/-8) 4 files modified
config/saitek-cyborg-cmdunit.map (+236/-0) lib/constants.py (+15/-0) lib/devices.py (+70/-7) pystromo-remap.py (+4/-1) |
To merge this branch: | bzr merge lp:~jeff-licquia/pystromo/saitek |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Raumkraut | Needs Fixing | ||
Review via email: mp+41413@code.launchpad.net |
Description of the change
This branch pulls in the changes from Shane McCormack to support the Saitek Cyborg Command Unit gamepad (with some updates from me).
Unmerged revisions
- 70. By Jeff Licquia
-
Get rid of print statements in lib dir.
- 69. By Jeff Licquia
-
Renamed sample file and gave it a better device ID.
- 68. By Jeff Licquia
-
Fix bug in InputDevice.
save_state( ), and remove debug statements. - 67. By Jeff Licquia
-
Include further changes in key mapping for LED "buttons".
- 66. By Jeff Licquia
-
First pass at refactoring according to suggestions from upstream.
Changes:
- References to "saitek" in variable names purged.
- Instead of configuring the saved state file, force it to a standard
location (currently ~/.local/pystromo, set in constants.py), with a
standard filename.- Instead of saving on every LED state change, save when pystromo-remap
exits. State is also only saved if needed (i.e. we read state on startup
and/or we detected a state change). - 65. By Jeff Licquia
-
Updated key constants for buttons F1-F4 and 21 on Saitek.
- 64. By Shane Mc Cormack
-
Pull in Saitek gamepad changes from Shane McCormack.
Original repo: git://git.
soren.co. uk/shane/ pystromo. git/
Thanks for bringing this to my attention, Jeff.
It's not going to get merged in though, as the features have been implemented in the wrong places:
- Parsing config files should be (and is!) done before an InputDevice is instantiated.
- Saving application-state information shouldn't really be done by the InputDevice either. And it's probably a bad idea to write config data every time an LED changes.
- Plus some nomenclature issues. :)
And I have to ask: why were some buttons renamed to "TRIGGER_HAPPY##", aside from the amusement factor? :)