Copiar Para e Mover Para no menu de contexto do Nautilus e Dolphin

Nessa dica eu mostrei como implementar no Thunar as opções de menu de contexto Copiar Para e Mover Para e assim economizar uns cliques nessas ações corriqueiras de trabalhar com arquivos. Agora vamos ver isso no Nautilus e no Dolphin cujas configurações já existem mas ficam meio escondidas.

Nautilus

O Nautilus anda vacilando com uma política de "vamos tirar sem perguntar nada" e com isso vemos extensões legais como o Nautilus Image Converter simplesmente sair dos repositórios (ou não disponibilizadas) e outras que deveriam já existir por padrão e a 'copiar/mover para' deveria ser uma delas. Para ter acesso à opção veja se o seu sistema tem os pacotes libnautilus-extension4 e python3-nautilus (nome do pacote no Debian). Se não o tiver:

sudo apt install libnautilus-extension4
sudo apt install python3-nautilus

Reinicie a sessão e as opções deverão estar disponíveis no botão direito do mouse:

Dolphin

No Dolphin há a necessidade do pacote dolphin-plugins. Se não o possuir:

sudo apt install dolphin-plugins

No Dolphin você pode baixar mais opções de menu de contexto (que se chama Service Menu) indo nos "3 pontinhos" do lado superior esquerdo, Configurar/Configurar Dolphin, Menu de Contexto; a opção Comandos 'Copiar e Mover para' deverá estar disponível (marque-a e clique em Aplicar).

Se não estiver, nessa janela clique em Baixar Novos Serviços e procure por lá, há bastante coisa para complementar o uso do Dolphin.
Uma vez instalados, as opções escolhidas estarão disponíveis.

"Keep It simple" não significa ter as coisas funcionais adequadamente...

 

 

 

Dotando o Thunar das opcoes Copiar para e Mover para no menu de contexto

 Aqui vou mostrar como criar as opções de Copiar para e Mover para no menu de contexto do mouse, que existe no Nautilus e no Dolphin e que também deveria ter no Thunar.

Copiar para:
Abra o terminal e crie o arquivo:

sudo nano /usr/local/bin/thunar-copiar-para.sh

Coloque dentro:

#!/bin/bash

# Escolher destino
destino=$(zenity --file-selection --directory --title="Escolha a pasta de destino")
[ -z "$destino" ] && exit 0

# Perguntar sobre sobrescrever
zenity --question --text="Deseja sobrescrever arquivos existentes?"
sobrescrever=$?

# Monta opção do rsync
if [ $sobrescrever -eq 0 ]; then
    OPTS="--ignore-existing"
else
    OPTS=""
fi

# Lista total de arquivos para progresso mais preciso
total=$(printf "%s\n" "$@" | wc -l)
count=0

(
for item in "$@"; do
    count=$((count+1))

    echo "# Copiando: $(basename "$item") ($count de $total)"

    rsync -a --info=progress2 $OPTS "$item" "$destino" 2>/dev/null

    echo $((count * 100 / total))
done
) | zenity --progress \
           --title="Copiando arquivos" \
           --percentage=0 \
           --auto-close \
           --width=400

zenity --info --text="Cópia concluída!"

Salve com CTRL+O e feche com CTRL+X. Depois:

sudo chmod +x /usr/local/bin/thunar-copiar-para.sh

Mover para:
Abra o terminal e crie o arquivo:

sudo nano /usr/local/bin/thunar-mover-para.sh

Cole dentro:

#!/bin/bash

destino=$(zenity --file-selection --directory --title="Escolha a pasta de destino")
[ -z "$destino" ] && exit 0

zenity --question --text="Deseja sobrescrever arquivos existentes?"
sobrescrever=$?

if [ $sobrescrever -eq 0 ]; then
    OPTS="--ignore-existing"
else
    OPTS=""
fi

total=$(printf "%s\n" "$@" | wc -l)
count=0

