Renaming an abbreviation or script sometimes requires AutoKey restart

[Elliria]

AutoKey is a Xorg application and will not function in a Wayland session. Do you use Xorg (X11) or Wayland?

Xorg

Has this issue already been reported?

• I have searched through the existing issues.

Is this a question rather than an issue?

• This is not a question.

What type of issue is this?

UI/Usability

Choose one or more terms that describe this issue:

• autokey triggers
• autokey-gtk
• autokey-qt
• beta
• bug
• critical
• development
• documentation
• enhancement
• installation/configuration
• phrase expansion
• scripting
• technical debt
• user interface

Other terms that describe this issue if not provided above:

No response

Which Linux distribution did you use?

Kubuntu 22.04 LTS

Which AutoKey GUI did you use?

GTK

Which AutoKey version did you use?

AutoKey 0.95.10

How did you install AutoKey?

From the Ubuntu repository.

Can you briefly describe the issue?

Renaming an abbreviation or script sometimes doesn't take effect until AutoKey is restarted.

Can the issue be reproduced?

Sometimes

What are the steps to reproduce the issue?

1. Right-click an abbreviation or phrase in the left panel of AutoKey.
2. Choose "Rename" from the context menu.
3. Type in a new name.
4. Press the "Enter" key or left-click the "OK" button.

What should have happened?

The abbreviation or script should now have the new name that you typed.

What actually happened?

Sometimes, nothing happens and the abbreviation or script keeps the old name until you restart AutoKey.

Do you have screenshots?

No response

Can you provide the output of the AutoKey command?

No response

Anything else?

When this happens, clicking on another abbreviation or script and then clicking the one you renamed again doesn't cause the new name to appear. Neither does closing the AutoKey main window and opening it again. If AutoKey is shut down and restarted, the new name will then be used.

I have not tested this in autokey-qt. It's an intermittent issue and cannot be reliably triggered. For reasons unrelated to this issue, I don't want to use autokey-qt for any length of time, so I won't be doing that kind of testing. Hopefully someone who uses autokey-qt will chime in here.

[josephj11]

If closing and reopening the window doesn't fix it, it's deeper in ihe code. The code that watches for changes seems like it may have some holes in it.

I would expect that file management would be in autokey-common. The GUI's just display things...

[Elliria]

Yeah, and the intermittent aspect of it will make it difficult to track down.

[Elliria]

I think I may have figured out the circumstances that make it happen, which will make it possible to consistently repeat it.

It just happened to me when I cloned a script that had contents in it. While the contents of the two scripts are identical, you get the behavior in this issue (name change does not take visible effect until AutoKey is closed and reopened). If, however, you edit the cloned script and change its contents, when you save the change, the name will be updated to the one you had tried to change it to earlier.

Perhaps there's some sort of comparison going on in AutoKey as part of the cloning process and it doesn't like it when two identical scripts have different names even if that's done after the clone has been completed.

[Elliria]

Nope. Just tried it and didn't get the error. Ah, well.

[josephj11]

What happens when you rename an action externally while AutoKey is running and some other action is selected and displayed in the editing panel?

[Elliria]

If I rename a script externally (by editing the name of its .py file, editing the name of its .json file, and editing its name inside of its .json file) and then click another script in Autokey and then click back to the one I just renamed externally, nothing happens to the one I renamed. If I then exit out of AutoKey and launch it again, the script is now renamed.

[josephj11]

That sounds like a deficiency if not an outright bug.

I didn't think about the name in the metadata file.

What happens if that doesn't get changed? It's labelled as "Description", so maybe it's just a display thing. I think I have renamed scripts before successfully without noticing that this field needed updating as well. Where is that used?

[Elliria]

By the way, I totally blew past the Dolphin notification that pops up when I close the file manager after renaming the files externally:

Apparently, it's expected behavior for us to have to close and restart AutoKey for name-changes that were made externally to take effect.

[Elliria]

It looks like the description entry in the .json file is the magic incantation that determines the name of the script.

If you don't change the description, the script name doesn't change, even after exiting AutoKey and launching it again.

If you just externally change the description value inside the .json file, you'll get the Dolphin notification and the script's name will not change in AutoKey until you exit out of AutoKey and launch it again.

The bad news is that if you just change the description value inside the .json file, although that's all you need to do to visibly change a script's name inside of AutoKey, AutoKey will not rename the .json and .py files for you, so those will keep their original names, which could be confusing. As a result, I'd recommend making all three changes when renaming scripts or phrases externally.

Note that in case you're interested in checking into this further, if you clone AutoKey or download a copy of AutoKey 0.96.0 and unzip it and then run the grep -r description * command inside of the autokey directory, you'll get 154 results. I'm not sure exactly how many of them reference the description used in the .json files. Some of the results can be dismissed automatically, but others would have to be examined.

[josephj11]

Not sure what "file manager" you are closing. Dolphin?

The message says you have to close and reopen the AutoKey window, not the whole application. Do you really need to terminate and restart AutoKey itself? If so, that requires further investigation to determine if it's a bug or not. Either the message or the code is wrong.

Your notes on external renaming should go in the wiki somewhere - probably under something like notes for advanced users.

[Elliria]

Yes, Dolphin, but that shouldn't matter. I would think that any file manager would pop up a similar message after such a change. It's not an AutoKey notification, because that string doesn't exist anywhere inside of AutoKey. And yes, you need to terminate and restart AutoKey. I suspect that's what they mean in that ambiguously-worded notification, too.

As for the note in the wiki, is the location for the AutoKey files always the same on all systems or does it change from one operating system to the next?

On my system, AutoKey 0.95.10 phrases and scripts are stored in these locations:

• ~/.config/autokey/data/Phrases
• ~/.config/autokey/data/Scripts

I don't have AutoKey 0.96.0 installed, but I've seen you mention that its phrases and scripts aren't hidden. Where are those kept?

Also, is the location for each of those versions of AutoKey always in the same place on different operating systems? If not, some sort of instructions would need to be added on how to find them.

Suggestions are welcome.

[josephj11]

Yes, Dolphin, but that shouldn't matter. I would think that any file manager would pop up a similar message after such a change. It's not an AutoKey notification, because that string doesn't exist anywhere inside of AutoKey. And yes, you need to terminate and restart AutoKey. I suspect that's what they mean in that ambiguously-worded notification, too.

In 18.04 land, Dolphin regularly had a problem with missing changes to files and folders. That seems (mostly?) fixed now.

AutoKey has some code to watch its directories for changes. If you need to terminate and restart it anyway, I'm not clear on what good (if any) that code is doing. This sounds like it's at least part of the problem.

As for the note in the wiki, is the location for the AutoKey files always the same on all systems or does it change from one operating system to the next?

On my system, AutoKey 0.95.10 phrases and scripts are stored in these locations:

• ~/.config/autokey/data/Phrases
• ~/.config/autokey/data/Scripts

I only use Kubuntu, so I can't say for sure. I assume AutoKey installs the same on all versions of Linux. I woud guess it does the same on BSD.

I don't have AutoKey 0.96.0 installed, but I've seen you mention that its phrases and scripts aren't hidden. Where are those kept?

Everything is in the same directores. The sidecar files are automatically renamed, removing the leading dot in their names which is what made them hidden.

This is a breaking change, so if you want to use the same config on the old versions, you have to make symlinks with the old names, but I'm not sure what the new version will do when it sees them.

Also, is the location for each of those versions of AutoKey always in the same place on different operating systems? If not, some sort of instructions would need to be added on how to find them.

Suggestions are welcome.

