This commit introduces a new komorebi.sample.ahk in the repository root,
as well as adding the latest generated versions of komorebic.lib.ahk and
komorebi.generated.ahk.
Pushing new users to use the AHK library by default will significantly
simplify the process of building a new configuration, and including the
application-specific configuration generated from the configuration
repository will result in a better first impression of komorebi where
more and more applications "just work".
This new sample is focused on setting a few sane configuration defaults,
and as few keybinds as possible, really just enough to allow the user to
switch focus and move windows around. This significantly reduces the
possibility of the first-time user accidentally triggering a command
that leaves them confused, frustrated and would probably end in them
killing the komorebi.exe proc from the task manager.
The new sample configuration will no longer be bundled with scoop
starting from the next release, which is also expected to introduce
support for installation via winget.
Instead, instructions have been added for users to download the latest
example configuration and generated libs from GitHub in the getting
started section.
resolve#62
These changes to the GitHub actions workflows will include an MSI
installer in the artifacts that are uploaded at the end of each
successful build, and also attach an MSI installer to a release when the
job runs on a tag that creates a new release version.
re #152
This commit introduces a change to allow users to set a custom
configuration directory for Komorebi to address concerns about $HOME
getting cluttered.
The custom directory can be set with the environment variable
$Env:KOMOREBI_CONFIG_HOME (this should probably be done in $PROFILE).
If this variable is not set, komorebi will default to using
the $HOME directory.
resolve#61
This commit ensures that when a window is dragged across a monitor
boundary, the ownership of the window container will be transferred to
the target monitor's currently focused workspace.
In order to achieve this, a new WindowManagerEvent variant has been
added, MoveResizeStart, which will store an optional pending_move_op on
the WindowManager struct. This must be consumed at the beginning of the
handler for MoveResizeEnd.
This is necessary because as soon as the window is dragged across a
monitor boundary, an event is sent (and handled) to update the currently
focused monitor and workspace as the target monitor and workspace, and
we still need to have the information about the original monitor,
workspace and container in order to make comparisons and ultimately
remove the origin container to be able to transfer it.
fix#58
