(Re)define modes when editing panels and widgets
Open, Needs TriagePublic

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