Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cycle_dimensions sequences shouldn't be hard-coded #13

Open
ssokolow opened this issue Sep 14, 2011 · 1 comment
Open

cycle_dimensions sequences shouldn't be hard-coded #13

ssokolow opened this issue Sep 14, 2011 · 1 comment
Assignees
Milestone

Comments

@ssokolow
Copy link
Owner

Currently, all aspects of mapping between key combinations and commands with --daemonize are configurable, but the definition of what those commands do is still hard-coded.

Given that most commands are essentially macros, cycling windows through sequences of position-dimension presets and that I've seen real-world examples of people editing quicktile.py simply to alter the POSITIONS map, this needs to change.

However, it won't be as simple as the existing config keys for the following reasons:

  • ConfigParser doesn't natively support lists of lists
  • SimpleJSON wasn't added to stdlib as the json module until Python 2.6
  • Mechanisms like pickle don't produce config files that are easy to read and edit by hand
  • I have no idea when I'll be ready to produce the GTK+ GUI for customizing configurations.
  • I don't want to add to QuickTile's list of dependencies for continued support of older Python versions just yet.

My current avenue of interest is exploring how much I'd have to compromise the expressiveness of the current system and what syntax I could easily parse to comfortably store a sequence of positions in a reasonably intuitive, human-editable string that will still be easy to both parse and generate when it comes time to create a configuration GUI.

@ghost ghost assigned ssokolow Sep 14, 2011
@ssokolow
Copy link
Owner Author

ssokolow commented Oct 1, 2013

Now that all my target platforms have at least Python 2.6, this will probably be the next thing I work on since it would remove the need for the vast majority of the forks up on GitHub.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant