xdo
whkd
xdo | whkd | |
---|---|---|
5 | 5 | |
294 | 356 | |
- | - | |
0.0 | 3.9 | |
9 months ago | 28 days ago | |
C | Rust | |
BSD 2-clause "Simplified" License | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
xdo
- Somehow AutoHotKey is kinda good now
-
How to limit a single app run?
An example with xdo:
-
Open app in the background
I might have understood your question wrong, if you want to close the GUI window after staring the app you'd want to take a look at xdo. I'd still give it a little bit of time after starting it to be ready and then use something like:
-
Keybind to center floating window?
xdo (by baskerville, bspwm's creator);
-
Update regarding Steam + DWM + focusonnetactive
The focusonnetactive patch replaces dwm's default behavior by removing the urgency bit to allow for focusing on the client sending the _NET_ACTIVE_WINDOW message instead. This is the preferred behavior if you use tools like xdo to perform actions on windows, for example:
whkd
-
WSL and Vim development setup
in powertoys, find a feature called “keyboard manager”. if you want to go deep into keymapping in windows, checkout autohotkey and whkd
-
Somehow AutoHotKey is kinda good now
It was only when I started writing my own sxhkd-inspired hotkey daemon[1] for Windows that I really started to appreciate just how _good_ AHK is. Even just for hotkey binding, AHK does some incredibly clever stuff very transparently to provide for such an excellent end-user experience. For example, using system hooks automatically when the user tries to bind a hotkey combination that is reserved by the system (usually win+something) is implemented so well. Really excellent software and I miss it when I'm using Linux or macOS.
[1]: https://github.com/LGUG2Z/whkd
-
AutoHotkey v2 Official Release Announcement
I ended up using AHK for komorebi[1] because I was still new to Windows when I start writing it and I didn't wanna have to write a tiling window manager AND a hotkey daemon. I even ended up generating a nice little AHK library to wrap around CLI commands that sent socket messages to the window manager to make it easier to write a configuration.
Ultimately the syntax changes make it impossible to fully reproduce the same library for AHKv2, which is being installed by default on all mainstream package managers now.
I ended up biting the bullet and making my own hotkey daemon[2] for use with komorebi based on skhd[3] and I haven't looked back since. This will be the "blessed" hotkey daemon recommended for use in the next release of komorebi.
I'm still using AHK (v1) for the stuff that it's good at (and there is a lot of stuff that it's good at!), but ultimately I've found that it's not the right tool as a hotkey daemon for a socket-based tiling window manager.
[1]: https://github.com/LGUG2Z/komorebi
[2]: https://github.com/LGUG2Z/whkd
[3]: https://github.com/koekeishiya/skhd
- Show HN: Whkd – A simple hotkey daemon for Windows
- whkd: A simple hotkey daemon for Windows
What are some alternatives?
prospect-mail - Prospect is an Outlook mail desktop client powered by Electron
AHK_X11 - AutoHotkey for Linux (X11-based systems)
core - Set of window manipulation tools
skhd - Simple hotkey daemon for macOS
autopy - A simple, cross-platform GUI automation module for Python and Rust.
TPMouse - A virtual trackball for Windows, via vim-like homerow controls.
windows-hotkeys - A lightweight, threadsafe and ergonomic rust crate to handle system-wide hotkeys on windows
ydotool - Generic command-line automation tool (no X!)
komorebi - A tiling window manager for Windows 🍉
autopilot-rs - A simple, cross-platform GUI automation module for Rust.
misc_settings - My opinions are correct, you should copy them :)