Is it possible to make AutoKey "reload"-friendly? Or, to "reload" on demand through Hotkeys?

340 views
Skip to first unread message

Linfeng Li

unread,
Feb 18, 2020, 9:42:01 PM2/18/20
to autokey-users
I plan to sync AutoKey settings on a number of Linux machines through Dropbox. I have learned per Joe's post how things are stored and sourced in AutoKey, and plan to conver my lengthy *.ahk script into a good number of AutoKey scripts and configuration files.

Yet, I wonder if I can get AutoKey to accept remote changes to the local folders **without** actively opening/closing the AutoKey window? For example, through a Hotkey + some script?

Please advise if there are CLI arguments to host AutoKey processes in the background, and either source/reload AutoKey settings according to the source folder on "file-change", or open/close AutoKey window every other minute or so?

Without reloading, despite remote changes to the local setting files are recognized, but not updated through the editor window. This creates confusion and will potentially lead to file-conflicts. One alternatively is to allow for file-changes within the AutoKey window to acknowledge and update the script that were changed?

Linfeng Li

unread,
Feb 18, 2020, 10:04:33 PM2/18/20
to autokey-users
I should take back what I typed previously. On Linux Mint, AutoKey seating in the system tray is actively registering new hotkey-settings configured on remote machines, synced through a shared Dropbox folder.

Manually reload the script is only relevant when one introduces the shared folder to AutoKey for the first time: to have AutoKey start sourcing files in the shared folder, it is necessary to quit the process through the icon in the system tray, and reopen AutoKey. (This is tested on my third AutoKey installation on my second Linux Mint machine.)

Keith Bainbridge

unread,
Feb 19, 2020, 12:23:08 AM2/19/20
to autoke...@googlegroups.com
G'day

How is this different in Mint, from how autokey reacts in other
installations of Mate, Cinnamon or xfce, please?


Keith Bainbridge

keith.bain...@gmail.com
0447 667 468

Linfeng Li

unread,
Feb 19, 2020, 7:39:25 AM2/19/20
to autokey-users
The latest release (0.95.10) worked out of the box on both Mate and Cinnamon. xfce not tested yet. The AutoKey icon lives happily on the system tray, and all hotkey remain responsive after closing the GUI window. Further, after "reboot", the AutoKey process without a GUI window shall reliably source changes in the folders that were "added" to it as new. (I am adding the same Dropbox folder to both installations of AutoKey, by first clicking on the "New" button in the GUI window and selecting the folder accordingly. To have AutoKey start sourcing from the assigned "new" folders, one needs to close it through system tray and re-open again.)

On Pop!_OS 19.10, AutoKey does not show up on the system tray, and will quit completely should I close the GUI window. Will update this post should I find re-doing the Pop!_OS installation on my Thinkpad X230T machine fixes anything.


On Wednesday, February 19, 2020 at 12:23:08 AM UTC-5, Keith Bainbridge wrote:
G'day

How is this different in Mint, from how autokey reacts in other
installations of Mate, Cinnamon or xfce, please?


Keith Bainbridge

Joe

unread,
Feb 19, 2020, 10:24:37 AM2/19/20
to autoke...@googlegroups.com
I don't know the AutoKey source code, but:

The way I think it works is that when you modify the body of an existing
script/phrase, AutoKey just gets the new version when it runs it. It's
just a couple of files, not some data structure stored elsewhere. But,
if you're adding a new script/phrase, I don't think it will be noticed
without restarting AutoKey. I would also guess this would apply if you
changed the trigger phrase or hotkey.

Running man autokey or autokey --help will show you what CLI options are
available. There are very few none of which will help in this case.

Normally, when AutoKey is launched, it does not display its main window.
You can force it to do so with the -c command line switch.

See my replies to your subsequent posts.

Joe

