O Kdenlive 24.08 foi lançado, está atualização chega com novos recursos e aprimoramentos em especial para Effects and Transitions. Esta versão aumenta o desempenho na reprodução de sequências e na renderização de visualização da linha do tempo, melhora o tratamento de problemas de transcodificação ao importar grandes quantidades de clipes, adiciona perfis de transcodificação VAAPI e corrige a transcodificação de GPU para Nvidia. 

Acompanhe mais detalhes na página oficial 
https://kdenlive.org/en/2024/09/kdenlive-24-08-0-released/

Após três meses de trabalho, o tutorial de Kirigami da KDE foi portado para o Qt6.

Caso você não saiba o que é o Kirigami:

• O Qt fornece duas tecnologias GUI para criar aplicativos de desktop: o QtWidgets e o QtQuick
• O QtWidgets usa somente C++ enquanto o QtQuick usa QML (e opcionalmente C++ e JavaScript)
• Kirigami é uma biblioteca feita pela KDE que extende o QtQuick fornecendo vários componentes vantajosos e que facilitam a vida

Tecnicamente não houveram muitas mudanças de API no Kirigami. As mudanças principais foram:

• trocar do Kirigami.Overlaysheet pro Kirigami.Dialog
• trocar de actions.{main,left,right} para apenas actions
• trocar do Kirigami.BasicListItem para o Controls.ItemDelegate ou o Kirigami.TitleSubtitle e afins

Todas são APIs fáceis de entender, então desenvolvedores de apps não deverão ter problemas portando para elas. Mesmo que seja o caso, temos uma página da wiki com instruções sobre como portar para Kirigami com Qt6.

O maior desafio na verdade veio de outro lugar: o novo uso de registrar módulos QML de modo declarativo (declarative registration).

O jeito antigo de registrar novos tipos do C++ pro lado do QML involvia um contexto global ou chamadas de API específicas, o que geralmente se traduz em instanciar o objeto no código C++, podendo ser inconveniente. A depender do jeito que você registra e como a API foi chamada, também pode vir a ser necessário implementar uma factory.

O novo jeito envolve criar módulos QML diretamente pelo CMake e adicionar uma ou duas macros na classe que você quer expor, de modo a não precisar instanciar nada do lado do C++. Como bônus, também dá para adicionar recursos QML diretamente pelo CMake ao invés de escrever código XML.

A API usada para o novo jeito de registrar de modo declarativo é o qt_add_qml_module(), mas para nossas coisas da KDE usamos o ecm_add_qml_module(), que remove um monte do boilerplate.

Uma consequência do novo método de registrar módulos QML é que tipicamente espera-se que URIs usem o esquema de DNS reverso, rDNS (por exemplo, org.kde.kirigami.delegates) e também que o resource path se torna longo demais:

<prefixo_do_recurso><URI_de_import><arquivo>

Por exemplo, “qrc:/qt/qml/org/kde/example/SomeModule.qml”.

Isso leva a uma mudança de API: do engine.load(“qrc:/qt/qml/org/kde/example/SomeModule.qml”) para o engine.loadFromModule(“org.kde.example”, “SomeModule”), que é muito mais curto.

O loadFromModule() no entanto requer um módulo QML (evidentemente), que precisa começar com uma letra maiúscula. Isso significa mudar toda instância de main.qml em Main.qml, e em todo lugar no tutorial. É uma tarefa cansativa, um chore task.

Um benefício legal de portar pro Qt6 foi que não é mais necessário especificar versões de import nos arquivos QML. Para usuários da API isso basicamente significa não ligar para o versionamento do app, e para escritores de tutorial isso significa não precisar caçar a versão mínima de import. Mas esta também é uma tarefa abrangente e cansativa.

Eu comecei a portar por este ponto por ser a parte que visualmente melhor indica que o conteúdo é em Qt6.

Melhorias opcionais🔗

Um problema antigo com o tutorial de Kirigami sempre foi as capturas de tela não atualizadas. Especificamente:

• imagens que não refletiam o código
• imagens que tinham ícones de janela X11
• imagens que tinham ícones de janela Wayland
• imagens que simplesmente não tavam bonitas
• imagens mal-posicionadas

Uma vez que o produto só pode ser tão bom quanto sua documentação, em outras palavras, o produto é a documentação, capturas de tela tem suma importância. Se o produto é exposto de maneira não profissional, ele se torna pouco atrativo.

