Minha experiência com o sway (duas semanas usando o wayland)

Tuxraldo · Dezembro 31, 2023, 2:53pm

Resolvi fazer uns testes com o wayland por aqui, afinal essa época do ano não temos muito o que fazer além das festas de família. Nada sério porque não tenho capacidade para isso. Apenas uns testes para ver como está o uso de algum dos twm disponíveis para wayland no dia a dia de um usuário comum, que é o meu caso. Faz quase 2 semanas que comecei a usar o sway.

Peguei minha config do i3wm e simplesmente copiei para a pasta do sway (~/.config/sway/) e tudo funcionou normalmente com duas exceções. Uso o atalho $mod+Shitf+Maior(greater) e $mod+Shift+Menor(less) para as opções de “focus parent” e “focus child”. Essas teclas são acionadas com shift+ponto e shift+vírgula, por algum motivo o sway não estava reconhecendo os atalhos, tive que mudar para $mod+Shift+period(ponto) e $mod+Shift+semicolon(vírgula). E também precisei alterar as classes dos programas no config. O sway não utiliza o “class”, usa o “app_id”.

i3wm:
assign [class="^thunar|vifm$"] $ws4

sway:
assign [app_id="^thunar|vifm$"] $ws4

Além disso não tive mais qualquer problema com meu arquivo de config do i3wm.

Uma coisa que achei bem interessante no sway, dá para fazer praticamente qualquer configuração que eu preciso direto no arquivo de config dele. Exemplo, o tema gtk/ponteiro/ícone, layout do teclado, opções do touchpad e habilitar o numlock junto com a sessão do sway. Ou seja, adiciono as configs lá e, se quiser trocar alguma coisa, basta um simples reload do sway e já era. Achei isso bem prático.

O que estou usando no wayland?

