Pie Menu

[microelly2]

why 8:
you can distinguish 8 main directions N NE, E ,SE, S, ....
this works too for a touch screen gesture
a real 12 part pie is harder to click

and the numpad 89632147 is easy to control by the finger of one hand without extra move.
and you have the possibility to build up to 4 pairs of inverse operations

[looo]

maybe also interesting for the future: http://doc.qt.io/qt-5/qml-qtquick-extras-piemenu.html

[triplus]

why 8:
you can distinguish 8 main directions N NE, E ,SE, S, ....
this works too for a touch screen gesture
a real 12 part pie is harder to click

and the numpad 89632147 is easy to control by the finger of one hand without extra move.
and you have the possibility to build up to 4 pairs of inverse operations

I see. I'll keep that in mind when testing things out. But i don't plan to introduce 8 tool limit for now. Therefore maybe if it will make sense and if it will be doable to provide additional possibilities when 8 or less tools are defined.

maybe also interesting for the future: http://doc.qt.io/qt-5/qml-qtquick-extras-piemenu.html

Yes i read about that in the past but i guess that is always one possibility left for the future. To use built in menu support instead of making one manually. But in the end that is only one part of it. Everything else that makes good Pie Menu has to be made separately anyway.

[pablogil]

A very important decision to limit the pies to 8 commands is that once you push the pie key you have a small amount of time to move quickly to the direction you want (N, W, E, S, NW, ...) and the command is quickly accepted if you moved more than x pixel in the chosen direction. It's called "threshold confirm" and it's awesome, so, it's not necessary to press the pie key to open the pie and the select the button with your mouse but just press the key and move to the desired direction... crazy fast. Filling the pie with more than 8 commands would make hard to hit the desired direction.

Please, check a video that explain all the potential of Blender pies and you will get the whole idea of its philosophy, it does worth it.

[triplus]

Thanks for all the input. Now i see it was important to ask for user opinion as it helped me narrow down some things. What will happen next is i guess a lot of testing and prototyping. I am not against any idea and will try to achieve the suggested ones in some way if possible. If not i will do whatever comes next on the list and it's doable.

As for the 8 tool limit the decision will likely be left to the end user. As i do feel some users would like to have for example all sketcher geometries or constraints tools in the same menu. 8 tool limit would prevent that. And i am not yet sure if i will go down the path of having "Top Level" Pie that does nothing more than opens up Sub Pies. Likely there will be a Pie and additional menu to select different one.

Anyway will report back when i have something or need more feedback. And likely i won't try to solve everything in the first release phase as that would probably push the first release phase in the distant future.

[triplus]

I went over the existing code base from @looo and @microelly2 and i feel prototypes for initial release phase are prepared. There are a lot of big and small challenges left to get this into release material therefore it will still take some time to get there.

@looo your code base is feature-rich and a lot of ideas are implemented in such way it made my work easier as i could reuse it in some way. The main difference or path i will follow is to go i guess a bit more "low level". That is to reuse existing "widgets" in FreeCAD and add Pie menu to them directly.

I guess one of the biggest challenges to be resolve are repaint events (3D View). I probably won't solve this issue in first release phase.

@microelly2

I probably won't be able to reuse much of the code base directly but the ideas and approaches still represented a valuable source of information. For initial release i will probably use concept similar to the one you used but from code perspective more close to the one found here:

http://www.freecadweb.org/wiki/index.ph ... e_snippets

It's for example quite straightforward task to add selection observer and after show Pie menu if user selects something in 3D View. This approach will be used for the first release.

[triplus]

I got PM regarding first release of PieMenu therefore i decided to share status update here too:

• I feel i implemented simple and light weight logic for setting up context sensitivity.
• I want to add control panel first before releasing the current code as doing it like that it will enable the end users to start doing something useful with PieMenu after first release.

This things will take a bit more time to be finished.

There is one thing left i am not sure i will resolve for first release. That is menu buttons will likely be squares instead of circles. The reason for that is i need to understand repainting of buttons first to make it perfect and i am not sure how much time will it take me to do that once i get to it. On the plus side there will be support for style sheets in the first release.

About interaction. I implemented 3 modes:

• Button press
• Button hover
• Proximity hover

To trigger the button. I decided i will add support only for first 2 modes in first release and seek for more feedback. As proximity hover complicates things in a lot of areas.

Maybe one question on how other users see it. Should PieMenu support buttons with menu or not? That is one possibility will be to turn QToolButtons from Toolbar in PieMenu buttons with ease. Some QToolButtons like for example in Sketcher WB have a menu and in it sketcher geometry of different types.

Now the question is should this be presented as menu button in PieMenu or should the tools from the menu be expanded (one tool -> one button)?

[looo]

There is one thing left i am not sure i will resolve for first release. That is menu buttons will likely be squares instead of circles. The reason for that is i need to understand repainting of buttons first to make it perfect and i am not sure how much time will it take me to do that once i get to it. On the plus side there will be support for style sheets in the first release.

As I understand you use buttons as menu entries? So you are subclassing a QButton for this?
I also tried many different ways. For me implementing the Menu as a QGraphicsView worked best. But this is for sure not the proper way. The best solution would be to subclass a std. QtQMenu and reimplement the painting?

Maybe we should have a look at how they have implemented the pie-menu in the qt-quick-extras package,
https://github.com/qtproject/qtquickcon ... nuIcon.qml,
https://github.com/qtproject/qtquickcon ... Helper.qml...

About interaction. I implemented 3 modes:

Button press
Button hover
Proximity hover


To trigger the button. I decided i will add support only for first 2 modes in first release and seek for more feedback. As proximity hover complicates things in a lot of areas.

I think this is a good plan. My menu had problems with the hoover selection. One problem was, that the center of the mouse pointer not always was at the center of the menu. (eg when you open the menu and the mouse in at the boarder of the screen)

Would it be possible to see your code for the pie menu?

Now the question is should this be presented as menu button in PieMenu or should the tools from the menu be expanded (one tool -> one button)?

have you tried the blender pie menu already?
I wouldn't nest the buttons. The main advantage of the pie-menu is the fast access to commands... For me the pie-menu is an extension to the short-cut system. If we have every action in a workbench connected with a key it's difficult to remember the keys. But if there are 3 keys connected with pie-menus remembering the keys will be easy. After some time also some direction will be remembered and the interaction will be as fast as key-only shortcuts. So the best interaction (imo) should be:
blender style: key_hold + direction + key_release (but this is difficult to implement in qt as key_hold is not relieable, maybe this is a problem with freecad)
key_press + QtTimer (which triggers if mouse has moved direction) else +mousebutton press (should be possible)

[microelly2]

I wouldn't nest the buttons. The main advantage of the pie-menu is the fast access to commands... For me the pie-menu is an extension to the short-cut system. If we have every action in a workbench connected with a key it's difficult to remember the keys. But if there are 3 keys connected with pie-menus remembering the keys will be easy. After some time also some direction will be remembered and the interaction will be as fast as key-only shortcuts. So the best interaction (imo) should be:
blender style: key_hold + direction + key_release (but this is difficult to implement in qt as key_hold is not relieable, maybe this is a problem with freecad)
key_press + QtTimer (which triggers if mouse has moved direction) else +mousebutton press (should be possible)

yes - the mouse in one hand and the other hand fingers on the keyboard

[pablogil]

I totally agree with looo, Blender pies are really good, they are the best reference to follow.

They don't nest buttons, dropdown, etc inside a pie, they just act as shortcut to other pie, list, dropdown or whatever, meaning that when you press a pie button it disappears and shows the following