(
for item in "$@"; do
    count=$((count+1))

    echo "# Movendo: $(basename "$item") ($count de $total)"

    rsync -a --remove-source-files --info=progress2 $OPTS "$item" "$destino" 2>/dev/null

    # Remove diretórios vazios após mover
    [ -d "$item" ] && find "$item" -type d -empty -delete

    echo $((count * 100 / total))
done
) | zenity --progress \
           --title="Movendo arquivos" \
           --percentage=0 \
           --auto-close \
           --width=400

zenity --info --text="Movimentação concluída!"

Salve com CTRL+O e feche com CTRL+X. Depois:

sudo chmod +x /usr/local/bin/thunar-mover-para.sh

Abra o Thunar e vá em Editar/Configurar Ações Personalizadas. Na janela que aparecer, clique em + e complete conforme abaixo.

Copiar para:

• Nome: Copiar para...
• Descrição: Ação de copiar pastas e arquivos para determinada pasta ou lugar
• Comando: /usr/local/bin/thunar-copiar-para.sh %F

Na aba Condições Para Aparecer, marque tudo.

Mover para:
Crie outra entrada agora como Mover para... e repita os procedimentos, mudando a linha de comando (e a descrição) para:

sudo nano /usr/local/bin/thunar-mover-para.sh

Dê OK em tudo e fecha as janelas. Para usar o menu de contexto, abra o Thunar e escolha um ou mais arquivos e pastas (podem ser misturados), escolha a opção Copiar para... ou Mover para... e selecione a pasta ou local de destino.

E aguarde a cópia/movimentação do que foi selecionado. Há uma barra de progresso por item e pergunta se é para sobrescrever se algo já existir.

Mais simples do que ganhar da "selessão barasileira de futibóu", hehehe...

Usando o ble.sh (Bash Line Editor) no lugar do bash completion

 O BASH é um excelente interpretador de comandos mas deixa um pouco a desejar no uso diário se for comparado com o ZSH. Aqui vou mostrar a instalação e uso do "ble.sh" para o bash e que tem mais funcionalidades que o bash completion disponível nos repositórios.

O ble.sh tenta reproduzir as funções mais modernas do zsh, como completar comandos, sugerir comandos com parte já digitada e até a colorir conteúdos como pastas e arquivos mas o achei limitado, pois o autosuggestions dele de comandos já digitados é apenas (pelo que eu experimentei) para o comando mais próximo do histórico. Por exemplo, se você já tiver digitado e está no histórico do bash:

• sudo apt install gawk
• sudo apt autoremove
• sudo apt remove ri-li

ao digitar "sudo apt", em vez de poder navegar com as setas para acessar as 3 opções mostradas (install gawk, autoremove e remove ri-li) ele "vai" na entrada mais nova (de baixo pra cima) e ignora as outras. O zsh consegue via "meio comando" (como no nosso exemplo) navegar pelas opções já digitadas anteriormente através das setas.

Mas enfim, para experimentar, faça assim:

git clone https://github.com/akinomyoga/ble.sh ~/.ble.sh
sudo apt install gawk
cd ~/.ble.sh
make

Depois:

nano ~/.bashrc

Coloque no final do arquivo:

# ble.sh
if [ -f ~/.ble.sh/out/ble.sh ]; then
  source ~/.ble.sh/out/ble.sh
fi

E finalmente:

source ~/.bashrc

O bash fica mais "alegrinho" e cheio de fru-fru mas, sinceramente, ainda prefiro o zsh e os "3 milhões" de plugins que ele tem.

Pelos testes que eu fiz o bash/ble.sh tem mesmo essa limitação de sugerir comandos "meio digitados" mas já digitados anteriormente. Se alguém descobrir uma forma de fazer isso no ble.sh ou mesmo no bash aos moldes do zsh por favor coloque nos comentários.

