This is a minor issue, but sometimes it drives me nuts that I cannot pin kickoff or the widget explorer.
Suppose you place a widget on the desktop, but you do not like it, so you press the remove button in the plasmoid. Doing that the widget explorer will disappear and you will have to reopen it and scroll down the list again, something that I find very annoying.
The same is true for kickoff: Open an application, kickoff will close. What if you want to open multiple applications at once? You have to reopen kickoff after that and navigate through all the menus again.
I think those specific applets really need a pin button.
Apart from that, this would add a bit of consistency.

Do you agree? I mean it can't hurt right?

kdeuserk wrote:Do you agree?

I do. Consistency is always good, and the use-cases are valid IMHO. Plasmoids that consists of an icon only, would need to get an overhaul.

The bug report can be found here: https://bugs.kde.org/show_bug.cgi?id=338347

kdeuserk wrote:The bug report can be found here: https://bugs.kde.org/show_bug.cgi?id=338347

I'd really recommend filing individual bugs. Such a broad bug will never see any action on it.

colomar, yeah I guess it would be better to do so, because my report is already marked wontfix as david edmundson is of the opinion it does not make sense for kickoff.
Which components should I file it against? I think widget explorer is a must.

kdeuserk wrote:colomar, yeah I guess it would be better to do so, because my report is already marked wontfix as david edmundson is of the opinion it does not make sense for kickoff.

David and I just calculated that if one only compares the number of clicks (and assuming that you don't want to keep Kickoff pinned after starting multiple applications), pinning would only save you clicks if you started at least four applications consecutively. That indeed sounds like quite an edge case.

Which components should I file it against? I think widget explorer is a must.

Widget explorer definitely, yes. Once we have it there, I'd put in the Activity switcher (the one that's opened when clicking the Plasmoid or the menu, not the one activated by a shortcut) as well for consistency reasons, given that their UIs are very similar.

Not sure about network management. Could be useful for when diagnosing network problems, but that's rather rare.
In most other cases, I'd say if someone want so see a Plasmoid permanently, it makes more sense to put in on the desktop instead of in the panel.

colomar wrote:Not sure about network management. Could be useful for when diagnosing network problems, but that's rather rare.
In most other cases, I'd say if someone want so see a Plasmoid permanently, it makes more sense to put in on the desktop instead of in the panel.

I find that inconsistency pretty irrational. Note though that placing on the desktop makes only sense if you do not have windows open, because always invoking dashboard (which for some strange reason does not allow interaction with the panels) is just uncomfortable in it's current form.

As I wrote in the bug report, counting clicks is a very limited argument (cursor movement is not taken into consideration, (and the plasma 5 menu can get quite big on some configurations), as well as navigating in kickoff itself.)

But I can live with the inconsistencies and you may be right about the corner case argument.

New bug report: https://bugs.kde.org/show_bug.cgi?id=338415

kdeuserk wrote:As I wrote in the bug report, counting clicks is a very limited argument (cursor movement is not taken into consideration, (and the plasma 5 menu can get quite big on some configurations), as well as navigating in kickoff itself.)

True, but if the applications one wants to start reside in different categories, navigating between them makes up more of the cursor movement than moving to the start button.