When you create a new folder for scripts or phrases using the AutoKey menu, you can choose an arbitrary path for it anywhere on your system. I always do that for several reasons. All of my stuff is outside of the config tree. I have detailed why and how I do this several times. If you haven't seen it, I can do it again. It's not in the wiki, etc.

While we're on the topic of symlinks, both my .config/autokey and my main folder for all my scripts and phrases are symlinks. I can just repoint them to versions that work on 0.95.x or on 0.96.x, so those directory trees can be anywhere as well as long as you make sure the targets are mounted and permissioned correctly when AutoKey starts running.

[Elliria]

AutoKey has some code to watch its directories for changes. If you need to terminate and restart it anyway, I'm not clear on what good (if any) that code is doing. This sounds like it's at least part of the problem.

No idea, but I would assume that externally changing the name of a file would require a restart of the program that uses it for that change to be recognized.

I only use Kubuntu, so I can't say for sure. I assume AutoKey installs the same on all versions of Linux. I woud guess it does the same on BSD.

We'd need to find out somehow in order to document it.

I don't have AutoKey 0.96.0 installed, but I've seen you mention that its phrases and scripts aren't hidden. Where are those kept?

Everything is in the same directores. The sidecar files are automatically renamed, removing the leading dot in their names which is what made them hidden.

I don't understand. They're only hidden because they're inside the hidden ~/.config directory. What changed to make them appear? If they're still in the ~/.config directory, they'll still be hidden on my system.

This is a breaking change, so if you want to use the same config on the old versions, you have to make symlinks with the old names, but I'm not sure what the new version will do when it sees them.

Nothing, as far as I can tell. I have AutoKey 0.95.10 installed in my VM, which means that AutoKey's data is in the ~/.config/autokey/ directory. I often clone the development version (which is AutoKey 0.96.0 and then some) and other versions. Regardless of which version I run, AutoKey always finds the scripts and phrases that live in the ~/.config/autokey/ directory and if I make changes to them with either version, those files are updated. No special treatment is required to get it to do that.

When you create a new folder for scripts or phrases using the AutoKey menu, you can choose an arbitrary path for it anywhere on your system.

Yeah, I've seen you mention that before and noted it in my personal wiki. That would make a nice advanced addition to the wiki (perhaps in a customization page), but my usual interest, when it comes to documentation, is in how to use AutoKey without customizing it in any way.

[josephj11]

No idea, but I would assume that externally changing the name of a file would require a restart of the program that uses it for that change to be recognized.

AFAIK, the only time that might be the case would be when an application has the file in question open (not the case here). When that occurs, the app holds on to the inode and Linux won't interfere until it lets go.

[josephj11]

I don't understand. They're only hidden because they're inside the hidden ~/.config directory. What changed to make them appear? If they're still in the ~/.config directory, they'll still be hidden on my system.

You're right and wrong. .config remains hidden, but once you get to your actions directories within that or wherever you have them, the individual sidecar files have names that no longer start with periods, so they are no longer hidden in those directories.

This makes my life easier because all normal copying methods will find them when people are making backups or otherwise moving things around.

[josephj11]

Nothing, as far as I can tell. I have AutoKey 0.95.10 installed in my VM, which means that AutoKey's data is in the ~/.config/autokey/ directory. I often clone the development version (which is AutoKey 0.96.0 and then some) and other versions. Regardless of which version I run, AutoKey always finds the scripts and phrases that live in the ~/.config/autokey/ directory and if I make changes to them with either version, those files are updated. No special treatment is required to get it to do that.

You're not using symlinks so you can't run into this potential issue.

Also, you're starting from scratch. If you copy your 0.95 configs into a VM and run 0.96 there, all the sidecars will be automatically renamed. Everything works. But if you subsequently run 0.95 on that same config (not in a new VM), none of the renamed sidecar files will be detected leaving things considerably broken.

If you then create symlinks from all the unhidden sidecar files to names that start with periods, 0.95 will work again, but if you run 0.96 after that - still on the same modified config, that's when something bad might happen.

