Combining hotkeys in one file

[avidseeker]

In Autohotkey, one can have multiple shortcuts in .ahk. E.g:

::email::myEmail@example.com
:o:name::John Smith
:^a:selectingAll
...

Autohotkey syntax looks more minimalistic than Autokey. I find this easier to debug, search and add. Does Autokey have a way to combine shortcuts instead of having piles of files cluttering ~/.config/autokey each with a .json.

[josephj11]

No. It wasn't designed that way.

AutoKey is far more powerful than AHK because it gives you the full power of Python for scripting instead of a special purpose language/syntax. However, this power comes with a bit of added complexity, e.g. the separate metadata files.

I don't know why the design approach to use separate metadata files rather than some sort of database was taken. It's just a feature of the original implementation of AutoKey.

#699 was recently requested which would help a little in this regard by letting you sort the entries in various orders, e.g. by hotkey, making it easier to look for conflicts, etc.

If you find too much clutter in a folder, AutoKey supports defining new subfolders so you can split things up into more manageable subsets. Additional folders can also be defined at arbitrary locations outside of AutoKey's configuration subtree. (If you do that, it works best to add the new folders to AutoKey as empty folders and then add the content to them after AutoKey already knows about the folders.)

However, the metadata files are all human readable plain text JSON files with the .json extension (and as of 0.96.0, they are no longer hidden files).

If you have some familiarity with a scripting language such as bash, it would be relatively easy to write (CLI) scripts to examine these files and extract all sorts of information from them and present it in a form that would help you solve issues.

I do a lot of bash scripting and would be happy to help with this if that approach interests you.

If you are very careful and make good backups, it is also possible to edit these files manually or with CLI scripts.

Any tools like this would be welcome additions to our wiki.

Also, many file managers such as Dolphin have built-in search capabilities which may meet some of your needs and there are also tools such as recoll which provide advanced searching capabilities.

If you join us over on Gitter, you could describe some of your specific problems that AutoKey and the above suggestions do not adequately address and maybe we can help you find solutions.

[josephj11]

That's almost exactly what putting scripts in our Modules directory is supposed to do, but until #248 gets implemented, you can't easily use API calls in scripts stored in the Modules directory. It was a design flaw IMO.

So, for now, there are some ways to approach this. They involve using scripts instead of phrases.

