[DolphinContextMenu] Fix excluding ourself from Open With menu
ClosedPublic

Authored by broulik on Mar 21 2018, 8:24 AM.

Details

Summary

The desktop file name changed to org.kde.dolphin a long time ago. To avoid this breaking again, just use qApp->desktopFileName()

BUG: 391997

Test Plan

Right clicked a folder in Dolphin, only offered to open in Gwenview now

Diff Detail

Repository
R318 Dolphin
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
broulik requested review of this revision.Mar 21 2018, 8:24 AM
broulik created this revision.

This works and is definitely more programmatically sane, but has the side effect of making the Open With menu empty so it has no sub-menu, which looks a bit odd, especially given that there's an Open with Gwenview item right above it:

That is by design in KFileItemActions and would need to be changed there, not sure we should, though. But that is unrelated to this fix which clearly fixes a bug.

ngraham accepted this revision.Mar 21 2018, 2:27 PM

Yes, but it causes another bug (or at least an odd behavior): without the patch, the Open With menu has two items: Dolphin and Gwenview. With it, Gwenview becomes its own top-level menu item and Open With... becomes ellipsized and only opens the open with panel.

Still, you're right that this patch fixes a bug, and the new issue should be fixed elsewhere.

This revision is now accepted and ready to land.Mar 21 2018, 2:27 PM

That is by design in KFileItemActions and would need to be changed there, not sure we should, though. But that is unrelated to this fix which clearly fixes a bug.

I've got some ideas for ways to improve the usability here and may submit some patches today or tomorrow. This can land, thanks again!

This revision was automatically updated to reflect the committed changes.
rkflx added a subscriber: rkflx.Mar 21 2018, 10:49 PM

That is by design in KFileItemActions and would need to be changed there, not sure we should, though. But that is unrelated to this fix which clearly fixes a bug.

I've got some ideas for ways to improve the usability here and may submit some patches today or tomorrow. This can land, thanks again!

@ngraham Are you sure there's a bug? It's always been this way (← bad reason), and it makes sense: If the list is too long there will be a submenu, and for only a few items the submenu is overkill and a flattened list is easier (← good reason ;)

Nevertheless, I'm curious about your idea (as long as it won't result in another KMoreTools-style UI).

That is by design in KFileItemActions and would need to be changed there, not sure we should, though. But that is unrelated to this fix which clearly fixes a bug.

I've got some ideas for ways to improve the usability here and may submit some patches today or tomorrow. This can land, thanks again!

@ngraham Are you sure there's a bug? It's always been this way (← bad reason), and it makes sense: If the list is too long there will be a submenu, and for only a few items the submenu is overkill and a flattened list is easier (← good reason ;)

Nevertheless, I'm curious about your idea (as long as it won't result in another KMoreTools-style UI).

Oh no, not at all. I'm still mulling it over, but I'll have a patch available soon enough for critique and discussion.

Nevertheless, I'm curious about your idea (as long as it won't result in another KMoreTools-style UI).

Oh no, not at all. I'm still mulling it over, but I'll have a patch available soon enough for critique and discussion.

D11569: Improve consistency of "Open With" UI by always showing top app inline