twm: sway
Terminal: foot (sei que o alacritty ja tem tempo que possui suporte para wayland, mas resolvi testar o foot e gostei bastante. Tenho o alacritty instalado e ele funciona perfeitamente também. A única coisa que sinto falta nos dois são as abas que tenho no xfce4-terminal. Para wayland, o kitty e o wezterm tem abas)
Painel: waybar (as configs do i3status funcionaram de boa na sway bar, assim como o i3blocks. No começo achei um pouco confusa a config da waybar, depois fui acostumando. A organização lembra um pouco a polybar)
Gerenciador de notificações: mako (o dunst é compatível com wayland)
Wallpaper: swaybg (funciona de forma parecida com o feh, só não consegui setar o wallpaper rápido como com o feh, tenho que editar o config do sway para trocar e depois dar um reload)
Bloqueador de tela: swaylock (bloqueador de tela simples, quase igual ao i3lock)
Gerenciador de arquivos: vifm (ainda estou sem o preview, porque no X11 uso o ueberzug) e o thunar (não é totalmente compatível com wayland, embora eu não tenha encontrado nenhum problema ao usá-lo)
Lançador de aplicações: dmenu (sim, estou usando ele e funcionando de boa. Testei o fuzzel, tofi e bemenu. O bemenu eu encontrei um problema com a fonte que ainda não consegui resolver. Se conseguir, vou migrar para ele. É um dmenu para wayland, tem os mesmos recursos que o dmenu (sem os patches). O fuzzel eu até achei interessante. Desisti de usá-lo apenas porque acho mais prático a forma de lidar com os scripts que tenho com o dmenu/bemenu. São scripts que fiz para usar com o dmenu, então a integração com o bemenu é bem mais simples. Na prática, não precisei de fazer nada, só trocar a forma como o bmenu lida com as cores e trocar o dmenu por bemenu dentro dos scripts.

O resto são programas que funcionam normalmente no wayland, como libreoffice, gimp, firefox, polkit, vim, pulseaudio, zathura etc.

Alguns outros programas (do X11) ainda não encontrei uma alternativa definitiva ou que eu gostasse/me adaptasse ou que fossem tão simples de usar. São eles: scrot, feh (ou o swayimg é meio limitado ou eu que ainda não sei usar ele. E não encontrei uma forma se definir o wallpaper rapidamente como com o feh), um bom front-end para o mpv (gosto bastante do smplayer), preview no vifm (fiz um teste com sixel + foot e ainda não tive bons resultados. Eu consigo obter os previews, porém o carregamento das imagens fica meio esquisito). Não quis testar outro gerenciador de arquivos TUI porque nunca encontrei um que tenha um painel duplo bom como o vifm. Tem até um jeito de fazer isso com o ranger, porém não é tão prático como no vifm.

TWM/compositores para wayland que testei

Testei o river (é baseado no bspwm, embora praticamente não tenha usado), qtile (que já havia utilizado no X11) e hyprland. Para mim o sway está bem a frente dos outros três. No hyprland eu tive problemas de congelamento do meu notebook após fazer logout. O bug é o seguinte: após fazer qualquer alteração no arquivo de configuração do hyprland, quando eu saia dele e retornava ou para o tty (sem gerenciador de login) ou para a tela do gerenciador do login, em vezes aleatórias (no meu caso foi a maioria) a tela ficava toda preta e o pc congelava totalmente. Eu não conseguia nem mudar para outro tty. Pesquisando no github oficial do projeto vi que existiam vários tópicos sobre esse problema e não existe uma solução para ele ainda.

Dois exemplos de issues desse bug de tela preta, se procurar lá no github tem mais sobre o tema: issue 1 issue 2

Quando digo que o sway está bem a frente, não estou falando que os outros dois não sejam possíveis de se utilizar, pelo contrário. Dá para usar tranquilamente, só que o sway está mais pronto. Até o momento não encontrei nada que me atrapalhasse ou impedisse o uso do sway, como minha limitação em python do qtile, o bug da tela preta do hyprland e minha preguiça em testar mais o river.

Class e app_id

A única dificuldade que encontrei até agora, e pode ser falta de leitura da wiki, é o problema que citei com as fontes no bemenu e com as classes na config do sway. No X11 basta um xprop e pegamos a classe do programa para adicionar ao arquivo de configuração de algum twm. O sway não trabalha com as classes, ele usa a opção “app_id”. Só que ainda não encontrei nada simples como o xprop e muitos programas não estão abrindo nas áreas de trabalho corretas. Vou pesquisar mais para achar uma alternativa ao xprop, certamente já tem. Não sei se é um problema com as classes/app_id ou se é de compatibilidade dos programas com o wayland.

Isso não é nada demais, significa apenas que estou em uma situação nova para mim e, obviamente, terei que aprender corretamente como funciona o wayland e o sway.

Conclusão

Estou apanhando um pouco da waybar, o sway tá bem de boa. O que ainda acho ou um pouco confuso, são os espaços, as separações, entre os itens na waybar. Porque acostumei muito com os separadores da polybar, embora eles também possam ser utilizados na waybar. Em síntese, a waybar funciona parecido com a polybar, só que ela divide, se você quiser, as configs entre personalização gráfica e opções/configurações, nos arquivos config e style.css.

Sinceramente, escutei falar muito do wayland, se fala muito bem e muito mal. Como sempre, respeito a opinião de quem entende e gosto também de tirar minhas próprias conclusões. E essa experiência com o wayland + sway em uso mais básico como o meu tem funcionado bem. Nem sei até que ponto o wayland atende a usuários com perfis mais específicos (tem o problema da nvidia, alguns com o obs etc.). Com algumas limitações e, sempre com a sensação de que está faltando algo (talvez por falta de familiaridade com wayland), tem sido uma experiência relativamente tranquila.

Pelo meu gosto pessoal e pela rápida experiência, acho que posso seguir usando o sway. Não diria o mesmo para o hyprland ou para o qtile. No caso do qtile, acho que é o que já comentei por aqui outras vezes, minha total falta de conhecimento em python, sinto que usar ele sem saber python é muito limitado. E no do hyprland por causa de bug que está ainda sem solução. Eu tive que desligar meu notebook no botão power umas 5 ou 6 vezes por causa desse bug. No github do projeto tem um script simples de um usuário que ajuda a evitar isso. A grande questão é que é uma solução temporária/quebra galho e, pelo que falam as issues abertas, os devs ainda não sabem o que está causando isso. Me lembrou até o bug eterno da systray da polybar com alguns ambientes (fluxbox, openbox, i3 etc.) que os devs também não sabiam o que causava o problema e resolveram (no último release da polybar) transformando a systray em modulo.

Pra galera da customização estilo unixporn, esses compositores para wayland serão uma farra. A waybar e o hyprland, por exemplo, dá para fazer muita coisa, efeitos ao mover janelas, degradê, bordas arredondadas e coloridas e por aí vai.

Os únicos pontos que achei negativos foram a ausência de algumas coisas nos repositórios oficiais. Instalei o sway no Arch, que é minha distro secundária e de testes, então várias coisas eu só achava no AUR. E uma sensação que tenho ao usar o wayland de que sempre está faltando alguma coisa. Essa sensação, suspeito, como já disse, pode ser falta de familiaridade com o wayland.

Os pontos positivos são a fluidez que o sway tem, o i3wm se usado sem nenhum compositor fica com a movimentação das janelas meio “dura”, no sway é mais suave, tem maior fluidez. Fiquei com a sensação, isso só o tempo pode confirmar, que o uso dos recursos do sistema é ligeiramente mais eficiente que no X11.

Acredito que quando sair uma versão estável do ecossistema do xfce para wayland (que já vem sendo realizada) talvez eu consiga migrar e ver o que acontece. Certamente terei que aprender algumas coisas novas (como já estou aprendendo), porém isso faz parte. Seguirei com o sway e se não encontrar nenhum problema ou empecilho, acho que futuramente vou tentar fazer uma instalação limpa aqui apenas com o wayland. Será uma experiência interessante.

E aí, a galera que já usa o wayland, o que tem a dizer? Essa minha curta experiência tá mais ou menos dentro do que se encontra o wayland atualmente?

Tinha esquecido do print, tá igual meus outros twm:

Links úteis:

Compilado de alternativas para wayland
Alterntivas para o wayland (dicas da wiki do sway)
Guia de migração do i3 para sway
comunidade do reddit
A wiki do Arch tem boas dicas
A wiki do Gentoo tem boas dicas

P.S: como sempre, qualquer erro de digitação, informações incorreta etc. avisa aí que eu arrumo.
P.S²: depois adiciono uns prints para ilustrar o tópico.

Tuxraldo · Janeiro 2, 2024, 7:18pm

Uma dica para quem for usar o sway e aproveitar a config do i3wm. Como mencionado no começo do texto, os apps nativos ou que tem total compatiblidade com o wayland, utilizam o “app_id” e, os que não são nativos/compatíveis rodam através do xwayland, ainda utilizam a opção “class”. Então, se você precisar, como eu, de app não nativos, prepares-se para um pouco de confusão na das definições de áreas de trabalho (assign/for_window) do seu arquivo de config

Aqui, por exemplo, o thunar funciona com “app_id” e o vifm com “class”. Tive que criar uma config para cada um. Nada de outro mundo, só aumentará algumas linhas no seu arquivo.

Capezotte · Janeiro 3, 2024, 3:45pm

Comecei usando as mesmas escolhas, mas acabei adotando depois as soluções do nwg-shell.

Admito que só peguei o gtk-lock por ele ser mais bonitinho, mas o SwayNC realmente é mais funcional (armazenamento de histórico, botões embutidos na própria notificação, etc.).

Acabo não sentido tanta falta assim porque tanto o Sway como o i3 possuem abas nativamente.

Cheguei até a experimentar tornar o Firefox “monoguia” com extensões e configurações do userChrome.css para usar ele do mesmo modo, mas a experiência nos navegadores modernos é muito dependente do sistema de guias embutido (o mecanismo de restaurar sessão, por exemplo), e voltei atrás.

Só dar killall swaybg antes de chamar swaybg -i ~/Imagens/...

É que, enquanto no X11 o wallpaper (textura da janela raiz) é uma propriedade que o feh e o nitrogen podem só alterar e sair, no Wayland o wallpaper é uma janela “normal”. Logo, chamar o swaybg de novo faz o swaybg que você criou “competir” com o swaybg que o Sway cria ao carregar a configuração.

#!/bin/sh
tree=$(swaymsg -t get_tree | jq 'recurse(.nodes[], .floating_nodes[]) | select(.visible)')

if xy=$(printf '%s\n' "$tree" |
	jq -r '{name} + {id} + .rect | "\(.x),\(.y) \(.width)x\(.height) \(.name) (\(.id))"' | 
		slurp -rf '{"x":%x,"y":%y,"width":%w,"height":%h}')
then
	printf '%s\n' "$tree" | jq --argjson xy "$xy" 'select(.rect == $xy)'
fi

Sai em formato JSON, mas nada de “outro mundo”, os rótulos são auto-explicativos.

Requer slurp (que talvez você já tenha, porque o grim depende dele) e jq.

Como é esse problema de fonte?

Já aqui o fuzzel virou xodó, tanto que quando bateu a preguiça de reescrever os scripts com dmenu, eu só criei um “wrapper” em shell script de mesmo nome na minha pasta que chama o fuzzel com as opções “traduzidas”.

Tem um fork do ueberzug compatível com Wayland.

Não cheguei a testar, no entanto, já que sixel é bom o suficiente para mim no lf.

Esse também é meu diagnóstico. Faz muito tempo que eu não testo outro compositor, mas na época (fim de 2021), só o Sway conseguia ajustar propriedades de mesas digitalizadoras, por exemplo.

fastos2016 · Janeiro 3, 2024, 4:37pm

Poxa, impossível eu não fazer um texto com essa pergunta rs, me vem tanta coisa na cabeça…
Uso wayland desde o Fedora 25, na minha experiência com Intel e AMD tenho mais fluidez e maior compatibilidade ou menos bugs de aceleração de hardware, como acontece com Nvidia + electron apps por exemplo.

No começo não tinha nem como gravar a tela, hoje o OBS e outros apps já suportam. Inclusive gravo todos meus vídeos no wayland.

KDE plasma 6 está implementando vrr/freesync no wayland, que já funciona, apesar de eu ter tido instabilidade ainda.

Anos sem ver um tearing mesmo em apps/jogos xwayland, esses dias entrei na sessão x11 no gnome para testar algo e esqueci de voltar para sessão wayland, então comecei perceber com pouco tempo de uso inconsistências nas animações, quanto mais apps abria mais arrastado a interface ficava, algumas piscadas estranhas com monitor secundários etc até que percebi que estava usando x11, quando voltei para o wayland normalizou.

É impressionante como nos acostumamos com tudo, até inconsistência gráfica, pois usei anos o x11 com todos os problemas de sempre (principalmente o famigerado tearing) e seus tutoriais pela internet tentando resolver.mas depois do wayland não tem volta. Sim ainda falta apps implementarem compatibilidade, devs usarem a tríade pipewire/portais/wayland, como o dev do KDE falou em blog recentemente…

Tuxraldo · Janeiro 3, 2024, 7:33pm

O mako e o swaylock tem me servido bem. Ficarei com eles. Eu cheguei a ver esse projeto nwg, como as alternativas que encontrei me serviram bem, acabei ficando com elas mesmo.

No caso das abas, faço exatamente isso, uso as abas do próprio sway.

Ah, essa do wayland tratar o wallpaper como janela eu não sabia. É por isso que quando eu tentava usar o sway -i novo_wallpaper.png ele ficava com dois processos abertos e não fazia nada. Então terei que criar um alias para matar o swaybg e depois carregar o novo wallpaper. E tem que usar o & para deixar o processo em segundo plano, se só rodar um sway -i wallpaper.png e fechar o terminal o wallpaper não fica salvo.

Acabei achando uma solução para o xprop, acho que igual a essa sua indicação, no próprio github do sway. Tenho usado mais para pegar o “app_id” então to filtrando com o grep. No meu caso um simples:

swaymsg -t get_tree

ou com o grep

swaymsg -t get_tree | grep app_id

Já me atende bem.E ainda posso usar para ver o que tá rodando via xwayland.

Essa do slurp me deixou confuso. Pelo que entendi o wayland não consegui lidar sozinho com a seleção de um pedaço/janela da área de trabalho, precisa de algum externo pra fazer isso. Pra eu conseguir tirar um print selecionando um pedaço da tela eu precisei instalar o grim e o slurp. Vou acabar tendo que fazer um script/alias pra facilitar.

Cheguei a testar fuzzel, porém sou meio apegado aquela forma de deixar o dmenu na parte de cima da tela e com a opção de listar as linhas em sequência.

O problema do bemenu é simples. Com o dmenu eu uso seguinte script que centraliza a configuração de todos os scripts que tenho para o dmenu (depois faço um source dentro dos scripts):

#!/usr/bin/env bash
 
# -----> opções
lines="-l 15 -i"
font='-fn JetBrainsMonoNF-9'

# -----> color scheme
colors="-nb #323D43 -nf #D8CAAC -sb #83A589 -sf #323D43"

Fiz o mesmo só que adaptando para o bemenu. Tudo funcionou de boa, menos a fonte que, por algum motivo, não reconhece de forma alguma. Já tentei de tudo e nada resolveu.

A fonte no script do bemenu está assim:

lines="-l 15 -i --fn 'pango:JetBrainsMono NF 11'"

Seu eu uso a config direto no terminal ela funciona, se usanda dentro do script não.

Consegui resolver o preview do vifm, com o foot (que tem suporte ao sixel). Nas imagens ainda não fica igual ao ueberzurg, com o sixels parece que carrega aos pedaços, aos poucos e é mais lento que com o ueberzurg, porém funciona. O resto dos previews funcionam normalmente.

Bom, tudo é uma questão de aprendizado também. Vou aprendendo o que tem e o que não tem no wayland e como fazer as coisas que preciso. Essa semana ou semana que vem vou ver se reinstalo o Arch aqui só com wayland pra ver no que dá. Percebi que ainda é quase impossível de usar o wayland sem o xwayland, ainda tem poucas opções nativas.

Capezotte · Janeiro 4, 2024, 2:31am

Exato.

Não é o Wayland que não consegue, é o grim que não consegue – tanto que tem o slurp que faz isso, sem usar Xwayland.

O grim prefere seguir o mesmo conceito do maim (uma ferramenta de screenshot do X11), de deixar a parte de selecionar a porção da tela pra um programa externo. Isso desacopla as funcionalidades e libera mais uma ferramenta para usar em scripts.

Tanto que no script que passei usei o slurp não para selecionar uma região da tela para fazer print, mas sim para selecionar uma janela para obter informações dela.

Com o grim, é essa a intenção.

Outros programas, como o Flameshot, são mais “tradicionais” e se responsabilizam tanto por selecionar a região quanto por gerar o print.

O problema não é o Bemenu, mas sim o shell. Ao dividir a string quando você invoca bemenu $lines não leva em conta aspas nem nada, só os espaços. Ele recebe como se fosse:

bemenu -l 15 -i --fn "'pango:JetBrainsMono" NF "11'"

Assim, ele entende que deve usar uma fonte chamada 'pango:JetBrainsMono (sim, com a aspa). O resto do nome e o tamanho vão pro espaço.

A solução é transformar esse paramêtros em arrays do Bash:

# no arquivo sourceado
lines=(-l 15 -i --fn 'pango:JetBrainsMono NF 11')
# no script
bemenu "${lines[@]}"

(Quando testei aqui, pango: também deu problema, e para dar certo tive que usar só --fn 'JetBrainsMono NF 11', mas como funciona por aí, deixei como está).

Outra solução, que é a que eu prefiro, é deixar um script no meu $PATH com as configurações, assim não precisa nem se dar ao trabalho de dar source e escrever $lines em cada script (e libera um nome de variável para você usar!).

#!/bin/sh
# pode salvar como, sei lá, ~/.scripts/tdemenu ou
# /usr/local/bin/tdemenu
exec bemenu -l 15 -i --fn 'pango:JetBrainsMono NF 11' "$@"

Pio · Janeiro 4, 2024, 8:11am

Sobre o Sway, nunca cheguei a testar ele.

Sobre o Wayland, as experiencias que tive não são incentivadoras.

Hyprland:

Horrivel em máquina virtual
No notebook tem problema de aquecimento, fazendo com que se reinicie o sistema

Qtile Wayland:

Não consegui fazer funcionar no notebook por causa da placa hibrida

No pc não cheguei a testar pelo fato de ter diversos scripts que uso para facilitar ou automatizar algumas tarefas do cotidiano e caso migrasse para o wayland, teria que refazer quase todos por causa da compatibilidade de app x11 X app wayland.

Confesso que não vou demorar muito para testar o hyprland no pc e começar a jornada de resolver os possíveis bugs e criação de scripts. Estou tendo alguns bugs com arrasto de arquivos com o mouse e também no script de screenshot, tendo que recorrer ao flameshot (acho o flameshot excelente, mas com o script fica mais prático, deixando para o flameshot apenas em situações em que tenha que utilizar as ferramentas de marcação de texto e afins.)

Tuxraldo · Janeiro 4, 2024, 1:21pm

Ah, então é porque o dmenu tem o hífen como separador, aí ele não lê o espaço e a fonte funciona de boa. O bemenu, pelo que pesquisei, não tem nenhum caractere que permite fazer essa divisão/separação de itens. Então é isso.

Adicionei a opção pango depois de ler a documentação, só para ver se fazia diferença. Na prática, acho que na maioria dos casos nem faz diferença.

Outra solução, que é a que eu prefiro, é deixar um script no meu $PATH com as configurações, assim não precisa nem se dar ao trabalho de dar source e escrever $lines em cada script (e libera um nome de variável para você usar!).

Nesse caso eu criaria o script com as configs que quero, prefiro deixar em $HOME/.local/bin, e depois é só chamar o meu_bemenu.sh que ele pega as configs, é isso?

Exemplo: meu_bemenu $HOME/.local/bin/command_menu

Vou testar por aqui, parece mais prático mesmo.

Capezotte · Janeiro 4, 2024, 1:27pm

Usando meu_bemenu no lugar de dmenu/bemenu nos scripts.

printf '%s\n' Sim Não | meu_bemenu

Tuxraldo · Janeiro 4, 2024, 1:30pm

Valeu, quando sobrar um tempo testarei. Essa dica de deixar o um script de configs no patch me parece bem mais prática mesmo.

Tuxraldo · Janeiro 13, 2024, 1:33pm

Resolvi reinstalar meu Arch de testes só com o wayland. A única coisa que não tá funcionando direito é a systray da waybar. Porém eles mesmos avisam que ainda está em beta e que pode conter bugs. Como os programas que tenho que fazem uso da systray são todos do X11, muito provavelmente esse é um dos problemas.

De resto, notei apenas algumas pequenas diferenças de comportamento do sway para o i3. Nada demais e a maioria deles é porque simplesmente copiei meu arquivo de config do i3 e só estou modificando o que realmente precisa, como a parte das áreas de trabalho que acabei refazendo. E ainda assim alguns programas, como o KeepassXC, mesmo definida a opção de focus (quando ele é aberto o foco vai para área de trabalho definida para ele), não funcionam. Muito provavelmente porque ele roda através do xwaylaned e usa o class e não o app_id. O modo de resetar os layouts é diferente também, no i3 uso um comando para resetar um workspace inteiro para o modo padrão (que não meu caso é o tiling + split horizontal), quando faço isso no sway, saindo do modo tabeado, a barra de título das janelas se mantém. Vou ler a documentação com calma depois para saber porque isso ocorre.

Depois desse tempo minha waybar está quase pronta, faltam apenas alguns pequenos ajustes. Tenho achado ela bem ao estilo da polybar, com a diferença de que o arquivo de config principal é em json e, se utilizar um separado para as personalizações, é em css.

Ainda não consegui encontrar uma boa solução para imagens no wayland, usava o feh e o nsxiv no X11 (não consigo trocar as cores por é feito vi Xresources). Então continuei usando o nsxiv e o feh substitui pelo swaybg (que achei mais limitado). E o sway não parece ter um equivalente do comando “i3 --more” que mostra pequenas informações sobre o carregamento atual do i3.

Por indicação do @capezotte resolvi conferir o projeto nwg-shell. Instalei o meta pacote que tem no aur e vem com uma pancada de coisas úteis para window managers.

A ideia do projeto é criar ou adicionar ferramantes para o uso de ambientes mais minimalistas. Pelo que entendi, me corijam se eu estiver errado, ele funciona apenas com sway, hyprland e parcialmente com o dwl (tipo um dwm).

Não testei tudo porque tem muita coisa. Anteontem tive tempo e fiquei por conta de dar uma olhada nas ferramenteas que eles disponibilizam.

Azote: gerenciador de wallpaper, me lembrou o nitrogren só que é mais completo.
nwg-bar: até onde testei é apenas um powermenu que abre, por padrão, no centro da tela.
nwg-displays: tem a mesma função do arandr.
nwg-dock: uma dock simples.
nwg-drawer: um menu com icones bem parecido com aquele padrão do gnome.
nwg-look: bastante semelhante ao lxapperance com mais recursos.
nwg-processes: tipo um gerenciador de tarefas, abre uma janela com todos os processos em execução e você pode ver as informações, matar algum processo etc.

E por aí vai, tem bastante coisa. Quem quiser é só conferir a página do github deles. Umas duas ou três ferramentas eu achei bem parecidas, visualmente mesmo, com algumas coisas do gnome.

Tem um painel (nwg-panel) que é bem interessante. Dá pra configurar ele todo através de uma ferramenta gráfica. Eu fiz uns testes e dá pra deixar ele pronto relativamente rápido e pra quem não gosta/tem medo de mexer com arquivos de configuração é uma boa. Apanhei um pouco no começo e, a parte com os nomes das janelas abertas, eu não consegui deixar como queria, com uma pesquisa provavelmente resolveria isso bem rápido.

Quando tiver um tempo testarei com calma algumas das ferraments nwg-shell. Eles tiveram uma ideia bem boa e o projeto me pareceu bem interessante. Não gostei de instalar via metapacote não, instalou coisa demais. Muita coisa mesmo, quase 100 pacotes novos após a instalação. A vantagem é que instala um pacote do aur e ele traz praticamente tudo o que você precisa. A desvatagem é que, talvez, tenha muita coisa que você nem use ou saiba que tem, então é bom conferir e pegar só o que você precisar ou te interessar. Por equanto vou ficar com as soluções que já estava utilizando porque estão funcionando bem até agora.

SobDex · Janeiro 15, 2024, 12:46am

Esses dias migrei do arch para o fedora spin i3wm.
Com o i3wm configurado, instalei o Sway ontem e consegui configurar com algumas alterações no config e tive que pesquisar bastante sobre o layout do teclado que só ficava em inglês quando eu ia para o wayland o que provavelmente aconteceu por que não baixei o pacote completo do sway que vem separado no fedora. Meu plano, quando migrei para o fedora, era de ter o wayland e o xorg à disposição e com o i3 e sway ficou bastante coerente.
Consegui deixar o i3wm e o Sway “idênticos” na aparência, um com a polybar e o outro com a waybar. O rofi funciona para os dois. Para configurar o tema no wayland tive que usar o gesettings.
Sobre o xprop do xorg o sway tem uma alternativa:

swaymsg -t get_tree | grep "app_id"

e sobre o feh eu estou usando um programa com gui chamado azote. Ele também cria um arquivo ~/.azotebg e o uso é o mesmo do feh

i3:

sway:

Falando dos apps que senti falta… eu senti falta de um color picker vi que tinha um comando do grim com o slurp e criei uma interface simples pra usar o colorpicker (tem que ter o tkinter no python. Se não me engano, no arch é python-tk):

from tkinter import *
import subprocess
import os

def get_color():
    user = os.getlogin()    
    color_file_path = f'/home/{user}/.config/sway/scripts/picker/color.txt'
    comando = "grim -g \"$(slurp -p)\" -t ppm - | convert - -format '%[pixel:p{0,0}]' txt:- | tail -n 1 | cut -d ' ' -f 4 | wl-copy"
    # Executa o comando para salvar a saída no arquivo
    subprocess.run(comando, shell=True)
    
    # Cola o que foi para o clipboard no arquivo de texto
    subprocess.run(f'wl-paste > {color_file_path}', shell=True)
    
    # Lê o conteúdo do arquivo
    with open(color_file_path, 'r') as file:
        color_hex = file.read().strip()

    # Atualiza o Text com o conteúdo lido
    hexdecimal.delete(1.0, END)  # Limpa o conteúdo atual
    hexdecimal.insert(END, color_hex)

    # Muda a cor do frame e da label
    colorshow.config(bg=color_hex)
    space.config(bg=color_hex)


root = Tk()
root.geometry('165x120')
root.minsize(165, 120)
root.maxsize(165, 120)
root.title('Sway Picker')
root.config(bg='#2a2e32', padx=5, pady=5)
top = Frame(root, bg='#2a2e32')
picker = Button(top, text='', bg='#2a2e32', fg='#FFF', command=get_color)
picker.pack(padx=5, pady=5, side=LEFT)

hexdecimal = Text(top, width=7, font=('Inter', 14), height=1)
hexdecimal.pack(padx=5, pady=5, side=LEFT)
top.pack(side=TOP)

colorshow = Frame(root, bg='#000000', bd=1, relief='solid')
space = Label(colorshow, text=' ', bg='#000000')
space.pack(pady=30)
colorshow.pack(fill=X, padx=5, pady=5, side=BOTTOM)


root.mainloop()

a única coisa que talvez seja necessária é mudar a fonte Inter para outra fonte de sua preferência. E também tem que lembrar que o caminho que ele vai procurar o arquivo de texto onde ele salva a cor: ~/.config/sway/scripts/picker/color.txt (altere como desejar). Ficou simples, mas me ajuda bastante.

20240115_00h37m12s_grim

Tuxraldo · Janeiro 15, 2024, 6:22pm

Cê teve problema ou trabalho para arrumar os espaços na waybar? A única coisa que me incomodou nela foi isso. É meio chato ficar a ajustando os espaços entre os módulos. Principalmente se algum modulo não fica visível sempre, no meu caso os de exibir o layout das janelas e o scratchpad. Tirando isso por aqui tá tudo de boa. Já tem, que eu me lembre, mais de duas semanas que to usando o sway direto.

Ainda tem um ou outro bug, coisa que com o tempo e com mais gente usando será resolvido com certeza. O modulo do cmus, por exemplo, se eu aumentar o volume (com o scroll do mouse) muito rapidamente, ele tá um bug (troca rapidamente a cor de fundo para uma das cores da própria waybar).

SobDex · Janeiro 15, 2024, 8:37pm

Os espaços entre os módulos eu ajustei só no css msm só usando o padding. Não tive muitos problemas pq minha waybar é simples, talvez por eu não ter módulos condicionais para aparecer só em certas circunstâncias. O css está assim:

* {
    font-family: FontAwesome, Roboto, Helvetica, Arial, sans-serif;
    font-size: 100%;
    font-weight: bold;
    min-height: 0;
	padding: 0px;
    margin-top: 0px;
    margin-bottom: 0px;
}

#waybar {
    /*background: linear-gradient(to bottom right, rgba(0, 0, 0, 0.9), rgba(16, 16, 16, 0.8), rgba(0, 0, 0, 0.9));*/
    background: rgba(0, 0, 0, 0.9);
    /*background-color: transparent;*/
    color: #ffffff;
    transition-property: background-color;
    transition-duration: .5s;
    border-radius: 5;
}

