Bug 417424

As kindly pointed out by Eric Adams on twitter, a workaround until this is fixed it to run:

qdbus org.kde.plasmashell /PlasmaShell evaluateScript "lockCorona(false)

Git commit 2bc3c5e92d4789146548e8de4d520cd191994e1c by Marco Martin.
Committed on 11/02/2020 at 15:43.
Pushed by mart into branch 'Plasma/5.18'.

unlock widgets

5.18 doesn't offer a way anymore from the gui
so unlock them if they're locked

A  +2    -0    desktoppackage/contents/updates/unlock_widgets.js

https://commits.kde.org/plasma-desktop/2bc3c5e92d4789146548e8de4d520cd191994e1c

Git commit 95c061015eb1fba26aeabb1909b1d863db7e4401 by Marco Martin.
Committed on 11/02/2020 at 15:42.
Pushed by mart into branch 'master'.

unlock widgets

5.18 doesn't offer a way anymore from the gui
so unlock them if they're locked

A  +2    -0    desktoppackage/contents/updates/unlock_widgets.js

https://commits.kde.org/plasma-desktop/95c061015eb1fba26aeabb1909b1d863db7e4401

*** Bug 417429 has been marked as a duplicate of this bug. ***

*** Bug 417480 has been marked as a duplicate of this bug. ***

*** Bug 417456 has been marked as a duplicate of this bug. ***

