Tiling Window Management for macOS.
komorebi for Mac is a tiling window manager that works as an extension to the standard macOS desktop environment.
komorebi for Mac aims to make as few modifications as possible to the operating system and desktop environment by default.
LGUG2Z/komorebi-for-mac is the public repository where versioned releases will be published.
KomoCorp/komorebi-for-mac is the private repository available to certain GitHub Sponsors tiers where ongoing development work happens and nightly releases are made available.
If you are reading this sentence on the public repository, komorebi for Mac
has still not had its first versioned release. If you would like to try out this
initial public snapshot, you can brew install lgug2z/tap/komorebi-for-mac or build from
source,
and then follow the
quickstart.
There is a Discord server available for komorebi-related discussion, help, troubleshooting etc. If you have any specific feature requests or bugs to report, please create an issue in this repository.
There is a YouTube channel where I post komorebi development videos, feature previews and release overviews. Subscribing to the channel (which is monetized as part of the YouTube Partner Program) and watching videos is a really simple and passive way to contribute financially to the development and maintenance of komorebi.
There is an Awesome List which showcases the many awesome projects that exist in the komorebi ecosystem.
komorebi
is educational source software.
komorebi is licensed under
the Komorebi 2.0.0 license, which
is a fork of
the PolyForm Strict 1.0.0 license.
On a high level this means that you are free to do whatever you want with
komorebi for personal use other than redistribution, or distribution of new
works (i.e. hard-forks) based on the software.
Anyone is free to make their own fork of komorebi with changes intended either
for personal use or for integration back upstream via pull requests.
The Komorebi 2.0.0 License does
not permit any kind of commercial use ( i.e. using komorebi at work).
komorebi for Mac is a free and educational source project, and one that encourages you to make charitable donations if you find the software to be useful and have the financial means.
I encourage you to make a charitable donation to the Palestine Children's Relief Fund or to contribute to a Gaza Funds campaign before you consider sponsoring me on GitHub.
GitHub Sponsors is enabled for this project. Sponsors can claim custom roles on the Discord server, get shout outs at the end of komorebi-related videos on YouTube, gain the ability to submit feature requests on the issue tracker, and receive releases of komorebi with "easter eggs" on physical media.
If you would like to tip or sponsor the project but are unable to use GitHub
Sponsors, you may also sponsor through Ko-fi, or
make an anonymous Bitcoin donation to
bc1qv73wzspc77k46uty4vp85x8sdp24mphvm58f6q.
A dedicated Individual Commercial Use License is available for those who want to
use komorebi at work.
The Individual Commerical Use License adds “Commercial Use” as a “Permitted Use” for the licensed individual only, for the duration of a valid paid license subscription only. All provisions and restrictions enumerated in the Komorebi License continue to apply.
More information, pricing and purchase links for Individual Commercial Use Licenses can be found here.
komorebi for Mac is currently accepting minimally invasive bug fixes. Proposals for any other kind of contributions can be discussed with me on Discord.
If you would like to contribute to komorebi please take the time to carefully
read the guidelines below.
Please see CONTRIBUTING.md for more information about how
code contributions to komorebi are licensed.
- Flatten all
usestatements - Run
cargo +stable clippyand ensure that all lints and suggestions have been addressed before committing - Run
cargo +nightly fmt --allto ensure consistent formatting before committing - Use
git czwith the Commitizen CLI to prepare commit messages - Provide at least one short sentence or paragraph in your commit message body to describe your thought process for the changes being committed
It is very difficult to review pull requests which touch multiple unrelated features and parts of the codebase.
Please do not submit pull requests like this; you will be asked to separate them into smaller PRs that deal only with one feature or bug fix at a time.
If you are working on multiple features and bug fixes, I suggest that you cut a
branch called local-trunk from master which you keep up to date, and rebase
the various independent branches you are working on onto that branch if you want
to test them together or create a build with everything integrated.
komorebi is a mature codebase with an internal consistency and structure that
has developed organically over close to half a decade.
There are countless hours of live coding videos
demonstrating work on this project and showing new contributors how to do
everything from basic tasks like implementing new komorebic commands to
distinguishing monitors by manufacturer hardware identifiers and video card
ports.
Refactors to the structure of the codebase are not taken lightly and require prior discussion and approval.
Please do not start refactoring the codebase with the expectation of having your changes integrated until you receive an explicit approval or a request to do so.
Similarly, when implementing features and bug fixes, please stick to the structure of the codebase as much as possible and do not take this as an opportunity to do some "refactoring along the way".
It is extremely difficult to review PRs for features and bug fixes if they are lost in sweeping changes to the structure of the codebase.
This includes but is not limited to:
- All
komorebiccommands - The
komorebi.jsonschema - The
komorebi-application-specific-configurationschema
No user should ever find that their configuration file has stopped working after
upgrading to a new version of komorebi.
More often than not there are ways to reformulate changes that may initially seem like they require breaking user-facing interfaces into additive changes.
For some inspiration please take a look
at this commit
which added the ability for users to specify colours in komorebi.json in Hex
format alongside RGB.
There is also a process in place for graceful, non-breaking, deprecation of configuration options that are no longer required.
Logs from komorebi will be appended to
$HOME/Library/Application Support/komorebi/komorebi.log.$timestamp.
Whenever running the komorebic stop command or sending a Ctrl-C signal to
komorebi directly, the komorebi process ensures that all hidden windows are
restored before termination.
If komorebi ever stops responding, it is most likely either due to either a
panic or a deadlock. In the case of a panic, this will be reported in the log.
In the case of a deadlock, there will not be any errors in the log, but the
process and the log will appear frozen.
If you believe you have encountered a deadlock, you can compile komorebi with
--features deadlock_detection and try reproducing the deadlock again. This
will check for deadlocks every 5 seconds in the background, and if a deadlock is
found, information about it will appear in the log which can be shared when
opening an issue.
The current state of the window manager can be queried using the
komorebic state command, which returns a JSON representation of the State
struct.
This may also be polled to build further integrations and widgets on top of.
It is possible to subscribe to notifications of every WindowManagerEvent and
SocketMessage handled by komorebi using Unix Domain Sockets.
UDS are also the only mode of communication between komorebi and komorebic.
First, your application must create a socket in $HOME/Library/Application Support/komorebi. Once the socket has been created, run the following command:
komorebic subscribe-socket <your socket name>If the socket exists, komorebi will start pushing JSON data of successfully handled events and messages as in the example above in the Named Pipes section.
It is possible to use the komorebi-client crate to subscribe to notifications
of every WindowManagerEvent and SocketMessage handled by komorebi in a
Rust codebase.
Below is a simple example of how to use komorebi-client in a basic Rust application.
// komorebi-client = { git = "https://github.com/LGUG2Z/komorebi-for-mac" }
use anyhow::Result;
use komorebi_client::Notification;
use komorebi_client::NotificationEvent;
use komorebi_client::UnixListener;
use komorebi_client::WindowManagerEvent;
use std::io::BufRead;
use std::io::BufReader;
use std::io::Read;
pub fn main() -> anyhow::Result<()> {
let socket = komorebi_client::subscribe(NAME)?;
for incoming in socket.incoming() {
match incoming {
Ok(data) => {
let reader = BufReader::new(data.try_clone()?);
for line in reader.lines().flatten() {
let notification: Notification = match serde_json::from_str(&line) {
Ok(notification) => notification,
Err(error) => {
log::debug!("discarding malformed komorebi notification: {error}");
continue;
}
};
// match and filter on desired notifications
}
}
Err(error) => {
log::debug!("{error}");
}
}
}
}A JSON Schema of the event notifications emitted to
subscribers can be generated with the komorebic notification-schema command.
A JSON Schema of socket messages used to send
instructions to komorebi can be generated with the komorebic socket-schema
command.