File manager context menus

Frank Reininghaus frank78ac at googlemail.com
Sun Aug 17 22:02:24 BST 2014


Hi,

thanks David for this initiative! More code sharing between file
management applications is indeed a nice goal!

2014-08-17 19:26 GMT+02:00 Emmanuel Pescosta:
>
> > 3) A popupmenu implementation moves to KIO, made of the best stuff from
> > dolphin and konqueror.
>
> +1 from my side!

+1 from me too.

> I have made two patches related to context menus (https://git.reviewboard.kde.org/r/115678/ and https://git.reviewboard.kde.org/r/115679/) some time ago, to make the DolpinContextMenu more independent, so that it can be reused in multiple places within Dolphin.

Yes, if we can remove code duplication by sharing the context menu
with others, I agree that using this shared menu also in other places,
like the Folders Panel, is worth considering :-)

> > enum ContextElements
> > ContextMenu(ContextElements::CUT | ContextElements::COPY | ContextElements::PASTE | ...)

Sorry, but this looks like YAGNI material to me [1]. If I'm not
mistaken, there is no use case for a file manager context menu which
does not have these actions, or am I missing something? And even if
the shared menu would be used in places where, e.g., the
cut/copy/paste actions are unwanted (maybe if we wanted to use that
menu also in the file dialog?), then the correct solution from my
point of view would be to add a "showEditActions" property which
defaults to true, and not to add lots of code that makes it possible
to enable/disable each individual action, unless we have a use case
which really needs something like that.

If the vast majority of the actions is the same in all current context
menus except for the order, then let's just find a good order that is
used everywhere, and add a function that permits to easily add the few
custom actions that the different mensus currently have.

> I think the "context" based approach to add the right actions, which is currently used in Dolphin's context menu, makes sense here and we should keep it, because we can easily provide default menus for specific contexts like trash, folder/file, viewport ... and if special contexts are needed, then they can be added really easily. So different users of the menu (Dolphin, folderview, ...) will have the same default items in the same order.

Yes, I agree. The new class should create the default actions based on
the URL where the menu is opened.

Considering QML compatibility is also important, of course. I'm not
really familiar with QML myself, but if supporting it properly is as
easy as adding overloaded functions for QWidget and QWindow, as Eike
says, then it should be done.

Cheers,
Frank

[1] http://en.wikipedia.org/wiki/YAGNI




More information about the kfm-devel mailing list