This thread comes from this thread Remove Plasma Cashew from Desktop Corner" [1] and the
the discussion of this post “Killing the Cashew” done right [2].

I propose to make the presence of a panel one of the integral parts of the Plasma desktop for basically the same reasons for having the Plasma Toolbox on the desktop.
Since Plasma supports more than one panel the last panel would be non-destructible or be automatically replaced by some kind of default panel when removed. So the regular user always can rely on a panel (which would then contain the original Plasma Toolbox, e.g. as menu button in the right corner).

For me this "panel of steel" is highly compliant with the KDE philosphy:

• simple by default:
  
  • It makes it impossible for regular users to remove their panel (which is one of the reasons to have the Plasma Toolbox in the first place).
  • No need for an additional icon in the top left or right corner to solve the "hidden feature" problem (avoid UIs that need right-clicks) because the Toolbox features could be accessed from the panel using left click.
  • One can complain that his nice wallpaper is occluded with some hard-to-remove icon.
  • For the normal cases the panel stays the default entry point for every action to the desktop.
• powerful when needed:
  
  • Expert users can also remove the panel with ease, e.g. by replacing it with the original Plasma toolbox (analogous to the method described in [2]).
  • No essential change to panel. It is still full of alternatives - especially thanks to the new "alternatives" menu introduced with Plasma 5.

Especially, all the functionality of the current Plasma Toolbox would be kept by merging it with the panel. So instead of being integral part of the desktop it becomes integral (and not-(easy)-removable) part of the panel.

I hope this is not entirely crazy talk to the core plasma developers and other plasma experts. Please give feedback if the "panel of steel" idea is missing some critical points or is entirely impossible with the current implementation.

[1] Remove Plasma Cashew from Desktop Corner
[2] “Killing the Cashew” done right

Wouldn't allowing to integrate the cashew in the panel be a more flexible solution? I think it's unnecessary to require a panel for something like the cashew.
Personally I can't quite understand whats the problem with the cashew. It's imho the only accessible way to have a configurable desktop like plasma is, without hiding things from the user. Enforcing panels just for the sake of removing the cashew is not a nice solution imho.
Maybe some people see an aesthetical issue with the cashew obtaining space.
However, Thomas (colomar) talked about rethinking the separation between edit mode and actual ui IIRC, maybe the cashew would be part of that consideration. Maybe he could give a quick status update?
Making the cashew a widget makes hierarchically no sense, since the cashew is kind of an control element of widgets.
I am quite uncertain but I am in favor of keeping the current situation until something better comes up, as the panel itself is a widget and I see no reason in enforcing a widget for the sake of control of other widgets.

kdeuserk wrote:Wouldn't allowing to integrate the cashew in the panel be a more flexible solution? I think it's unnecessary to require a panel for something like the cashew. [...] Enforcing panels just for the sake of removing the cashew is not a nice solution imho.

The removal of the cashew from the wallpaper would only be a side effect. It could still be present if wanted, e.g. in the panel, I like that idea. It's more about making the panel a first-class citizen for the average user.

kdeuserk wrote:It's imho the only accessible way to have a configurable desktop like plasma is, without hiding things from the user.

Can you give an example of such a configuration / situation? (The proposal says that the expert user can easily remove the panel if needed)

Thank you for bringing new ideas into this discussion! And bonus points for referring to our mantra

Additionally to the pros and cons you already mentioned, these are further pros and cons I see:
Pro:
- Users won't get into the situation where they don't have a panel anymore

Con:
- If you want to just "reboot" you panel, you'd have to add a new one first in order to remove the old one, which might not be obvious to users.

The idea Andrew and I went with while thinking about the "Plasma config mode" kdeuserk mentioned was to put the toolbox button in the panel as long as there is one, like gregormi suggested here as well, but put it on the desktop as a separate element as soon as the last panel is removed.

This would give the user the life-saver needed to get a panel back if it was accidentally removed (though remember that now we also have the "Plasma undo" feature which allows to easily undo the accidental removal) but would still allow to remove panels.

