Tracking issue: High-level modules for KDE applications

[SigmaSquadron]

We're currently missing a lot of apps. Let's organise the imporant ones in a single tracking issue.

---

Development

• Kate add indentation options to kate #88

Graphics

• Okular Add module for Okular #244

Internet

• KDE PIM akonadi pim #111
• KDE Connect Options: Per-device databases for custom commands, as well as the hostname.
• NeoChat Note: Matrix clients are notoriously difficult to configure, as they're extremely stateful.

Multimedia

• Elisa feat(elisa): init Elisa module #391

Office

• Calligra - Note: I'm the Calligra maintainer on Nixpkgs; I may be able to help with this.
• Ghostwriter Add module for Ghostwriter #342
• Marknote
• Merkuro Note: This requires the KDE PIM module.

System

• Dolphin Note: Dolphin is obviously a large application.
• Konsole Add module to manage konsole and it's profiles #69
• KWalletManager Note: KWallet is pretty nonsensical at times so making a working module for this may be difficult.
• Plasma System Monitor Options: Many free-form options for configuring each system monitor panel.

Utilities

• Ark Note: Quite a large application.
• Kleopatra Options: Various local and external OpenPGP/Cert options.
• Spectacle spectacle: add shortcuts #27

[HeitorAugustoLN]

I think this list is too extensive, we should only support some applications, that come default with plasma, and some other popular applications

[HeitorAugustoLN]

Also, many of these applications are so simple that they don't even have configuration. So they don't need a module, such as kcolorchooser.

[bew]

Yes, keep in mind that this is plasma-manager, not kde-manager

[SigmaSquadron]

Yes, I started with an exhaustive list that can be reduced afterwards. Check the updated list, and see if I've deleted anything essential, or if more should be deleted.

[SigmaSquadron]

There are quite a few duplicates as well. Ghostwriter, Marknote and KleverNotes all do the same thing, but Marknote seems the newest of the three.

[SigmaSquadron]

We're down to 48 apps. There are a few more I think could be removed, but we'd be removing unique and/or popular apps.

[bew]

⚠️ Also I think we need to be careful about the maintanability of this repo, because as we add support for more apps, support issues can rise as programs are updated, adding/removing options, or changing how the config is done (without necessarily telling you about it since usually these programs expect to be configured manually..)..

I'm not saying this is the way to go, but maybe we could split some(all?) non-builtin-to-Plasma apps to a separate repo 🤔

[SigmaSquadron]

Well, the same could be said for Nixpkgs, and yet people write modules anyway. This issue is supposed to be completed in the long term; I'm not proposing that the current contributor team be responsible for every single KDE application.

[bew]

Well, the same could be said for Nixpkgs, and yet people write modules anyway.

True, and modules should actually now use settings-options instead of having a explicit options for everything (mentioning difficulty to write, review, maintain, work with such full modules).
See https://github.com/NixOS/rfcs/blob/master/rfcs/0042-config-option.md

I personally always consider how likely to change are the configs of a tool before using their modules, and sometimes just don't for things that are not really supposted to be declaratively configured / with 'volatile' config files..

[Asqiir]

I might chime in:
How about making 2 different repos, where one is plasma-manager (meant to manager the plasma desktop) and the other one is konfigurator (meant to manage config files that don't work well as symlinks, such as (famously) the config files by kde programs).

[magnouvean]

I do agree in general think that if we were to actually support this many apps that we would have maintainability difficulties, but we'd probably just have to rely on PRs. Having this in a separate repo could make sense, but I also think some of this could be in home-manager as well (at least kdenlive and krita and whatnot). I'm not sure the stance they take on non-symlink config-files though.

Splitting it into another repo would also not immediately help maintainability as I see it. There's also the fact that kde plasma also needs to manage files that don't work well as symlinks. I think having options for some core applications makes sense, but perhaps not all of them. The ones in bold above I think at the very least makes sense to have in this project.

[SigmaSquadron]

List has been trimmed again. The bare essentials should be actionable.

[HeitorAugustoLN]

This list looks really good now. I also think we probably should maintain these configurations in this repo, and not a separate one, since we already have some apps here, and we already have the scripts to write kde configurations. But if we are going to add more applications here. Each application should have your own maintainer, or cover only main options, or both. But we can think of it later.

[SigmaSquadron]

Each application should have your own maintainer

I'd recommend something simple like what treefmt-nix does.
It's just a string with your GitHub username.

{
  meta.maintainers = [ "SigmaSquadron" ];
}

Possible concerns:

• Usernames can change.
• Contributors are required to have a GitHub account.

[dweee]

Contributors are required to have a GitHub account.

I feel it would probably be best doing something along the lines would make more sense

{
  meta.maintainers =  ["github:dweee" "mailto:[email protected]" "pgp:FFFFFFFF" ];
}

Usernames can change.

Maybe a comment at the end of the string with a reference to the ID returned by the GitHub API?