2

The Problem:
KDE has lots of great widgets, but there's several which are potentially becoming redundant, and having sets of widgets with identical functionality (but using, essentially, different "hardcoded configurations") increases the maintenance, codebase, and perceived bloat.

Currently when adding new plasmoids, you add them to desktops/panels with whatever default options they are configured with. After examining some of the work done in the VDG in designing new layouts, it's become obvious we can remove several separate widgets, instead presenting fewer "core" widgets which can be configured to do the same thing as their smaller counterparts.

For Example:
There's a widget called the "System Monitor" which dispays swap, RAM, and CPU usage; there's also two additional widgets which individually monitor RAM and CPU. One of the things brought up in the discussion is having the sensors displayed by the monitor widget be configurable. So, in practise, the unified System Monitor could play triple duty; it could be configured to display several individual monitors, obsoleting the individual widgets, lightening the codebase; we would also get a Swap plasmoid for free.

But the catch to this is, if we eventually depreciate single-serving plasmoids in favour of more configurable plasmoids - it adds complexity for the users (because they must now configure more plasmoids to get the same effect), it takes away from the perceived features of KDE ("half the widgets are gone!"), and the defaults on the more complex widgets are less likely to serve the users migrating from smaller plasmoids.

The solution
Adding "Configuration Profiles" to widgets. Each widget could optionally bundle a set of alternate configurations ("profiles"). When browsing widgets to add to the desktop, each profile a widget offers would be presented as a separate widget. Each profile would contain icons, names, descriptions, and functionalities offered by that profile, along with the configuration settings to override against the defaults of that widget.

The profile files would be small QML files, and could contain some basic scripts piggybacking off the plasma API to provide dynamic configuration; this could be used to do things like check the computers' location to pre-select a weather location, or a locale check to pre-select language settings for a translation plasmoid.

For the most part, profiles would be invisible to the user. When they add a widget, the profile config would simply be applied over the widgets default settings, then the widget would be treated as normal once the config is applied.

The System Monitor Example (revisited)
Back to the System Monitor, the monitor would have it's "default" profile (displaying swap/RAM/CPU) and three "alternate" profiles: CPU, Swap, and RAM, appearing as 4 separate widgets, "System Monitor", "Swap Monitor", "CPU Monitor", and "RAM Monitor".

Benefits to Existing Upcoming Features
One of the new features landing (landed?) in Plasma 2 is the ability to switch between widgets with similar functionality. With many widgets, we increase the number of extra potential groupings (meaning less results per group), devaluing the feature. But taking better advantage of existing and configurable plasmoids, we reduce the number of widgets overall, allowing more overlap and better use of the feature. In addition, if the profiles is built-in deeply and transparently enough, we could see alternate configurations presented in the widget switcher; if the user opts to go with the same widget, they could potentially keep user-defined configuration.

I in general like this idea very much.

The only issue that I see is, how does this complicate if e.g. I want one of the System Monitor widgets to display just basic agregate data in a panel and different widgets to display the more detailed data in my e.g. “Hacking” Activity.

If this problem is solved/omitted, I 100% agree with this improvement

hook wrote:I in general like this idea very much.

The only issue that I see is, how does this complicate if e.g. I want one of the System Monitor widgets to display just basic agregate data in a panel and different widgets to display the more detailed data in my e.g. “Hacking” Activity.

If this problem is solved/omitted, I 100% agree with this improvement

It wouldn't pose any problem, actually; the configuration profiles would be more like presets - there would be nothing stopping you from laying down multiple widgets and changing their configurations or selecting different profiles. Profiles are essentially just groups of useful presets meant to cut down the time needed to configure a complex widget - or expose an alternate use-case for existing widgets. They're save-states you can load on-demand.

For example, with the system monitor you could place a CPU profile-configured widget in a panel, and a multi-monitor version on the desktop. Since it's just per-widget configuration, they wouldn't clash. The config profiles only affect the widget at the time of creation (applying the presets) or if you "factory reset" a widget to a different profile. Once the widgets are down the profiles don't change anything about the existing behaviour. Any activity-related issues would be unchanged.

Kver wrote:It wouldn't pose any problem, actually; the configuration profiles would be more like presets - there would be nothing stopping you from laying down multiple widgets and changing their configurations or selecting different profiles. Profiles are essentially just groups of useful presets meant to cut down the time needed to configure a complex widget - or expose an alternate use-case for existing widgets. They're save-states you can load on-demand.

Cool, I’m all for it then