Hi Triplus,
in the German Freecad forum section I started a thread on how to improve the look from Freecad, with desktop background-, sketcher elements colors and so on.
I created a video in German language to explain how to change the settings: https://peertube.mastodon.host/videos/watch/5bfdb2d1-5ae2-4e49-b712-0088788e5133
As you can see, my customized icon menu bar is full with helpful and most needed icons, so I think about to impove it using the piemenu.
Do you have a demo video to show how to set the piemenu and to show how nice and helpful it can be, and maybe speedup the work?
Sorry, my English is so lala.
I plan to add documentation once i will consider the work to be finished. I occasionally add Use Cases describing on how something can be achieved. Try to follow one. This one for example describes on how to enable context sensitivity. And to auto show PieMenu based on the selection in the 3D view:
P.S. Note that the PieMenu version currently in development will likely have similar preferences as seen in the command panel. Therefore things will change a bit.
OK CommandPanel back-end is more or less done. Will start releasing the work done in near future. As for the PieMenu. Before i port the CommandPanel back-end i feel that best if PieMenu front-end gets done. Therefore in near future this process will start.
And now for the first question. Some of you likely used PieMenu in the past and have some understanding of what is missing (for you). Or maybe something should be removed as it isn’t used at all. If you compare that to the development plan above. Is there something else worth mentioning not already listed? Now is the time to express that as development plan can still adapt slightly.
Will read your feedback and will respond likely next weekend. Therefore there is roughly a full week available to provide feedback. That is if there is any (going beyond the development plan list above).
After this gets settled PieMenu front-end development phase will start and we can get more specific at proposed solutions. As for the development plan above. More or less everything is already in at least prototype condition. Most of it is in release condition and just needs some additional QA.
default button from ‘Tab’ to ‘Q’ as in the previous thread
as an old request,
it would be nice to force place Pie Menu in an area in which all the Pie would be fully visible (i.e. if your mouse would be in a lateral area, force Pie Menu to be slightly moved to be fully displayed)
– EDIT:
an option to add a menu to RMB to have Pie Menu entry in the context menu
–
I said i will respond at the end of next week. But as you provided such comprehensive feedback a short reply is in order:
1.) Will happen (as a part of development plan).
2.) Yes. Multiple users asked in the past and i listened. Originally not a part of the development plan. But i have developed such functionality.
3.) As for the RMB. As a part of the development plan investigation on how to invoke the PieMenu with mouse is listed. Over time i somehow started to feel providing such option would interfere with context menu. Therefore i don’t know if this will happen. Didn’t decide on this 100% yet but likely it will not happen. As for having a PieMenu entry in the context menu. To be honest i am not all that sure that makes much sense? Keyboard shortcut to invoke PieMenu will likely be it. Especially as you will be able to define a keyboard shortcut for each command once invoked. And therefore PieMenu is in the end somehow geared towards the keyboard usage.
First thanks for the provided feedback. What was discussed was included in the development plan as mentioned. I went over everything else again. Some of you convinced me in the past to include another feature (not currently listed in the development plan):
That is the button style should be configurable. Did bring some additional geometry issues to resolve but i guess it is worth to pursue this goal.
As for the developer expectations and some discussions in the past. I am leaning towards the idea of having a single instance running and for workbench developers to provide definitions and to define the behavior through API (dictionary). Compared to developers creating instances and to work with that by using the instance methods. As with instances each developer needs to think about things like setting the invoke shortcut. Preferences (if the user should be able to customize the (individual instance / workbench) pie menu experience) should therefore ideally be made available for each instance. As “Subsequential PieMenu button” will be able to invoke another pie menu. I feel that the need to have multiple pie menus defined is less important. Any further opinions on this aspect?
Hi @triplus
Thanks for all your work on this feature. This is very exciting. So, I’m not sure this is covered, I haven’t read all the auxiliary threads of this thread and I may have missed it in this thread all together… Is it possible that PieMenu can automagically/intuitevly populate itself based on the toolbar that one is currently utilizing? For example if one is constraining their sketch the way it seems to go is the ole’ back and forth between the sketch and the constraint toolbar:
clicking on a point or line; perhaps clicking another point line; perhaps repeating that… and then moving the mouse pointer to the toolbar clicking the constraint. Then repeating again etc…
So Instead of this back and forth mentioned above does pie menu have a way to shorten the distance between the constraint buttons and the sketch itself?
First of all the strategy to develop PieMenu and Command Panel in parallel (again) turned out to be a bad strategy. Instead doubling the performance the overall day-to-day work done has reduced. Therefore in the next week or two i will try to finish Command Panel altogether. And after move to PieMenu development completely.
You’re welcome.
Is it possible that PieMenu can automagically/intuitevly populate itself based on the toolbar that one is currently utilizing? For example if one is constraining their sketch the way it seems to go is the ole’ back and forth between the sketch and the constraint toolbar:
clicking on a point or line; perhaps clicking another point line; perhaps repeating that… and then moving the mouse pointer to the toolbar clicking the constraint. Then repeating again etc…
So Instead of this back and forth mentioned above does pie menu have a way to shorten the distance between the constraint buttons and the sketch itself?
PieMenu does bring commands closer to mouse cursor and therefore the expected mouse distance to travel is less. Setting trigger mode to Hover saves you an additional click needed. Proximity trigger mode will further be able to reduce the mouse distance traveled and in combination with subsequential buttons it will likely enable the end users to perform “gesture alike” operations. Therefore doing some operation by “flying blind”. In addition context sensitivity can be set and used to invoke PieMenu based on the selection in the 3D View:
If in some use case end user needs to perform some task repetitively. PieMenu can be invoked automatically by for example selecting two vertices in the 3D View.
@triplus here is an example of what I mean. Maybe you can demonstrate PieMenu to me in this context:
In the beginning of the clip till the end @Willem navigates several times to the following toolbars: Sketcher Geometries and Sketcher Constraints
How would he use PieMenu to make his workflow more effective ?
PieMenu is a launcher for commands. The same as toolbars, command panel, Launcher … Each has its pros and cons and is more or less suitable for some specific use case. As for PieMenu i plan to add more detailed documentation once the coding related work will be done. For now and as for your question. What you can do is to first install PieMenu. After go in Sketcher edit mode and in PieMenu QuickMenu select one of the toolbars:
For example Sketcher geometries. This should be the quickest way to start creating sketcher geometry with PieMenu. After i guess try it out and see how it goes.
Likely command panel will be fully released before November. And after PieMenu will become the main focus. I tried to work on both of them in parallel. In the past few weeks. But the overall result was less. Therefore in this finalizing stages it is best if i work on one at a time.
Turning toolbar in PieMenu is just a convenience feature (to get quick results). Not much that can be done here if the toolbar has large amount of commands. I will close the issue report once some of the (seemingly) related tasks from the development plan get done.
Invoking PieMenu in a certain condition displays 2 PieMenus glitch
What about putting any overflow in to a 2nd and 3rd row?
Invoking PieMenu in a certain condition displays 2 PieMenus glitch
thanks!
Have you ever used Krita’s pop-up palette ? It has this feature that you can tag certain brushes and then you can invoke them while the dialog is open. This might be a good way to shortcut opening custom toolbars quickly with less clicks? Should I open a feature request ? https://docs.krita.org/fr/user_manual/getting_started/navigation.html#pop-up-palette
In early days of PieMenu development this was discussed and it was established end users don’t want this. If you want more commands in some invokable container and support for things like rows. Try out command panel. It already support the invoke option (and it will improve in the future). Basically you can have a whole lot of commands in it. And things are still manageable. In PieMenu single row and around 8 commands for individual PieMenu is optimal and desired.
Have you ever used Krita’s pop-up palette ? It has this feature that you can tag certain brushes and then you can invoke them while the dialog is open. This might be a good way to shortcut opening custom toolbars quickly with less clicks? Should I open a feature request ?
No. I don’t plan to implement something like that. If you look at the development plan the subsequential button is what was established it is currently missing. And therefore i will add that. Anyway you are asking a lot of question already discussed in the other thread in the past. Nothing wrong with that but at this point i don’t feel spending much time on such discussions again is worth it. If you are interested on what already happened read the previous thread. As for the future it makes more sense to provide feedback when something from the development plan gets released.
P.S. In short if when using toolbar as a source is producing too much buttons. Open the Preferences and define some custom PieMenus with less buttons. And use them instead. Note that once workbench developers will be able to define such PieMenus up front (part of the development plan). End users shouldn’t need to use the Toolbar option as a source to get quick results anymore. As defaults should do. And if defaults won’t do as said customize as much as you like. That already is possible.
I see. Wasn’t aware of that discussion. Thanks for explaining.
Yea, I see. What I’m seeking is features that are spread across 3 different utilities that you’ve graciously created. I’m still trying to get it straight and organized in my head where it seems like for you it is all very clear. Thank you again for you time.
Basically documentation is missing. And therefore for now new end users can look for clues in what was already discussed. And i guess by trying it out and to see how it goes. For you therefore the next step is to try and figure it out on how to build and use a custom PieMenu.
P.S. Documentation will be made (after the coding related work will be done).
