Published on

Finding the Perfect Balance: My Journey to Sway Window Manager

Introduction

After experimenting with River and Niri window managers, I found myself facing a surprisingly mundane but critical problem: screen sharing. When you need to collaborate with others through video calls, the ability to reliably share your screen becomes non-negotiable. This simple requirement sent me on a journey through different window managers that ultimately led me to Sway - a Wayland compositor that combines modern display protocol support with the battle-tested i3 workflow.

This post documents my journey from River through Niri, a brief detour to X11 with i3, and finally settling on Sway as the window manager that meets all my requirements.

The Screen Sharing Problem

The catalyst for change was simple: I needed to use WeMeet (Tencent Meeting) for remote collaboration. While Wayland offers better security and performance, screen sharing support in many applications remains inconsistent. My attempts to get screen sharing working with WeMeet on River failed, leading me to explore alternatives.

The X11 Detour: Out of frustration, I switched to i3 running on X11. Screen sharing worked immediately - X11's mature ecosystem meant applications like WeMeet could capture the screen without issues. Problem solved, right?

Not quite. Running a 4K primary monitor (3840x2160) alongside a 2K secondary display (2560x1440) on X11 revealed another challenge: per-monitor DPI scaling. X11 struggles with mixed-DPI setups, forcing you to choose between:

  • Sharp text on one monitor, tiny text on the other
  • Comfortable reading size on one monitor, blurry text on the other
  • Complex workarounds involving xrandr scaling that never quite work right

Wayland handles per-monitor scaling natively, making mixed-DPI setups trivial. I couldn't go back to X11's limitations just for screen sharing.

Discovering i3's Layout Flexibility

While using i3 on X11, I stumbled upon a feature that addressed another long-standing frustration: tabbed and stacked layouts.

The Workspace Exhaustion Problem Revisited

In my Niri blog post, I discussed hitting River's 9-tag limit when managing multiple projects. But i3 (and by extension Sway) offers a different solution than Niri's infinite horizontal canvas: container layouts that let you organize multiple windows within a single workspace.

Tabbed Layout: Windows appear as tabs, similar to browser tabs. Perfect for grouping related applications:

  • Multiple terminal sessions for a project
  • Different browser windows for research
  • Related documentation and code editors

Stacked Layout: Windows appear stacked vertically with title bars, like a deck of cards. Great for:

  • Monitoring multiple log files
  • Comparing different documents
  • Managing several chat/communication windows

This revelation was eye-opening. Instead of needing separate workspaces for every context, I could use:

  • Workspace 1: Development (tabbed terminals + stacked reference docs)
  • Workspace 2: Communication (tabbed chat apps)
  • Workspace 3: Browsers (stacked research windows)
  • Workspace 4: Monitoring (tabbed system tools)

Suddenly, 9 workspaces felt like plenty. The "tag exhaustion" problem wasn't about having too few workspaces - it was about not fully utilizing container layouts to organize windows within each workspace.

Why Not Stick with Niri?

Niri's infinite horizontal canvas is genuinely innovative and elegant. So why did I leave it?

Application Navigation Challenges: While Niri's scrolling paradigm works beautifully when you have a mental map of your window order, finding a specific application became frustrating. Without tags or workspaces as clear organizational boundaries, I found myself:

  • Scrolling back and forth looking for the right window
  • Losing track of which applications were open
  • Missing the muscle memory of "workspace 2 = communication apps"

Learning Curve vs Immediate Productivity: I spent a full day trying to adapt to Niri's workflow, but couldn't develop the navigation patterns that came naturally with workspace-based systems. This isn't a criticism of Niri - it's an acknowledgment that sometimes muscle memory and established workflows matter.

The horizontal scrolling concept remains brilliant for certain workflows, but for my multi-project, frequently-switching work style, discrete workspaces with rich container layouts felt more intuitive.

Enter Sway: i3 + Wayland

Sway is a drop-in replacement for i3 that runs on Wayland instead of X11. This combination offers:

  • i3 compatibility: Nearly identical configuration and keybindings
  • Wayland benefits: Better security, proper per-monitor scaling, modern display protocol
  • Mature ecosystem: Years of i3 development, extensive documentation, huge community
  • Screen sharing: Works with modern applications through xdg-desktop-portal

The Best of Both Worlds