#waybar.hidden {
    opacity: 0.2;
}

#sway-workspaces {
    padding: 0px 10px;
    color: #ffffff;
}

#workspaces button {
    padding: 0 5px;
    margin-right: 4px;
    color: #ffffff;
}

#workspaces button:hover {
    color: #ffffff; /* Altera a cor do texto durante o hover */
}

#workspaces button.urgent {
    background-color: #eb4d4b;
}

#workspaces button.focused {
    /*border-bottom: 1px solid #fff;*/
    color: #00ffff;
}

#workspaces button.persistent {
    color: #ffffff;
}

#custom-play, 
#custom-prev, 
#custom-next,
#custom-cmus {
	border: none;
    color: #AAAAAA;
    text-shadow: 2px 2px 4px rgba(0, 0, 0, 0.5);
}

#custom-killcmus{
	border: none;
    color: #AAAAAA;
    padding: 0px 10px 0px 0px;
    text-shadow: 2px 2px 4px rgba(0, 0, 0, 0.5);
}

#window {
    text-shadow: 2px 2px 4px rgba(0, 0, 0, 0.5); /* Adiciona sombra ao texto do #window */
}

/* Outros módulos (substitua os IDs conforme necessário) */
#clock,
#custom-temp,
#custom-updates,
#custom-wallpaper,
#custom-picker,
#cpu,
#memory,
#pulseaudio,
#pulseaudio.muted,
#tray {
    padding: 0px 5px;
    color: #ffffff;
}