colomar wrote:Con:
- If you want to just "reboot" you panel, you'd have to add a new one first in order to remove the old one, which might not be obvious to users.

Good point. Do you mean reboot in a sense of "reload panel with all customization intact" or "reset panel to default settings"? (Either way - and also independent of this topic: what about having some kind of "reset" menu item in the context menu of panels?)

colomar wrote:The idea Andrew and I went with while thinking about the "Plasma config mode" kdeuserk mentioned was to put the toolbox button in the panel as long as there is one, like gregormi suggested here as well, but put it on the desktop as a separate element as soon as the last panel is removed.

This would give the user the life-saver needed to get a panel back if it was accidentally removed

Sounds reasonable. So is putting the toolbox button in the panel (if there is at least one) a part of the "Plasma config mode" idea (I would be interested in the discussion page if there is one) or do you think it could also be shipped "stand-alone" as an intermediate step towards it? I ask because as I understood it, with the current Plasma 5 design the user does not get any option to move the Toolbox away from the desktop without having to read special instructions)

colomar wrote:The idea Andrew and I went with while thinking about the "Plasma config mode" kdeuserk mentioned was to put the toolbox button in the panel as long as there is one, like gregormi suggested here as well, but put it on the desktop as a separate element as soon as the last panel is removed.

This would give the user the life-saver needed to get a panel back if it was accidentally removed (though remember that now we also have the "Plasma undo" feature which allows to easily undo the accidental removal) but would still allow to remove panels.

+1

gregormi wrote:

colomar wrote:Con:
- If you want to just "reboot" you panel, you'd have to add a new one first in order to remove the old one, which might not be obvious to users.

Good point. Do you mean reboot in a sense of "reload panel with all customization intact" or "reset panel to default settings"? (Either way - and also independent of this topic: what about having some kind of "reset" menu item in the context menu of panels?)

I meant "reset to default panel". However, your idea of a reset button makes a lot of sense to me as well!

colomar wrote:The idea Andrew and I went with while thinking about the "Plasma config mode" kdeuserk mentioned was to put the toolbox button in the panel as long as there is one, like gregormi suggested here as well, but put it on the desktop as a separate element as soon as the last panel is removed.

This would give the user the life-saver needed to get a panel back if it was accidentally removed

Sounds reasonable. So is putting the toolbox button in the panel (if there is at least one) a part of the "Plasma config mode" idea (I would be interested in the discussion page if there is one) or do you think it could also be shipped "stand-alone" as an intermediate step towards it? I ask because as I understood it, with the current Plasma 5 design the user does not get any option to move the Toolbox away from the desktop without having to read special instructions)

There is currently no specific thread about the "Plasma config mode" afaik, the ideas are currently spread over several Plasma-related threads.
I see no reason why the idea regarding the toolbox button would be tied to the config mode ideas. From a usability perspective, it could be implemented at any point. Now we just have to convince the Plasma team that it's a good idea.

Disclaimer: I'm usually one of those who argue that the cashew currently is needed, but on my own desktop it's one of the first things I remove.
(Why? Because I like simplicity and minimalism, and the tool box is a distraction that I have no use for. But I can see why it's there by default.)

I've thought of different solutions before but never arrived at one I was happy with. Unfortunately I don't have much time nowadays to contribute much, but here are some comments based on the current posts:

colomar wrote:The idea Andrew and I went with while thinking about the "Plasma config mode" kdeuserk mentioned was to put the toolbox button in the panel as long as there is one, like gregormi suggested here as well, but put it on the desktop as a separate element as soon as the last panel is removed.

This would give the user the life-saver needed to get a panel back if it was accidentally removed (though remember that now we also have the "Plasma undo" feature which allows to easily undo the accidental removal) but would still allow to remove panels.

What if I don't want it in my panel? And which panel would it be in if there are multiple panels - all of them? Only one? If only one - what if you want to "move" the tool box? Where does it end up if I have multiple panels and I delete the one with the tool box?

I had a similar idea and I think it might be better than the current situation, but it still sounds too complicated and inelegant to me.

I've also thought about adding an "auto-hide" option, but this also poses several problems. For example, if you move the tool box, hide it, and then forget where you put it when you want to access it, you would have to hunt around the screen edges to find it. One solution to this would be to not allow the user to move it and remove the "show activity name" feature (it doesn't make much sense nowadays since activity != desktop containment anymore; the current activity name should really be a widgets of its own). Then, if the user hides the tool box, it would always be located in one specific place.

