Title: Command item editor: “Undo Flag” toggle is shown as an unlabeled blue square
Versions
Broken: Pie Menu Editor 2.1.0-beta.8, Blender 5.2.2
Looked right: Pie Menu Editor v1, Blender 3.6
Description
When editing a Command item (e.g. bpy.ops.wm.tool_set_by_id(name='builtin.poly_build')), the Undo Flag toggle next to the operator call mode dropdown (“Invoke (Default)”) is drawn as a small blue square with no label.
In PME v1 the same toggle took half the row and was labelled “Undo Flag”, so it was clear what it does and whether it was on. In v2 the square gives no hint of its purpose: you only find out by hovering it, and it is easy to miss or click by accident.
Steps to reproduce
Open a pie or menu in Pie Menu Editor and edit an item of type Command.
Enter an operator call, e.g. bpy.ops.wm.tool_set_by_id(name='builtin.poly_build').
Look at the row with “Set Tool by Name Operator: Invoke (Default)”.
Expected: a labelled “Undo Flag” toggle, as in v1. Actual: an unlabeled blue square at the right end of the row.
Screenshots: v2 on Blender 5.2 (first) and v1 on Blender 3.6 (second).
Is it possible to assign two different hotkeys to the same PME menu or item?
My use case: I switch between two setups at the same desk.
Wacom display tablet + pen: the shortcut should sit on a pen or tablet button (mapped in the Wacom driver to a key or mouse button).
Keyboard + mouse: the same menu on a normal keyboard shortcut.
Right now each menu or item has one hotkey, so I would have to duplicate the whole menu and keep two copies in sync. Is there a way to add a second hotkey that calls the same menu? If not, would you consider supporting multiple hotkeys per menu or item?
Thanks for the report! Yes, you’re right.
I’ll tidy up these small UI issues before the next release.
Multiple hotkeys is an idea I hadn’t considered, and it’s technically possible. My preference is to keep the basic setup as simple as possible, so this would likely be an opt-in feature.
I’m planning improvements to make hotkey conflicts easier to spot, so I’ll look into adding support for multiple hotkeys alongside that work.
Thanks for the feedback! Please let me know if you notice anything else!
Hi @Pluglug,
I’m an existing Gumroad customer of Pie Menu Editor 1.18.8. I originally purchased it on August 24, 2020, so quite a long time ago.
I’m trying to migrate to PME 2.1, but the setup page requires a Gumroad license key. My purchase is visible in my Gumroad Library, I can view and resend the receipt, and I also used Gumroad’s purchase/license lookup successfully, but no license key is shown anywhere.
Since the purchase is from 2020, I’m wondering if the license-key system may not have existed yet for older purchases.
Could you please tell me how I can get access to PME 2.1 with this existing purchase?
I can provide the receipt or purchase details privately if needed.
Thanks!
MichaelColina
(The "Mr. Polygon Punisher" is your)
6095
Hello. Nope you need to afford this fork version for a new license this time with support and updates, unlike the old original PME in which unfortunately is no longer (as of now) in development by original dev. Therefore, it means you can’t transfer the original product’s license into the new fork license, as this would be complicated.
And i should reiterate for future and existing old PME users that want to update PME for newer blender versions: $36 is not a lot for acquiring the same original addon but now improved and supported further, and it helps the current volunteer developer to keep active development on this fork.
It covers the Context Browser, which I’ve wanted to explain for quite a while. PME 2.1 users can access the update right away. There is still a little work left to do, so the free release will come a bit later.
As for development progress, the GPU drawing work still refuses to end.
If the GPULayout implementation in 2.0 was around 30/100, I’d say it’s now roughly 60/100. It will probably never truly be finished.
So I’m planning to draw a line under PME 2.1 within the next few days and move on.
I’m currently working on some performance issues.
This is a test where I’m drawing P2D’s Rig UI as-is.
You can add it through Interactive Panels. I’ve put together a video showing the steps.
You can use it just like a Popup Dialog. The basic functionality is complete, but it’s still marked as Unsupported because some commonly requested widgets, such as UIList, aren’t supported yet.
Performance optimizations are planned for around version 2.2.
Yeah, I understand. Give it a try whenever you have some time and feel up to it. Once you set it up, future updates should be much easier to receive.
It really isn’t that difficult, but honestly, if someone told me I had to read through the current documentation, I might want to run away too. I’ll make a video tutorial for the migration soon.
Also, if you happen to watch the video I recently posted, please let me know if any part of the explanation was unclear or awkward. I’m still not very confident about making tutorials.
Hotkey Mode “Click Drag” creates a Press keymap item instead of Blender’s native Click Drag
PME Fork 2.1.0, Blender 5.2.2, Windows 11.
When I set an item’s Hotkey Mode to Click Drag, the keymap item PME adds to Blender (`wm.pme_user_pie_menu_call`, visible in Preferences > Keymap) gets the event value Press (direction Any), not Click Drag. This happens for every Click Drag item I have, whether the key is a mouse button or a keyboard key. Double Click is handled the native way: those items get Blender’s own Double Click value. (Internally the mode is still stored as `TWEAK`; Blender replaced tweak events with the Click Drag value in 3.2.)
Steps to reproduce:
Create an item, set its Hotkey Mode to Click Drag and assign a key.
Open Preferences > Keymap and find the item (`wm.pme_user_pie_menu_call`). Its event value is Press.
Questions:
Is the Press value intentional, with PME detecting the drag on its own?
How do I set the drag direction for a Click Drag item in PME? A native Click Drag keymap item in Blender has a Direction setting (Any, North, North-East, East…), so the action can depend on the direction the mouse moves. I’d like the same in PME, e.g. different items on the same key for different drag directions.
Could Click Drag items use Blender’s native Click Drag value, with the keymap item’s Direction carrying the drag direction, the same way Double Click items use the native Double Click? Blender would then tell a click from a drag itself.
To answer your questions directly, you can use native CLICK and CLICK_DRAG by enabling Settings > Hotkeys > Experimental Modes.
And yes, as you suspected, PME’s Click Drag starts with a PRESS event, then PME handles the routing internally. It recreates the old Tweak behavior, and its internal identifier is still TWEAK.
The reason for this is to avoid keymap conflicts.
While preparing this reply, I’ve been comparing Press and Click, and I wonder whether they feel slightly different in practice.
I use Press and Click Drag (Tweak), but @MichaelColina , weren’t you using Click and Click Drag (Native)? Is that a matter of personal preference?
1 Like
MichaelColina
(The "Mr. Polygon Punisher" is your)
6108
click and click drag for the same shortcut one e.g Tab for object mode pie menu and Tab+drag for viewport overlay settings, these features should be out of experimental lol because the point is to have PME keymaps synced with blender keymaps, therefore in the older versions you could only use press from PME but manually had change the keymap mode in the blender keymaps editor to be able to use two shortcuts like that natively.
Well, I’m really just hiding the complexity behind the “Experimental” label and not explaining it properly.
But I think it’s more accurate to frame the goal as making shortcuts behave as intended, rather than keeping PME’s settings in sync with Blender’s keymaps.
For example, if Blender already has a built-in Press hotkey for the same shortcut, adding a Click binding won’t work. You’d need to disable the existing hotkey. I tend to want to keep this kind of complexity away from beginners.
I think “a short tap opens one menu, while holding the key and dragging opens another” can already be achieved with Press + Click Drag (Tweak). And if you then want to add Hold as well, combining it with Tweak is the only option.
There are probably customizations that need native Click / Click Drag, so I hope a future hotkey conflict detection feature can help make these interactions clearer.
It also looks feasible to add direction options to Tweak, and I found some room for performance improvements too.
By the way, PME’s Press mode doesn’t behave exactly like a native Press binding. When triggered, it checks the keymap and routes the input based on conflicts. This is part of roaoao’s original design, and I like this approach.
looks like you only get one try at the “set up repository”
your License key only works once. So I’ve been shut out of updating.
I talk with Gumroad and was told this new install process in not there doing.
After completing setup, you should have received a repository URL, a Repository token, and a Recovery secret. Please keep these somewhere safe.
You can use the repository URL and token to continue downloading updates through Blender. Even after your Update Access period ends, you’ll still be able to download the updates that were available to you during that period.