#tray > .passive {
    -gtk-icon-effect: dim;
}

#tray > .needs-attention {
    -gtk-icon-effect: highlight;
    background-color: transparent;
}

Sobre o cmus eu não uso este módulo. Para controle de mídia eu uso o playerctl

Tuxraldo · Janeiro 15, 2024, 8:45pm

Ia comentar do layout e esqueci. Se usar um (no config do sway):

input "type:keyboard" {
    xkb_layout br
}

Não resolve o problema? Usando essa opção dentro do arquivo de config do sway, toda vez que ele carregar ele vai usar esse layout que você definiu. Fiz isso aqui logo na primeira vez que instalei e nunca tive qualquer problema.

SobDex · Janeiro 15, 2024, 8:46pm

Sim agora eu uso também desta forma, mas demorei para achar essa informação no dia que instalei

Tuxraldo · Janeiro 15, 2024, 9:43pm

Faz parte, quem nunca fez nada assim em um twm que atire a primeira pedra kkkkkkkk

Uma dica, dá uma conferida com calma em alguns links que coloquei lá no fim da primeira postagem. Tem bastante coisa útil, especialmente no github do sway. Consegui configurar tudo rapidinho só lendo o conteúdo desses links que postei.

Tuxraldo · Fevereiro 17, 2024, 2:11pm

