Originally created by @LGUG2Z on GitHub (Jan 20, 2023).
Originally assigned to: @LGUG2Z on GitHub.
Is your feature request related to a problem? Please describe.
The release of AHKv2 has been very frustrating; besides the difficulty in replicating the komorebic.lib AHK library for v2, whenever running v2 and sending commands that change window focus, komorebi is faced with access denied errors. I'm not sure it's worth investing the time into achieving feature parity between AHKv1 and AHKv2 for komorebi users.
Describe the solution you'd like
First-class support in komorebi to load configuration from a ps1 file, which could also be used to start a hotkey daemon that I'm working on, similarly to how sxhkd is usually started in bspwmrc.
"First-class support" would include auto-loading at start up and hot-reloading changes to a komorebi.ps1 file, as well as support for generating application-specific configuration tweaks that could be imported in a komorebi.ps1 file.
Describe alternatives you've considered
I've tried using komorebik and hotkeyD, but I think that the sxhkd/skhd-style grammar is ultimately the way forward here instead of TOML or INI files.
Additional context
How this works in bspwmrc (from the example):
#! /bin/sh
pgrep -x sxhkd > /dev/null || sxhkd &
bspc monitor -d I II III IV V VI VII VIII IX X
bspc config border_width 2
bspc config window_gap 12
bspc config split_ratio 0.52
bspc config borderless_monocle true
bspc config gapless_monocle true
bspc rule -a Gimp desktop='^8'state=floating follow=on
bspc rule -a Chromium desktop='^2'
bspc rule -a mplayer2 state=floating
bspc rule -a Kupfer.py focus=on
bspc rule -a Screenkey manage=off
How it might look for komorebi (based on what I'm currently playing with):
Originally created by @LGUG2Z on GitHub (Jan 20, 2023).
Originally assigned to: @LGUG2Z on GitHub.
**Is your feature request related to a problem? Please describe.**
The release of AHKv2 has been very frustrating; besides the difficulty in replicating the komorebic.lib AHK library for v2, whenever running v2 and sending commands that change window focus, `komorebi` is faced with `access denied` errors. I'm not sure it's worth investing the time into achieving feature parity between AHKv1 and AHKv2 for komorebi users.
**Describe the solution you'd like**
First-class support in komorebi to load configuration from a `ps1` file, which could also be used to start a hotkey daemon that I'm working on, similarly to how `sxhkd` is usually started in `bspwmrc`.
"First-class support" would include auto-loading at start up and hot-reloading changes to a `komorebi.ps1` file, as well as support for generating application-specific configuration tweaks that could be imported in a `komorebi.ps1` file.
**Describe alternatives you've considered**
I've tried using `komorebik` and `hotkeyD`, but I think that the `sxhkd`/`skhd`-style grammar is ultimately the way forward here instead of TOML or INI files.
**Additional context**
How this works in bspwmrc (from the example):
```bash
#! /bin/sh
pgrep -x sxhkd > /dev/null || sxhkd &
bspc monitor -d I II III IV V VI VII VIII IX X
bspc config border_width 2
bspc config window_gap 12
bspc config split_ratio 0.52
bspc config borderless_monocle true
bspc config gapless_monocle true
bspc rule -a Gimp desktop='^8' state=floating follow=on
bspc rule -a Chromium desktop='^2'
bspc rule -a mplayer2 state=floating
bspc rule -a Kupfer.py focus=on
bspc rule -a Screenkey manage=off
```
How it might look for komorebi (based on what I'm currently playing with):
```powershell
if (!(Get-Process swhkd -ErrorAction SilentlyContinue))
{
Start-Process swhkd -WindowStyle hidden
}
. $PSScriptRoot\komorebi.generated.ps1
komorebic window-hiding-behaviour minimize
komorebic cross-monitor-move-behaviour insert
komorebic invisible-borders 7 0 14 7
komorebic workspace-layout-rule 0 0 0 ultrawide-vertical-stack
komorebic workspace-custom-layout-rule 0 0 4 ~/custom.yaml
komorebic container-padding 0 0 20
komorebic workspace-layout 1 0 rows
komorebic container-padding 1 0 20
komorebic active-window-border-colour 66 165 245 --window-kind single
komorebic active-window-border-colour 256 165 66 --window-kind stack
komorebic active-window-border enable
komorebic global-work-area-offset 0 5 0 0
komorebic monitor-work-area-offset 0 0 5 0 0
komorebic watch-configuration enable
komorebic complete-configuration
```
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @LGUG2Z on GitHub (Jan 20, 2023).
Originally assigned to: @LGUG2Z on GitHub.
Is your feature request related to a problem? Please describe.
The release of AHKv2 has been very frustrating; besides the difficulty in replicating the komorebic.lib AHK library for v2, whenever running v2 and sending commands that change window focus,
komorebiis faced withaccess deniederrors. I'm not sure it's worth investing the time into achieving feature parity between AHKv1 and AHKv2 for komorebi users.Describe the solution you'd like
First-class support in komorebi to load configuration from a
ps1file, which could also be used to start a hotkey daemon that I'm working on, similarly to howsxhkdis usually started inbspwmrc."First-class support" would include auto-loading at start up and hot-reloading changes to a
komorebi.ps1file, as well as support for generating application-specific configuration tweaks that could be imported in akomorebi.ps1file.Describe alternatives you've considered
I've tried using
komorebikandhotkeyD, but I think that thesxhkd/skhd-style grammar is ultimately the way forward here instead of TOML or INI files.Additional context
How this works in bspwmrc (from the example):
How it might look for komorebi (based on what I'm currently playing with):