On 2/18/20 9:42 PM, Linfeng Li wrote:
> I plan to sync AutoKey settings on a number of Linux machines through
> Dropbox. I have learned per Joe's post
> <https://groups.google.com/forum/#!searchin/autokey-users/source$20scripts%7Csort:date/autokey-users/qQ-zy51HURU/hweXkwCQBQAJ>
> how things are stored and sourced in AutoKey, and plan to conver my
> lengthy *.ahk script into a good number of AutoKey scripts and
> configuration files.
>
> Yet, I wonder if I can get AutoKey to accept remote changes to the
> local folders **without** actively opening/closing the AutoKey window?
> For example, through a Hotkey + some script?
>
> Please advise if there are CLI arguments to host AutoKey processes in
> the background, and either source/reload AutoKey settings according to
> the source folder on "file-change", or open/close AutoKey window every
> other minute or so?
>
> Without /reloading/, despite remote changes to the local setting files
> are recognized, but not updated through the editor window. This
> creates confusion and will potentially lead to file-conflicts. One
> alternatively is to allow for file-changes within the AutoKey window
> to acknowledge and update the script that were changed?
> --
> You received this message because you are subscribed to the Google
> Groups "autokey-users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to autokey-user...@googlegroups.com
> <mailto:autokey-user...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/autokey-users/b09fa5a6-f5d6-4509-8067-5691ec552bcf%40googlegroups.com
> <https://groups.google.com/d/msgid/autokey-users/b09fa5a6-f5d6-4509-8067-5691ec552bcf%40googlegroups.com?utm_medium=email&utm_source=footer>.

Joe

unread,
Feb 19, 2020, 10:29:43 AM2/19/20
to autoke...@googlegroups.com
Although AutoKey sometimes sees changes to its files while it's running,
I wouldn't rely on that working. I haven't stopped to analyze it when
things like that have gone wrong. I have just restarted AutoKey.

Joe

On 2/18/20 10:04 PM, Linfeng Li wrote:
> I should take back what I typed previously. On Linux Mint, AutoKey
> seating in the system tray is actively registering new hotkey-settings
> configured on remote machines, synced through a shared Dropbox folder.
>
> Manually reload the script is only relevant when one introduces the
> shared folder to AutoKey for the first time: to have AutoKey start
> sourcing files in the shared folder, it is necessary to quit the
> process through the icon in the system tray, and reopen AutoKey. (This
> is tested on my third AutoKey installation on my second Linux Mint
> machine.)
>
> On Tuesday, February 18, 2020 at 9:42:01 PM UTC-5, Linfeng Li wrote:
>
> I plan to sync AutoKey settings on a number of Linux machines
> through Dropbox. I have learned per Joe's post
> <https://groups.google.com/forum/#!searchin/autokey-users/source$20scripts%7Csort:date/autokey-users/qQ-zy51HURU/hweXkwCQBQAJ>
> how things are stored and sourced in AutoKey, and plan to conver
> my lengthy *.ahk script into a good number of AutoKey scripts and
> configuration files.
>
> Yet, I wonder if I can get AutoKey to accept remote changes to the
> local folders **without** actively opening/closing the AutoKey
> window? For example, through a Hotkey + some script?
>
> Please advise if there are CLI arguments to host AutoKey processes
> in the background, and either source/reload AutoKey settings
> according to the source folder on "file-change", or open/close
> AutoKey window every other minute or so?
>
> Without /reloading/, despite remote changes to the local setting
> files are recognized, but not updated through the editor window.
> This creates confusion and will potentially lead to
> file-conflicts. One alternatively is to allow for file-changes
> within the AutoKey window to acknowledge and update the script
> that were changed?
>
> --
> You received this message because you are subscribed to the Google
> Groups "autokey-users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to autokey-user...@googlegroups.com
> <mailto:autokey-user...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/autokey-users/f38481a2-bbb0-464b-bbc1-f618d604241f%40googlegroups.com
> <https://groups.google.com/d/msgid/autokey-users/f38481a2-bbb0-464b-bbc1-f618d604241f%40googlegroups.com?utm_medium=email&utm_source=footer>.

Joe

unread,
Feb 19, 2020, 11:02:17 AM2/19/20
to autoke...@googlegroups.com
There should be a way to get your icon in the Pop!_OS system tray. If
you can't easily solve this, you should consider asking on their support
forums, etc. or create an AutoKey issue at
https://github.com/autokey/autokey/issues .

Linux has  inotifywatch and inotifywait commands which can monitor files
and directories for changes.

https://askubuntu.com/questions/819265/bash-script-to-monitor-file-change-and-execute-command

You could write a bash script using these commands and install it on
your target machines.

It would do something like the following:

If nothing has changed, do nothing.
Is AutoKey running? If not, do nothing.
Restart AutoKey using bash code like in my previous reply.

