Contextual menu rearrangement

[pgilfernandez]

Maybe it's because I'm still new with Friction but I find the contextual menu (secondary button menu) a little bit messy, I mean, not all options available and ordered and some "hidden" under "actions"...
What would you think to make it simpler and listed as follows?:

Arranging on top the most common or used commands makes it easier to find and use them.

The only thing that I don't know if could be done is turning the all effects types checkable and at the same time be able to open a secondary menu with their child available effects.

I would even suggest that the last 6 "effects" items loose the word "Effect" and add a title called "Effect" on top of their "group"... This way is would be simpler and easier to "scrub" with your eyes as simpler words are easier to find.

It's just an idea, what do you think?

[rodlie]

The context menu is not the best regarding UX and could be improved, but there is also a reason things are the way they are.

The "Actions" menu is the main menu, every "box" (in Friction every item in a project is a box) includes this, and it's own actions (that differs from box to box). Adding duplicates from "Actions" is IMHO a bad thing, we now have duplication of code etc. I have made exceptions in the past to include some "common" actions in the box menu, but it's still code duplication and I don't like it.

A menu refactor is probably the best option, but this will take time away from other things (features/fixes).

[pgilfernandez]

I understand, I only had the UX perspective and didn't know if it was easy/difficult/impossible to do and, more important, if it worth it or if it had sense...

[rodlie]

I'm all for fixing this, but we need to figure out how we are going to visualize it, I can override the QMenu and paint whatever.

[pgilfernandez]

I'll have a deeper look at the code you shared but I'm not very good at C++... I feel more comfortable on the graphics/design side 😅

[rodlie]

The code is not that important. When the user right-click we must show a QMenu, that QMenu has the actions associated with the current box first, then various other actions are added under, sometimes in submenus.

We could then try to figure out how we are going to visualize this, suggestions are welcome.

We also don't need to show a QMenu, could be a custom widget that does something with the menus we have.

Also see #169

[pgilfernandez]

OK, I'll have a look at it and try to suggest something doable