Inconsistent window state when AutoKey opens

[Elliria]

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

Which Linux distribution did you use?

Kubuntu 20.04 LTS and Ubuntu MATE 16.04 LTS.

Which AutoKey GUI did you use?

Both

Which AutoKey version did you use?

I tested three different versions in two different environments:

• AutoKey 0.96.0-beta.10
• AutoKey 0.95.10
• AutoKey 0.90.4

How did you install AutoKey?

The beta was installed via pip in a virtual machine.
AutoKey 0.95.10 was installed from the Ubuntu repositories in a virtual machine.
AutoKey 0.90.4 was installed from the Ubuntu repositories on an actual machine.

Can you briefly describe the issue?

The state of the AutoKey window is not consistent from one version of AutoKey to the next and also not consistent between the GTK and Qt versions.

Can the issue be reproduced?

Always

What are the steps to reproduce the issue?

There are two ways this can be tested:

Method 1:

1. Open AutoKey without using the -c option so that the main window is not opened by default.
2. Click the AutoKey icon in the panel to open the AutoKey window.
3. Observe the state of the window.
4. Open a phrase or script.
5. Close AutoKey without closing the phrase or script.
6. Reopen AutoKey.
7. Click the AutoKey icon in the panel to open the AutoKey window.
8. Observe the state of the window.

Method 2:

1. Open AutoKey using the -c option so that the main window is opened by default.
2. Observe the state of the window.
3. Open a phrase or script.
4. Close AutoKey without closing the phrase or script.
5. Reopen AutoKey.
6. Observe the state of the window.

What should have happened?

The desired state of the AutoKey window is debatable, but it should be consistent regardless of whether AutoKey GTK or AutoKey Qt is used. Also, unless a deliberate change was made to the default state in development, the state of the window should be consistent from one version of AutoKey to the next.

What actually happened?

AutoKey 0.96.0-beta.10:

GTK: Each time I open the AutoKey GTK beta, the "New" option is selected in the toolbar, the last script or phrase that I had open is selected in the left pane, and its contents are displayed in the right pane. This is consistent, repeatable behavior that happens every time I open the AutoKey GTK beta.

Qt: Each time I open the AutoKey Qt beta, nothing is selected in the toolbar, all folders are collapsed in the left pane, and the upper-most folder is selected, but not opened.

Environment:

• Kubuntu version: Kubuntu 20.04 LTS running inside of VirtualBox
• KDE Plasma version 5.18.8
• KDE Frameworks version: 5.68.0
• Qt version: 5.12.8
• Kernel version: 5.13.0-28-generic
• OS Type: 64-bit
• AutoKey version: autokey-gtk 0.96.0-beta.10

AutoKey 0.95.10:

GTK: Each time I open the AutoKey GTK version 0.95.10, the "New" option is selected in the toolbar, all folders are collapsed in the left pane, and the upper-most folder is selected, but not opened.

Qt: Each time I open the AutoKey Qt beta, it doesn't open with the main window showing even with the -c option used on the command line (perhaps another issue and if not, I should make it one), and when I click the AutoKey icon in the tray, nothing is selected in the toolbar, all folders are collapsed in the left pane, and the upper-most folder is selected, but not opened.

Environment:

• Kubuntu version: Kubuntu 20.04 LTS running inside of VirtualBox
• KDE Plasma version: 5.18.5
• KDE Frameworks version: 5.68.0
• Qt version: 5.12.8
• Kernel version: 5.13.0-28-generic
• OS type: 64-bit
• AutoKey version: autokey-gtk 0.95.10

AutoKey 0.90.4:

GTK: Each time I open AutoKey GTK, nothing is selected in the toolbar, all folders are collapsed in the left pane, and the upper-most folder is selected, but not opened.

Qt: Not tested.

Environment:

• Ubuntu MATE 16.04 LTS.
• OS type: 64-bit
• AutoKey version: autokey-gtk 0.90.4

Do you have screenshots?

autokey-gtk 0.96.0-beta.10:

autokey-qt 0.96.0-beta.10:

autokey-gtk 0.95.10:

autokey-qt 0.95.10:

autokey-gtk 0.90.4:

autokey-gtk 0.90.4:

No image available.

Can you provide the output of the AutoKey command?

No response

Anything else?

In the event that this difference is by design, I'd like to cast my vote for either going back to how things used to be or giving us control over how AutoKey opens with an option in AutoKey's settings. I like how it was in the old version of AutoKey or the Qt version of the beta where nothing is selected in the toolbar, the folders in the left pane are collapsed, and the uppermost one is selected, but not opened.

[josephj11]

To summarize, it seems that things were as desired and consistent until the new beta version of autokey-gtk (only) introduced new behavior that some of us (including me) don't prefer. Have I got that right?