This could be implemented as an infinite loop with a long sleep command
in the middle so it doesn't check too frequently or as a cron job.

Possible issue: If the machine is being actively used when this check
occurs, it might kill AutoKey while it is in the middle of doing
something. I'm not clear on how to avoid this (at least not without a
lot of overhead.)

Most AutoKey scripts do one thing relatively quickly and finish, but it
is possible to write scripts that continue to run for a long time. These
would be most vulnerable.

I have posted a question on Gitter about this general topic. You can see
it and/or join in the conversation here: https://gitter.im/autokey/autokey

Joe

On 2/19/20 7:39 AM, Linfeng Li wrote:
> The latest release (0.95.10) worked out of the box on both Mate and
> Cinnamon. xfce not tested yet. The AutoKey icon lives happily on the
> system tray, and all hotkey remain responsive after closing the GUI
> window. Further, after "reboot", the AutoKey process without a GUI
> window shall reliably source changes in the folders that were "added"
> to it as new. (I am adding the same Dropbox folder to both
> installations of AutoKey, by first clicking on the "New" button in the
> GUI window and selecting the folder accordingly. To have AutoKey start
> sourcing from the assigned "new" folders, one needs to close it
> through system tray and re-open again.)
>
> On Pop!_OS 19.10, AutoKey does not show up on the system tray, and
> will quit completely should I close the GUI window. Will update this
> post should I find re-doing the Pop!_OS installation on my Thinkpad
> X230T machine fixes anything.
>
> On Wednesday, February 19, 2020 at 12:23:08 AM UTC-5, Keith Bainbridge
> wrote:
>
> G'day
>
> How is this different in Mint, from how autokey reacts in other
> installations of Mate, Cinnamon or xfce, please?
>
>
> Keith Bainbridge
>
> keith.bai...@gmail.com <javascript:>
> 0447 667 468
>
> On 19/2/20 2:04 pm, Linfeng Li wrote:
> > I should take back what I typed previously. On Linux Mint, AutoKey
> > seating in the system tray is actively registering new
> hotkey-settings
> > configured on remote machines, synced through a shared Dropbox
> folder.
>
> --
> You received this message because you are subscribed to the Google
> Groups "autokey-users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to autokey-user...@googlegroups.com
> <mailto:autokey-user...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/autokey-users/a2c583c0-eaa1-49b5-af05-61f8df234e4e%40googlegroups.com
> <https://groups.google.com/d/msgid/autokey-users/a2c583c0-eaa1-49b5-af05-61f8df234e4e%40googlegroups.com?utm_medium=email&utm_source=footer>.

Joe

unread,
Feb 19, 2020, 11:19:36 AM2/19/20
to autoke...@googlegroups.com
Just thought of another issue:

If the user on the target machine has the AutoKey main window open and
is doing something - especially if they are modifying a script or
phrase, they would be very unhappy if AutoKey suddenly closed and
restarted, losing all their changes.

We'll see what the developers say. The more I think about  it, the more
obvious it becomes that AutoKey itself should handle this situation
gracefully.

Joe

Little Girl

unread,
Feb 25, 2020, 3:11:58 PM2/25/20
to autoke...@googlegroups.com
Hey there,

This thread was in my Gmail spam folder and I happened to check that
today, so I'm replying to this a bit late, but hopefully it will
still be useful.

Joe wrote:
>On 2/19/20 7:39 AM, Linfeng Li wrote:

>> On Pop!_OS 19.10, AutoKey does not show up on the system tray, and
>> will quit completely should I close the GUI window. Will update
>> this post should I find re-doing the Pop!_OS installation on my
>> Thinkpad X230T machine fixes anything.
>
>There should be a way to get your icon in the Pop!_OS system tray. If
>you can't easily solve this, you should consider asking on their
>support forums, etc. or create an AutoKey issue at
>https://github.com/autokey/autokey/issues .

This isn't quite the same issue the OP is having, but while we're on
the subject of vanishing tray icons, I thought I'd mention that the
tray icon has vanished more than once for me when I was trying to
click "Show Main Window" in the AutoKey context menu and accidentally
clicked "Remove icon" because they're mighty close together.

