You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Given that some of the forks I see are purely for the purpose of implementing a custom command, it'd probably be a good idea to add support for extending QuickTile in case the user wants to also have it installed outside their homedir.
The first thing I'll want to do is extend the config file syntax to allow users to customize tiling presets without having to know any Python (issue #13) but, once that's done, it should just be a simple matter of allowing users to write custom commands into a file with a name like ~/.config/quicktile/extra_commands.py.
This will probably be a bit low priority, since I'll first want to set up the infrastructure to encourage users to share their enhancements, but it shouldn't be too difficult now that I've cleaned up the command API and switched to using decorators to register them.
The main design concern will be that, since I haven't yet justified the added complexity of a multi-file design, I can't use imp.load_source. As such, I'll probably use execfile instead and pass the extension API in without requiring an import.
It has its problems, but I don't foresee any of them becoming significant to this use case in the near future. (And certainly not before the 1.0.0 release when apply any API-breaking fixes that have accumulated on the TODO list.)
The text was updated successfully, but these errors were encountered:
Given that some of the forks I see are purely for the purpose of implementing a custom command, it'd probably be a good idea to add support for extending QuickTile in case the user wants to also have it installed outside their homedir.
The first thing I'll want to do is extend the config file syntax to allow users to customize tiling presets without having to know any Python (issue #13) but, once that's done, it should just be a simple matter of allowing users to write custom commands into a file with a name like
~/.config/quicktile/extra_commands.py
.This will probably be a bit low priority, since I'll first want to set up the infrastructure to encourage users to share their enhancements, but it shouldn't be too difficult now that I've cleaned up the command API and switched to using decorators to register them.
The main design concern will be that, since I haven't yet justified the added complexity of a multi-file design, I can't use
imp.load_source
. As such, I'll probably useexecfile
instead and pass the extension API in without requiring animport
.It has its problems, but I don't foresee any of them becoming significant to this use case in the near future. (And certainly not before the 1.0.0 release when apply any API-breaking fixes that have accumulated on the TODO list.)
The text was updated successfully, but these errors were encountered: