Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

Display picker overlays all open on the focused monitor on Wayland

Fechada
  • Algo errado?
#2,408 1 comentário 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
64/100
Tipo de issue
Bug
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
rust, tauri
Domínio
desktop, operating-systems

Direção de pesquisa

Start in apps/desktop/src-tauri/src/windows.rs, especially the set_position code at lines 2161-2179 and the title setup at line 1299. Reproduce the picker on a Wayland compositor with multiple monitors, then investigate the reported fullscreen_on_monitor or layer-shell direction. Done means Display mode opens one overlay on each corresponding monitor instead of stacking them on the focused monitor.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

bug

First off I just want to say thanks for making this software. It has been awesome to use so far. I love seeing quality OSS software that meets or even surpasses (which this does) the capabilities of equivalent commercial solutions. Especially in the desktop software space.

I also want to commend y'all for still allowing the purchase a normal lifetime license for a piece of desktop software. I just bought it because of that when I very likely would not sign up for a subscription with my current usage patterns, but love to be able to support great OSS when I can.

Description

With 3 monitors on Niri, picking Display mode opens one overlay per display, each sized right for its display, but all three open stacked on whichever monitor has focus. Expected each overlay to open on its own display.

The overlay gets placed with set_position (windows.rs#L2161-L2179), but Wayland compositors ignore client positioning so it never takes effect.

Proper fix is probably fullscreen_on_monitor or layer-shell.

Potential Workaround

One thing that would be easier to do and would let people work around this is to just include the display name in the title of the window. Cap Target Select - DP-1 instead of the fixed Cap Target Select (windows.rs#L1299). Then compositor users could pin each one with a window rule. For example on Niri I would do something like this (totally untested):

window-rule {
    match title="^Cap Target Select - DP-1$"
    open-on-output "DP-1"
}
Reproduction
  1. Run Cap on a Wayland compositor (Niri here) with more than one monitor
  2. Open the recording picker and choose Display
  3. All the overlays open on the focused monitor
Additional Context
  • Cap version: 0.6.0 (the .deb, repackaged for Nix)
  • Operating system, version: NixOS, Linux 6.18.53, Niri 26.04
  • Device (optional): 3 monitors, one portrait 1080x1920 and two 1920x1080

niri msg windows while the picker is open, all three on the same workspace at the same position:

  Window ID 53:
    Title: "Cap Target Select"
    App ID: "Cap"
    Is floating: yes
    PID: 216607
    Workspace ID: 4
    Layout:
      Tile size: 1080 x 1920
      Workspace-view position: 0, 34
      Window size: 1080 x 1920
      Window offset in tile: 0 x 0

  Window ID 54:
    Title: "Cap Target Select"
    App ID: "Cap"
    Is floating: yes
    PID: 216607
    Workspace ID: 4
    Layout:
      Tile size: 1920 x 1080
      Workspace-view position: 0, 437
      Window size: 1920 x 1080
      Window offset in tile: 0 x 0

  Window ID 55:
    Title: "Cap Target Select"
    App ID: "Cap"
    Is floating: yes
    PID: 216607
    Workspace ID: 4
    Layout:
      Tile size: 1920 x 1080
      Workspace-view position: 0, 437
      Window size: 1920 x 1080
      Window offset in tile: 0 x 0
Linguagem predominante
Rust
Estrelas
23.4k
Forks
2.1k
Merge médio
2d 1h
PRs com merge (30d)
298

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de CapSoftware/Cap

Todas as issues de CapSoftware/Cap

Issues semelhantes

Mais issues de Rust

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.