Vou explicar de novo esse lance de auto-complete e auto-suggestions. O auto-complete funciona, você digita o comando pela metade e as opções de comando ficam disponíveis. Por exemplo, digitando apenas "apt" e apertando TAB aparecerão os complementos ao comando disponíveis: 

apt                   apt-extracttemplates  apt-mark            
apt-cache             apt-ftparchive        apt-sortpkgs        
apt-cdrom             apt-get                                   
apt-config            apt-listchanges   

Já o auto-suggestions quando, se você já tiver digitado e estiver no histórico:

sudo apt install gawk
sudo apt autoremove
sudo apt remove ri-li

ao digitar apenas sudo apt TUDO em termos de comandos que estejam no histórico do bash (no caso, no zsh) DEPOIS do sudo apt podem ser acessados via setas do teclado. No zsh isso funciona assim; no bash só mostra o comando mais novo e ignora o resto.

Vale a pena ter mais de uma interface grafica no seu Linux?

Nos meus anos de uso de Linux (sim, eu não uso só por um dia e depois largo) já usei todo tipo de interface gráfica (ou ambiente de desktop) e de versões de Linux, de principais até as derivadas e hoje em dia prefiro usar uma principal customizada com o que eu preciso. Não adianta pegar uma "baseada" do tipo "podrão da Central" (termo no RJ para aquele sanduba com tudo dentro) onde o "desenvolvedor" enfia nessa "distribuição" tudo o que ele acha que o usuário vai precisar no dia a dia e tira desse mesmo usuário o eventual e valioso aprendizado para implementar um desktop mais produtivo.

Muitos usuários usam a máquina do jeito que recebem, acham um saco ou mesmo perda de tempo deixar o sistema funcional para as suas necessidades. Pra que perder tempo em fóruns e vídeos na internet que pedem Pix de 10 pilas e ensinam como configurar as coisas se fumar e beber - que são coisas dispensáveis - são prazeres temporários e mais caras do que conhecimento? Cadê a curiosidade, a vontade de experimentar, deixar as coisas do seu jeito? Essas coisas devem estar nas telas do Tigrinho...

Aqui vou falar dos prós e contras de se usar mais de uma interface gráfica no seu desktop Linux.

Alguns prós

• Aumenta o leque de aprendizado e experiência de uso;
• Se um ambiente morrer tem outras opções;
• Integração de aplicativos ou recursos que funcionam melhor em um ambiente gráfico do que em outro;
• Se ficar de saco cheio de uma interface (e acredite, vai ficar) dá pra trocar por outra sem precisar instalar/desinstalar.

Alguns contras

• Aumenta o espaço em disco utilizado;
• Aumenta o tamanho da instalação final e dos eventuais updates de pacotes ao longo do uso;
• Os menus de aplicativos acabam ficando mais poluídos pelos outros aplicativos das outras interfaces gráficas;
• Bibliotecas redundantes (no caso, GTK e QT);
• Serviços que se iniciam e que não pertencem ao ambiente em uso, como dois serviços de notificação ou dois keyrings de senhas;
• A aparência entre aplicativos podem ficar "feia" se rodarem no ambiente ao qual não "pertencem".

A imagem acima mostra como fica a sessão Sistema tendo Gnome, Plasma 6 e XFCE na mesma máquina, onde é mostrado ícones de programas das 3 interfaces gráficas. Algumas não são mostradas pois alguns arquivos .desktop tem a variável OnlyShowIn=XFCE. Por exemplo, o Cairo-Dock:

[Desktop Entry]
Type=Application
Exec=cairo-dock
Icon=cairo-dock
Terminal=false
Name=Cairo-Dock
Comment=A light and eye-candy dock and desklets for your desktop.
Comment[pt_BR]=Um dock de aplicativos bonito e leve com desklets para o seu ambiente de trabalho.
Categories=System;
OnlyShowIn=XFCE;
Hidden=false