A mudança de API de Overlaysheet para Dialog era uma mudança drástica na interface. Já que eu já precisava atualizar as capturas de tela pro Dialog mesmo, eu podia usar o novo redesign do Dialog do Carl Schwann, que tem aparência ótima.

A mudança de API nas Kirigami actions também levou a mudanças de interface, mas na interface para telefones e tablets. O Plasma Mobile também era pouco representado no tutorial, o que exigia atualizações.

Então eu resolvi atualizar a maioria das capturas de tela, o que levou a algumas outras coisas em seguida:

• fazer as imagens representarem o código de exemplo
• fazer o código de exemplo representar as imagens
• arrumar o espaçamento entre imagens comparativas
• arrumar o posicionamento das imagens
• adicionar um arquivo desktop pros exemplos para que ícones de janela aparecessem no Wayland
• explicar como instalar o aplicativo para que ícones de janela aparecessem no Wayland

As duas primeiras implicavam em mudanças no design do app, usando as mesmas questões que vou falar na próxima seção desta postagem de blog. As duas últimas na verdade foram consequência das minhas atualizações incompletas de anos atrás.

Originalmente, o tutorial de Kirigami tinha vários problemas óbvios como código faltando, poucas imagens, quase nenhum link, nenhuma instrução de compilação ou de como rodar, etc. Quando eu atualizei ele anos atrás, eu não fui até o fim e também não tinha a expertise necessária.

Para que ícones de janela apareçam no Wayland, o aplicativo precisa ser instalado no sistema e fornecer um arquivo desktop. No X11 é possível ignorar o requerimento do arquivo desktop, mas o aplicativo ainda precisa ser instalado. Já que antes eu não sabia como instalar os aplicativos corretamente, eu apenas forneci instruções de como compilar e como consequência não pude fornecer capturas de tela com ícones de janelas. O atual tutorial finalmente tem isso.

Além disso, agora, já que o código está correto e fornece um arquivo desktop e as instruções de instalação certas, qualquer um que venha a testar o tutorial no futuro (eu inclusive) vai achar muito mais fácil de testar. Agora é possível copiar e colar o código diretamente com confiança de o projeto vai estar como deve. Quem teria imaginado que fornecer código reproduzível e instruções ajuda no QA e economiza tempo? /s

No estado atual, a não ser que hajam mudanças drásticas na API ou no tutorial, a maioria das partes em que eu mexi deverão durar pelo menos até o Plasma 7.

Desafios de documentação🔗

Para quem mexe com documentação, atualizar um tutorial de aplicativos desktop não é tarefa pequena ou simples. Tem várias coisas para se ter em mente:

• que design de app devo recomendar para os usuários?
• que design de app é de fato usado pelos desenvolvedores?
• que design de app é esperado de upstream?
• que API merece ser mencionada?
• há palavras chave para o leitor saber o que deve pesquisar para achar mais informações?
• como tornar os exemplos de código mais didáticos?
• como criar exemplos de código que ficam bonitos nas capturas de tela?
• que nível de explicação devo usar?
• o que devo remover?
• quando os exemplos de código devem ser resumidos ou completos?
• foram apresentados todos os conceitos necessários para o leitor terminar o tutorial?
• o que deve ser parte do tutorial e o que deve ser apenas uma nota?
• que práticas de documentação devo seguir ou ignorar?
• devo incluir workarounds para problemas comuns?
• devo incluir menções de possíveis problemas?
• e onde?
• como as capturas de tela devem estar posicionadas na página?
• que seções devo usar para esta página?
• qual ordem lógica deve ser usada para as seções?
• isso está consistente em todas as partes do tutorial que toquei?
• ainda faltam capturas de tela?
• ainda faltam links?
• o que eu devo deixar para fazer depois?

É necessário ter essas questões em mente e tomar decisões a respeito delas para poder lidar com a tarefa. Naturalmente, isso não significa que você deve lidar com todas ao mesmo tempo, apenas que você deve tê-las em mente.

As questões de design de aplicativos foram umas das mais difíceis de tratar, não tanto em relação aos exemplos de código usados, mas mais devido à estrutura de arquivos do projeto, que pode ser extremamente maleável em C++. Mesmo olhando apenas nos projetos da KDE eu encontrei uns 5 tipos diferentes de estrutura de projeto! E na maioria das vezes indo contra recomendações do Qt. Por exemplo, se seguirmos o Qt à letra, eles recomendariam usar uma estrutura de arquivos similar ao URI (como src/org/kde/example/AlgumModulo.qml) enquanto a KDE quase nunca faz isso (src/AlgumModulo.qml or src/qml/AlgumModulo.qml or src/algumsubdir/AlgumModulo.qml).

