Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking issue: High-level modules for KDE applications #398

Open
5 of 17 tasks
SigmaSquadron opened this issue Oct 19, 2024 · 12 comments
Open
5 of 17 tasks

Tracking issue: High-level modules for KDE applications #398

SigmaSquadron opened this issue Oct 19, 2024 · 12 comments

Comments

@SigmaSquadron
Copy link
Contributor

SigmaSquadron commented Oct 19, 2024

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


Development

Graphics

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

Office

System

Utilities

@HeitorAugustoLN
Copy link
Member

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

@HeitorAugustoLN
Copy link
Member

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
Copy link

bew commented Oct 19, 2024

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

@SigmaSquadron
Copy link
Contributor Author

SigmaSquadron commented Oct 19, 2024

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link

bew commented Oct 20, 2024

⚠️ 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
Copy link
Contributor Author

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
Copy link

bew commented Oct 20, 2024

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
Copy link
Contributor

Asqiir commented Oct 23, 2024

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
Copy link
Collaborator

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
Copy link
Contributor Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants