Just a heads-up - there's a bug open at the moment concerning a clash between the desktop toolbox that in Plasma 1 was on the top right of the screen and in Plasma 5 is on the top left, and widgets & icons (https://bugs.kde.org/show_bug.cgi?id=337060). The issue is shown in this screenshot:



Solutions suggested so far in the bug report include:

* The toolbox could be made to 'push' icons etc out of the way (if that's technically possible)
* Move the toolbox to the top-right of the screen
* Increase the margin on the right of the screen to move icons etc away from the toolbox

The last comment at the moment is from Bhushan Shah & asks 'What do usability and VDG guys say about this?' Have we got any input??

there is this thread viewtopic.php?f=285&t=122416 but thanks for update the Cashew "problem".

“Customize my Desktop” mode

- on the blog from colomar http://sessellift.wordpress.com/2014/10 ... australis/ there was a nice comment from AGui about a “Customize my Desktop” mode.

- the idea is to have a button/menu entry in every kde application and when you click this button you can customize the application.

Plasma & KDE

- On the other part, there is the "Problem" of KDE and Plasma. All of us know KDE, but in future we have Plasma 5 so a Plasma icon for the Cashew would be also a good solution.

About the margit bug

- Push the Cashew into a plasmoid and you solve this issue. And with the new undo function for removing plasmoids the user know what he do when he remove the Cashew plasmoid.

- Put it on the right corner would work also for me, but than it should look more than an edit button in the window decoration. than you can use the idea of DWD

This topic even has already come up in this forum: viewtopic.php?f=285&t=122416

The thing is: The "Cashew" seemed to have been one of the most disliked features of Plasma 4 for some people (there even was a "Hide the Cashew" Plasmoid that did nothing but... well... what the name says), and now we brought it right back for Plasma 5.

In the aforementioned thread, there was the idea to only have such a button in a panel, but that could cause the problem that users may end up "getting into a broken layout with no escape hatch", as Stephen Horlander from Mozilla calls it, if they remove all panels. Now with the brilliant Plasmoid Undelete feature Marco Martin came up with, however, users can easily undo an accidental panel deletion.

So how about re-thinking the Plasma toolbox as a Plasmoid that users could place anywhere on the desktop or on a panel? If a user accidentally removes it, they can get it back via undo.
If users for some reason remove the Plasmoid, then fail to undo the removal, they'd still end up with a situation they could only fix via context menu. To be honest, however, I don't think we should make the experience worse for all other users just to provide a safety net for users who have fallen through all other safety nets before.

I think that a good solution for that, is to hide the "Cashew" by default (when there are panels on the desktop). And show the "Cashew" when the user have removed all the panels of the desktop. Also, we can show a notification to the user instead of the "Cashew" when the desktop don't have panels. I believe that the beginner user will click intuitively something that appears in the screen instead of the right click on the desktop to show the context menu.

andreas_k wrote:“Customize my Desktop” mode

- on the blog from colomar http://sessellift.wordpress.com/2014/10 ... australis/ there was a nice comment from AGui about a “Customize my Desktop” mode.

- the idea is to have a button/menu entry in every kde application and when you click this button you can customize the application.

This is not directly related to the issue discussed in this thread. I really think that this approach deserves a closer look. Unfortunately, I am not a designer and I don't have the skills to do such great mockups as the ones made on this forum (nor the time to get those skills). I think it would make a great topic for Kver's What-if series : "What if Plasma used Firefox Australis' approach for customising the desktop?". Or I can open a specific thread here and we can discuss about the issues to solve, such as pointed out in the replies to my comment.

So what is the stance of VDG on that bug? Colomar, Jens, others?

Here is my take. I think I understand the original purpose of the toolbox, but unless we are using a device with a touch screen as the primary input I honestly don't see the utility of the thing always being visible. So, my thought is that if we have the capability to detect an active keyboard and mouse then we don't show the toolbox, otherwise show it.

If detection of an active keyboard and mouse is not reliable then, much as I'm loathe to add yet another option, I think we should just add an option to enable/disable it. If we go this route, assuming a laptop or desktop is the most likely Plasma 5 target in the short term, I'd suggest setting it to disabled by default. Of course of there is functionality uniquely accessible via the toolbox menu, we would need to find an alternate way of exposing them.

I know there may be some hemming and hawing because of the history of the debate surrounding the cashew/toolbox but my suggestion is that we take ownership of the thing and make a conscious, deliberate design decision for it.

Hope this helps!

Instead of detecting input devices, can't we do a simple check for panels? I.e.:

If Number_of_Panels < 1 { enable Cashew }

That way there will also be a fallback if a user manages to hide all the panels in Plasma.

I agree with Andrew, Colomar and veqz.

I think we should only show the desktop toolbox when:
1. there is less than 1 panel present
2. the widgets are unlocked

Similarly, the "cashew" in the panel should only be shown when the widgets are unlocked. This should enable users who do not want any "cashew" to be present to remove them.

veqz wrote:Instead of detecting input devices, can't we do a simple check for panels? I.e.:

If Number_of_Panels > 0 { enable Cashew }

That way there will also be a fallback if a user manages to hide all the panels in Plasma.

But panels can be empty. :/

Personally, I think the best solution for the toolbox is simple; add an option to the desktop context menu to toggle the thing. Right click -> Hide Toolbox. Right click -> Show Toolbox. If we wanted to be obscenely careful about it, we could have a pop-up saying "You hid your toolbox,right-click on the desktop to bring it back" and/or only show the option when the desktop is unlocked.

Outside of that, for the issue of overlapping; I'd move the toolbox back to the top-right. It surprised me that it was moved.

But even an empty panel contains the cashew, so there wouldn't be a need for a separate cashew at that point.

Also, right clicking to toggle it would be ideal, but if I understood colomar correctly, that's not a wanted behaviour, as an inexperienced user could end up with an empty desktop and no idea how to toggle on the cashew...

Also, my pseudocode was wrong.

Here's what I think:
I think that as long as there's a panel present (which is the case 99,9% of the time), the button there is sufficient, we don't need a second way to access the desktop config.

We only need a fallback solution if the user removes the last panel.
So it would be fine with me to just put the toolbox in a corner of the screen edge where the last panel was removed (ideally the last panel would be "reduced" to that button in an animation when removed.

Would that work?

colomar wrote:Here's what I think:
I think that as long as there's a panel present (which is the case 99,9% of the time), the button there is sufficient, we don't need a second way to access the desktop config.

We only need a fallback solution if the user removes the last panel.
So it would be fine with me to just put the toolbox in a corner of the screen edge where the last panel was removed (ideally the last panel would be "reduced" to that button in an animation when removed.

Would that work?

Thomas if I understand you correctly, no desktop toolbox when a panel is present and show it in the location of the last removed panel when no panels are present. Assuming I understood correctly then I think that's a reasonable approach. For clarity though, the panel toolbox and the desktop toolbox aren't necessary related since, if I recall correctly, the toolboxes were originally meant to expose the containment actions, the desktop and panel being different containments. This might be a classic case of implementation driving design, but I digress...

In any event, as a consequence I think there are actions exposed only via the desktop toolbox that are not exposed elsewhere. So we would just need to make sure they're exposed when a panel is present and the desktop toolbox isn't available. Looking at my current Plasma 5 install, actions like "Show Dashboard", "Activities", "Desktop Settings", and "Leave" might need consideration since they aren't available via the panel toolbox.

• "Activities" can be exposed via the panel plasmoid (and isn't really specific to the desktop containment anyway)
• "Show Dashboard" is similarly not specific to the desktop containment and could perhaps be exposed by a panel plasmoid.
• "Desktop Settings" is in the right click menu but, as you mention, isn't quite as discoverable. A right click on the desktop is a common interaction pattern on most platforms but then most other desktops have a system settings-style module for the desktop as well which aids discoverability. Worth thinking about?
• "Leave" is available via both application menus, either of which is available by default.

So maybe we find ways to expose these actions elsewhere when the toolbox isn't visible, while ensuring that all the desktop containment actions are accessible via the right click menu. The right click would at least preserve the functional locality of those actions, even if it is not as discoverable as the desktop toolbox. But at least we would avoid all the layout conflicts that can occur when the toolbox is always present.

Hope this is helpful!

Yes, Andrew, you understood my suggesiton exactly the way I meant it

I admit that when making this suggestion, I wasn't aware that the desktop and panel toolboxes currently do fundamentally different things, and that is exactly the problem. They use the same icon, but do different things. Which they shouldn't.

Having settings exposed only through context menus would violate the HIG ("Do not use context menus as the only way to start a function. Always have a redundant access."), but it can be the quickest way to access a function.

That said, I'm not sure if we can really find a good solution to the immediate problem of things overlapping the desktop toolbox if we keep the fundamental paradigm of "Every containment has its own configuration" in place. As you already pointed out, this is a classic example of "UI follows implementation" or "The code is staring you in the face right through the UI". I bet that containments are not part of the mental model most users have of their workspace.
The whole workspace is one thing, and a panel is just one area of it like any other.

So I'd really like to push for a rethink of workspace configuration as a "mode": There would be "use mode" and "configure mode". In "use mode", everything is locked. Nothing can be changed accidentally. A single click on the toolbox button chanegs to "configuration mode", where everything can be changed freely. This would make things so much more clear and easy for users.

Makes sense to me colomar.

How about we do this:

• Short term: we propose one of the following
  
  • move the toolbox to the right where it might be less likely to conflict OR
  • show/hide the toolbox as proposed with the caveat that "Desktop Settings" be exposed via another more-discoverable-than-the-right-click mechanism. (all the other desktop toolbox actions are available elsewhere)
• Longer term: Do a full-fledged design project to address configuration and use of the workspace. I'm talking a follow-the-HIG approach with clearly defined Vision, Personas, Scenarios, Use-cases, Organization then layout design and mockups. We know how to do this. We have the tools and the talent to do this. I think we should do this. It's post 5.2/5.3 stuff, but I think it fits with the Plasma team's plans which I believe was to focus initially on getting 4. x functionality and workflows in place first then being a little more adventurous once that's done.

Any objections?