Sway gave me everything I needed:

  1. Screen Sharing on Wayland: Through proper xdg-desktop-portal integration, applications can share screens reliably
  2. Multi-DPI Support: Native per-monitor scaling (my 4K at scale 2.4, 2K at scale 1.6)
  3. Tabbed/Stacked Layouts: Full i3 container layout system
  4. Workspace Organization: Clear, numbered workspaces with muscle memory keybindings
  5. Wayland Performance: Tearing-free graphics, better touch gesture support

Building a Local Screen Sharing Solution

While Sway's built-in screen sharing works with many applications, WeMeet's Wayland support remained problematic. Rather than compromise on my window manager choice, I built a custom solution: share-screen - a WebRTC-based local screen sharing application.

Why Build a Custom Solution?

Local Network Focus: Most screen sharing happens on local networks (home office, conference rooms). Why route through external servers?

Application Independence: Works regardless of which video conferencing software supports Wayland properly.

Full Control: Custom features like audio sharing, fullscreen mode, and room-based access control.

Technical Overview

The screen sharing application uses:

  • WebRTC: Browser-native screen capture and peer-to-peer streaming
  • WebSocket Signaling: Lightweight server for coordinating connections
  • Room System: Simple codes for connecting broadcaster to viewers

Architecture:

Broadcaster's Browser (Sway + Wayland)
    ↓ getDisplayMedia() captures screen
    ↓ WebRTC peer connection
    ↓ Via WebSocket signaling server (port 3001)
    ↓ Direct peer-to-peer connection established
    ↓
Viewer's Browser (any device on local network)

Key Features:

  • Screen + audio sharing
  • One-to-many broadcasting
  • Low latency (local network only)
  • Simple room codes
  • Fullscreen viewer mode

This approach lets me use Sway on Wayland while maintaining reliable screen sharing for collaboration. The application works across any device on the local network - colleagues can view on their laptops, tablets, or phones.

Sway Configuration Highlights

My complete Sway configuration is available in the arch-config repository. Here are the key features:

Multi-Monitor Setup with Per-Monitor Scaling

# DP-1: 4K primary display, scaled for comfortable readability
output DP-1 mode 3840x2160@60Hz pos 0 0 scale 2.4

# HDMI-A-1: 2K secondary in portrait, perfect for reading docs/code
output HDMI-A-1 mode 2560x1440@60Hz pos 1600 0 scale 1.6 transform 90

The portrait-oriented secondary monitor at 900×1600 effective resolution is perfect for:

  • Reading long documents
  • Viewing code with long vertical context
  • Monitoring chat applications
  • Following social media feeds

Container Layout Keybindings

The game-changers for workspace organization:

# Switch between layouts quickly
bindsym $mod+s layout stacking  # Stack windows vertically
bindsym $mod+w layout tabbed    # Tab windows horizontally
bindsym $mod+e layout toggle split  # Return to tiling

Real-world usage example:

  • Working on a project with 3 terminals, 2 browser windows, and Slack
  • $mod+w → Tab the terminals together (quick Alt+Tab within workspace)
  • $mod+s → Stack the browser windows (see all titles, click to focus)
  • $mod+e → Tile Slack alongside the containers

All on one workspace, clearly organized, instantly navigable.

Vim-Style Navigation

# Focus movement
bindsym $mod+h focus left
bindsym $mod+j focus down
bindsym $mod+k focus up
bindsym $mod+l focus right

# Window movement
bindsym $mod+Shift+h move left
bindsym $mod+Shift+j move down
bindsym $mod+Shift+k move up
bindsym $mod+Shift+l move right

Workspace Management

# Quick workspace switching (1-9)
bindsym $mod+1 workspace number 1
bindsym $mod+2 workspace number 2
# ... through $mod+9

# Move window and follow
bindsym $mod+Control+1 move container to workspace 1; workspace 1
bindsym $mod+Control+2 move container to workspace 2; workspace 2
# ... convenient for reorganizing workflow

# Quick workspace toggle
bindsym $mod+Tab workspace back_and_forth

Window Rules

# Float specific applications
for_window [app_id="gdcv"] floating enable  # Dictionary lookup
for_window [app_id="wshowkeys_rs"] floating enable  # Screencast key display

# Positioned window for key overlay (bottom-left)
for_window [app_id="wshowkeys_rs"] floating enable, move position 20 750, resize set 300 80

# Float any window with "float" in its app_id (convention for quick floating)
for_window [app_id="^float"] floating enable

Workflow Comparison

Let me compare how I organize work across the three window managers I've used:

