Skip to content

RFC: QML-based Overview Settings menu

Proposing a new QML Settings overlay for the Overview+Grid effect, inspired by the Tiles Editor's interface.

I am a heavy user and fan of the combined Overview feature (previously Present Windows+Grid), and have been more and more involved with changes to this system, so I wish to assist with porting the user options in a fresh, future-proofed manner that everyone can adapt to.

This concept adds a small QML button to the top-right of the Overview Effect to invoke a QML drawer. This drawer presents a list of contextual Overview options that change based on the view. The results can be observed in real-time in the activated effect, to demonstrate the differences in option values to the end user.

Video example. Many of the options showcased are older features I am currently working on restoring:

2024-12-12_19-54-06_t

While this example illustrates the panel's usefulness and is functional in a dev session, this feature still needs much work. Without the following parts, it is not ready to ship. Design-related points will require discussion with VDG team:

  • Core

    • QML proofreading
      • Almost ready to submit a branch
      • No errors are produced in console, but there is a QTQuick Spinbox implicitWidth loop warning which also occurs in Tiles Editor
        • I want to try and resolve this in both effects.
    • Writing settings to disk
      • KCM binding, Dbus, or Kwriteconfig? Need to look for another QML example in codebase.
    • Highlight non-default settings
      • This is seemingly possible with KCM.SettingHighlighter in QML, but does add KCM context back into play (it's declared in other places as well, the API is likely not going anywhere).

  • Placement and invocation

    • Indicator? Hotkey? Hide after a dismissable tip on first use? Should the menu change cue based on effect state?
      • Graphical indicators/arrows/cues could help here. Repeated animations/indicators would get annoying for heavy users
    • The QTQuick Drawer type allows swipe interaction. Useful, but may not be best if invoked via button.
    • Should the menu drop vertically or horizontally? Fade in and out during movement? On that note:

  • Animations

    • Every interaction should be smooth with slides/fades and easing, no popping or abrupt transitions.
    • Several effects do not animate/refresh when their settings are changed, evident in the video.
      • Layout mode DOES do this properly. Just need to apply that logic elsewhere.
    • Each effect will need suitably uniform transition timing and easing.

I doubt I can fix all of these before the 6.3 freeze for new UI features, but I'll try.

Background and reasoning:

There's been a drive to move away from modules in System Settings, and to streamline customization into effects themselves: this is a great idea yes! During this process of refinement though, there has been a trend towards dummying out or removing customization, even if these options and features are not broken.

Offering effect tweaks is something KDE has been (traditionally) all about, and with Overview being the result of several features merged together, you have to evaluate every case those previous features provided on their own.

Stability does not come at the cost of user customization here, and i'll stake that. This would include crashes, window misbehavior, console output errors, etc. I'd like to know how choice of visual styling is detrimental to an Overview user's experience, versus any other part of Plasma that offers customization. The Overview is too useful to let user customization slip away at a whim.

I really and truly think this is a great idea if properly polished to have no animation glitches, and it will help the System Settings KCM to be properly deprecated and cleared out in due time. Let's talk about it!

Edited by Blazer Silving