In any case, both front ends should behave as identically as possible, so whatever is decided should be implemented in both of them.

If it's not too much trouble, having this new behavior as a settable option would be nice. Since it's probably a set and forget option, a parameter in the JSON configuration file might be good enough without bothering to add the setting to the GUI configuration menus.

[Elliria]

Not quite. I believe everything was fine in AutoKey GTK 09.90.4, but never tested the Qt version, although the Qt version is behaving consistently in the other two versions mentioned here.

The deviation looks like it began at or before AutoKey GTK 0.95.10, but after AutoKey GTK 0.90.4. If you look at the AutoKey GTK 0.95.10 screenshot, the folders are still collapsed with the uppermost one selected and not opened, but the New option is selected in the toolbar and it shouldn't be.

More recently, in the AutoKey GTK beta, the New option is still selected in the toolbar, but now the last script or phrase you had open is also opened.

I agree that the two front ends should behave as identically as possible.

Also, in the event that the new behavior is what we move forward with, I'd love a set-it-and-forget-it JSON configuration that we could use to prevent it.

[Elliria]

Here's sort of a visual round-up:

AutoKey GTK 0.96.0-beta.10:

• The "New" option is selected in the toolbar. <===[DEVIATION]
• The last script or phrase that had been opened is selected in the left pane. <===[DEVIATION]
• The folder's contents are displayed in the right pane. <===[DEVIATION]

AutoKey Qt 0.96.0-beta.10:

• The "New" option is not selected in the toolbar.
• All folders are collapsed in the left pane.
• The upper-most folder is selected, but not opened.

AutoKey GTK 0.95.10:

• The "New" option is selected in the toolbar.<===[DEVIATION]
• All folders are collapsed in the left pane.
• The upper-most folder is selected, but not opened.

AutoKey Qt 0.95.10:

• The "New" option is not selected in the toolbar.
• All folders are collapsed in the left pane.
• The upper-most folder is selected, but not opened.

AutoKey GTK 0.90.4:

• The "New" option is not selected in the toolbar.
• All folders are collapsed in the left pane.
• The upper-most folder is selected, but not opened.

AutoKey GTK 0.90.4:

• Unknown.

[josephj11]

Thanks for the clarifications.

[BlueDrink9]

Awesome summary of the changes. It seems the new behaviour in GTK is a desirable new feature - and iirc that's what it was? Might have been non-trivial to port to QT.

So seems like the issue is consistency, and since it's just visual this feels like lo-priority to me

[Elliria]

You consider that behavior to be desirable? I'm just curious why you would want the "New" option to be selected in the toolbar for you by default. Also, I hope that both of these behaviors will at least be made optional so that those of us who prefer not to have the "New" option selected by default and don't want the last script or phrase we had open to be opened automatically for us when we open the program can choose to disable it.

[Elliria]

Also, it's not just visual. We need to act to unselect the toolbar option and to close the unwanted script or phrase before we can get to work. So from where I sit, it's an unwanted disruption. I might be the only one who feels that way, though, so this is just my two cents, for whatever it's worth.

[BlueDrink9]

I hear you. I thought your main issue was having the previous phrase open - the user story I picture is debugging/modifying a script, and wanting to return to the last script you edited the next time you open it.
It should be easier to collapse everything, that's fair.

Highlighting 'New' is probably not ideal though.

[Elliria]

This issue report is technically about inconsistent behavior depending on which of the two front-ends one uses, with (1) the "New" button being selected or not and/or (2) the folders being expanded or collapsed in the left pane and/or (3) the last-used phrase or script being opened in the right pane or not.

Something changed with the "New" button behavior in the GTK front-end at or before version 0.95.10 and all three behaviors changed in the GTK front-end at or before version 0.96.0-beta.10. And the changes were not also implemented in the Qt front-end, so they now both behave differently.

That then segued into a discussion on how some folks want to have the last phrase or script they were working on reopened automatically and/or have all their folders expanded, whereas some of us would rather have our programs tidy everything up at the end of a session so we can start fresh with nothing opened up for us each time.

I'd say each of those behaviors are important in their own way depending on which type of person you are, with the "New" button behavior being a bug that needs fixing and the other two behaviors being worthy of consideration as options the user can choose for themselves.

[ineuw]

@Elliria, what a great explanation with a an equally good closure! Thanks.

[Elliria]

Is there any chance anyone has come up with a work-around that can be done on the command line or a file that can be edited inside of AutoKey to force the specified folder to be selected and expanded when the GTK front-end of AutoKey is launched?

[josephj11]

Write an AutoKey script to adjust the display at the start or on demand. This answer is mostly tongue in cheek, but it should actually work. :)