To restore the icon in my outdated version of AutoKey, I shut down
AutoKey by killing its process on the command line, edited the
~/.config/autokey/autokey.json file, changed the "showTrayIcon" entry
from false to true, saved the file, and relaunched AutoKey.

I noticed that the current AutoKey release has replaced "Remove icon"
with "Temporarily Hide Icon" which means I won't be needing to edit
that .json file any more, but I suspect that the close proximity
of those two menu entries will mean that I'll still be needing to
force kill AutoKey from time to time and restart it so I can recover
from my own blunder.

In the event that I'm not the only careless clicker in the world, I'd
suggest either moving the icon-hiding option to a sub-menu so it
can't accidentally be clicked or making its presence in the context
menu an optional configuration choice that isn't enabled by default.

--
Little Girl

There is no spoon.

Keith Bainbridge

unread,
Feb 25, 2020, 5:12:30 PM2/25/20
to autoke...@googlegroups.com
On 26/2/20 7:11 am, Joe wrote:
>> There should be a way to get your icon in the Pop!_OS system tray. If
>> you can't easily solve this, you should consider asking on their
>> support forums, etc. or create an AutoKey issue at
>> https://github.com/autokey/autokey/issues .

DistroWatch says it's a gnome desktop, and based on ubuntu.

Linfeng, have you installed a different desktop?
--
Keith Bainbridge

keith.bain...@gmail.com
+61 (0)447 667 468

Linfeng Li

unread,
Feb 25, 2020, 6:07:49 PM2/25/20
to autokey-users
RE: Linux Mint xfce 19.3 ==> it worked flawlessly as well, both the tray icon and reopen upon reboot. I installed manually, by pulling for two installer files from the latest release, first the *common* file and then the *gtk* file. I also manually "sourced" a shared Dropbox folder, by clicking on the New button to appoint the desired Dropbox folder, shut down the process through Tray icon, and restart the Autokey process.

Should I have a completely customized AutoKey script, I think it is doable to reload a Linux (Mint) installation with all hotkeys that I need within minutes.

Though, I am shirking away from fully turning to Linux Mint for production: I have a good collection of redundant AHK stuff that I need to convert, and I haven't packed properly to start the journey :)

Linfeng Li

unread,
Feb 25, 2020, 6:09:09 PM2/25/20
to autokey-users
I summon the AutoKey window with its pre-defined hotkey. This may avoid accidentally clicking on irrelevant menu items.

Joe

unread,
Feb 27, 2020, 3:13:06 AM2/27/20
to autoke...@googlegroups.com
The current version of AutoKey has the Hide Icon and Show main window
icon in a sub-menu at the top of the icon context menu (accessed by
right clicking on the AutoKey tray icon.) However, just left clicking on
the tray icon, should open the main window without using the context
menu at all.

You can also get the main window to display with the CLI commands
autokey-qt -c or autokey-gtk -c. This won't start a second instance of
AutoKey.

The main thing I use the AutoKey Icon context menu for is to launch a
bunch of AutoKey scripts that have no hotkey or trigger phrase assigned.
I put them in there instead because I use them infrequently and don't
want to memorize a new hotkey or trigger phrase for each of them. I also
use the View script error button when debugging scripts.

Probably not the issue here, but it is possible to select the "wrong"
AutoKey icon for your desktop theme - dark icon on dark background or
light icon on light background which can make the icon invisible even
though it's there. (Settings->Configure AutoKey->System Tray Icon->Used
system tray icon theme.)

Joe

Joe

unread,
Feb 27, 2020, 3:18:28 AM2/27/20
to autoke...@googlegroups.com
If you'd like a new option for displaying or hiding a menu option (or
any other enhancement), feel free to open an enhancement request issue
at https://github.com/autokey/autokey/issues .

Joe

On 2/25/20 3:11 PM, Little Girl wrote:

Little Girl

unread,
Feb 28, 2020, 8:40:34 PM2/28/20
to autoke...@googlegroups.com
Hey there,

Joe wrote:

>The current version of AutoKey has the Hide Icon and Show main window
>icon in a sub-menu at the top of the icon context menu (accessed by
>right clicking on the AutoKey tray icon.)

Hmmm. I must have seen a different version. I grabbed the Kubuntu
20.02 daily build and installed AutoKey and that one (I didn't note
the version because I assumed it was the latest) had them in the
context menu rather than in a sub-menu off of the context menu. The
sub-menu would definitely be an improvement for the icon hiding
feature, but if the show main window feature is in the sub-menu with
it, then the same mis-click could still occur.

>However, just left clicking on the tray icon, should open the main
>window without using the context menu at all.

I noticed that. It will take me a little while to get used to that
since I've been left-clicking the icon to access the context menu in
the old version that I'm still using in this operating system. Once
I'm used to it, though, that will be handy.

>You can also get the main window to display with the CLI commands
>autokey-qt -c or autokey-gtk -c. This won't start a second instance
>of AutoKey.

Yep, I've seen that as well (in the man page) and I added the -c
option to the AutoKey shortcut in my menu since I like seeing the main
window when I first launch AutoKey.

>The main thing I use the AutoKey Icon context menu for is to launch a
>bunch of AutoKey scripts that have no hotkey or trigger phrase
>assigned. I put them in there instead because I use them
>infrequently and don't want to memorize a new hotkey or trigger
>phrase for each of them.

I use the context menu for testing out new scripts that I haven't set
a trigger phrase for yet. I've also put the script for taking a
screenshot of the current window into it since it's nice to have a
one-click way to do that.

>I also use the View script error button when debugging scripts.

Same here. Major kudos to the person who thought of adding that
feature.

>Probably not the issue here, but it is possible to select the "wrong"
>AutoKey icon for your desktop theme - dark icon on dark background or
>light icon on light background which can make the icon invisible even
>though it's there. (Settings->Configure AutoKey->System Tray
>Icon->Used system tray icon theme.)

I saw that. That's very nice. I think this is the first time I've
seen any program offer such a thing. Some more major kudos to the
person who thought of doing that.

Little Girl

unread,
Feb 28, 2020, 8:40:35 PM2/28/20
to autoke...@googlegroups.com
Hey there,

Joe wrote:

>If you'd like a new option for displaying or hiding a menu option (or
>any other enhancement), feel free to open an enhancement request
>issue at https://github.com/autokey/autokey/issues .

Oh, no need. It was just an observation.

Joe

unread,
Feb 29, 2020, 6:03:09 AM2/29/20
to autoke...@googlegroups.com
Inline.

Joe

On 2/28/20 8:38 PM, Little Girl wrote:
> Hey there,
>
> Joe wrote:
>
>> The current version of AutoKey has the Hide Icon and Show main window
>> icon in a sub-menu at the top of the icon context menu (accessed by
>> right clicking on the AutoKey tray icon.)
> Hmmm. I must have seen a different version. I grabbed the Kubuntu
> 20.02 daily build and installed AutoKey and that one (I didn't note
> the version because I assumed it was the latest) had them in the
> context menu rather than in a sub-menu off of the context menu. The
> sub-menu would definitely be an improvement for the icon hiding
> feature, but if the show main window feature is in the sub-menu with
> it, then the same mis-click could still occur.

It is a submenu (sort-of), but it is displayed at the same time as the
rest of the options, so it is "vulnerable" to that sort of error.

If you would like it (optionally?) hidden, then that would be a
reasonable feature request to file. (Not saying that it will or won't
get done, but it would get considered.)

>> However, just left clicking on the tray icon, should open the main
>> window without using the context menu at all.
> I noticed that. It will take me a little while to get used to that
> since I've been left-clicking the icon to access the context menu in
> the old version that I'm still using in this operating system. Once
> I'm used to it, though, that will be handy.
Except when IIRC it was broken for awhile, it always did that.
>
>> You can also get the main window to display with the CLI commands
>> autokey-qt -c or autokey-gtk -c. This won't start a second instance
>> of AutoKey.
> Yep, I've seen that as well (in the man page) and I added the -c
> option to the AutoKey shortcut in my menu since I like seeing the main
> window when I first launch AutoKey.
>
>> The main thing I use the AutoKey Icon context menu for is to launch a
>> bunch of AutoKey scripts that have no hotkey or trigger phrase
>> assigned. I put them in there instead because I use them
>> infrequently and don't want to memorize a new hotkey or trigger
>> phrase for each of them.
> I use the context menu for testing out new scripts that I haven't set
> a trigger phrase for yet. I've also put the script for taking a
> screenshot of the current window into it since it's nice to have a
> one-click way to do that.
What do you use for screenshots? I was using ksnapshot, but it was
replaced by Spectacle which I didn't really like. Now, I'm using shutter
which is pretty good, but getting it to take screenshots is not very
convenient. I usually take rectangular regions, not the whole screen
and, rarely, screenshots with a delay timer to set up the shot.
>> I also use the View script error button when debugging scripts.
> Same here. Major kudos to the person who thought of adding that
> feature.
That would be Chris Deckter, the original author.
>
>> Probably not the issue here, but it is possible to select the "wrong"
>> AutoKey icon for your desktop theme - dark icon on dark background or
>> light icon on light background which can make the icon invisible even
>> though it's there. (Settings->Configure AutoKey->System Tray
>> Icon->Used system tray icon theme.)
> I saw that. That's very nice. I think this is the first time I've
> seen any program offer such a thing. Some more major kudos to the
> person who thought of doing that.

