Refine how global edit mode relates to panel edit mode and the previous widget locking feature
Open, NormalPublic

Description

In Plasma 5.18, we introduced a new "Global Edit Mode" feature designed to replace the old widget locking feature. We didn't actually remove the feature, but we removed the UI for it. This means that users now have unlocked widgets now.

Though overall the feature has been well received, we've had a few concerns, and there are some remaining issues:

  • It turned out that at least one organization was using the widget locking feature to protect users' default panel settings from accidental damage; see https://bugs.kde.org/show_bug.cgi?id=417424#c21
  • Based on bug reports as well as recent personal testing, the Quick Launcher widget appears to only be usable when widgets are locked and suffers from various bugs when widgets are unlocked; see https://bugs.kde.org/show_bug.cgi?id=419855 and https://bugs.kde.org/show_bug.cgi?id=384009 in particular
  • There are various concerns with panel editability having poor usability or being too dangerous for regular users. See https://bugs.kde.org/show_bug.cgi?id=419853
  • Entering global edit mode shows the toolbox and makes desktop widgets immediately editable, but not the panel; you need to separately enter panel edit mode, which is a separate thing independent from the global edit mode
  • Having features with no UI leads to bit-rot; ideally these features should either be removed entirely or have a UI (whichever is appropriate)

Based on discussions had in the above bug reports, I'd like to propose the following:

  • Improve panel edit mode usability by fixing https://bugs.kde.org/show_bug.cgi?id=419853 and investigating further UX improvements
  • Fix the outstanding bugs in the Quick Launch widget that make it problematic to use when widgets are unlocked
  • Roll Panel edit mode into global edit mode such that triggering one automatically triggers the other too, and remove the distinction between them in the UI

Optional:

  • To not let the widget locking feature bit-rot, lock widgets when not in global edit mode, and unlock widgets when entering global edit mode, or else expose a UI for it in some deep-hidden place

Thoughts?

ngraham created this task.Apr 9 2020, 5:49 PM
ngraham triaged this task as Normal priority.
davidre added a subscriber: davidre.Apr 9 2020, 6:11 PM

To not let the widget locking feature bit-rot, lock widgets when not in global edit mode, and unlock widgets when entering global edit mode, or else expose a UI for it in some deep-hidden place

What's the differenc to now? There's no user visible difference just an implementation detail

Small idea for how I think implementing panel customisation in standard Global Edit Mode could go:

  • Keep it as it is, but...
  • No matter if Panel's Edit Mode popup is visible or not still have the whole panel Plasmoids movement addition that currently entering Panel Edit Mode gives you be accessible by simply editing Global Edit Mode and then only cease once Global Edit Mode is exited, rather than relying on the visibility of the Panel Edit Mode popup to do so (in other words make the state of the panel when the Panel Edit Mode popup is visible be the state the panels are always in when in Global Edit Mode, sans the Panel Edit Mode popup itself)
  • Also keep the current toolbox on the right visible (when in G.E.M.) to enter the 'Advanced Panel Edit Mode' popup of that respective panel, just like how it's currently implemented

Also when triggering the 'Add Widgets' sidebar it should IMHO also trigger Global Edit Mode if it's not in Global Edit Mode. This would inadvertently also fix confusion from the show desktop feature staying activated after you drag a widget into the desktop or a panel since closing Global Edit Mode immediately nullifies the Show Desktop state.

To not let the widget locking feature bit-rot, lock widgets when not in global edit mode, and unlock widgets when entering global edit mode, or else expose a UI for it in some deep-hidden place

What's the differenc to now? There's no user visible difference just an implementation detail

That's what I thought too, but there are subtle differences. This has been noticed with the Quick Launch widget for example which has different behaviors based on locked vs not locked modes.