SUMMARY Currently there are still setting menus available that cannot be reached from within systemsettings. Two examples are settings for the desktop (wallpaper etc.) and for docks. At least for the desktop I was expecting to find wallpaper settings from within systemsettings. But also for other settings like docks it would be nice to have them available as via systemsettings, although in that case that might require some more discussion and refactoring. I was even expecting to find Info Center there. As I just learned, system information is available from both Info Center and System Settings, which can lead to confusion, especially when trying to access it simultaneously from both (which does not work). I'd propose to merge Info Center with System Settings and introduce a category "Info" for that purpose. This is at least what I am used to from Android and Windows (I think). Since this issue is about different integrations, this can be split later maybe if needed.
Info Center is actually the same app internally as System Settings now. Combining them into one app doesn't make a ton of sense to me though, unless we did something like rename it "Settings and Info". ...Which I guess we could so, and there's a discoverability argument in favor of that: anecdotally a lot of people don't seem to know that Info Center exists and what's in it. Regarding adding Plasma applet/panel/desktop/wallpaper stuff into System Settings is kind of problematic from a UI point of view. Plasma has this concept of "containments", where each screen and activity is a containment. Each containment can have its own wallpaper, widgets, panels, etc. So presenting all of this in System Settings is very difficult to envision.
Got it. Regarding Info Center, I am not entirely sure what would be best. As I stated, other systems tend to combine things it contains with the settings app (Android for example has energy information in the settings app and GNOME has network information there). However, there is stuff available in the Info Center that is currently not (that detailed) in other systems. Examples are the memory information which Windows probably locates in the task manager (there is also a less detailed version available in KSysGuard) or device information which reminds me of the device manager in Windows. Having more detailed information available is probably fine, though. Regarding naming: Note that Windows and Android (and GNOME I guess) just call it Settings. However maybe a more accurate name can help people. I did not really know about containments and also had to look up what activities are. I still don't know exactly, but I guess I got an idea. Two thoughts about it: - Currently it seems that one only can change those stuff when currently using this activity, correct? So one way would be to always display the settings for the currently used activity. - One could even add improvement to only being able to change that while using this activity by offering some kind of selection to which one the settings are going to be applied and maybe also some option to apply that setting to several selected or all ones. However, since I am still talking pretty much in theory without really having ever used them (currently there is also a bug with Wayland), that suggestions might not really fit that concept.
So basically this is a request for two new KCMs: - Wallpaper - Desktop Layout Can you please file two new bug reports, one for each? In general, huge meta bug reports that request many diverse things aren't really actionable. :)
Not only. Actually this report is about more stuff (as written in the description) including the KCMs you mentioned. I can open sub bugs and mark them as blockers of this one. In general I don't think big meta bugs are a problem at all. They can actually be useful, imho to keep track of some larger goal. One just has to create subtasks for needed, actually actionable items. Thus I'd expected a discussion here about how to proceed and then according blocker bugs for this (I also mentioned something like that in this bug's description). Seeing this bug closed before sub tasks are discussed or created and after a not continued discussion is not that encouraging, although I of course understand that time is very limited. My personal standpoint regarding bug triaging is pretty conservative and not that often used on projects. Still I think that there are benefits of not losing track of stuff (closing things because they are upstream is a common example, Ubuntu handles that much better on Launchpad, imho), although it is more time consuming. But that is a bit off topic. I will reopen this for now and create some blocker bugs (note though that those are not entirely covering the scope of this one, yet).
In general we use Phabricator tasks to track "meta work", not Bugzilla tasks. Over time we've found that Bugzilla works best with bug reports are small actionable bugs or features, not huge overarching stuff. What happens is that a fraction of the subtasks get completed, so the meta-bug never gets closed, and as a result, it's just cluttering up the bug list. Cluttered bug lists make it harder for developers to find the real actionable bugzilla tickets. I strongly recommend using Phabricator Tasks to track work that is large in scope and keep Bugzilla for discrete, actionable bugs or features. Please listen to my voice of experience here. :)
Unfortunately currently there are two overlapping systems to track things. Hopefully that will improve with the move to GitLab issues. From my understanding, Phabricator tasks were mostly used for actually worked on things, while feature requests (also large ones) are preferred to be tracked on Bugzilla. In my opinion, the separation between those things is pretty hard and I also don't think that it makes much sense to have this distinction. Personally I don't see big problems with huge meta bugs that probably will be open for a long time. This of course might need proper labeling and filtering when going through bug lists. And the fact that the bug is open indicates that it does indeed still have work to do (and probably still open actionably dependency bugs that are actionable). I guess it is more some kind of psychological thing whether you want to have many open bugs that might be hard to fix (like Ubuntu had with the "Make Linux the no. 1 operating system", which got closed by the way due to the success of Android). > I strongly recommend using Phabricator Tasks to track work that is large in > scope and keep Bugzilla for discrete, actionable bugs or features. Please > listen to my voice of experience here. :) I remember that in the past a Phabricator Task from me got closed because it was not thought for "users"? That is the reason why I report everything that I don't plan to work on but still consider a good improvement to Bugzilla.