Replies: 3 comments 8 replies
-
|
TL;DR: This is a sufficiently weird edge case (and probably an upstream issue) and can probably be safely ignored. @Elliria You really are good at breaking things! LOL Never did anything that would recreate this error. It is a rather obscure case, but it is undesirable behavior. Maybe there is some confusion between parent window and current window. First guess is that this is a shortcoming or bug in Zenity since that is what autokey-gtk calls for dialog functionality. This leads in two directions. If this is a Zenity bug, then maybe there is a way to reproduce it without using AutoKey. I believe it would have to be something convoluted like a bash script launched in a terminal which launches another script asynchronously (ending the command line with an ampersand) and having the new script invoke Zenity after opening or switching to another window while the original script is still running or at least sleeping. Coding something like this would be quite easy. Knowing exactly what sequence to code is where the difficulty arises. I know just enough about visible/invisibe and active/inactive windows to be thoroughly confused about what's actually going on here and how to recreate it. The other side of this is that if we can identify precisely when this occurs (still assuming it's an artifact of Zenity design/implementation), we shoud be able to detect when this situation occurs and issue some (wmctrl?) commands to normalize it. This assumes that when Zenity has been called and has not terminated and returned to the caller, there is a way to run anything instead of being stuck waiting for it to return. Maybe someone on the Zenity team could provide some insight. I'm not sure where to find them. The community appears to be here, but maybe stackoverflow or askubuntu woud be better. |
Beta Was this translation helpful? Give feedback.
-
|
The relationship between Kubuntu and Linux Mint is very odd. e.g: In Ku, the mouse acceleration control is readily available in GUI. In LM, I must search for it in the dconf-editor, after researching the web. This is a design simplification by LM, which is a time saver for the developers, but there is no documentation, unless a kind soul bothered to post it somewhere in conjunction with Autokey, that mouse acceleration should be flat. This change reduced my numerous mouse related navigation problems. |
Beta Was this translation helpful? Give feedback.
-
|
That should be in our wiki somewhere if it isn't already. Hopefully, it should include some discussion of what goes wrong when it is enabled. My acceleration happens to be at 0, but primarily because manual dexterity has never been my strong suit. I bet a lot of people use it - especially gamers. |
Beta Was this translation helpful? Give feedback.
-
Okay. It should probably be noted, though, in case others run into it during testing.
I know. Right? I need to find a way to get paid for it.
You can run AutoKey's GTK front-end from a terminal window that remains open and your dialogs will sit on top of AutoKey or any other window and not just on top of the terminal window? I'll see if I can get any more information from the Zenity team to see if there's some sort of parent-window issue that they're aware of. I suppose that it's possible they don't know about it because it only happens if there's a parent window that happens to be a child window of another window. |
Beta Was this translation helpful? Give feedback.
-
I don't see one in Kubuntu, either, but these are my window focus settings:
Perhaps one of them is to blame, but I like how the focus works on my system and don't have focus issues with any other programs, so monkeying with those might cause problems. |
Beta Was this translation helpful? Give feedback.
-
I believe Chris Deckter's (AutoKey Author) job is something like test engineer. So he probably breaks things for a living and designs tests to detect such breakages by others. Looks like there might be almost a quarter of a million job openings for that in the USA if those numbers are at all reliable. |
Beta Was this translation helpful? Give feedback.
-
|
I get the same behavior on Linux mint when joining a new wifi network. The
dialog box prompting for the wifi password often shows up below others with
the only clue that this has happened being a red tray icon.
…On Thu, May 11, 2023, 6:35 AM Joe ***@***.***> wrote:
That should be in our wiki somewhere if it isn't already. Hopefully, it
shoud include some discussion of what goes wrong when it is enabled.
My acceleration happens to be at 0, but primarily because manual dexterity
has never been my strong suit. I bet a lot of people use it - especially
gamers.
—
Reply to this email directly, view it on GitHub
<#857 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAYJEQQJHB2C6LRJXTVW5QLXFS6GDANCNFSM6AAAAAAX3YUPYA>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
The behavior I see, in the scenario above, is similar, but there's no indication that another window has opened, so unless you happen to know to go looking behind your existing windows, your repeated clicks to try to get a dialog will just keep piling up the dialogs and you'll only see them all once you start closing or moving the ones that are there. |
Beta Was this translation helpful? Give feedback.
-
|
@darenschwenke Glad to see you're still around! I assume you mean that this occurs without any involvement by AutoKey. I revoked your developer access, but I'd be happy to restore it if you are ever inclined to contribute again. (The "maintainer" tag still shows up on your post, but I don't see your account having any special access.) |
Beta Was this translation helpful? Give feedback.
-
I discovered something that may be considered an issue in the GTK front-end of AutoKey. It's present in the development version, in AutoKey 0.96.0, and in AutoKey 0.95.10. It may also be in earlier versions, but I didn't test those.
When I run AutoKey from a terminal window and run a script that has
dialog.info_dialog("HELLO WORLD")as its contents, the dialog appears on top of the terminal, but behind the current window. It doesn't matter whether the current window is AutoKey's main window or that of some other program. If I minimize the terminal window and trigger the script, no dialog is shown until I unminimize the terminal window, at which point, the dialog is shown on top of it. If I minimize the terminal window again, it takes the dialog along with it.The dialog is on top of all windows when the GTK front-end of AutoKey isn't run from a terminal (when it's run from the main menu or a shortcut). The behavior can be seen, however, if the shortcut is configured to run in a terminal window, although that's not a default shortcut setting.
This behavior isn't seen in the Qt front-end of AutoKey, which always displays all dialogs on top of any open window(s) or on the desktop if the terminal window is minimized. It's possible that my KDE environment in Kubuntu 22.04 LTS plays a role in that, since Qt is native here and GTK isn't.
Is this expected behavior or an issue that I should report?
Beta Was this translation helpful? Give feedback.
All reactions