Decidi ir com uma abordagem híbrida parecida com a solução 2 desta postagem do blog do Qt com o Main.qml na pasta src/ e outros módulos QML numa subpasta (ou em múltiplas subpastas), já que é mais didático e escala melhor.

Outro aspecto para o qual você não deve se render é a desmotivação causada por tarefas cansativas ou entediantes! Pensar no design do aplicativo ou tentar descobrir jeitos didáticos de resolve problemas costuma ser desafiador, interessante ou divertido, mas tarefas entediantes sugam sua alma.

Para mim a parte mais exaustiva foi atualizar as capturas de tela. Eu precisei criar por volta de 200 dessas, seja por conta de erros ou de mudanças de design/didática. Acabei atualizando aproximadamente 51 imagens do tutorial, e isso ainda nem é tudo. Faz sentido, afinal, já que o tutorial do Kirigami tem 30 páginas de conteúdo (e eu mexi em 19 delas).

De maneira geral, lidar com documentação e tutoriais de API requer que o escritor passe por todo esse trabalho para que o leitor não passe por nenhum trabalho a mais e possa focuar só no que é necessário.

Como aprender mais sobre🔗

Para aprender sobre mais questões de documentação como esta e lidar com elas, dois excelentes materiais que eu recomendo que são gratuitos são o Guia de Estilo de Documentação para desenvolvedores da Google (em inglês) e o Curso de Escrita Técnica da Google (em inglês). Não seguimos estritamente essas diretrizes, mas elas são diretas e bons pontos de entrada.

Também temos o Guia de Estilo do KDE Develop (em inglês) que trata de certas coisas que fazemos apenas no KDE Develop. Em particular quero mencionar a seção final: Siga práticas de documentação onde fizer sentido, que lista vários outros recursos para aprender sobre escrita técnica, tendo conteúdos curados especialmente por mim.

A KDE tem uma página da wiki para documentação explicando as diferentes áreas de documentação em que você pode contribuir na KDE, mencionando também as tecnologias que usamos para isso.

Além de coisas de coisas de documentação, temos também uma página com recursos dedicados para aprender desenvolvimento com Qt, incluindo uma lista curada de materiais de estudo.

E eu tenho um repositório pessoal chamado minimal-qml6-examples que está ainda incompleto mas fornece vários exemplos de código em Qt puro explicando o essencial de como registrar módulos QML usando a nova API do CMake.

Exclusivamente para os leitores brasileiros, também tenho um repositório chamado Materiais de aprendizado Qt que explica o básico do que é o Qt e fornece uma quantidade gigantesca de links para você aprender Qt.

E é simples de conseguir isso, na real.

Mas qual o lance disso afinal?

O problema🔗

Já há tempos existe a reclamação de que a pasta ~/.config/ em sistemas Linux pode ficar infestada de arquivos de configuração. Esse é o caso com software da KDE também.

A ideia que proponho é de colocar esses arquivos em subpastas dentro de ~/.config/.

A especificação XDG Base Directory da Freedesktop apenas menciona de modo geral que arquivos de configuração tradicionais precisam ir dentro de XDG_CONFIG_DIRS. É só tacar lá que funciona. Certamente não há nada de errado em simplesmente enchar a pasta ~/.config/ com eles.

Mas a especificação também não é tão específica com isso, ela se preocupa mais com o papel desses arquivos e os caminhos usados para procurar por eles. Contanto que esteja dentro do XDG_CONFIG_DIRS, funciona. Em outras palavras, os aplicativos podem armazenar seus arquivos de configuração de usuário em ~/.config/ e em ~/.config/appdir/.

Isso fica bem claro perto do fim da especificação:

Specifications may reference this specification by specifying the location of a configuration file as $XDG_CONFIG_DIRS/subdir/filename. This implies that:

• Default configuration files should be installed to $sysconfdir/xdg/subdir/filename with $sysconfdir defaulting to /etc.
• A user-specific version of the configuration file may be created in $XDG_CONFIG_HOME/subdir/filename, taking into account the default value for $XDG_CONFIG_HOME if $XDG_CONFIG_HOME is not set.
• Lookups of the configuration file should search for ./subdir/filename relative to all base directories indicated by $XDG_CONFIG_HOME and $XDG_CONFIG_DIRS . If an environment variable is either not set or empty, its default value as defined by this specification should be used instead.