I'm not sure who added that, but I think it was after Chris left. Might
have been Troy or Thomas.

It was definitely needed. I had an invisible icon for awhile and
manually replaced the icon file to fix it.

>

Joe

unread,
Feb 29, 2020, 6:12:28 AM2/29/20
to autoke...@googlegroups.com

On 2/28/20 8:40 PM, Little Girl wrote:
> Hey there,
>
> Joe wrote:
>
>> If you'd like a new option for displaying or hiding a menu option (or
>> any other enhancement), feel free to open an enhancement request
>> issue at https://github.com/autokey/autokey/issues .
> Oh, no need. It was just an observation.
>
No problem. I just want to make it clear that all users can submit
requests. Even if the exact thing that's requested doesn't get
implemented, the discussion around it may lead to a better product.

User feedback is really important for end user products such as AutoKey.
Developers have a very different view of what's useful than a typical
user does, so they need the feedback.

Joe


Little Girl

unread,
Feb 29, 2020, 4:02:45 PM2/29/20
to autokey-users
Hey there,

Joe wrote:
>Little Girl wrote:

>> Joe wrote:
 
>> The sub-menu would definitely be an improvement for the icon
>> hiding feature, but if the show main window feature is in the
>> sub-menu with it, then the same mis-click could still occur. 

>It is a submenu (sort-of), but it is displayed at the same time as
>the rest of the options, so it is "vulnerable" to that sort of error.

I see. So it's a section within the context menu.


>If you would like it (optionally?) hidden, then that would be a
>reasonable feature request to file. (Not saying that it will or won't
>get done, but it would get considered.)

That shouldn't be necessary once I get used to left-clicking the icon
to open the main window.


>> It will take me a little while to get used to that since I've been
>> left-clicking the icon to access the context menu in the old
>> version that I'm still using in this operating system. Once I'm
>> used to it, though, that will be handy. 

>Except when IIRC it was broken for awhile, it always did that.

That explains it. My only experience with AutoKey so far has been
with it in its broken state until recently.

 
>What do you use for screenshots? I was using ksnapshot, but it was
>replaced by Spectacle which I didn't really like. Now, I'm using
>shutter which is pretty good, but getting it to take screenshots is
>not very convenient. I usually take rectangular regions, not the
>whole screen and, rarely, screenshots with a delay timer to set up
>the shot.

I use mate-screenshot because I'm currently using Ubuntu MATE. I'll
be switching back to Kubuntu in April, so I'll be using Spectacle.

I grabbed Shutter in my Kubuntu VM, but that pulled in a heck of a
lot of packages, so I'm unlikely to use that after I switch back to
Kubuntu. I ended up messing around with Spectacle and Shutter and
updated my script, which started from one of the AutoKey script
examples. It currently has code that will work for Ubuntu, Ubuntu
MATE, Kubuntu with Spectacle, and Kubuntu with Shutter.

It needs to be customized before use, but instructions are in the
script. It wants to be streamlined further to get rid of the
repetitious code, but I'm not a Python scripter and I fell over hard
just trying to get it to accept a variable for the path and file
name, so one of you might want to make it sleeker if you want to add
it to the example scripts.

Without further ado, here it is:

# THIS SCRIPT:
   
# deletes the my_screenshot.png file from the desktop if it exists
   
# takes a screenshot of the current window
   