• Write a script which manually exposes the AutoKey API and does what you want (see Scripting API: Overwrite import semantics to inject API functions into user modules #248 for how to do that)
• Write a script that does what you want, but uses the xdo module or direct calls to xdotool using subprocess() to do the desktop interactions without using the AutoKey API

its calling sequence should look something like this
cleanly_insert(string, xoffset=50, yoffset=50)

Put that script in the Modules directory.

I added the offset parameters with default values to make the script more flexible.

Write individual scripts tied to trigger phrases and/or hotkeys that look something like this

import cleanly_insert
cleanly_insert("letter A")

For help implementing this, join us over on Gitter.

[avidseeker]

Yes, not having modularity is a major design flow. It's been 3 years over #248. Any hope of fixing it soon?

So, if I implement this in xdotool, then will AutoKey only help for detecting hotkeys and abbreviations?

[josephj11]

Yes, AutoKey would still trigger your script(s), but the events would be implemented using xdotool...

Check out @Elliria 's suggestion about looking for keypresses. That sounds like it might help.

As for getting the root problem fixed, there are two problems. First, we currently have one active developer who is in the middle of writing a masters thesis on the way to getting a PhD. He really doesn't have much time for anything new.

Second, when this was initially researched, it wasn't entirely obvious how to fix it, so some research will be involved.

So, don't hold your breath. (And if you know any Python developers looking for a great project to contribute to, send them our way!)

[avidseeker]

What library is AutoKey using for binding keys? I managed to have a couple of working scripts for xdotool but I need to bind them with keys. I need a tool similar to xbindkey but window-specific (AutoKey has a couple of great options for binding keys to scripts).

[josephj11]

@avidseeker IDK Python or the AutoKey sources well enough to answer that.

It could get pretty convoluted pretty quickly, but it would also be possible to have an AutoKey script to run xbindkeys or other "global" actions and then another script to undo them. This would only work well if you were not also switching to other windows in the middle of this.

[Elliria]

The keyboard.wait_for_keypress() API call would be useful for this, but it still needs some work since return codes aren't provided by AutoKey. It was reported in issue #659, which is still open, but there seems to be a link to a work-around if you'd like to give that a try.

[sim2pro]

I want to know how can I import clipboard and keyboard in external scripts (not directly in the autokey scripts). Then I can can put the common scripts in an external module and call them using autokey scripts binding with shortcut keys.

Thank you!

[josephj11]

That's great idea.

Have you tried it to make sure the API calls work?

So, store.get_global_value("foo")() gets it and runs it in one step?

I assume that foo() remains available to the script for its duration or until you remove it. Even after you remove it, is it still available in the context of the running script?

I know I asked this before, but where do all these functions get stored? If someone builds up a large collection of these, does it impact performance, etc.?

I'm thinking I would write one script to create each "class" of these functions (i.e. a library/toolkit) and another to remove them. I would probably call these indirectly somehow (not from a trigger) to set and reset the environment before and after using them.
Something like this would keep them organized and make them portable to a new install. This is what Python modules are for, but I don't know enough Python to be sure of how to take advantage of that.

To be safe, the scripts that call these functions might need a test to make sure they're there (loaded) before trying to use them.

This might also be a good use case for hooks in AutoKey to run scripts when AutoKey starts so such things could be available without having to remember to "load" them each time before use.

@BlueDrink9 This sounds like it's too good to be true. Do you have any thoughts on the best way to do this or on any potential downsides?

[BlueDrink9]

That sounds like it should work quite nicely! Well done!

Regarding hooks, could probably be done but implementing the ui change is unlikely to be something I'm interested in.

I use hooks with my autokey. I have a single script that sets up all my hotkeys as temporary hotkeys, and I run that script with autokey-run every time I start my computer. So I just include the hooks in that script. That's probably not the way most people want to use autokey, but I just don't like messing with GUIs

[josephj11]

@BlueDrink9 If there is a (new) folder in the config somewhere, any scripts placed there could be run automatically at AutoKey startup. No GUI work needed to implement this at all. I'm sure a GUI would be nice, but maybe we could get it for free by defining a "startup" special folder in the normal AutoKey file hierarchy. Then, the existing GUI would do all of work, probably with no modifications. This has the added benefit of making the startup scripts easy to access while testing them.

One other point I'd like a little help with: A collection of functions as mentioned above is pretty much what a Python module is.
Is there some way to store a whole module in a variable and then use the functions within it? It would be much cleaner and probably more Pythonic than to have to do each function one by one in separate variables. This would also eliminate errors like forgetting to define one of the functions in a set or defining one of them with a typo, etc. because you get the whole group or nothing.

[BlueDrink9]

Yup, importing a module exposes it as a variable

[Elliria]

Have you tried it to make sure the API calls work?

Yep. dialog.info_dialog(message="Hello world!") is an API call and works totally smoothly when used in this way.

So, store.get_global_value("foo")() gets it and runs it in one step?

Nope. The store.set_global_value("foo", myFunction) runs the myFunction function and stores its output in the foo global value. Then, when you want to use the foo global value, the store.get_global_value("foo")() command retrieves the stored foo global value from within any script anywhere.

I assume that foo() remains available to the script for its duration or until you remove it. Even after you remove it, is it still available in the context of the running script?

The stored foo global value can be retrieved again and again until you do either of these:

• intentionally change the foo global value with store.set_global_value("foo", myFunction) from inside of the same script where the myFunction function is - it doesn't matter where.
• delete the foo global value with store.remove_global_value("foo") from inside of any script

I know I asked this before, but where do all these functions get stored? If someone builds up a large collection of these, does it impact performance, etc.?

The beauty of global values is that you can create them and/or put information into them and/or update them and/or delete them from anywhere without having to keep the code that gave them their value. The most important thing (the global value) is remembered for you by AutoKey. The global value can then be accessed from any script or phrase, including the script that created it.

The myFunction function is run once to create and populate the foo global value. At that point, the myFunction function is no longer necessary and can be deleted. I have an AutoKey script that I keep around and use all the time for sticking temporary code into for testing purposes or to create global values.

If the information in your foo global value is likely to change, you'd want to keep the myFunction function in a script somewhere in AutoKey and run the store.set_global_value("foo", myFunction) command from inside of the same script where the myFunction function is as often as needed to update the foo global value with the latest and greatest information.

If you want to, you can keep the functions you used to put information into global values. I often do, for later reference. I just stick them into an appropriately-named script so I can find them again if I need to, but I don't run them again unless I've deleted the global value and need to get its value back or unless I want to change its value. My main use for them so far has been for sharing them with others.

I'm thinking I would write one script to create each "class" of these functions (i.e. a library/toolkit) and another to remove them.

You can definitely do that. Classes are my weakness, so I probably wouldn't be of much use with them yet.

I would probably call these indirectly somehow (not from a trigger) to set and reset the environment before and after using them. Something like this would keep them organized and make them portable to a new install. This is what Python modules are for, but I don't know enough Python to be sure of how to take advantage of that.

That's where engine.run_script(...) API call would come in handy. If your environmental code is stored in the "environment" script, then you can run engine.run_script("environment") from any other script to run that script at any time and update your environment.

To be safe, the scripts that call these functions might need a test to make sure they're there (loaded) before trying to use them.

Ah, yes, debugging. That's always a good idea.

This might also be a good use case for hooks in AutoKey to run scripts when AutoKey starts so such things could be available without having to remember to "load" them each time before use.

It probably wouldn't even be necessary for that, since the hook would presumably launch the specified script(s), which could just run the code instead of running it and storing it inside of a global value, unless that was the goal. I'm after full automation on that wish, so I'd want the hook to just run my code on start-up and be done with it.

---

The code above is more readable with myGlobalValue in place of foo:

# Create a function:
def myFunction():
    dialog.info_dialog(message="Hello world!")

# Store the function in a key-value pair for global use by any script:
store.set_global_value("myGlobalValue", myFunction)

# Get the value of the stored key-value pair and add parentheses to call/run the function:
store.get_global_value("myGlobalValue")()

# Remove the global key/value pair:
store.remove_global_value("myGlobalValue")

[josephj11]

If I understand you correctly, you basically want to use the Modules directory the way it ought to work, but doesn't. To do that now (or any time soon), you have to use the workaround in the feature request referenced above or do it with non-AutoKey tools such as xdotool (in a module/function in our Modules directory) because you can access them directly and don't need our API calls.

[Elliria]

I misread what the second OP (@simprome) wanted the first time around and gave a purely-AutoKey solution. If I understand the request better now, @simprome would like to export clipboard and keyboard data to an external Python module file that can be used by AutoKey scripts or by any other Python script on the system. If that's the case, here's part of the code that would make that happen. It's a small demonstration of putting some text onto the clipboard, reading the clipboard, and then appending its contents to an external Python file (with optional instructions for overwriting that file, if desired). The example then opens the file and displays its contents in a dialog so we can see that it worked:

# Create a variable for some text:
MyText="\nHELLO WORLD"

# Create a variable for the path to your Python module file:
MyModule="/path/to/mymodule.py"

# Put some text onto the clipboard:
clipboard.fill_clipboard(MyText)

# Put the contents of the clipboard into a variable:
MyClip = clipboard.get_clipboard()

# Display the contents of the variable in a dialog:
dialog.info_dialog(title="Clipboard Contents", message="The contents of the clipboard are:\n\n" + MyClip)

# Open the file in append mode (use w instead of a if you want to overwrite the file):
with open(MyModule, "a") as f:
    # Write the contents of clipboard to the file:
    f.write(MyClip)

    # Close the file:
    f.close()

# Open the file in read mode:
with open(MyModule, "r") as f:

    # Create a variable and put the contents of the file into it as a string:
    MyModuleContents=f.read()

    # Close the file:
    f.close()
    
# Display a dialog with the variable's contents:
dialog.info_dialog(title="File Contents", message="The contents of the file are:\n\n" + MyModuleContents)

What's missing is instructions for using the module file from within AutoKey (although I believe that's covered in the wiki). I'm also not sure of what' meant by "keyboard" in the request. If that's in reference to the keyboard.send_keys(...) API call, then the file would have to be opened and focused, then written to, saved, and closed by AutoKey, but that's all doable if it's what @simprome would like.

[josephj11]

This is going to take me a bit to assimilate.

So, now, I can store functions or modules of functions in a global variable and use them wherever they are needed.

If i have retrieved a module of functions (MyModule) from a global stored variable, I presume I would then use it with something like MyModule.MyFunction().

I'm still not clear on the persistence of global stored variables. I have a set of scripts that give me a feature which is like memory store, memory retrieve, and memory clear on a calculator. I almost never bother to clear it. The other day, after I rebooted or something, I tried the memory retrieve function and nothing was there. I haven't tried to nail down exactly what happened yet, but I was expecting a value to be there. If global stored variables have some limit on their shelf life, then that will have to be accounted for.

---

I put class in quotes above, because I'm referring to the concept rather than the Python capability. I mean "things that just conceptually go together". I never learned OOP, so I have no idea how to do anything with an actual Python class.

---

You said:

# Get the value of the stored key-value pair and add parentheses to call/run the function:
store.get_global_value("foo")()

I'm confused. It says it gets and runs it, but your reply says it doesn't. Could you clarify this for me?

[Elliria]

This was a hijacked thread and has gotten longer than intended (and is about to be even longer as you'll see in a moment), so I've created a new discussion for it in the Running non-local code in an AutoKey script #743 discussion to continue this discussion there.