Swaymux allows the user to quickly navigate and administrate outputs, workspaces and containers in a tmux-style approach. https://git.grimmauld.de/Grimmauld/swaymux
Go to file
2024-03-12 12:49:47 +01:00
Keys Add detail view 2024-03-12 11:48:43 +01:00
nix manually set app_id 2024-03-10 00:16:37 +01:00
sway_bindings Add detail view 2024-03-12 11:48:43 +01:00
tree Add detail view 2024-03-12 11:48:43 +01:00
util add basic QT tree 2024-03-02 22:33:27 +01:00
.gitignore attempt nix packaging 2024-03-09 15:38:58 +01:00
CMakeLists.txt Add detail view 2024-03-12 11:48:43 +01:00
flake.lock attempt to fix broken app_id 2024-03-09 17:58:15 +01:00
flake.nix Add some details to README.md 2024-03-11 10:18:39 +01:00
LICENSE attempt nix packaging 2024-03-09 15:38:58 +01:00
main.cpp manually set app_id 2024-03-10 00:16:37 +01:00
mainwindow.cpp hide ugly vertical headers 2024-03-12 12:49:47 +01:00
mainwindow.h Add detail view 2024-03-12 11:48:43 +01:00
mainwindow.ui Add detail view 2024-03-12 11:48:43 +01:00
README.md Add some details to README.md 2024-03-11 10:18:39 +01:00
swaymux_en_US.ts add basic QT tree 2024-03-02 22:33:27 +01:00

What's this?

Swaymux aims at making navigation in sway easier. To achieve this, swaymux provides a main interface listing the full tree of outputs, workspaces, containers, as well as the scratchpad. This main interface is primarily inspired by tmux. Swaymux can be navigated using the keyboard, with keybindings that closely follow the tmux bindings.

This project is not feature-complete, far from it. So far swaymux supports listing and navigating into outputs, workspaces and containers, creating a new workspace, or creating a workspace with all currently marked containers.

Planned features and fixes include closing windows from within swaymux without specifically jumping to them, better keyboard navigation through the sway tree in the main interface, a closer look at performance tweaking, as well as maybe even iconification of containers where applicable.

Installing

Requirements

This system expects the $SWAY_SOCK environment variable to be set and the associated socket to be bindable. If that isn't the case, this program will fail to launch. Further, on Nix and NixOS the runtime dependencies should already be packaged. For any other system i currently do not have a good way to test, but a valid QT QPA platform plugin should be all that is needed runtime.

Nix and NixOS

Swaymux is packaged as a nix flake. It can be tested using nix run git+https://git.grimmauld.de/Grimmauld/swaymux, this will build and launch swaymux in a temporary environment that will be removed at next garbage collect in store.

To install swaymux permanently, add the flake input, e.g. using the following snippet:

swaymux = {
  url = "git+https://git.grimmauld.de/Grimmauld/swaymux";
  inputs.nixpkgs.follows = "nixpkgs";
};

Make sure you can request inputs as part of where you install it. Adding swaymux to the actual system then is as easy as putting it into your packages:

environment.systemPackages = [
  inputs.swaymux.packages."${system}".default
];

If you want to directly copy this, keep in mind you'll need to make the system and inputs constants available, e.g. by setting specialArgs = { inherit inputs system; }; as part of your nixosSystem definition in your systems flake.

Other systems

This project uses cmake and requires the nlohman json library as well as QT6. Last time I tested, both GCC and clang compilers worked. Therefore, the classic installation process with cmake, make and make install should just work, though I currently do not have a good way to test.

Integrating with sway

Once the package is available, it can be made available in sway by keybinding. Setting swaymux to be floating is recommended.

for_window [app_id="swaymux"] floating enable
bindsym $mod+c exec swaymux

Available key bindings can be viewed in-App.

Developing

On Nix, the flake makes nix develop available, which provides a development environment with all the required dependencies. It does however not provide an IDE by itself. On any other system, or if you don't like nix develop, the standard way of developing cmake based c++ projects should work. Just make sure both compile and runtime dependencies are available.