Quase dois meses após a instalação e sigo firme no sway. Ele tem algumas pequenas diferenças para o i3wm. A swaybar (equivalente da i3-bar), por exemplo, tem umas opções de frufru visual a mais (quando sobrar um tempo, farei um post sobre isso), tipo adicionar aqueles “gaps” entre a barra e os cantos da tela. No sway de modo geral não notei nada que me pareceu específico, só um ou outro nome que, por motivos óbvios, são diferentes dos do i3.

Tudo que eu utilizava no x11 já usei, substitui ou testei no wayland com uma única exceção, aqueles programas de acesso remoto, tipo o anydesk. Preciso de um instalado porque de vez em quando preciso mexer no pc de algum parente e, normalmente, a galera mora em outra cidade. Me falaram que esses programas ainda não funcionam direito no wayland, não sei porque ainda não usei. A única desvantagem que vi até agora são a falta de alternativas, os programas existem mas em menor quantidade. Isso certamente só será resolvido quando o wayland for mais utilizado.

Minhas configs já estão totalmente adaptas e, com exceção do vim, tudo funcionando normalmente. Não sei por qual motivo, o vim não tá copiando para o clipboard (wl-clipboard). Ainda não tive tempo de pesquisar, parece que tem um plugin que conserta isso. Instalei o neovim pra testar e tá funcionando. Com as mesmas configs do vim, não alterai absolutamente nada. Só fiz um source do meu vimrc lá no init.vim. Já vi muita gente elogiando a velocidade do neovim, no meu uso tá igualzinho o vim, não vi diferença nenhuma. Alguém aí sabe o que pode ser esse problema do vim+clipboard?