River (Tag-Based)

Organization: 9 tags, windows can have multiple tags, view multiple tags simultaneously

Example workflow:

  • Tag 1: Primary development
  • Tag 2: Secondary projects
  • Tag 3: Browsers
  • Tag 4-7: Various contexts
  • Tag 8: Communication
  • Tag 9: Media

Challenge: Tag exhaustion with many concurrent projects

Niri (Infinite Horizontal Canvas)

Organization: Vertical workspaces, infinite horizontal scrolling per workspace

Example workflow:

  • Workspace 1: Scroll through all dev windows horizontally
  • Workspace 2: Scroll through all communication apps
  • Workspace 3: Scroll through all research browsers

Challenge: Finding specific windows in the horizontal strip

Sway (Workspace + Container Layouts)

Organization: 10 workspaces, each with flexible container layouts

Example workflow:

  • Workspace 1: Project A (tabbed terminals + stacked docs)
  • Workspace 2: Project B (tabbed editors + tiled browser)
  • Workspace 3: Communication (tabbed chat apps)
  • Workspace 4: Research (stacked browsers)
  • Workspace 5-9: Additional contexts as needed

Advantage: Clear separation with rich organization within each workspace

Key Sway Features I Love

1. Tabbed Containers for Context Grouping

Grouping related windows into tabs eliminates the need for separate workspaces:

Workspace 1 (Development):
┌─────────────────────────────────────┐
│ [Terminal 1][Terminal 2][Terminal 3]│  ← Tabbed
├─────────────────────────────────────┤
│  Editor (full width)                │
├─────────────────────────────────────┤
│ [Doc 1]                             │  ← Stacked
│ [Doc 2]                             │
│ [Reference]                         │
└─────────────────────────────────────┘

2. Stacked Containers for Overview

Seeing title bars of all stacked windows lets you quickly scan and select:

┌─────────────────────┐
│ auth-service.log    │ ← Click to focus
├─────────────────────┤
│ api-gateway.log     │
├─────────────────────┤
│ database.log        │ ← Currently focused
│                     │
│ [LOG CONTENT HERE]  │
│                     │
└─────────────────────┘

3. Per-Monitor DPI Scaling

Wayland's proper scaling support means each monitor renders perfectly:

  • 4K monitor: Scale 2.4 → 1600×900 effective, comfortable text size
  • 2K portrait: Scale 1.6 → 900×1600 effective, perfect for vertical content

No blurry text, no tiny fonts, no compromises.

4. Workspace Back-and-Forth

$mod+Tab toggles between current and previous workspace. Incredibly useful for:

  • Checking reference docs while coding
  • Monitoring logs while debugging
  • Switching between project contexts

5. Move and Follow

$mod+Control+[1-9] moves window to workspace AND switches to it. Streamlines reorganization:

  • Realize a browser window belongs in workspace 3
  • $mod+Control+3 → Window moved, you're in workspace 3
  • Continue working immediately

Conclusion

My journey from River to Niri to Sway taught me that the best window manager isn't about features - it's about solving your actual problems.

River offered elegant simplicity and tag flexibility, but I hit practical limits with workspace exhaustion.

Niri provided an innovative infinite canvas that solves tag limitations brilliantly, but the navigation paradigm didn't match my workflow patterns.

Sway combines i3's proven workspace model with Wayland's modern capabilities, solving my core needs:

  • Screen sharing that actually works
  • Multi-DPI display support without compromise
  • Workspace organization through container layouts
  • Battle-tested stability and extensive community support

The tabbed and stacked container layouts were the revelation that made "only" 10 workspaces feel like plenty. Combined with Wayland's proper scaling and screen sharing support, Sway provides the balanced solution I needed.

Who Should Consider Sway?

Perfect for:

  • i3 users wanting to move to Wayland
  • Multi-monitor setups with different DPI requirements
  • Those who want proven stability and extensive documentation
  • Developers comfortable with i3-style tiling but wanting modern display protocol

Maybe not ideal for:

  • Users who prefer the infinite canvas approach (stick with Niri)
  • Those wanting eye-candy animations and effects (try Hyprland)
  • Complete beginners to tiling WMs (consider starting with a DE)

Resources

The window manager journey continues to be one of exploration and refinement. Sway represents my current optimal balance, but the Linux desktop ecosystem's diversity means there's always something new to discover. The key is finding what solves your problems, not just what's trendy or feature-rich.

Happy tiling!