Esse parâmetro faz com que o ícone do Cairo-Dock só apareça no XFCE e isso é usado nos .desktops para permitir ou não que programas de um ambiente "apareçam" em outro. Isso não é padrão de ser feito, eu mesmo coloquei esse parâmetro para que o Cairo-Dock apareça só no XFCE mesmo porque estou satisfeito com o Dash to Dock do Gnome e com o painel de ícones do Plasma 6. E atenção, o ícone pode não aparecer MAS o programa ainda estará disponível para ser aberto.

Tirando os "contras" não há problemas no uso de mais de uma interface gráfica, o que gere isso é basicamente a necessidade pessoal. Os desktops podem ser configurados de modo que os ícones de programas "oficiais" do ambiente fiquem mais acessíveis.

Por exemplo, a extensão Dash To Dock permite que o usuário coloque os programas que mais usa no dock de ícones que fica disponível o tempo todo e, em modo overview, juntar na primeira janela de ícones o resto dos programas que usa "menos vezes" e o resto ele "joga pra lá" (nas outras telas do overview).

No Plasma, a mesma coisa. O dock de ícones recebe os programas mais utilizados e o Kicker (o menu de aplicativos) tem a possibilidade de se colocar os outros favoritos na listagem.

E no XFCE - que pode ser visto na primeira imagem, o Cairo-Dock possui os ícones dos programas mais usados, ficando o resto no menu de aplicativos e que podem ser chamados pelo U-Launcher (no meu caso).

Só quando se usa ambientes de desktop cujos menus de ícones são mais "crús" (como o do XFCE) é que o caldo pode engrossar. A combinação de interfaces como Mate, Cinnamon e XFCE podem dar mais trabalho de serem configuradas mas, no final, o efeito é o mesmo, cada ambiente configurado com o que mais se usa sem interferir no funcionamento do outro ambiente.

Até pode dar trabalho mas vale a pena.

 

A combinação de WMs com compositores feitos por fora

O gerenciador de janelas (WM ou Window Manager) é a parte responsável pela estrutura das janelas que vemos no desktop: posicionamento, movimentação, redimensionamento, foco entre janelas, atalhos de teclado e também pelas decorações das janelas (botões, bordas, título etc.). Em outras palavras, o WM monta toda a estrutura visual básica das janelas junto com o tema escolhido (botões, contorno, cores e tudo mais) e é assim que vemos tudo organizado na tela.

Já um compositor é o componente responsável pela "amenização visual" das janelas, aplicando efeitos como transparências, blur, sombras, animações e outros efeitos gráficos.

Uma forma simples de entender o conceito é imaginar o gerenciador de janelas como a estrutura básica da imagem de uma pessoa sem maquiagem, enquanto o compositor seria a mesma imagem depois de receber maquiagem e filtros - tipo aquelas fotos mais "produzidas" que aparecem no Tinder, mais falsas do que nota de 150 pratas, hehehe...

O sistema pode ficar sem compositor, mas não pode ficar sem um gerenciador de janelas. Sem compositor tudo continua funcionando normalmente mas a aparência fica mais simples e sem efeitos visuais.

Com compositor:

Sem compositor:

Para a maioria dos usuários, um desktop Linux minimamente apresentável acaba sendo um fator importante na escolha da distribuição. Muitas vezes a aparência pesa até mais que a própria utilização no primeiro contato, principalmente quando o usuário vem do Windows e quer saber "qual é essa de Linux". Se o sujeito vê uma distribuição com aparência muito crua ou mal configurada, a reação costuma ser rápida: instala, olha… e tchau.

Por isso os ambientes gráficos (Desktop Environments) normalmente já vêm com gerenciadores de janelas que também incluem um compositor integrado. Por exemplo:

• O GNOME usa o Mutter — o compositor pode ser desativado apenas em modo X11.
• O KDE Plasma usa o KWin — o compositor pode ser ativado ou desativado.
• O XFCE usa o Xfwm4 — também possui compositor embutido que pode ser desligado.