A única diferença do sway para o i3 que me incomoda é o comportamento padrão do modo tabeado. No i3 se eu abrir duas janelas e colocar em modo tabeado, quando eu fechar uma das duas a barra de títulos da janela que ficou aberta é automaticamente escondida. Essa janela (chamada de container no i3/sway) ainda mantém o modo tabeado como layout, sem a barra de títulos. No sway a barra de título se mantém e, na documentação não tem (eu não consegui achar) uma forma de evitar isso. Eu entendo a ideia, afinal se o container tá em modo tabeado a barra de títulos visível ajuda a indica isso, só acho um comportamento desnecessário, prefiro o jeito do i3.

Duas janelas em modo tabbed:

Após fechar o terminal e deixar só o container com o vimwiki, repare que a barra de títulos se manteve:

Resolvi testar o hyprland novamente, só de curiosidade mesmo, porque não acho que ele apresente algum recurso ou nada que realmente me interesse. É o twm da moda e a galera gosta pela questão visual, raramente vejo alguém elogiando algum recurso que seja um diferencial ou coisa do tipo. E, novamente, o problema da tela preta após o logout. Desisti, desinstalei e larguei pra lá. Provavelmente nunca mais usarei

Bom, já me adaptei ao jeito de ser do wayland. Porém, sempre tem uma ou outra coisa que parece que não tá totalmente adaptada ou 100% funcional e outras que, simplesmente, ainda não tem alternativa. O bug de fechar aleatoriamente a janela do virt-manager continua, o que me irrita as vezes. Achei uma issue sobre o tema e pelo que entendi nem sabem direito o que pode estar causando o problema. Digo o mesmo para o problema do hyprland, tem link dessa issue aí pra cima. Ao contrário da do virt-manager, a do hyrpland tá em constante atualização.