In normal usage, none of this will occur. It will only occur if someone attempts to revert from 0.96 to 0.95 or they have their config on the cloud and access it from one machine running 0.96 and from another one running 0.95.

[Elliria]

AFAIK, the only time that might be the case would be when an application has the file in question open (not the case here). When that occurs, the app holds on to the inode and Linux won't interfere until it lets go.

Maybe AutoKey holds onto it during the entire session.

[Elliria]

You're right and wrong. .config remains hidden, but once you get to your actions directories within that or wherever you have them, the individual sidecar files have names that no longer start with periods, so they are no longer hidden in those directories.

Ah, I see. There are none like that in the Phrases directory in AutoKey 0.95.10, but the .json files inside the Scripts directory all have leading dots. I agree that those are pointless, so it's good that they've been done away with.

[Elliria]

In normal usage, none of this will occur. It will only occur if someone attempts to revert from 0.96 to 0.95 or they have their config on the cloud and access it from one machine running 0.96 and from another one running 0.95.

Thanks for the detailed explanation. Those scenarios would make a good addition to the wiki if they aren't already there.

[josephj11]

There are none like that in the Phrases directory in AutoKey 0.95.10, but the .json files inside the Scripts directory all have leading dots.

Every phrase has a sidecar file for its meta data, so they should be there in 0.95 or the phrases woudn't work. In 0.95, they're still hidden, so you have to do something like ls -a to see them.

[josephj11]

AFAIK, the only time that might be the case would be when an application has the file in question open (not the case here). When that occurs, the app holds on to the inode and Linux won't interfere until it lets go.

Maybe AutoKey holds onto it during the entire session.

That would be highly unlikely. The operation affects the directory entry only, so the file itself never needs to be opened.

Maybe some sort of OS-level caching is going on, but that sort of thing sounds like a major OS bug, so that's not likely either.

[Elliria]

Every phrase has a sidecar file for its meta data, so they should be there in 0.95 or the phrases woudn't work. In 0.95, they're still hidden, so you have to do something like ls -a to see them.

You're right. On closer look, it seems that I have some files with a leading dot in their names and some without in both the Phrases and Scripts directories. There's no rhyme nor reason to them, though. They're all .json files, but in both cases, I have some .json files with a leading dot and some without. No idea why.

Here are some of my phrases in my file manager with hidden files showing:

And here are some of my scripts in my file manager with hidden files showing:

[josephj11]

That's not cool!

Given the amount and variety of testing you do, figuring out how that occurred might be quite difficult.

You should clear out all the ones not compatible with the version of AutoKey you want to use them with.

If you switch Autokey versions as is, each affected action is going to be looking at a different metadata file depending on which version of AutoKey you are running. If you change the metadata in one, it won't affect the other version. This could be quite unexpected and confusing.

Maybe you used the 0.95 config with 0.96 and it renamed whatever was there at the time. Then you went back to 0.95 and tried to edit an action. It couldn't find the renamed metadata and created a new hidden metadata file for it.

Whatever occurred is most likely an artifact of your testing and not something that would occur under normal usage, so it doesn't require investigation.

[Elliria]

It's not the testing, because that's done in a VM. I have, however, had AutoKey for years and have brought the data files with me each time I upgraded the operating system, so perhaps I dragged some old files along that shouldn't have been there when the more recent version of AutoKey was installed. I've never installed AutoKey 0.96.0 in Kubuntu 22.04 LTS, which is what I currently use. I've only ever install what's in the Ubuntu repositories, so I'm currently using AutoKey 0.95.10.

Now the question is: What should my files look like in AutoKey 0.95.10? Leading dots or no leading dots? I may try renaming the ones that are incorrect to see what happens.

On a side note, I've installed AutoKey 0.95.10 in a VM and have run AutoKey 0.96.0 in the VM from a variety of sources (downloaded zip files, clones of master, develop, and some pull requests, etc.) without installing them.