Seguindo aquela lógica de jogador de Counter-Strike que gosta de pegar a arma do adversário, também é possível usar compositores externos em vez dos que já vêm integrados nas interfaces gráficas. Um exemplo bastante conhecido é o Picom.

Assim, você pode desativar o compositor nativo do ambiente gráfico e rodar o Picom no lugar. Isso pode ser feito no Plasma, no XFCE ou em ambientes que usam apenas um gerenciador de janelas.

Vale lembrar, porém, que os compositores (e também os gerenciadores de janelas) que vêm integrados a cada ambiente gráfico são desenvolvidos especificamente para funcionar bem naquele ambiente. Usar alternativas externas pode funcionar, mas às vezes o resultado não fica tão integrado ou estável quanto a solução original.

Também é possível usar um gerenciador de janelas no lugar de outro. Isso permite experimentar comportamentos diferentes sem trocar todo o ambiente gráfico.

Por exemplo, no XFCE é possível substituir temporariamente o gerenciador de janelas padrão, que é o Xfwm4.

Para usar o KWin no XFCE:

kwin_x11 --replace

Esse comando encerra o gerenciador de janelas atual e faz o KWin assumir o controle das janelas naquela sessão.

Em ambientes baseados em Wayland a lógica é diferente, e o comando --replace normalmente não se aplica da mesma forma, porque o gerenciador de janelas costuma fazer parte do próprio compositor da sessão.

Esses comandos substituem o gerenciador de janelas apenas temporariamente. Ao reiniciar a sessão ou o computador, o ambiente gráfico volta a iniciar o gerenciador padrão configurado - no caso do XFCE, o Xfwm4 volta a mandar na bagaça.

Também é importante lembrar que gerenciadores de janelas como o KWin ou o Mutter foram desenvolvidos para funcionar principalmente dentro de seus ambientes gráficos originais - respectivamente o KDE Plasma e o GNOME.

Isso significa que substituir o gerenciador de janelas do XFCE por outro não transforma o XFCE em GNOME ou Plasma. Muitas funcionalidades visuais, integrações e comportamentos que vemos nesses ambientes dependem de outros componentes da interface gráfica, extensões e serviços que não estão presentes fora do ambiente para o qual foram projetados.

Em outras palavras: trocar o gerenciador de janelas pode mudar o comportamento das janelas e alguns efeitos visuais, mas não recria toda a experiência do ambiente gráfico original.

Toda experimentação é válida para otimizar ao máximo o uso da máquina com a DE ou WM escolhida, mas não espere estabilidade total com esse tipo de alteração.

Um compositor mais leve (como o Picom) pode ser bastante interessante para manter o básico da composição gráfica em máquinas mais modestas, que podem "achar ruim" rodar o KWin no KDE Plasma ou o Mutter no GNOME, especialmente em sessões X11.

Já substituir o gerenciador de janelas pode ser tentado para testar novos comportamentos ou estilos de gerenciamento das janelas, mas isso também pode introduzir novos problemas, incluindo aumento no consumo de memória, maior uso de recursos gráficos ou até perda de integração com algumas funções do ambiente gráfico.

Em muitos casos essas trocas funcionam bem para testes ou experimentação, mas o gerenciador de janelas original do ambiente gráfico costuma oferecer a melhor integração e estabilidade no uso cotidiano.

O bom e velho Xterm

Em tempos de terminais bonitinhos com múltiplas abas, integrações de ícones e outras coisas, tem um carinha que normalmente é instalado por padrão nas distribuições de Linux mas que fica mais deixado de lado do que manual de instrução de celular: o XTerm.

O Xterm é um terminal simplão, sendo considerado "feio" para os padrões de hoje: fonte quadrada, cara de software abandonado, interface que parece ter sido desenhada quando monitor ainda era quadrado (e foi, hehehe). Se você abrir isso hoje, do lado de um terminal cheio de transparência, blur, sombra e emoji colorido, a comparação fica bem mais evidente. Mas aí entra o detalhe que muita gente odeia admitir: XTerm funciona; sempre.