# saves the screenshot as the my_screenshot.png file on the desktop
   
# started here: https://github.com/autokey/autokey/wiki/Scripting

# CUSTOMIZE THIS SCRIPT:
   
# Enable the flavor line below that corresponds to your operating system.
   
# Change all instances of ~/Desktop/ to the directory you prefer for the screenshot.
   
# Change all instances of my_screenshot.png to the file name you prefer for the screenshot.

# CHOOSE YOUR UBUNTU FLAVOR:
#flavor = "kubuntu"
#flavor = "kubuntu_with_shutter"
#flavor = "ubuntu"
flavor
= "ubuntu_mate"

# TASK FOR ALL FLAVORS:
system
.exec_command("bash -c 'rm ~/Desktop/my_screenshot.png'",False)

# FLAVOR-SPECIFIC TASKS:
if flavor == "kubuntu":
    system
.exec_command("spectacle -a -b -o ~/Desktop/my_screenshot.png")
elif flavor == "kubuntu_with_shutter":
    system
.exec_command("shutter -a -e -o ~/Desktop/my_screenshot.png")
elif flavor == "ubuntu":
    system
.exec_command("gnome-screenshot -w", False)
    window
.wait_for_exist("Save Screenshot", timeOut=5)
    window
.activate("Save Screenshot", switchDesktop=False)
    keyboard
.send_keys("my_screenshot")
elif flavor == "ubuntu_mate":
    system
.exec_command("mate-screenshot -w", False)
    window
.wait_for_exist("Save Screenshot", timeOut=5)
    window
.activate("Save Screenshot", switchDesktop=False)
    keyboard
.send_keys("my_screenshot")
else:
   
pass


>>> I also use the View script error button when debugging scripts.
>> Same here. Major kudos to the person who thought of adding that
>> feature.

>That would be Chris Deckter, the original author.

Thank you, Chris. That's a very useful feature that's already gotten
me out of several pickles since Python is not my strong point.

 
>>> Probably not the issue here, but it is possible to select the
>>> "wrong" AutoKey icon for your desktop theme - dark icon on dark
>>> background or light icon on light background which can make the
>>> icon invisible even though it's there. (Settings->Configure
>>> AutoKey->System Tray Icon->Used system tray icon theme.) 

>> I saw that. That's very nice. I think this is the first time I've
>> seen any program offer such a thing. Some more major kudos to the
>> person who thought of doing that. 

>I'm not sure who added that, but I think it was after Chris left.
>Might have been Troy or Thomas.

My thanks to either or both of them.


>It was definitely needed. I had an invisible icon for awhile and
>manually replaced the icon file to fix it.

Yeah. The alternative is to make a single icon that contains light and
dark colors that each go out to the edge. That way it will always be
visible no matter what.

Joe

unread,
Mar 1, 2020, 2:22:40 AM3/1/20
to autoke...@googlegroups.com
> ifflavor =="kubuntu":
>     system.exec_command("spectacle -a -b -o ~/Desktop/my_screenshot.png")
> elifflavor =="kubuntu_with_shutter":
>     system.exec_command("shutter -a -e -o ~/Desktop/my_screenshot.png")
> elifflavor =="ubuntu":
>     system.exec_command("gnome-screenshot -w",False)
>     window.wait_for_exist("Save Screenshot",timeOut=5)
>     window.activate("Save Screenshot",switchDesktop=False)
>     keyboard.send_keys("my_screenshot")
> elifflavor =="ubuntu_mate":
>     system.exec_command("mate-screenshot -w",False)
>     window.wait_for_exist("Save Screenshot",timeOut=5)
>     window.activate("Save Screenshot",switchDesktop=False)
>     keyboard.send_keys("my_screenshot")
> else:
>     pass
>
> |
>
> >>> I also use the View script error button when debugging scripts.
> >> Same here. Major kudos to the person who thought of adding that
> >> feature.
>
> >That would be Chris Deckter, the original author.
>
> Thank you, Chris. That's a very useful feature that's already gotten
> me out of several pickles since Python is not my strong point.
>  
> >>> Probably not the issue here, but it is possible to select the
> >>> "wrong" AutoKey icon for your desktop theme - dark icon on dark
> >>> background or light icon on light background which can make the
> >>> icon invisible even though it's there. (Settings->Configure
> >>> AutoKey->System Tray Icon->Used system tray icon theme.) 
>
> >> I saw that. That's very nice. I think this is the first time I've
> >> seen any program offer such a thing. Some more major kudos to the
> >> person who thought of doing that. 
>
> >I'm not sure who added that, but I think it was after Chris left.
> >Might have been Troy or Thomas.
>
> My thanks to either or both of them.