(In reply to Rik Mills from comment #0)
> 
> ... as this is now the intended
> state with locking and unlocking a 'hidden feature'
> 

May I ask where that 'hidden feature' will be hiding?

Or if wishing to lock|unlock are we expected to now use 

qdbus org.kde.plasmashell /PlasmaShell evaluateScript "lockCorona(true|false)

With widgets unlocked it's all too easy to inadvertently middle click on the desktop and create an unwanted sticky note.  Or maybe I'm just too clumsy...

If the rason why you want to lock widgets is to disable the the "middle-click to create a sticky note with the contents of the clipboard" feature, you can turn it off in:

Right-click desktop > Configure Desktop > Mouse Actions > click minus button on the row containing "Middle".

(In reply to Nate Graham from comment #8)

> Right-click desktop > Configure Desktop > Mouse Actions > click minus button
> on the row containing "Middle".

Does that apply to middle click on the desktop only, I use middle click to paste.

(In reply to Paul from comment #9)
> 
> Does that apply to middle click on the desktop only, 

Answering my own question, yes that would appear to be the case.

Nonetheless, it would still be useful to know where the 'hidden feature' (of lock|unlock widgets) is hiding...

Correct me if I'm wrong but I believe the intent is that the concept of locking is superseded by the Customize Layout option. Widgets are locked unless you have Customize Layout enabled.

i confirm thee is no more problem

If I right click 
the item "customize your layout" is no more in gray thus i get "global editor bar"
then I can click on "add graphical component" and thee is a new item "add grapical component"

If I right click then choose "desktop settings" then i get no more warning about locked graphical components.

Method to modify "control board" bar has changed.

just right click on the control board then you get an item "modify control board"

(In reply to Eric Adams from comment #11)
> Correct me if I'm wrong but I believe the intent is that the concept of
> locking is superseded by the Customize Layout option. Widgets are locked
> unless you have Customize Layout enabled.
Essentially, yes. Explicitly locking widgets is not intended to be more of a sysadmin-only thing for preventing users from changing anything.

I'm not overly happy about this setting being hidden. I use it to stop stuff getting moved as I have essential tremor. I guess I will have to apply the 'hidden' setting.

Please don't make anything else UI related configurable via policy script only.

Widgets still can't be moved with accidental clicks-and-drags. What problem are you seeing with the new approach in Plasma 5.18?

It is entirely possible to remove a widget by rogue clicks. Anyone with Parkinson's Disease or essential tremor (similar effect to Parkinson's) does not have full control of motor action. So it doesn't take much to accidentally evoke customize layout and drag something or remove widgets. One right click, slight movement of mouse and left click, all of which can happen involuntarily.

Please don't dismiss this feedback off-hat.

Ah ok, so if a multi-step process is still vulnerable to that, then it sounds like you might like to continue locking widgets. You can do it it by running the following command:

qdbus org.kde.plasmashell /PlasmaShell evaluateScript "lockCorona(true)"

Thanks, I already did that :)

I posted the enable and disable code lines on the manjaro forum for others to use too.

Today I've updated from plasma 5.17.5 to plasma 5.18.1. I had desktop widgets locked before updating. After updating desktop widgets remained locked.

I had to manually run already mentioned command:
qdbus org.kde.plasmashell /PlasmaShell evaluateScript "lockCorona(false)"

Here are some contents of my configs:

$ tail -n 2 ~/.config/plasmashellrc
[Updates]
performed=/usr/share/kf5/plasma/shells/org.kde.plasma.desktop/contents/updates/obsolete_kickoffrc.js,/usr/share/kf5/plasma/shells/org.kde.plasma.desktop/contents/updates/move_desktop_layout_config.js,/usr/share/kf5/plasma/shells/org.kde.plasma.desktop/contents/updates/unlock_widgets.js

$ cat /usr/share/kf5/plasma/shells/org.kde.plasma.desktop/contents/updates/unlock_widgets.js

__AppInterface.locked = false;


Shouldn't widgets have been automatically unlocked?

Nevermind. Looks like my issue is caused by downstream patches.

Until now we relied on the "soft-lock" feature of KDE to prevent - statistically speaking - user frustration due to misconfiguration of the desktop. 

The Plasma desktop was delivered locked by default and users who know what they are doing were taught how to lock and unlock via the UI. The majority of users we have been working with would not want to change the desktop layout that we pre-configure and deliver so the lock was very useful to preserve the sanity of their desktops - including widgets, bar, system tray, etc.

This modus operandi was built on the experience of working with end users over more than 15 years and observing how - statistically speaking again - they manage to accidentally misconfigure their desktops and become frustrated with the result. I am talking about normal users without any specific condition. This is just the way that non-technical users behave and there is not much that can be done in that regard.

We believe that the UI based lock/unlock feature was a good one to rely on and it is still very necessary - for example, it is very easy to accidentally remove a Quick Launcher from the bar, but it is not super easy for a normal user to set it back to how it was.

Given this explanation we kindly as you to restore the UI based lock/unlock menu entry. Would that be possible?

We would be OK even with an implementation where we have to active the appearance of this option on a configuration file.

Thanks in advance,
Gustavo

Created attachment 127353 [details]
Version information

Version information

Created attachment 127354 [details]
Launcher right click example

Example of how easy it is to remove a quick launcher.

If there are specific issues where things are easy to remove, lets file new bugs on them and we can discuss how we can fix those things. 

I would rather fix the situation to improve the experience for everyone than have ever-diverging code paths and UXs.

I really don't see why certain elements of KDE Project are being so adamant over not adding the lock/unlock feature back to the UI. The April Fools post about KNOME is actually starting to ring true ;)

I'd open a separate bug based on the accessibility concern but am willing to wager money that it would get closed as a duplicate straight away since it's already been raised and dismissed by yourselves as no issue anyway.

Suffice to say I'm actually disgusted by this ignorant stance. If you won't add the option back to the desktop right-click context menu and panel one, then at least consider putting an entry to control the corona (oh the irony...) value in the Accessibility settings under System Settings

Hi 

I am more than happy to file individual bugs for those things.

In the meantime (because those things usually take a long time to discuss and fix) we would like the traditional lock/unlock UI feature to be present again, even if it has to be activated by a configuration file through a setting that can be off by default, if that is the devs preference.

We believe this feature is necessary for the users we deal with *while* the things we should file new bugs for are discussed and implemented. The effort to bring this feature back is probably low compared to all the UX improvements that are necessary to prevent all types of accidental desktop misconfigurations, which means that the time scales for doing one thing and the other are probably very different.

I hope I have presented the case clearly.

Hoping to receive a confirmation that this feature can be brought back for the timeline of Kubuntu 20.04.

Thanks again.

(In reply to gustavo from comment #26)
> Hoping to receive a confirmation that this feature can be brought back for
> the timeline of Kubuntu 20.04.

Not going to happen. Plasma 5.18 branch is feature frozen, as is Kubuntu 20.04.

JFYI insulting the developers is not generally an effective way to get them to do what you want. ;)

I understand your concern that removing this feature from the UI has made it more difficult for you to provide curated experiences for your different technical classes of user.

Our explicit goal was in fact to implement this model more naturally, via a global edit mode. It was intended that when not in the global edit mode, users would be prevented from accidentally destroying their desktop, because they would need to enter the global edit mode.

However I think I see the problem: you can still remove a widget using the context menu. Our model of user behavior was that non-technical users don't tend to right-click much, so preserving the ability to delete widgets using the context menu outside of the edit mode was okay as it would mostly be used as an accelerator for experts. Perhaps this was a flawed assumption, and we should revisit that to remove all widget deletion options from the context menu when not in the global edit mode.

This would more or less get you back to where you were before: the widgets look immutable to non-technical users who will not figure out how to enter the global edit mode, or do it by accident. While more advanced users will be able to enter the global edit mode easily to customize their systems.

How does that sound?

(In reply to Rik Mills from comment #27)
> (In reply to gustavo from comment #26)
> > Hoping to receive a confirmation that this feature can be brought back for
> > the timeline of Kubuntu 20.04.
> 
> Not going to happen. Plasma 5.18 branch is feature frozen, as is Kubuntu
> 20.04.

This not good :( :(

My question remains however to a broader timeline. It seems to me that the removal of the feature broke compatibility with an important use case with incomplete re-evaluation of the UX issues that made it necessary.

I'm hoping it can be brought back soon.

I'd be happy to participate in detailed reporting of use cases scenarios that are prone to misconfigurations afterwards.

(FWIW while the 5.18 branch is indeed feature frozen, bugfixes can still go in. If we decide to address this and the change we make is non-invasive enough and does not involve changing or adding any more text strings, it would be possible to get it into 5.18.[something])

Anyway, can you confirm that the root of the problem for your less advanced users is the ability to delete widgets using the context menu outside of the global edit mode?

@Nate Graham

Thanks for your answer. I believe I have written politely all the time and I will continue to do so :-)

In regards to your question:

>Anyway, can you confirm that the root of the problem for your less advanced 
>users is the ability to delete widgets using the context menu outside of the
>global edit mode?

It would take sometime to reply with a robust statement because I would need to check one by one all cases where a user can by mistake misconfigure something.

Let me try to do my best with what I can quickly look into.

In the screenshot I posted, you can see that the user is easily able to:

* remove the entire Quick Launch widget with the carefuly curated items we have put there (a disaster...)
* disable individual shortcuts from the Quick Launch widget (not good either)

The users can also easily go to "Edit Panel" mode where they can drag and remove panel components with a few clicks even if they are just trying to exit that mode.

Just during this reply I destroyed my desktop with a few clicks and even as a technical user it will take me at least 5-10m to put it back exactly to how it was.

The lock widgets feature was a great safety net. At least the users would have to explicitly perform an action that speaks by itself "Unlock widgets" to start messing around the the desktop. Without this we are going to have a "statistical attack" of support requests and see the levels of silent and vocal user frustration increase - 15 years of working with KDE on non-technical users here.

(In reply to Nate Graham from comment #28)

[...]

> 
> Our explicit goal was in fact to implement this model more naturally, via a
> global edit mode. It was intended that when not in the global edit mode,
> users would be prevented from accidentally destroying their desktop, because
> they would need to enter the global edit mode.
> 

If you are referring to the Customize Layout / Finish Customizing Layout feature, the problem is that it does not prevent the panel from being reconfigured. If this feature also controlled the panel it would be the same as Lock Widgets / Unlock Widgets.

And in that case I would not even complain that the name of the feature had changed.

>Our model of user behavior was that non-technical users don't tend to right-
>click much, so preserving the ability to delete widgets using the context menu 
>outside of the edit mode was okay as it would mostly be used as an accelerator 
>for experts. Perhaps this was a flawed assumption, 

There is a spectrum of technicality from entry level users who are afraid of breaking the system and only click on what they know (a minority) to highly technical users (like the ones discussing here) which are disciplined with clicks and are able to reconfigure whatever they break. 

Your assumption might be right to the leftmost part of the spectrum.

Unfortunately, the majority of the users lies in the middle of the spectrum: they are technical enough to not be afraid to click but not technical enough to put things back as they where. I am talking of non-technical former Windows and OSX users at their peak of non-technical productivity. They will consider that the desktop is bad if they manage to break it accidentally - and I have seem that happen in the past and that is why I am saying we should prevent it with a "Lock widgets" or equivalent feature.

> If you are referring to the Customize Layout / Finish Customizing Layout feature,
> the problem is that it does not prevent the panel from being reconfigured. If this
> feature also controlled the panel it would be the same as Lock Widgets / Unlock
> Widgets.
In the past, when widgets were locked, editing the panel required the following:
1. Right-click on the panel or desktop and choose "Unlock widgets"
2. Click on the settings button on the panel

Now, editing the panel requires the following:
1. Right-click on the panel and choose "Edit Panel"

Are you saying that your users are explicitly clicking on this "Edit Panel" menu item and then destroying their panels while in panel edit mode? That seems like it's exposing an issue with the usability and potential destructiveness of panel edit mode itself.

I agree with you that many users lie in a middle ground where they're not afraid to experiment but expect that experimenting won't break their systems. That's something we want to support, for sure. However this bug report is getting pretty cluttered and it would probably be best to file new ones on the use cases that you find are problematic. This would be very valuable information, for sure. Once you file those bugs, please mention them in a comment here.


Regarding the issues with the quicklaunch widget, they appear to be unique to that widget. The widget is building its own context menu and displaying the same items regardless of whether the user is in edit mode or not. We should definitely fix this, but we will need a separate bug report on this. Can you file one on kdeplasma-addons | quicklaunch and mention the URL in a comment here?

Hi again Nate,

And thanks for the replies.

(In reply to Nate Graham from comment #33)
> > If you are referring to the Customize Layout / Finish Customizing Layout feature,
> > the problem is that it does not prevent the panel from being reconfigured. If this
> > feature also controlled the panel it would be the same as Lock Widgets / Unlock
> > Widgets.
> In the past, when widgets were locked, editing the panel required the
> following:
> 1. Right-click on the panel or desktop and choose "Unlock widgets"
> 2. Click on the settings button on the panel
> 
> Now, editing the panel requires the following:
> 1. Right-click on the panel and choose "Edit Panel"

Exactly.

> 
> Are you saying that your users are explicitly clicking on this "Edit Panel"
> menu item and then destroying their panels while in panel edit mode? That

Yes, it has happened in the past. "My users" are not special :-) They are just a sample of the majority of the working population. That's how normal non-technical users behave, whether I like it not :-)

> seems like it's exposing an issue with the usability and potential
> destructiveness of panel edit mode itself.

I fully agree with you. And I am also saying that those UX things are subtle and require focus and time investment and therefore might be important on the short term have the lock widgets safety net.

> 
> I agree with you that many users lie in a middle ground where they're not
> afraid to experiment but expect that experimenting won't break their
> systems. That's something we want to support, for sure. However this bug
> report is getting pretty cluttered and it would probably be best to file new
> ones on the use cases that you find are problematic. This would be very
> valuable information, for sure. Once you file those bugs, please mention
> them in a comment here.

please see below

> 
> 
> Regarding the issues with the quicklaunch widget, they appear to be unique
> to that widget. The widget is building its own context menu and displaying
> the same items regardless of whether the user is in edit mode or not. We
> should definitely fix this, but we will need a separate bug report on this.
> Can you file one on kdeplasma-addons | quicklaunch and mention the URL in a
> comment here?

I'd be very happy to invest time on that and the above.

Do you think those issues can be discussed and implemented in the same time frame that temporarily bringing "lock widgets" back would be done?

If so, I will open the new bug reports in the next hours. 

Otherwise, I will need to invest short term time in working around this problem and preventing the forthcoming 20.04 deploy from not being well received (maybe with some qdbus automation hack or something I don't yet know).

We can fix the quicklaunch widget's context menu in the 5.18 timeframe for sure.

Improving the usability of panel edit mode is probably going to be a 5.19 project, unless we can really identify discrete bugs causing the usability to be bad, in which case it might be feasible to fix them for 5.18.x. If the whole UX needs an overhaul though, that's definitely a 5.19 project.

Regarding your deployment, widgets are still lockable with all the same effects as before, it's just the UI to toggle it has been disappeared as it's now considered an admin-type feature--which is in fact how you're using it, so I'm glad we were right about that at least. :) So maybe you can lock the widgets and tell your knowledgeable users how to unlock them with the `qdbus org.kde.plasmashell /PlasmaShell evaluateScript "lockCorona(false)"` command, perhaps even shipping a bash alias for it or something that they can easily run via KRunner.

Either way, let's close this bug again and we can discuss subsequent fixes in addition bug reports.

Thanks for reporting your concerns and helping to make Plasma better!

Hi Nate,

For our understanding to converge with accuracy, I'm going to provide an extra reply.

We are not using this as an admin feature.

We are using this as an extra layer of user confirmation in the same spirit of "do you really want to delete this file forever"?

Users are forced to read and click on "Unlock widgets" before they can click into Panel Edit Mode.

So users (not sysadmins) are in control still but they have an extra confirmation layer which statistically speaking prevents many occurrences of desktop misconfiguration.

What we had until now and lost from 5.17 to 5.18 was something subtle: a delicate balance between user control and user protection.

In regards to your suggestions: it is not doable to teach regular users how to run qdbus or even use krunner in order to be allowed to perform desktop customization. It is also not doable to not allow any user to configure the desktop or to rely on a sysadmin to unlock things.

I'm not sure I am expressing myself clearly :-) but this is an attempt.

> In regards to your suggestions: it is not doable to teach regular users how to run
> qdbus or even use krunner in order to be allowed to perform desktop customization.
> It is also not doable to not allow any user to configure the desktop or to rely on
> a sysadmin to unlock things.
Are we talking about the panel edit mode, or the general edit mode now?

If I'm understanding you correctly, you're saying that in your experience panel edit mode in its current form is so dangerous that it should require two steps to enter, not just one. And that Plasma 5.18 turned it into a one-step process by default, and regaining the second step requires using the command line, which is problematic since some of your users are just technical enough that they can handle the danger of panel edit mode if it's guarded behind a GUI-only two-step process, but they are not technical enough for one of those steps to be a command-line action.

If so, all of this definitely points to serious usability issues with panel edit mode, and requiring an extra step is just a band-aid over that issue. Could you file bug reports on plasmashell | panel detailing your observations regarding why its usability is so bad and its danger level so high for the users in your organization?

You don't need to keep re-opening this bug report. We can talk even when it's set to RESOLVED. Again, let's focus on how to improve the problems that we're identifying here, not reverting the new global edit mode or making widget locking a CLI-only feature.

Nobody actually insulted anyone yet if you were referring to my post Nate.

Dismissing genuine user feedback about accessibility issues is not the way to do things either. The need to enter code in a terminal instead of being able to do enable/disable such things in a UI is not a practical approach for users with impaired motor functions either.

I'm trying to do KDE a favour by reporting this but if you can't see that then I'm not really the one with an issue here.

I don't believe that I am dismissing any feedback. Rather, I've spent half my morning discussing that feedback in great detail. :)

So in that discussion, we've found that people have been using widget locking as a band-aid over panel edit mode being too dangerous and having bad usability. So we'll fix that. However we can't re-add the GUI for widget locking because it conceptually conflicts with the new global edit mode; the latter was meant to replace the former such that having both visible in the UI doesn't really make sense. So if we restore the widget locking GUI, we also need to revert the global edit mode feature to keep the UI coherent, which obviously cannot be done in a bugfix point release. That means such a change would need to be done in the next major version--Plasma 5.19. But if we need to wait for Plasma 5.19 for a resolution anyway, we might as well just fix the underlying issue itself--panel edit mode needing a UX overhaul. So let's do that.

Again, I would appreciate if people could file bug reports on plasmashell | panel regarding the usability issues they've found with panel edit mode.

Thanks!

(In reply to Nate Graham from comment #38)
> You don't need to keep re-opening this bug report. We can talk even when
> it's set to RESOLVED. Again, let's focus on how to improve the problems that
> we're identifying here, not reverting the new global edit mode or making
> widget locking a CLI-only feature.

Don't worry, I have had more than enough of being fobbed off to give a crap any longer. It's your problem if you start haemorrhaging users, not mine.

All right. I'm sorry you've had a bad experience, but I believe my conduct in this Bugzilla ticket speaks for itself. :)

(In reply to Nate Graham from comment #37)
> > In regards to your suggestions: it is not doable to teach regular users how to run
> > qdbus or even use krunner in order to be allowed to perform desktop customization.
> > It is also not doable to not allow any user to configure the desktop or to rely on
> > a sysadmin to unlock things.
> Are we talking about the panel edit mode, or the general edit mode now?

I am talking about unlocking widgets if we decide to have them locked by default. It is not doable to not allow it or to rely on a sysadmin but it is also not doable to teach users to run qdbus, etc. What we had (unlock widgets was doable).

> 
> If I'm understanding you correctly, you're saying that in your experience
> panel edit mode in its current form is so dangerous that it should require
> two steps to enter, not just one. 

Yes. As it was before was fine in my opinion. I work with KDE with widgets locked full time - even for me it is a major annoyance to set something back if accidentally misconfigured.

>And that Plasma 5.18 turned it into a
> one-step process by default, and regaining the second step requires using
> the command line, which is problematic since some of your users are just
> technical enough that they can handle the danger of panel edit mode if it's

... it is more that less of them will reach the danger of panel edit mode. The ones who do needed to click on "Unlock widgets" first which makes them more aware of what they are about to do.

> guarded behind a GUI-only two-step process, but they are not technical
> enough for one of those steps to be a command-line action.

Average users (imagine the average Windows or OSX user) don't know how to use the command line.

> 
> If so, all of this definitely points to serious usability issues with panel
> edit mode, and requiring an extra step is just a band-aid over that issue.

I might agree but i need to look in detail into all configuration actions. It worries me that the band aid has been removed and apparently can't be put back before we have time to examine the danger.

> Could you file bug reports on plasmashell | panel detailing your
> observations regarding why its usability is so bad and its danger level so
> high for the users in your organization?

My short term effort will be directed towards restoring the protection we had before in a way that can be implemented quickly: if getting the lock/unlock behaviour back is considered by the Plasma team to be undesirable I will have to check how to work it around.

Once that is done I can look in detail into specific usability issues. It is clear to me that putting the band aid back and discussing+fixing sophisticated user interactions so that the band aid is not necessary require very different amounts of time.

(In reply to Nate Graham from comment #42)
> All right. I'm sorry you've had a bad experience, but I believe my conduct
> in this Bugzilla ticket speaks for itself. :)

Yes, it spoke volumes. Like I said, if you can't or won't redress this then what is the point of opening another bug anyway?

I'm wasting both our time here, goodbye.

> However we can't re-add the GUI for widget
> locking because it conceptually conflicts with the new global edit mode; the
> latter was meant to replace the former such that having both visible in the
> UI doesn't really make sense. 

Well, can you make the current Customize Layout / Finish Customizing Layout also lock / unlock ?

In that case we could protect both the desktop and the panel with a single menu entry without any logical UI conflict.

I mean, everything would work the same as before from a user perspective, but with a different name.

I think this could flatten the curve of accidental misconfigurations for the forthcoming Kubuntu 20.04 users and we would gain time for a more in-depth usability discussion without the pressure of this release timeline.

(In reply to gustavo from comment #45)
> > However we can't re-add the GUI for widget
> > locking because it conceptually conflicts with the new global edit mode; the
> > latter was meant to replace the former such that having both visible in the
> > UI doesn't really make sense. 
> 
> Well, can you make the current Customize Layout / Finish Customizing Layout
> also lock / unlock ?
Hmm, that's easily possible. However this would introduce UI changes in that by default, you would not be able to replace panel widgets with alternative ones or add new panel widgets without entering the global edit mode. One of the reasons why we didn't do this before was a hesitancy to hide the widget features and editability that's at the core of Plasma so much. But maybe that's reasonable and these implementation details are too close to the surface at the moment.

However arguably your proposal is conceptually correct: in edit mode, you'd be able to add, swap, or remove widgets. Outside of edit mode, you can't. That's a nice simple separation between the modes.

On the other hand, if we did this, we would want to make entering the global edit mode also automatically enter panel edit mode too, or else there would be an inconsistency: entering global edit mode would make everything on the desktop editable immediately, but the panel would not be similarly editable without a second operation (the "Edit Panel" context menu item). Why should panel widgets have more "protection" than desktop widgets?

I feel like this needs some discussion with the Plasma and VDG teams. I will bring it up.

(In reply to Nate Graham from comment #46)
> (In reply to gustavo from comment #45)
> > > However we can't re-add the GUI for widget
> > > locking because it conceptually conflicts with the new global edit mode; the
> > > latter was meant to replace the former such that having both visible in the
> > > UI doesn't really make sense. 
> > 
> > Well, can you make the current Customize Layout / Finish Customizing Layout
> > also lock / unlock ?
> Hmm, that's easily possible. However this would introduce UI changes in that
> by default, you would not be able to replace panel widgets with alternative
> ones or add new panel widgets without entering the global edit mode. One of
> the reasons why we didn't do this before was a hesitancy to hide the widget
> features and editability that's at the core of Plasma so much. But maybe

We love how configurable it is because one can fully customize the user experience, which is what we do. My comments are towards enjoying the detailed configurability to optimize user experience and protecting that configuration when necessary also to optimize user experience.

> that's reasonable and these implementation details are too close to the
> surface at the moment.
> 
> However arguably your proposal is conceptually correct: in edit mode, you'd
> be able to add, swap, or remove widgets. Outside of edit mode, you can't.
> That's a nice simple separation between the modes.
> 
> On the other hand, if we did this, we would want to make entering the global
> edit mode also automatically enter panel edit mode too, or else there would
> be an inconsistency: entering global edit mode would make everything on the
> desktop editable immediately, but the panel would not be similarly editable
> without a second operation (the "Edit Panel" context menu item). Why should
> panel widgets have more "protection" than desktop widgets?

If in doubt I would prefer charging users who want to perform a change with an extra click rather than saving a click to users who are not sure what they are doing.

That said, if you prefer to auomatically enter "panel edit mode" from clicking on the Customize Layout menu item, it would still be an improvement over the current situation - at least there would be a global place to enter/leave configuration mode that includes visual feedback from top and bottom (see screenshot) in relation to what is going on.

> 
> I feel like this needs some discussion with the Plasma and VDG teams. I will
> bring it up.

Thank you for considering the proposal.

Created attachment 127367 [details]
everything in edit mode?

Yep, that's pretty much what I had in mind. I'll put together a proposal and start a discussion around it!

Meanwhile, could you file some bugs about the usability issues you've observed with respect to your users and panel edit mode?

Hi Nathan,

What I observed over the years is completely misconfigured panels and desktops in general. So I have a robust opinion in regards of these things being easy to misconfigure accidentally.

I don't have specific knowledge of how exactly they did it, i.e., which normal use cases (statistically) lead to unwanted results. That's because I am not watching them as they work, I just witness the problems when they complain or - worst then that - on random occasions if rather than complaining they suffer in silence.

I can open some bug reports and give a personal opinion about the UI flows but that will be a personal opinion not a robust statement - a multi stakeholder review as discussion will be necessary to converge to a consensus about how to improve. It can take months to get this right,

This is why I am advocating so much for protecting the configuration from user misclicks (the band aid) and insisting that fixing the root cause (which you aim for and I agree is the mid term best route) belongs to another timescale.

I will do my best opening those bug reports anyway.

Thanks again.

@Nathan,

Opened this new issue as you requested:

https://bugs.kde.org/show_bug.cgi?id=419853

Hi Nate,

(In reply to Nate Graham from comment #49)
> Yep, that's pretty much what I had in mind. I'll put together a proposal and
> start a discussion around it!
> 
> Meanwhile, could you file some bugs about the usability issues you've
> observed with respect to your users and panel edit mode?

I filed another one here:
https://bugs.kde.org/show_bug.cgi?id=419855

Thanks everyone!

I've opened a Phab task to continue the discussion in https://phabricator.kde.org/T12942.