O spec impõe a procura desse tipo de subpasta se existir.

Isso é inclusive o padrão do QSettings do Qt se você definir um nome de organização:

QSettings settings("MySoft", "Star Runner");

em que "MySoft" é o nome da organização e "Star Runner" é o nome do aplicativo, isso resulta no arquivo:

~/.config/MySoft/Star Runner.conf

Então não tem efetivamente uma razão técnica para evitar armazenar arquivos de configuração dentro de ~/.config/subdir/. E mesmo assim guardamos a maioria deles direto em ~/.config/.

O processo de organização🔗

Se você, que nem eu, realmente desgosta de uma pasta ~/.config/ entupida, acho que você vai gostar deste artigo: você pode mudar o status quo. Só acompanhe o texto por enquanto.

Levando as coisas acima em consideração, você precisa cogitar certas coisas:

• Programas podem não ter só um, e sim múltiplos arquivos de configuração

O Kate por exemplo gera até quatro (talvez mais?) arquivos de configuração de usuário: katerc, kateschemarc, katevirc, katemetainfos.

Disso vem a conclusão natural: é só colocar os arquivos em ~/.config/kate/. Todos os quatro arquivos do mesmo app ficam juntos.

Isso funciona bem para quem quer, por exemplo, escolher quais arquivos de configuração vão pro seu backup. Ao trocar de sistema, você pode fazer um backup da pasta do Kate e só.

• Nem todo programa é um aplicativo completo por si só

Alguns programas são componentes essenciais do sistema. O KWIn, KIO, Plasma, KScreen, KRunner, Plasma Addons, Plasma Integration, Plasma Thunderbolt, essas coisas nunca são publicadas separadamente como aplicativos estilo o Kate.

Algumas coisas como o Spectacle, por exemplo, são ambíguas: o Spectacle é um app completo por si só, mas (atualmente) só pode ser usado no Plasma.

Poderíamos então armazenar todos esses arquivos no mesmo grupo, ~/.config/plasma/? Ou manter cada coisa em sua própria pasta ~/.config/appdir/?

• Existem vários grupos de arquivos possíveis

O Plasma por exemplo não é "só" o Plasma, mas também o Plasma Desktop, o Plasma Mobile, o Plasma Bigscreen, o Plasma Nano, etc. Precisaríamos então de algo como ~/.config/plasma-desktop, ~/.config/plasma-mobile/, and por aí vai.

Dentro do ~/.config/plasma-desktop/, por exemplo, se veria arquivos como o plasmashellrc ou o plasma-org.kde.plasma.desktop-appletsrc.

• Todo programa da KDE é feito pela comunidade KDE

...Obviamente. A conclusão natural seria de ter todos os programas da KDE dentro de ~/.config/kde/appdir/, não? Seria tão conveniente para os usuários pode simplesmente copiar a pasta ~/.config/kde/ ao trocar de sistema, certo?

Bem...

• Alguns programas da KDE são agnośticos

Eu acho perfeitamente aceitável que apps completos por si só sejam independentes do sistema ao nível dos arquivos de configuração também. O que quero dizer é que impor ou mesmo sugerir que aplicativos assim que estão sob o nome da KDE armazenem seus arquivos de configuração dentro de ~/.config/kde/appdir/ não daria certo.

Os apps devem ser livres para afirmar sem sombra de dúvidas que eles funcionam em qualquer ambiente e que eles tratam esses ambientes como primeira classe.

Ademais, o ponto anterior só funcionaria se todo programa da KDE ficasse dentro de uma pasta ~/.config/kde/. Afinal, se você tivesse aplicativos individuais com sua própria ~/.config/appdir/, por quê você iria procurar por outros aplicativos inidividuais dentro do ~/.config/kde/? Isso seria inconsistente.

• Alguns programas que parecem ser da KDE podem não ser da KDE

Este é o caso com KCMs.

A ideia dos KCMs é que eles podem ser embutidos dentro das Configurações do Sistema independente de quem os criou. Eles são feitos para serem úteis para terceiros também. Terceiros neste caso significa qualquer um que não esteja usando a infraestrutura da KDE para a distribuição direta de seu software, como distros do Linux, desenvolvedores não afiliados à KDE, empresas fornecendo seus próprios módulos.