It has the advantage that you can do it yourself/your way even if our developer(s) never get around to fixing this.

Depending on how you do it, you might need visgrep to determine what your initial state is before making changes.
Given the number of different things that can be displayed on the main window, getting your starting point right might be tricky.

If you get that to work and are really serious about it, you could file an enhancement issue for AutoKey to do something like scan for a open_main_window.py script and run it if it is found. Maybe, it would be internally triggered by the main window being opened for display.

It would have to know if the AutoKey window was displayed at all because it usually isn't when AutoKey first runs. A window filter might handle that.

If this works out, then maybe custom hooks could be proposed for other AutoKey state changes.

Conceptually, this should be relatively easy to implement (but IDK the source code). Maybe easier than fixing the original issue and, with clever scripting, one script could be made to work on both front ends.

We might need a new API call that returns which front end is active. One that returns the AutoKey version wouldn't hurt either. Maybe several things like this could be returned as a list from one API call.

[Elliria]

It looks like there are several ways to do it. I've currently got this script that does it, but requires me to type the trigger to make it happen:

# Get the title of the currently-focused window:
win = window.get_active_title()

# If the AutoKey window is focused:
if "AutoKey" in win:
    # Press the tab key, down arrow, and Enter key:
    keyboard.send_keys("<tab><down><enter>")
# Otherwise:
else:
    # Do nothing:
    pass

If I could fire this script on launch, I'd be all set, but even as is, it's a pleasant improvement.

[josephj11]

Glad you were able to do this so easily!

If you set a window filter, you could probably eliminate everything except the send_keys.

Do you only need this when AutoKey launches or are there also other times when opening/restoring the main window?

Now you can file an enhancement request for a hook to fire the script for you if you want to, but as mentioned above, you'd need to know what was on the screen to start with, if for instance, you were running the Qt front end that doesn't need this. Also, it is not just on startup. At minimum, it is when the main window is first displayed, because many users start AutoKey with the main window closed.

[Elliria]

I'd actually prefer to hard-code it rather than set the window filter, but that's just a personal preference for script control versus GUI control. It's only needed when AutoKey launches. It turns out that Qt also needs it, but in my case, the keyboard command above needs to be modified to keyboard.send_keys("<down><down><right>") for the Qt front end to achieve the same result, because the Qt front-end of AutoKey has the folders in a different order and has one selected, but not opened.

My new modified script checks which front-end is in use and sends the appropriate key-combinations to get the job done. It's working smoothly for me. You might want to give it a try after modifying the key-combinations to suit your setup:

# Run a system command to check for the full current AutoKey process name and store it in a variable:
process_name = system.exec_command("ps -q $(pgrep autokey) -o comm=")

# Get the title of the currently-focused window and store it in a variable:
win = window.get_active_title()

# If the AutoKey window has the current focus:
if "AutoKey" in win:
    # If gtk is in the process name:
    if "gtk" in process_name:
        # Press the tab, down arrow, and Enter key:
        keyboard.send_keys("<tab><down><enter>")
    # If qt is in the process name:
    elif "qt" in process_name:
        # Press the down arrow, down arrow, and right arrow:
        keyboard.send_keys("<down><down><right>")
    # If anything else happens:
    else:
        # Do nothing:
        pass
# Otherwise, if any other window has the focus or if no window has the focus:
else:
    # Do nothing:
    pass

You're right about the main window being closed in some cases. The else clause accounts for that and causes the script to do nothing. The script will also do nothing if AutoKey has been launched and another window has the focus or if AutoKey has been launched and no window has the focus. If you then give AutoKey the focus later and provide the trigger, it works the same way as it would have on launch. So far, it seems like a solid work-around for the time being. I'm loving it.

[josephj11]

Just to beat a dead horse: If you use a Window filter instead of an in script test, then the script will not be triggered at all on inappropriate conditions. Aside from an insignificant savings of overhead, this will allow the same hotkey to be assigned to trigger other events in these other circumstances.

It's a matter of personal preference, but including a vestigial else clause makes the script longer and more complex with no obvious benefit. Extra code increases the attack surface of your script even if the possibility of an attack is only you accidentally adding a typo. It also makes me think, "what was there before that used this condition" which is cognitive overhead.

I have seen large systems that contained substantial amounts of dead code that could not safely be removed because no one was absolutely sure some obscure edge case wouldn't access it and get someone a call in the middle of the night to come in and fix it. This makes me very sensitive to such things. This was much worse in a commercial shop whose whole software base was written in COBOL, a language that lends itself to bad coding practices. (And where production ran mostly at night when no programmers were on site and remote access did not exist.)

[Elliria]

Thanks for the tips.