But then, what if you want to put a panel where the tool box is? You don't want the tool box to show up when you want to access something in that panel. Maybe have it only show when you swipe to the right, similar to Windows 8? Again, annoying if you want, say, a panel on the left side.

So in short, the customizability of Plasma makes this pretty tricky! I apologize if I sound overly negative in this post, I just think that many of the proposed solutions I've seen (and that I've thought about) introduce many new problems. Or maybe it's because I'm hungry. Anyway, I would vote for the solution that is a) simple, and b) allows me to keep my whole workspace (including panels) free from tool boxes.

On an unrelated topic, the "Plasma config mode" sounds very promising. I've wanted to see a change in the current lock/unlock widgets workflow for a long time (a normal/edit mode would make more sense to me).

Hans wrote:What if I don't want it in my panel? And which panel would it be in if there are multiple panels - all of them? Only one? If only one - what if you want to "move" the tool box? Where does it end up if I have multiple panels and I delete the one with the tool box?

Hi. The good thing about panels is: they have a context menu (please correct me if there are panels which do not have one or should not have one). So by default there would be one panel and the toolbox icon visible. Choosing to "remove" it would simply mean to hide the icon. The context menu would contain the Plasma toolbox anyway. So with or without the visible icon you access the toolbox via context menu. The "Hide Toolbox" function would be in the context menu, so a user who is capable of hiding the Toolbox should have the knowledge to access it via context menu.

About multiple panels: for example one could say every new panel gets the Toolbox icon by default and then it can be hidden using the context menu as described above. What do you think about that?

gregormi wrote:Hi. The good thing about panels is: they have a context menu (please correct me if there are panels which do not have one or should not have one). So by default there would be one panel and the toolbox icon visible. Choosing to "remove" it would simply mean to hide the icon. The context menu would contain the Plasma toolbox anyway. So with or without the visible icon you access the toolbox via context menu. The "Hide Toolbox" function would be in the context menu, so a user who is capable of hiding the Toolbox should have the knowledge to access it via context menu.

About multiple panels: for example one could say every new panel gets the Toolbox icon by default and then it can be hidden using the context menu as described above. What do you think about that?

Unfortunately this has the same problem as the context menu on the desktop:
1. A bad-behaving widget in the panel could hijack the context menu. You could make sure that there's always one item (e.g. "unhide toolbox") in the context menu, regardless of the widget, but that would a) clutter the menus (think e.g. the task manager - you don't want that option when right-clicking on a task), and b) limit the features of widgets (what if I want right-click do to something else?).
2. It would be considered "hidden". If the context menu were the solution, we could as well just let the user hide the current toolbox and put "show toolbox" in the right-click menu of the desktop. I think one of the reasons for the toolbox was to not hide features in the right-click menus.

Thanks for the detailed explanation. Since you also thought about a different solutions, I am interested what you say about my thoughts below.

Hans wrote:Unfortunately this has the same problem as the context menu on the desktop:
1. A bad-behaving widget in the panel could hijack the context menu.

Hmm. Is such a thing possible? I mean if there is more than one widget on the panel, is it possible for a bad-behaving widget to hijack the context menu of the other widgets, too? Or make them all disappear (possibly crash the panel)?

Just to clear something: are we talking about malicious widgets designed to harm the user or just (fixable) bugs in widgets?

Hans wrote:You could make sure that there's always one item (e.g. "unhide toolbox") in the context menu, regardless of the widget, but that would a) clutter the menus (think e.g. the task manager - you don't want that option when right-clicking on a task), and b) limit the features of widgets (what if I want right-click do to something else?).

You mean similar to the "Unlock widgets" / "Panel options..." context menu item in Plasma 4? What about having a guideline of how the context menu of a nice-playing widget has to be designed: give access to the Plasma Toolbox but with an exception to that rule so that potential features are not limited. Or add the toolbox menu item by default but give widgets (like the taskbar) the possibilty not to show it?

Hans wrote:2. It would be considered "hidden". If the context menu were the solution, we could as well just let the user hide the current toolbox and put "show toolbox" in the right-click menu of the desktop. I think one of the reasons for the toolbox was to not hide features in the right-click menus.

Does the do-not-hide-features-in-right-click rule (which I also support) also apply when the user actively hides this feature using a right-click context menu in the first place? (If it is made in a consistent manner, someone who knows how to hide it should know how to get it back, don't he?)

Hans wrote:What if I don't want it in my panel? And which panel would it be in if there are multiple panels - all of them? Only one? If only one - what if you want to "move" the tool box? Where does it end up if I have multiple panels and I delete the one with the tool box?

Every panel currently already has a "cashew" of its own, which is currently only used to configure that panel. The idea was just to enhance it to configure the workspace in general, not only the panel.
I might have missed something, but I haven't heard many users complain about the panel "cashew". It's the one on the desktop that people usually complain about. Therefore, merely adding functions to the existing panel toolbox should not be a big problem, right?

On an unrelated topic, the "Plasma config mode" sounds very promising. I've wanted to see a change in the current lock/unlock widgets workflow for a long time (a normal/edit mode would make more sense to me).

Nice to hear! This feature currently only exists in the heads of a few people, and we haven't secured buy-in from the Plasma team yet, so it may or may not ever be realized.

gregormi wrote:Hmm. Is such a thing possible? I mean if there is more than one widget on the panel, is it possible for a bad-behaving widget to hijack the context menu of the other widgets, too? Or make them all disappear (possibly crash the panel)?

I don't think a widget can change the context menu of other widgets. However, consider this: what if you have a widget that takes up all available space (like the task manager), and does something different with right click? How are you going to do anything to a panel with such a widget (and nothing else) if you don't have a toolbox?

Just to clear something: are we talking about malicious widgets designed to harm the user or just (fixable) bugs in widgets?

I'm mostly talking about the latter case.

You mean similar to the "Unlock widgets" / "Panel options..." context menu item in Plasma 4? What about having a guideline of how the context menu of a nice-playing widget has to be designed: give access to the Plasma Toolbox but with an exception to that rule so that potential features are not limited. Or add the toolbox menu item by default but give widgets (like the taskbar) the possibilty not to show it?

Yes exactly. As long as you have the option to not show something like "Panel options", you have the possibility of a broken panel that cannot be removed if the user adds a badly behaving widget.

In short, I'm considering the worst-case scenario here. When it comes to software I think many would choose a "better safe than sorry" approach, and I can see why one would not want to take the risk in this case, since the gain seems relatively minuscule in comparison (hiding a small icon on the desktop).

Does the do-not-hide-features-in-right-click rule (which I also support) also apply when the user actively hides this feature using a right-click context menu in the first place? (If it is made in a consistent manner, someone who knows how to hide it should know how to get it back, don't he?)

I think the idea is that the whole "hide things behind context menus" is bad. I don't necessary 100 % agree with this notion, so I can't really explain it well. (I sometimes see e.g. touchscreens being brought up, but I don't really know if it's a valid point or not, so I'm not going to talk about it.)

colomar wrote:I might have missed something, but I haven't heard many users complain about the panel "cashew". It's the one on the desktop that people usually complain about. Therefore, merely adding functions to the existing panel toolbox should not be a big problem, right?

That's because you can easily hide the panel cashew by locking your widgets. Believe me, people were complaining about it when it was introduced.

As a side note, this is what my panel currently looks like. If you want to force the panel toolbox to always be visible you can be sure that I will complain.
Ok, my setup may be a bit exotic, but you can also think about e.g. people who use their panel as a dock - they probably don't want a toolbox in their panels that they can't remove.

Hans wrote:In short, I'm considering the worst-case scenario here. When it comes to software I think many would choose a "better safe than sorry" approach, and I can see why one would not want to take the risk in this case, since the gain seems relatively minuscule in comparison (hiding a small icon on the desktop).

Yes, I agree, any proposal should consider the worst-case sceanrio.

Hans wrote:I don't think a widget can change the context menu of other widgets. However, consider this: what if you have a widget that takes up all available space (like the task manager), and does something different with right click? How are you going to do anything to a panel with such a widget (and nothing else) if you don't have a toolbox?
[...]
As a side note, this is what my panel currently looks like. If you want to force the panel toolbox to always be visible you can be sure that I will complain.
Ok, my setup may be a bit exotic, but you can also think about e.g. people who use their panel as a dock - they probably don't want a toolbox in their panels that they can't remove.

Thanks for the explanation. I see now better (together with your screenshot) that my earlier proposals are a bit short-sighted.

To have a solid basis for new ideas I think it would be good to have the "worst-case scenarios" described more in detail and all in one place (instead of spread in different forum answers). (Also @colomar and @kdeuserk) Is there maybe already something written in some wiki page about the topic? Due to the different configuration possiblities it would be nice to have some central place where this is documented. Anyway, I try to summarize the things that came up in the discussion up to now:

Configurable / variable elements on the desktop:

• 1..n desktops (I assume there is at least one desktop and there are several desktops in a multiscreen scenario)
  
  • The desktop widget
  • The desktop widget's context menu
  • The desktop's movable Plasma Toolbox
• 0..n panels
• On a panel:
  
  • 0..n widgets
  • Widgets don't take all the panel space: The panel's context menu
  • Widgets take all the panel space: each widget's context menu
  • The panel's Plasma Toolbox

Situation that can happen in which the Plasma-Toolbox must still be accessible:
Assumptions:

• A bad-behaving widget does not show the Plasma Toolbox menu item in its context menu
• Hiding things behind context menus is generally considered bad but context menus still have a right to exist because they avoid visual clutter in some cases

Base situation for worst-case scenarios:

• By default there is 1 panel with a visible Plasma Toolbox
• The Plasma Toolbox is currently hidden from the desktop because it is visible in the panel (as suggested by colomar et al above)
• User chose to hide the Plasma Toolbox from the desktop and from any panel because he/she does not want to see it by default
• 1 desktop with a bad-behaving desktop widget (can desktop widgets bad-behave at all?)

Possible worst-case scenarios:

• 0 panels
• 1 panel with 0 widgets (are there also bad-behaving panels?)
• 1 panel with 1..n bad-behaving widget that takes up all the space
• 1 panel with 1..n bad-behaving widget that takes up all the space because they squeeze the other widgets to to zero length (is this possible?)

So with the current worst-case scenrios I understand why there _should not_ be an obvious way for the casual user (including context menu) to hide the desktop Plasma Toolbox.

The following suggestion
a) wants to enable the casual user to remove the Plasma Toolbox from the desktop and panel(s) without sacrificing the ability to restore panels etc. in case of a worst-case scenario
b) enhances colomar's and kdeuserk's idea of showing the Plasma Toolbox in the panel by default and if it is hidden from there showing it on the desktop by considering possible worst-case scenarios

Suggestion:

• The user gets the ability to hide the Plasma Toolbox using a context menu.
• Plasma keeps track of Plasma Toolbox context menu items registered by any desktop or panel widget. Plasma could then detect worst-case scenarios (where no widget context menu has got a Plasma Toolbox item) and react by adding the Plasma Toolbox to all widget context menu anyway.
• => By default nothing changes: the user gets a good visible Plasma Toolbox but when he/she chooses to hide it there will always be a context menu item to access it or get it back.