Faria sentido então ter ~/.config/kcm/? Ou faria mais sentido que cada KCM tenha seu ~/.config/appdir/? Ou deveríamos então juntar esses arquivos todos dentro de ~/.config/plasma-{desktop,mobile}/appdir/, já que as Configurações do Sistema são tão essenciais para o Plasma?

A proposta🔗

O seguinte são minhas opiniões pessoais sobre o que fazer com arquivos de configuração, baseadas nas questões acima. Embora a seção anterior sirva para reflexão, a proposta em si é bem simples:

• Aplicativos individuais: ~/.config/appdir/
• Programas essenciais: ~/.config/kwin/, ~/.config/kio/, ~/.config/krunner/, ~/.config/spectacle, ~/.config/plasma-desktop/, ~/.config/plasma-mobile/
• KCMs: ~/.config/kcm/ OU ~/.config/systemsettings/

Não creio que seja necessário complicar as coisas com mais que uma subpasta dentro de ~/.config/. Além disso, a especificação do XDG Base Directory só impõe explicitamente a procura de um nível de subpastas dentro do XDG_CONFIG_DIRS.

Que tal deixar aplicativos individuais serem individuais e completos por si só. Apps essenciais que podem ser considerados individuais e completos por si só podem ser simplesmente isso mesmo.

Requisitos essenciais para produtos do Plasma podem ser postos num só lugar.

Considere talvez unir os KCMs em uma pasta separada sem relação direta com o Plasma para encorajar desenvolvedores terceiros.

A implementação🔗

A razão de eu ter escrito este artigo agora e não antes é porque agora entendo bem como implementar isso.

Na verdade é bem simples. O arquivo de configuração padrão para a KDE segue o formato INI. Por exemplo, tendo um arquivo myappconfigrc:

[Nome do Grupo]
Entrada1=Valor1
Entrada2=Valor2

[Outro Grupo]
RodouUmaVez=true
cor=#ffffff

Para gerenciar esses arquivos de configuração, a KDE usa a biblioteca KConfig. Ela precisa de quatro passos básicos:

1. Criar um objeto que representa um arquivo de configuração
2. Criar um objeto que representa um grupo num arquivo de configuração
3. Ler/escrever para o objeto representando o grupo
4. Se tiver escrito algo no objeto representando o grupo, sincronizar as mudanças para o disco

Se você souber um mínimo de C++, você vai entender rápido. Vamos falar só do passo 1, por enquanto.

Vamos dar uma olhada na assinatura da função do KConfig que nos interessa, um dos construtores:

KConfig (const QString &file=QString(), OpenFlags mode=FullConfig, QStandardPaths::StandardLocation type=QStandardPaths::GenericConfigLocation)

O primeiro parâmetro é file, ou arquivo, bastante auto-explicativo, é o arquivo de configuração que queremos mexer.

O segundo parâmetro é mode, o modo como o arquivo de confiração será gerenciado. Na maioria das vezes, o modo vai ser KConfig::SimpleConfig (apenas um arquivo) ou KConfig::FullConfig (todos os arquivos de config relevantes). Se um código de verdade que você encontrar tiver algo diferente, não mude.

O terceiro parâmetro é o que mais nos interessa, type, ou tipo, isto é, que tipo de arquivo é e onde ele deve ser salvo. Por padrão é QStandardPaths::GenericConfigLocation, correspondendo a ~/.config/.

Vamos checar um exemplo prático rapidamente.

KConfig configurationFile("myappconfigrc", KConfig::SimpleConfig, QStandardPaths::AppConfigLocation);

O arquivo é myappconfigrc.

SimpleConfig foi escolhido aqui por razões didáticas.

A parte interessante é o AppConfigLocation. Ele corresponde a ~/.config/appname/.

Ao simplesmente mudar o padrão de GenericConfigLocation, isto é, ~/.config/, para AppConfigLocation, isto é, ~/.config/appname/, já terminamos a implementação.

Sim, você leu certo. É uma mudança de uma linha só.

Você talvez se depare com o KSharedConfig ao invés do KConfig. Sua assinatura de função relevante é:

KSharedConfigPtr KSharedConfig::openConfig (const QString &  fileName = QString(), OpenFlags  mode = FullConfig, QStandardPaths::StandardLocation  type = QStandardPaths::GenericConfigLocation)