[Elliria]

It's not the testing, because that's all done in a VM, with the version of AutoKey available in the Ubuntu repositories, with downloaded zip files, and with clones.

I have, however, had AutoKey for years and have brought the data files with me each time I upgraded the operating system, so perhaps I dragged some old files along that shouldn't have been there when the more recent version of AutoKey was installed. I've never installed AutoKey 0.96.0 in Kubuntu 22.04 LTS, which is what I currently use. I've only ever install what's in the Ubuntu repositories, so I'm currently using AutoKey 0.95.10.

Now the question is: What should my files look like in AutoKey 0.95.10? Leading dots or no leading dots? I may try renaming the ones that are incorrect to see what happens.

Interestingly, I just tried an experiment:

• I created a new script and saved it. I refreshed Dolphin and saw just a new .son file. with a leading dot that was marked as created and modified "just now" in Dolphin.
• I chose a phrase that had just one .son file with no leading dot. I edited it in AutoKey and saved the change. I refreshed Dolphin and saw two .json files - one with a leading dot and one without, and the one with the leading dot was marked as created and modified "just now" in Dolphin.
• I chose a phrase that had two .son files - one with a leading dot and one without. I edited it in AutoKey and saved the change. I refreshed Dolphin and saw that the one with the leading dot was marked as modified "just now" in Dolphin and the one without the leading dot was unchanged.

On a side note, I've installed AutoKey 0.95.10 in a VM and have run AutoKey 0.96.0 in the VM from a variety of sources (downloaded zip files, clones of master, develop, and some pull requests, etc.) without installing them.

[josephj11]

Before 0.96.0, all sidecar files were hidden (named starting with a dot).

0.96.0 automatically renames these without the dot.

The sidecar files need to be named the same as their corresponding action file (of the same name without the dot and with an extension of .txt for phrases and .py for scripts).

I don't know what happens when AutoKey finds one of the pair, but not the other.

If a current action has no sidecar file, then that action has no metadata and can't do anything. A sidecar file with no action file has nothing to apply the metadata to.

If your actions work at all, they are already correctly paired with their sidecar files.

So, I wouldn't recommend renaming any unmatched files. I'd delete them.

If you're curious and you have two sidecar files with the same name, but one name starts with a dot, you can diff or meld them and see what you find. Or just cat them or view them in a pager or text editor...

[josephj11]

The results of your experiment are what I expected. AutoKey ignores any other files in its directories. However, any settings in the one without the dot would be ignored, so when you edited the action, AutoKey created a new sidecar file from scratch. If you were expecting any of those settings to be preserved, then that might have been unexpected.

Again, under normal usage, none of this happens, so it's not of much concern whatever it does.

Where the trouble starts is if you have sidecar files without the dot and then you run 0.96.0. Then, it will either just start using them instead of the (renamed) correct ones or it will rename the dotted one and overwrite the undotted one or get some error if the renaming fails because it collides with the existing file. All this should just be avoided by cleaning out anything that doesn't belong in these directories.

[Elliria]

AutoKey sees them all. If I don't do anything with any of the ones that aren't named correctly (no leading dot), AutoKey doesn't do anything. If I edit one of those, it creates a duplicate of it with a leading dot and then uses that. I guess I'll leave them there until they've all been created and then get rid of the ones with no leading dots. If I felt strongly about it, I'd edit each of them to make it happen right away, but I've got so many of them that it would take forever and I don't feel like doing it. They'll eventually sort themselves out.

[josephj11]

That's what krename is for. It will let you mass rename them with tons of flexibility as to how you do that. You can just add a prefix of a dot to them, making sure you only do it to the .json files that don't already have one.

[Elliria]

Yeah, I could batch-rename them. I'd want to back up the directory first in case AutoKey isn't happy with me for having done it.

[josephj11]

Backups should exist anyway.