Enquanto um terminal bombadão instalado e configurado:

• depende de GPU;
• depende de Wayland ou mesmo X11 alinhados;
• depende do compositor não estar de "compositagem";
• depende de meia dúzia de libs que quebram a cada release;

o XTerm tá lá, firme, olhando pra você dizendo: "Ô môuçu, eu estou aqui!" igual a minha gata pedindo comida.

O XTerm não é pra agradar e sim para funcionar. Terminais modernos têm um problema sério: tentam ser legais demais, muitas vezes por vontade do usuário que procura facilidades de uso que normalmente são dadas por plugins, como transparência, blur, "adivinhar" o que você quer e até reinventar copy/paste. O Xterm não tem nada disso, nem abas, nem interface de configuração. Ele só quer emular um terminal direito, como manda o figurino, o usuário é que muda (ou quer mudar) as coisas.

Selecionou com o mouse? Copiou; botão do meio? Colou; quer diferente? Vai configurar, cumpadi. E é aí que o bagulho complica. Vão dizer que "Mas ninguém usa isso hoje" mas usa sim, a não ser a galera que troca de distro "a cada seis meses". Os terminais são usados por:

• quem depura software sério;
• quem mexe com sistemas antigos;
• quem trabalha remotamente;
• e, principalmente, quem faz edições de configuração de arquivos manualmente ou uso programas cmd e scripts.

Mas quando algo dá errado em modo texto em um terminal bonitinho, adivinha em qual terminal o cara testa primeiro? Não é no terminal com blur roxo translúcido. É no XTerm porque, se quebra no XTerm, aí sim você tem um problema de verdade.

Configuração: o item que gera a "crise do 'nungostêi' por ser feio"

Aqui mora a metade do ódio. XTerm não tem arquivinho bonito, wizard, menu gráfico, preview ao vivo ou abas, é só a janela do terminal todo preto com letras parecendo bugadas e com a aparência dos jogos da seleção brasileira. Ele usa Xresources, aquela coisa jurássica que faz muita gente chorar no banho.
Mas o detalhe é que os chorões ignoram o nível de controle absurdo que isso proporciona. Você pode configurar praticamente tudo: fonte, cores, cursor, comportamento de seleção, scroll, teclado, mouse, encoding mas tudo já está funcional sem mexer em nada disso. Só não pode reclamar que é difícil e, ao mesmo tempo, querer controle total. Escolha um.

Robustez: quando tudo quebra, o XTerm continua lá

Esse é o ponto que dói. Você muda compositor, driver de vídeo, WM, DE, backend gráfico e de repente o terminal não abre, o texto pisca, o input atrasa, cola errado, trava e já começa "máis qui sistêma pôudre, púrisso êu perefíru Uíndôws". Aí você abre o XTerm e... ele funciona! E isso não é coincidência, é a consequência de querer manter funcionando o que já funciona.

O problema não é o XTerm - é o ego do usuário

Muita gente odeia o XTerm porque ele expõe uma verdade incômoda: você não precisa de 90% das firulas que acha que precisa. O XTerm escancara isso pois não tem abas, ícones, blur ou animação, é mais sem graça do que descobrir que todo mundo ganhou aumento menos você. E mesmo assim, faz o trabalho melhor do que muita coisa "moderna" - como você no exemplo anterior em relação ao aumento. Isso fere o ego de quem confunde produtividade com estética e isso não é só no terminal, também ocorre com distribuições onde o usuário normalmente dá mais valor àquela "distro bunitinha" do que uma funcional. E por conta disso o Xterm só costuma mostrar a sua funcionalidade quando a vaca já foi pro brejo...

