(Re)define modes when editing panels and widgets
Closed, ResolvedPublic

Description

In M144 @ngraham suggested that we need to (re)define in which different modes you edit your panels and widgets.

There are currently 3 modes, each with different levels of editability exposed:

ModePanel movablePanel removablePanel editableCan directly enter Panel Edit ModePanel widgets movablePanel widgets RemovablePanel widgets replaceablePanel Widgets configurableCan add new panel widgetsPanel widgets can be interacted with
Panel Edit ModeYesYesYesYesYesYesYesYesYesNo
Unlocked ModeNoNoNoYesNoNoYesYesYesYes
Locked modeNoNoNoNoNoNoNoYesNoYes

This level of complication is overwhelming, confusing and inconsistent, and it needs to be discussed how we want to have it and what could be changed.

I see two general paths here:

  • Retain the distinct modes. In this case, we should have only two modes: Using and Editing ( kinda-sorta-in-between mode). The critical task for this option is to make it easy to find and enter Editing mode.
  • Remove the modality entirely, allowing panels to be edited without having to enter a distinct mode. The critical task for this option is to make it hard to accidentally mess up your panel while using it.
GB_2 added a comment.EditedDec 15 2018, 9:48 PM

I personally prefer having a more strict seperation between editing and using (Option 1).
You could easily find the edit mode with the panel toolbox or in the context menu like in M144.
There should be as little editing options in the context menu as possible when not editing the panel.

rooty added a subscriber: rooty.Jan 4 2019, 12:11 AM

We can actually do this by having two modes, Edit and Locked, without an Unlocked intermediate. You enter Edit and that unlocks things automatically, and once you're done you close it (and the elements lock automatically).

GB_2 added a comment.Jan 4 2019, 12:16 AM

That's a great idea!

GB_2 added a comment.Jan 4 2019, 8:38 AM

We can remove almost every option from the context menu that can be done in the edit mode, since that is the only place where you should edit or configure things.

GB_2 added a comment.Jan 4 2019, 8:41 AM

But we should probably keep the "Configure [Widget Name]..." menu entry, since it's better to have quicker access to it and it is also shown for desktop widgets.

GB_2 added a comment.EditedJan 4 2019, 8:49 AM

The question is, do we want to keep the panel edit mode button (the one on the right or bottom) if there is no more locking/unlocking and the edit panel menu entry is right in the context menu?

I suspect the reason for the third "unlocked" mode is to make it easier to add widgets, since otherwise you'd need to enter Edit mode which makes it more annoying and less discoverable.

Idea: how about we allow adding and removing widgets to and from the Desktop while in Locked mode. Adding/removing/changing widgets on a panel still requires entering Edit mode.

GB_2 added a comment.Jan 4 2019, 11:50 AM

I suspect the reason for the third "unlocked" mode is to make it easier to add widgets, since otherwise you'd need to enter Edit mode which makes it more annoying and less discoverable.

Idea: how about we allow adding and removing widgets to and from the Desktop while in Locked mode. Adding/removing/changing widgets on a panel still requires entering Edit mode.

That's a good idea too!

Codezela added a subscriber: Codezela.EditedJan 4 2019, 12:32 PM

we can make the move widget with keyboard combine with mouse
like ctrl+mouse click
it will be like quick mode to move things

GB_2 added a comment.Jan 8 2019, 5:20 PM

we can make the move widget with keyboard combine with mouse
like ctrl+mouse click
it will be like quick mode to move things

Yes, or just click and drag without needing to hold the widget for a few seconds (this is how Cinnamon does it for example), but that's a different task.

GB_2 added a comment.Jan 8 2019, 5:24 PM

There is actually a HIG rule that is somwehat relevant here: https://hig.kde.org/patterns/content/viewingediting.html
"Only show editing controls when appropriate. Examples include:

  • When an item is selected, contextually-appropriate editing controls can be shown in a toolbar or panel.
  • If an explicit editing mode is appropriate, then editing controls should not be shown until that mode is activated."

Very long story short. I remember my first experience with KDE and Plasma 5, it was around 4 years ago. After installing KDE I have removed by accident some important widgets from panel, I had no idea how to restore these items. After less than an hour I have decided to remove KDE and haven't touched it till October last year. I was incredibly upset back then.

I think panel editing might be still overcomplicated for new users, it should be obvious for user that panel is in edit mode, what is possible to do there and maybe there should be an option to reset changes when in edit mode. I am currenctly running 5.12.7, I know it's not latest version and panel has received couple of nice updates too.

I think Firefox has nicely made panel editing. ;)

Yeah, I agree that we need to put more thought into how to help users recover when they've made a mistake while experimenting. Right now we show a notification with an Undo button in it after they remove a widget, but the notification disappears in a few seconds and it's not clear to a new user that it can be found later in the Notifications system tray entry (also... you can remove the System Tray!).

Ideas:

  • For any default widget that's on the default panel, make the "you removed a widget" notification persistent so the user has to explicitly dismiss it
  • Add a "Reset desktop layout to default settings" button somewhere obvious that you'll see when you're in edit mode
GB_2 added a comment.EditedSep 15 2019, 6:19 AM

I think this is the best way forward:

  • Move panel options out of submenu
  • Hide the option to lock widgets in the UI (widgets are always unlocked)
  • Remove the panel edit mode button in the panel on the bottom/right
  • Clean up panel options menu

This is what I have implemented in my patches now.

In general I feel like that makes sense.

IIRC "locked mode" was intended as a sysadmin/enterprise type thing to allow admins to lock specific layouts to prevent their users from blowing themselves up by removing panels or task managers widgets or whatever. As long as this feature is still available (even via config file only), I think that's fine.

One thing I'm noticing with your patches is that the Alternatives menu item no longer appears in the context menu for widgets in a panel; for those, it's now only visible in Panel Edit mode. But it is still available in the context menu for widgets on the desktop. This feels a little odd TBH, like it's mixing modes.

GB_2 added a comment.Sep 15 2019, 8:51 PM

One thing I'm noticing with your patches is that the Alternatives menu item no longer appears in the context menu for widgets in a panel; for those, it's now only visible in Panel Edit mode. But it is still available in the context menu for widgets on the desktop. This feels a little odd TBH, like it's mixing modes.

Ok, I think I'll add that back.

ngraham moved this task from To Do to Work in Progress on the Plasma board.Sep 27 2019, 3:04 PM
ngraham moved this task from Backlog/Planned to Sent to dev on the VDG board.
ngraham closed this task as Resolved.Oct 21 2019, 4:01 PM
ngraham claimed this task.

I think we can call this done now!

zachus added a subscriber: zachus.EditedNov 3 2019, 9:09 PM
In T10190#172495, @GB_2 wrote:

we can make the move widget with keyboard combine with mouse like ctrl+mouse click

why deviate from the "Alt-F3 MOVE" mouseless-move-window procedure ? to add one more to the gazillions of hotkeys which no one can memorize? Many VGA-driver/XRANDR sufferers had to learn "Alt-F3 MOVE" or Alt+MOUSEmove the hard way. why not put that knowledge to good use? That said, I also felt the urge to voice my relief over the dumping of that darn cashew with no name that cluttered the desktop for next to no reason.

can't say what bothered me more: the namelessness of "desktop-toolbox" like "krunner" or its clutter-factor on an otherwise clean (solid color only, of course) desktop.