- Foi confirmado oficialmente o desenvolvimento do Karton, um gerenciador de máquinas virtuais dedicado ao KDE Plasma
- O projeto é feito com base em Qt Quick e Kirigami, sendo otimizado para o ambiente KDE
- Usando a API libvirt, o objetivo é controlar várias máquinas virtuais e, no futuro, oferecer suporte multiplataforma
- Os principais recursos incluem visualizador SPICE personalizado, snapshots, interface intuitiva e suporte à alternância de hipervisor entre sistema/usuário
- A conclusão está prevista para por volta de setembro de 2025, seguindo o cronograma do Google Summer of Code 2025
Contexto e necessidade do desenvolvimento do Karton
- No ambiente GNOME, existem ferramentas fáceis e consistentes para executar máquinas virtuais, como o GNOME Boxes
- Usuários de KDE usavam alternativas como o antigo qt-virt-manager, mas enfrentavam interrupção no desenvolvimento e o problema de falta de identidade própria do KDE
- Cresceu a necessidade de uma solução de gerenciamento de VMs naturalmente integrada ao ambiente KDE Plasma moderno
Visão geral do projeto Karton
- O Karton começou como uma tentativa de criar um frontend para QEMU e foi levado adiante como projeto do Google Summer of Code pelo desenvolvedor do KDE Harald Sitter
- Derek Lin, da University of Waterloo, está atualmente desenvolvendo o projeto ativamente como participante do Google Summer of Code 2025
- O objetivo do Karton é oferecer uma ferramenta nativa de gerenciamento de máquinas virtuais adequada ao ecossistema KDE
Principais tecnologias e características
- O Karton é desenvolvido com Qt Quick e Kirigami, buscando integração visual e de usabilidade completa com o KDE Plasma
- Por meio da API libvirt, ele oferece gerenciamento de máquinas virtuais e extensibilidade, também considerando suporte multiplataforma no futuro
- Em vez de chamar diretamente a CLI virt-install, a implementação atual usa libosinfo para reconhecimento automático de imagens de sistema operacional e geração automática de XML do libvirt
- A expansão para configuração de dispositivos e suporte a diversos hipervisores também faz parte das tarefas de desenvolvimento
Principais recursos e cronograma-alvo
Os recursos descritos por Lin na proposta do Google Summer of Code são os seguintes
- Instalação e configuração de máquinas virtuais por meio do formato XML do libvirt
- Desenvolvimento de um visualizador SPICE personalizado baseado em Qt Quick (substituindo o virt-viewer)
- Recurso de snapshots de máquinas virtuais (backup/restauração)
- GUI intuitiva e elegante com pré-visualizações, com incorporação de feedback da comunidade
- Referência de design no layout de lista do UTM para MacOS
- Oferta de interface amigável para dispositivos móveis
- Atualizações de estado em tempo real processadas com eficiência pela função
virEventRegisterImpl - Recurso de navegação que fornece uma lista dos principais sistemas operacionais
- Gráficos de uso de GPU/memória (no estilo do virt-manager)
- Função para alternar entre os modos de sessão (usuário) e sistema (root) do hipervisor QEMU
Cronograma de desenvolvimento
- A data oficial de início da codificação do Google Summer of Code 2025 é 2 de junho de 2025
- Está planejado que o protótipo para a avaliação intermediária seja concluído em 14 de julho e que o prazo final de envio da versão completa seja 1º de setembro
Conclusão
- O Karton é um novo projeto que pode resolver a antiga ausência de uma ferramenta nativa de gerenciamento de máquinas virtuais otimizada para o ambiente KDE
- Ao mesmo tempo, ele oferece visibilidade e usabilidade alinhadas às tecnologias modernas do Qt e do KDE, representando uma mudança significativa tanto para usuários quanto para desenvolvedores de desktops Linux
1 comentários
Comentários no Hacker News
Acho que o KDE deveria focar em funções básicas como organização de janelas, renderização de janelas e ícones do lançador de aplicativos. Se eu precisar de máquina virtual, uso um software de VM separado. A suíte integrada do KDE tem alguns bons programas, mas não vejo necessidade de integrá-los ao ambiente de desktop. Um gerenciador de arquivos, um VTE e um editor de texto já bastam. Seria bom gerenciar os ícones separadamente em cada aplicativo. As tentativas de unificar ícones só acabam causando problemas, como ícones que não aparecem ou ícones pretos sobre fundo preto
Parece haver uma confusão entre o projeto KDE e o Plasma. O Plasma é o ambiente de desktop, enquanto o projeto KDE desenvolve e distribui vários aplicativos. Muitos apps do KDE funcionam em outros sistemas operacionais, como o Windows, e é possível usar apenas o Plasma sem instalar outros apps do KDE. Historicamente, o ambiente de desktop era chamado de KDE, mas hoje ele é apenas um entre vários softwares desenvolvidos pelo projeto KDE. Também não concordo com temas de ícones, e eu mesmo não uso tema de ícones
O KDE vem desenvolvendo várias ferramentas há mais de 20 anos: navegador, cliente de e-mail, app de gerenciamento de contatos etc. Já no KDE 1 existia explorador de arquivos, e uma suíte de escritório já estava em desenvolvimento. A suíte do KDE existe desde o começo. O Plasma é só uma parte muito pequena do que o KDE produz. Se a pessoa quer apenas o papel de gerenciador de janelas, há alternativas mais minimalistas como LXDE, Hyprland, Sway e i3
A tentativa de transformar ícones em um recurso compartilhado e integrado aos aplicativos sempre falha. A comunidade do GNOME acertou nisso. Veja https://stopthemingmy.app/. O suporte à consistência visual entre aplicativos sempre foi uma fantasia dos anos 90 e, na prática, só ficava bonito em screenshots
Foi por isso que migrei para o sway. A integração entre partes do sistema é necessária, mas cada parte deveria ser separada. GNOME e KDE só funcionam bem quando você usa tudo deles. O XFCE é muito mais modular
É um pouco decepcionante que a maioria dos comentários esteja falando de outra coisa em vez da notícia em si. Estou animado com o lançamento de um novo gerenciador de VM. Uso principalmente o virt-manager, mas ele quase não recebe manutenção e tem problemas sérios de escala em telas HiDPI. O GNOME Boxes tem muitos bugs e poucos recursos. Parece que só dão atenção ao CLI
virsh, então hoje em dia não existe uma GUI de VM realmente boaUso KDE Plasma no Arch e gosto muito desse ambiente. Ele até tem filtro de luz azul embutido. Não penso em voltar para o Windows. O KDE é mais rápido, mais bonito e não tem anúncios nem rastreamento indesejado. É o melhor para uso diário
Estou testando Cachy e Plasma dentro de uma VM e pretendo instalar essa combinação direto no próximo PC. Hoje uso dual boot com Ubuntu e Windows, mas faz mais de 6 meses que não entro no Windows. Provavelmente no próximo PC nem vou instalar dual boot
Usei gnome por um ano e depois voltei para o plasma. O gnome é desconfortável demais. Eu me virava com extensões como remendo temporário, mas elas quebram assim que atualiza. Configurar a interface em inglês com unidades ISO também é complicado. Para gerenciar programas de inicialização, precisa instalar outro app. Escalonamento de tela, múltiplos monitores e gravação de tela são todos ruins. Meu monitor é 60 fps e mesmo assim o ponteiro do mouse trava. Esconder os teclados sueco, sami e svdvorak também não ajuda muito. Copiar e colar não funciona entre monitores. Se troco de janela com alt+tab, o arrastar e soltar para de funcionar. Quando abre um menu de contexto, o foco inteiro fica travado; se a caixa de diálogo de cópia de arquivos do Nautilus estiver aberta, não dá para clicar em outro app. Depois que por engano testei o KDE numa VM, percebi que não havia motivo para continuar suportando o desconforto do gnome. Naquele mesmo dia voltei para o openSUSE
Usei KDE 1.0 pela primeira vez há mais de 20 anos. Na época parecia um pouco uma tentativa de imitar o Windows, mas lembro que o nível de acabamento era até melhor
Uso Ubuntu + Plasma como ambiente principal há 3 anos. Acho que é aquilo que o Windows 7 sonhava ser. Como engenheiro de
dotnete DevOps, os anos 2020 alinharam perfeitamente a qualidade do toolchain Linux com a maturidade do open source.Rider,datagrip,vscodee tudo o mais funcionam muito bem. Não há a complicação dedockerouwsl. Só inicializo o Windows para rodar versões antigas do .NET Framework, e a qualquer momento posso configurar boot do Windows NVMe dentro de uma VM e praticamente abandonar de vezO que o KDE precisa não são novos recursos, e sim menos bugs
Eu também sempre reclamei dos bugs do KDE, mas desde a versão 6.3 não encontro nenhum bug sério pela primeira vez em 10 anos. Se você ficou um tempo sem usar, vale a pena testar de novo agora
Penso de forma parecida. Tentei várias vezes, mas o KDE sempre me pareceu inferior ao gnome em estabilidade e acabamento. Provavelmente isso se deve ao alto grau de customização do KDE. Gosto do conceito, mas não deve ser fácil de manter, e parece que os desenvolvedores se sentem mais atraídos por adicionar novos recursos do que por corrigir bugs
Gostaria que o KDE oferecesse uma solução integrada de VM. Seria ótimo se aplicativos rodando dentro da VM pudessem aparecer como janelas do Kwin. Isso talvez exigisse um daemon auxiliar no sistema convidado. Já existiram coisas parecidas antes, mas seria fantástico se um DE principal oferecesse isso oficialmente
Surpreendentemente, o Windows oferece isso via WSL2. Uma vez rodei
nautiluspor brincadeira e fiquei impressionadoEstou montando uma experiência quase igual com o VirtualBox. Rodo várias VMs no notebook e, quando conecto um monitor externo, posso ajustar o tamanho das janelas livremente. Quando desconecto o monitor, as janelas encolhem de novo automaticamente. Com compartilhamento de área de transferência e afins, a experiência fica quase nativa. Mantenho VMs separadas por finalidade: uma para navegador diário, outra para projetos contratados etc. Uso desktops virtuais no host e um único desktop dentro da VM. Configurei o alt+tab para funcionar só dentro da VM. Estou arcando com os bugs aleatórios do VirtualBox e o risco jurídico da Oracle, mas infelizmente continuo preso ao VirtualBox porque QEMU e KVM ainda parecem menos polidos
Tecnicamente isso exige bastante gambiarra. Em sistemas operacionais fechados é difícil, e no Windows isso só é suportado por RDP
Também dá para tentar uma abordagem mais leve e com menor consumo de recursos usando
debboostrape montagem comchrootEntre as soluções atuais, nenhuma dá suporte perfeito a isso. Dá para fazer encaminhamento X11, mas exige configuração e não é suave. Ainda não encontrei um cliente/servidor que ofereça isso nativamente no Linux
Fico muito feliz por poder escolher uma alternativa ao virt-manager. Gosto especialmente do fato de ser baseado em Qt. Acho uma pena usar Kirigami e Qt Quick. Tenho a impressão de que tanto a aparência quanto as funcionalidades ficam piores do que numa base com Qt Widgets
Também acho que é preciso uma alternativa ao virt-manager. É desconfortável até para coisas comuns como buscar texto no XML ou usar undo. Colocar KDE no nome parece meio antiquado, mas acho Karton um nome bem melhor
O próprio Plasma shell é baseado em Kirigami e Qt Quick, então não existe ambiente mais integrado e consistente do que esse
A lentidão característica da renderização em QML só dá para evitar com licença comercial do Qt. Em compensação, há a vantagem de poder criar apps com uma sintaxe parecida com JSON
O Qt Quick é mais genérico, e o Kirigami é uma camada mais especializada construída por cima dele
Gosto do acabamento e da riqueza do KDE, mas o design me parece ultrapassado em comparação com outros SOs ou DMs atuais. Dá para customizar, mas quanto mais se mexe, mais o sistema fica lento e estranho. Por isso escolho o gnome
Acho curioso que tanta gente pense exatamente o contrário. Para mim, o KDE é o único ambiente realmente moderno e bonito
Fico me perguntando se você já testou o Plasma 6. Pessoalmente, acho muito mais moderno que o gnome
Acho o design do KDE muito superior ao do Windows. Tenho a sensação de que o Windows sempre consegue renovar o posto de pior design de desktop
Se ao menos adicionarem um menu hambúrguer, volto para o KDE na hora. Acabei de verificar e o KDE também entrou nessa tendência, mas felizmente dá para desativar nas opções
Fico em dúvida se realmente precisamos de outra GUI para kvm/qemu. Acho que o cockpit-project já atende bem a esse objetivo
O virt-manager sempre foi suficientemente satisfatório para mim, então não sei se realmente faltava uma nova alternativa. Ainda assim, concorrência é sempre bem-vinda
Interfaces web servem para usuários avançados, mas para usuários comuns são difíceis. O próprio conceito de VM já é complicado, e uma UI familiar como VirtualBox ou VMWare aumenta muito mais a acessibilidade
Uso virt-manager há muito tempo, então estou bem animado com uma solução nativa do KDE. Também estou esperando suporte do virt-manager para renderização Vulkan (
libvirt). A UI baseada em Kirigami parece apertada por causa das margens excessivas. Tive sensação parecida na UI Kirigami doprint-managerAntigamente o aqemu era meu frontend favorito. É uma pena que esteja sem manutenção há mais de 10 anos