Mesmo sendo velho, feio e chato de ser configurado, ainda assim está lá pra te tirar da lama enquanto os outros te deixaram na mão, pra depois ser esquecido de novo quando tudo voltar a funcionar graças a ele. Se você odeia o XTerm, tudo bem, ele está nem aí por você; mas quando seu terminal favorito resolver dar piti numa compilação de 5 horas, ou uma gravação de vídeo via cmd, ou quando o sistema "morrer", adivinha quem ainda vai estar lá, aberto, esperando você digitar?

Pois é...

Aqui então está uma configuração que vai dar uma "upada" na aparência do XTerm sem fazê-lo perder as funcionalidades. Edite o arquivo ~/.Xresources:

nano ~/.Xresources

Cole essas linhas:

Xcursor.theme: WinSur-dark-cursors
Xcursor.size: 16
XTerm*faceName: DejaVu Sans Mono
XTerm*faceSize: 12
XTerm*geometry: 79x21
XTerm*scrollBar: false
XTerm*borderWidth: 0
XTerm*background: #2e3436
XTerm*foreground: #d3d7cf
XTerm*cursorColor: #fce94f
XTerm*cursorTextColor: #2e3436

CTRL+O para salvar e CTRL+X para sair; depois:

xrdb -merge ~/.Xresources

Vá lá no XTerm e ele deverá aparecer como mostrado abaixo.

Acredito que as configurações mostradas devam satisfazer a maioria dos usuários, com uma janela de tamanho adequado, basicamente com tudo que o sistema do usuário já tenha. Até as cores são configuradas para que os comandos usados não fiquem com letras sobrepostas pelo cursor do mouse.
Há outras configurações mas creio que essas já são suficientes para tirar a "cara de véio" para algo mais moderno sem perder a identidade funcional.

O bom e velho XMMS substituído pelo VLC, Audacious e até mesmo o QMMP

Eu estava procurando plugins ao estilo VU Meter que tinha para o XMMS mas não encontrei um equivalente para usar no Audacious ou outro player de áudio para ter aquele efeito de VU mecânico existente até hoje em aparelhos de som, tanto os vintage (anos 80/90) quanto os profissionais. O VU ao qual me refiro é esse aqui:

 O funcionamento é simples, o ponteiro se movimenta na escala mostrada de acordo com o nível de sinal, dando um efeito rítmico que fazia muitas pessoas ficarem paradas na frente do equipamento só "urubuservando" o equipamento.
Claro que hoje em dia há outros tipos de VU, como os de barra de LEDs ou com construções luminosas de leds que fazem até desenhos mas os medidores de ponteiro ainda são um "must" dos saudosistas.

Nesse tipo de pegada tínhamos o XMMS com um plugin chamado VU Meter mas que infelizmente não foi portado para o Audacious e nem pro QMMP e o VLC "finge" que tem um parecido. Mesmo compilando plugins o que temos é:

Audacious

QMMP

VLC

Tudo até legalzinho, o VLC - como falei - "finge" ter um VU do tipo mas nada que chegue perto ao que tínhamos no XMMS:

Aí sim era legal ouvir músicas no PC, bastava deixar o XMMS tocando a playlist e a janela do plugin de VU acima das outras janelas e pronto, temos um monte de gente em cima do PC perguntando "mas que aparelho é esse?", hehehe...

Sei que as coisas precisam de evolução mas é uma pena que projetos interessantes que não possuam qualquer tipo de ajuda - seja financeira ou de colaboradores já que ninguém vive de brisa - somem do mapa e há centenas de outros projetos na mesma situação. Alguns deles, sejam abandonados ou praticamente parados no desenvolvimento ou atualizações:

• XMMS;
• Compiz Fusion;
• Amarok;
• SystemBack;
• Remastersys;
• latte-dock.

e tantos outros que ou realmente sumiram, ou estão presentes em distribuições mais antigas (e que podem ou não funcionar) ou ganharam um "fork", como o XMMS tem o Audacious e o Remastersys/SystemBack tem o Penguins Eggs.

Mas "C'est la vie", saudosismo de tempos mais simples, hehehe...