Outra coisa que me chamou atenção nos primeiros usos e se confirmou com o tempo, é a dependência de repositórios externos. Muita coisa, no caso do Arch, só tá disponível no aur. Tenho preguiça disso, gosto de praticidade. Se instalar as coisas direto pelo pacman, para atualizar e manter depois é mais prático. Só tenho dois pacotes do aur e, como eles não tem dependências no próprio aur, mantenho eles atualizados manualmente mesmo.

Acho que é isso, pra não virar um diário do wayland, essa tá sendo minha experiência. Paro os posts por aqui. Confirmo o que disse aí pra cima, o wayland ainda tem bastante chão pela frente e o sway é a melhor alternativa de twm. No estado atual dá para usar de boa, entendendo as limitações e, certamente, você vai se deparar com algum bug (citei o do virt-manager e do appimage) ou falta de algum programa específico. Nada que não dê para contornar. Agora, isso da perspectiva de quem usa um twm, provavelmente, usando gnome ou kde, talvez você nem note que não tá usando o xorg.

Tenho gostado de usar o wayland. O foot é um ótimo terminal e o sway, como não podia ser diferente, idem. Recomendo que, quem tem curiosidade, faça um teste aí. Uma pena que ainda não temos o xfce funcional no wayland, e pelo visto nada a curto prazo. Como alternativa temos o mate. O gnome e o kde são ótimos projetos, só não consigo me adaptar a eles. Para quem curte, também funcionam muito bem com wayland. O gnome principalmente, porque já tem tempo que tá focado nele.

