-
Notifications
You must be signed in to change notification settings - Fork 76
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
Comments
I think this list is too extensive, we should only support some applications, that come default with plasma, and some other popular applications |
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. |
Yes, keep in mind that this is plasma-manager, not kde-manager |
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. |
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. |
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. |
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 🤔 |
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. |
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). 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.. |
I might chime in: |
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. |
List has been trimmed again. The bare essentials should be actionable. |
We're currently missing a lot of apps. Let's organise the imporant ones in a single tracking issue.
Development
Graphics
Internet
Multimedia
Office
System
Utilities
The text was updated successfully, but these errors were encountered: