Bug 488086

Summary:	The UX for enabling plugins is very unintuitive
Product:	[Applications] dolphin	Reporter:	hazelnot <hazelnot>
Component:	general	Assignee:	Dolphin Bug Assignee <dolphin-bugs-null>
Status:	CONFIRMED ---
Severity:	normal	CC:	felixernst, kfm-devel
Priority:	NOR
Version:	24.05.0
Target Milestone:	---
Platform:	Other
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description hazelnot 2024-06-05 17:16:12 UTC

SUMMARY

I'm aware this is not a bug in the technical sense of the word, but this is where I've been told to file a report. Apologies if this isn't the right place for UI and UX feedback/issues.

The UX for enabling plugins in Dolphin is very unintuitive. It used to be located under a "Services" header in the Configure window, but was moved to "Context Menu". This is not a problem when using plugins that just show up under the context menu, but some plugins have additional functionality.

For example, I was confused as to how to enable the Dropbox plugin. To me, the main functionality is displaying the sync status of files and folders with Dropbox, but I never use the context menu items it also adds. I had to ask for help in order to confirm that all the plugins have in fact been moved under the "Context Menu" header.

I would suggest either renaming "Context Menu" to "Plugins" (or revert it to "Services" as it used to be known, or think of a better name than either suggestion), or splitting it into two headers - one specifically handling plugins, and one for handling the context menu entries.

SOFTWARE/OS VERSIONS
Linux: Endeavour OS (rolling)
KDE Plasma Version: 6.0.5
KDE Frameworks Version: 6.2.0 
Qt Version: 6.7.1

Comment 1 Felix Ernst 2024-06-20 16:21:31 UTC

I agree with the basic issue raised in this bug report. We did have a discussion about this in https://invent.kde.org/system/dolphin/-/merge_requests/422 before but didn't find a solution that everyone was happy with.

>I would suggest either renaming "Context Menu" to "Plugins"
>(or revert it to "Services" as it used to be known, or think of a
>better name than either suggestion), or splitting it into two headers
>- one specifically handling plugins, and one for handling the context menu entries.

It's IMO difficult to find a good solution here. "Context menu" as a title has the advantage that it can be understood by many users. "Services" or "Plugins" is a bit abstract perhaps. It is also difficult to split it into two disparate groups because – as you pointed out – some plugins provide both changes to the general view as well as adding context menu actions.

My idea before was to name it "Extensions" perhaps, though this doesn't really make it clear that users should navigate here if they want to hide some action from their context menu.

I haven't seen a solution to this yet which seems great. I'll mark this as confirmed for now. It is definitely not ideal as it is.