fileName, aí mode, aí type com padrão em ~/.config/, mesma coisa que o KConfig.

Num código de verdade, você poderia ver algo similar a:

KSharedConfigPtr configurationFile = KSharedConfig::openConfig("myappconfigrc", KConfig::SimpleConfig, QStandardPaths::AppConfigLocation);

Bem simples. É quase a mesma coisa, você simplesmente atribui o resultado de openConfig() a um simples ponteiro.

O KSharedConfig é preferível ao KConfig no geral, na verdade. Então você provavelmente vai encontrar o KSharedConfig mais comumente em código de verdade.

Alguns outros exemplos de código de verdade que você pode encontrar seriam similares a:

KSharedConfigPtr configurationFile = KSharedConfig::openConfig("myappconfigrc", KConfig::SimpleConfig);
KSharedConfigPtr configurationFile = KSharedConfig::openConfig("myappconfigrc");
KSharedConfigPtr configurationFile = KSharedConfig::openConfig();

No primeiro caso, o último parâmetro, type, não existe, então seu padrão (o que vem após o = na assinatura da função) é o GenericConfigLocation.

No segundo caso, o parâmetro mode está faltando também, então o padrão é FullConfig e GenericConfigLocation.

No terceiro caso não há nenhum parâmetro, nem mesmo fileName, então o padrão se torna appname, FullConfig e GenericConfigLocation. appname, no caso, é o nome do aplicativo como foi definido com QCoreApplication ou KAboutData.

Você agora está preparado para alterar o código da KDE e solicitar que seu aplicativo favorito comece a usar ~/.config/appdir/! Vai lá! \òwó/

Bem, pelo menos para aplicativos que usem ~/.config/appdir/. Usar nomes de pastas específicas fica para outro dia. Mas já faz diferença.

Só para satisfazer a curiosidade, vamos dar uma olhada nos passos 2, 3 e 4, usando como base o arquivo de configuração INI mencionado alguns parágrafos atrás, e usando o KSharedConfig ao invés do KConfig. Só para relembrar, o arquivo INI é assim:

[Nome do Grupo]
Entrada1=Valor1
Entrada2=Valor2

[Outro Grupo]
RodouUmaVez=true
cor=#ffffff

Começamos com o passo 2:

KConfigGroup configurationGroup = configurationFile->group("Outro Grupo");

Literalmente não poderia ser mais simples. Você captura um grupo chamado "Outro Grupo" do arquivo de configuração e atribui ele a um objeto KConfigGroup.

QString cor = configurationGroup.readEntry("cor", QString());

Então lemos uma entrada que fica dentro do grupo "Outro Grupo", neste caso "cor". Se ele estivesse vazio, ele retornaria apenas um QString(), uma string vazia; daria para usar QColor no lugar de QString também se quisesse.

De todo modo, a entrada não está vazia, então o código retorna "#ffffff".

configurationGroup.writeEntry("RodouUmaVez", false);

Bem simples: escrevemos o valor false na entrada "RodouUmaVez". Embora tenhamos escrito para o objeto de configuração, ainda precisamos escrever para o arquivo de configuração, então nos falta o último passo:

configurationGroup.sync();

E pá, salvo.

Outra possível ocorrência que você pode encontrar em código real pode ser:

KSharedConfig::openConfig()->sync();

Que faz literalmente a mesma coisa.

E é isso. Você agora sabe o básico de como gerenciar arquivos de configuração com o KConfig. Bem simples, não? Eu adoro o quão fácil ele é de usar, só precisava de mais documentação, que está sendo feita.

Os recursos🔗

Ficou interessado e quer ver mais sobre? Estou trabalhando com a documentação da API do KConfig para deixar bastante fácil de ler e usar, fique no aguarde. Você pode clicar em Class List ou Alphabetical List para ver as classes e funções disponíveis.

Enquanto as melhorias não saem, a Introdução ao KConfig serve bem. É em inglês. Ela menciona mais ou menos o mesmo do que eu disse aqui.

Também vale a pena dar uma olhada na documentação de API do QSettings e do QStandardPaths.

Eu nem cheguei a falar sobre o KConfigXT porque, bem, ainda não estudei ele a fundo. Você só precisa saber que para ver mais você vai precisar procurar por arquivos .kcfg e .kcfgc. Não sou tão fã do uso de XML, mas o negócio tem de fato uma API super conveniente.