Pra quem se interessar, seguem minhas configs do sway.

Capezotte · Fevereiro 17, 2024, 8:10pm

O Vim utiliza diretamente as bibliotecas de clipboard do X11 (você pode confirmar com ldd $(which vim)), enquanto o Neovim utiliza os comandos externos do wl-clipboard/xclip conforme o ambiente.

Segundo o patch que adicionou suporte a Wayland no Gvim, os compositores wlroots (incluindo o Sway) só sincronizam as duas clipboards (Xwayland e Wayland de verdade) quando o foco está numa janela do Xwayland. Rodando o vim no foot, isso nunca acontece.

Pio · Fevereiro 18, 2024, 2:24am

Estes dias instalei o hyprland em um pc que estava parado e me deparei com este problema, procurei até encontrar no NoMachine, ele funcionou 50% do esperado, agora não me recordo realmente onde especificamente foi o problema, visto que usei apenas 1x enquanto estava configurando o hyprland.

Os possíveis cenários que testei:
Qtile para Hyprland (pc 2)
Hyprland (pc 2) para Qtile
Hyprland (pc 2) para Hyprland

Dentre a 2 ou 3 opção não consegui funcionar mesmo desabilitando o firewall do pc principal, não fiquei muito tempo vendo isso visto que estava mais focado em ajustar o hyprland, portanto não posso garantir o funcionamento do app NoMachine, mas segue a sugestão caso não encontra alguma opção. Estou viajando senão testava para identificar o problema que eu tive.