AFAIK, none of the devs follow this list (and Chris doesn't follow the
project at all any more.)

However, most of the rest, including a couple of inactive ones are still
members of our Gitter group, so if you want to thank them, etc., come on
over to Gitter where they will see it. Gitter is very slick and very
easy to use.

>
> >It was definitely needed. I had an invisible icon for awhile and
> >manually replaced the icon file to fix it.
>
> Yeah. The alternative is to make a single icon that contains light and
> dark colors that each go out to the edge. That way it will always be
> visible no matter what.
>
> --
> You received this message because you are subscribed to the Google
> Groups "autokey-users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to autokey-user...@googlegroups.com
> <mailto:autokey-user...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/autokey-users/2250966e-b14c-40e8-b9a4-c346cc541e69%40googlegroups.com
> <https://groups.google.com/d/msgid/autokey-users/2250966e-b14c-40e8-b9a4-c346cc541e69%40googlegroups.com?utm_medium=email&utm_source=footer>.

Thanks for the script.

I didn't think of making an AutoKey script for this. Duh!

I'll play with it when I get a chance.

I'll have to have a good look at the CLI switches the programs offer to
see if I can get them to do what I want.

I might also adapt the function which generates file names on the fly
for my print2file script so I can save multiple screenshots.

Joe

.directory

Little Girl

unread,
Mar 1, 2020, 5:18:15 PM3/1/20
to autoke...@googlegroups.com
Hey there,

Joe wrote:
>Little Girl wrote:
>> Joe wrote:

[Re: view script error button]
>> That would be Chris Deckter, the original author.
>
> Thank you, Chris. That's a very useful feature that's already gotten
> me out of several pickles since Python is not my strong point.

[Re: customizable dark and light icon]
>> >I'm not sure who added that, but I think it was after Chris left.
>> >Might have been Troy or Thomas.
>>
>> My thanks to either or both of them.
>
>AFAIK, none of the devs follow this list (and Chris doesn't follow
>the project at all any more.)

>However, most of the rest, including a couple of inactive ones are
>still members of our Gitter group, so if you want to thank them,
>etc., come on over to Gitter where they will see it. Gitter is very
>slick and very easy to use.

I'll drop in some time on my Elliria account.

>Thanks for the script.

Any time.

>I didn't think of making an AutoKey script for this. Duh!

Me neither. It started out from one that was on the
https://github.com/autokey/autokey/wiki/Scripting page that I
discovered after seeing it mentioned on this list a few days ago. I
just added to it. I like the fact that it just takes the screenshot
without you having to make decisions, unlike the default MATE
screenshot interface.

>I'll play with it when I get a chance.

I look forward to it. I'll end up messing with it later, too, as my
Python skills improve. Right now I cobble together some clumsy
scripts that end up accidentally working, but could be done in a much
more elegant way by someone with a deeper understanding of Python.

>I'll have to have a good look at the CLI switches the programs offer
>to see if I can get them to do what I want.

When I use that AutoKey script, my Ubuntu MATE screenshot program
doesn't just take the screenshot and save it to the desktop the way
your Kubuntu screenshot programs do. It actually takes the screenshot
and then drops me into the final screen of the mate-screenshot
interface where it fills in the file name automatically. I still have
to click the "Save" button to finish the process, but while I'm
there, I can change the file name if I like.

I'm sure your script would work in a similar way. The man page
mentions selecting an area as one of the options, so you could script
it to put you at that point in the screenshot-taking process. I may
take a look at that a bit later today. I had to reinstall my Kubuntu
VM today and haven't yet reinstalled Shutter.

>I might also adapt the function which generates file names on the fly
>for my print2file script so I can save multiple screenshots.

That's actually a good idea for an option to add to that script in
general since I'm sure there will be others who don't want to
overwrite an existing screenshot and would rather make an incremented
or randomly-named collection of them instead.
Reply all
Reply to author
Forward
0 new messages