I'm having trouble with this right now - It almost feels like 2 events are being sent on click instead of 1.

I'm using the provided linux build, with the official "pie menus" addon on.

The "hold functionality" seems to work great. I hold for x miliseconds and the menu appears, but the tap functionality I can get working reliably. I tap as quickly as I can and can't get it to behave like it was before.

I tap "Tab" for instance and it quickly flashes into edit mode, and then flashes back to object mode.
Likewise, when I tap "Z" it quickly flashes into wireframe, and then insta flips back to solid shading.

If I mash on the button a bunch of times I can get it to flip over, but of course that won't fly! I feel like all the ingredients are here, but we need a bit of fine tuning. Thanks for slamming on this rough problem Severin!

Hey @Sean Olson (liquidape), glad you're playing with it already :)

Mhhh, no similar issue appears here, have you tried with factory settings? My first guess would be a conflicting key config.

liquidApe: "I tap "Tab" for instance and it quickly flashes into edit mode, and then flashes back to object mode."

Possible cause..

(A) Sean's Operating System keyboard repeat-timing may be different so a given function may repeatedly be called due to the OS registering and returning multiple key presses(but only for some OS/Blender configurations.

(B) ....

I am using the default settings within Blender - for reference, here is how I have my keyboard repeat setup within Ubuntu 14.04 - though I don't recall ever having changed it:
http://is.gd/KxtfAg

I have tested it a bit and was able to get it working, and it seems to work okay, but there is one issue, unfortunately hard to reproduce and nail down:
The hold functionality seems to "eat" keystrokes. I have set the Tab menu from official pie menus to hold, and now when i quickly hit Tab a couple of times to go in and out of Edit-Mode then after a while the key seems to stop working, and even more, also other keys like Spacebar Menu doesn't respond anymore. The sticky key for Tab however keeps on working. If I wait a while it works again. The whole thing behaves a bit random, so it is hard to really tell what's happening.
Did others notice something similar? Or is my keyboard simply broken? Although, in master this doesn't seem to happen.
Oh, and I have DoubleClick interval set to 150, and Click Timeout to 10. (Why is 10 the lowest limit btw?)

@Sebastian Koenig (sebastian_k) happened to me the same and i also had reduced to 10ms the timeout. Once set back to 15, worked fine here.

I tested a bit and while this is great and much awaited, it seems it destroy the "quick gesture" approach, it's quite slow to react imho. Maybe reduce the ms needed? (assumed the the little bug sebastian said and i encountered too get fixed)..??

Thanks @Julian Eisel (Severin) for working on this.

I'm not getting the insta-flip, or the event eating. But when I go into the Z pie and let it open (no quick gesture) I can't click on anything other than shade smooth/flat. In the pivot menu nothing is clickable, tab works fine.

Middle mouse button gets stuck sometimes, until I hit Esc. Happens sometimes after I close a pie.

I agree the react time is a little too much. The threshold between tapping and holding seems too close too. Feels like I have to strike the key really fast or it doesn't do anything.

Eeek, all those issues are pretty weird, none of them are appearing here (I previously tested everything carefully with different OS, Hardware, etc). I'll try to investigate some time during bconf to see what I can do. Hopefully all the problems can be lead back to the same root, so they are easily solvable.

Thanks all for the feedback and testing. I really didn't see this coming, but I'll try my best to solve every issue.

Hi,

Thanks for working on this. I just tried it out. For me the pie menu's aren't activating fast enough. I think it might be a good idea to add a setting controlling the delay between when the key is pressed, and the menu pops up.

@TARDISMaker There already is - read the description under "Click Timeout"

Sorry about that. I guess I missed it when I looked threw there.

Edit:
Even after lowering it though, the time it take for the pie to spawn is too long. Does it get buggy when the timeout is less than 10?

@TARDISMaker Yeah, that's why i set it to min 10. However, I'm working on the patch to fix all the issues, so you'll be able to set it sub 10.

Xmas update :)

New patch, new testbuilds...
And now: Test, test, test! Let's get that thing ready for master!

Yeah !
Thanks a lot for the build, my own build was not working for some mysterious reasons.
That is a good xmas gift :-)
It's perfectly working for me.

Tried this and still have a problem with trackball and rotate also with tool bar and properties

@Aaron Carlisle (Blendify), heh? Not sure what you mean... What problem are you talking about?

It will still switch rabidly between the options

Ah, guess you've created your own sticky keys? Remember that you always have to change the key value of both operators, one must be "Click" the other "Hold". Optimally this would happen automatically as soon as you set one operator to "Hold", but I didn't start working on that.

I have not created my own sticky keys when I hold done the R key it still changes rapidly from trackball and rotate

That has nothing to do with stickies, that's how it works in master and that's how it is expected to work :)

Sorry I thought that this was supposed to fix these problems.

@Aaron Levey (aaron), just tap R once to rotate normal, tap R again to rotate trackball. But yeah, as Severin said, totally different UI concept at play here.

@Sean Olson (liquidape) @Aaron Levey (aaron) is a differant person then me please us the name outside the () thanks for your commit

Does anyone have any new feedback? I'd really like to see if people are testing the builds and how they're working. Positive feedback is allowed as well (and helps getting this into master) ;)

It's working quite well for me. It's doing everything that I expect it to do.

I have a minor critique but It's beyond the scope of this patch. Basically I'd like it to guess when a gesture for a pie menu is used and then automatically switch to the menu, but It seems to me like this is too much of a pie menu only type of thing.

I just tried to make a simple one, by making the toggle fullscreen command to be a hold spacebar instead of shift spacebar. It works, but it goes back and forward on the toggling.

Would it be possible to make it so I need to release the key for the command to be sent again?

Super exciting feature though, and thanks for making the test builds available!

If you do what @Luiz Kruel (lkruel) suggested, It should probably be an option. This type of behaviour probably wouldn’t play well with pie menus.

Looking deeper into it, what I requested should probably be a series of bindings.

I was thinking of doing things like Press G and you go into grab mode, and when you release G it pops you out. But I can do that already, I just need to add 2 different bindings.

If the hold is purely meant to be used with pie menu commands then I guess it's fine. Just seems a bit weird of having the option of creating some really weird behavior. It would almost make more sense to me to have it be a part of the creation process of the pie menu, where you bind it to a key and hold is the default way of starting a pie menu.

Total blender noob here, so take it with a grain of salt. I'm just getting started and trying to work it into my workflows. So ignore this if it doesn't make any sense.

Thanks for the awesome features!

Thanks for the feedback guys! :)

@TARDISMaker, could you describe a bit more what you mean? It's a bit off-topic here, but would still interest me.
@Luiz Kruel (lkruel) sticky keys are not only for pie menus, one of the main goal is to make them accessible for every operator (this way we can get rid of a lot of over-complicated shortcuts). Currently there are just a few more steps needed if you want to create your own sticky keys. E.g. for the fullscreen toggle you'd have to do the following steps:

• Hold spacebar is used for the Manipulator Pie in my build (assuming the Pie Menu Add-on is enabled, if not you can skip this step), so you first need to free it. User Prefs->Input->type pie into the search menu and change or delete the shortcut assigned to the spacebar
• Search for the fullscreen shortcut, change it to spacebar and set the value to hold

If everything is alright, it should now show the search menu if you just quickly tap the spacebar, and toggle into fullscreen if you hold it.

I'm talking about when you have a pie menu set to hold, it would be nice if when you gesture (like you normally would without sticky keys) and it automatically switches to the pie menu.

So basically if you want to go into rendered view mode and you have pie menus and sticky keys enabled, you don't have to wait the full timeout for the pie menu to be enabled, you just have to gesture in the direction of the rendered view button and the pie menu is automatically enabled. The main problem with this is that this behaviour would only be useful for pie menus and would just get in the way for other types of menus.

It might be possible to implement something like this and just use a checkbox for if it's used or not without it messing up everything else.

I hope that makes sense.

Hi Severin,

Thanks for the detailed answer.

Enabling the official pie menu addon works great, and the spacebar works with the spacebar hotkey as you mentioned. So that's all working as advertised.

I did follow your instructions and got the same result as I mentioned before, I'd be curious if you hit the same. I basically keep toggling back and forward really fast between fullscreen and not fullscreen.

Also, I'm talking about the fullscreen area under Screen, not under Window in the User Inputs.

+1 for getting rid of over complicated shortcuts

FWIW I'm testing on the mac build, I'll try out the windows 64 as well, just to make sure it's not something special with the mac keyboards.

EDIT: Tested this on windows and it also happens. But I think it's related to an earlier comment that multiple press events get sent when you hold a key down. Which is a separate issue. If you start blender and hold shift + spacebar you get the result that I'm describing. Seems like it's not related to your change and fixing that will fix the issues that I'm seeing.

Thanks for the commit, I've been waiting for something like this for a while. I hope it makes it to main soon!

@TARDISMaker yep, that makes sense, but I'm afraid this would conflict with the normal toggle behaviour. If we implemented this, this would mean you would have to avoid any mouse move for 250 ms (depending on how you set the click timeout in the user preferences). That's not much but I bet users would complain about this.

@Luiz Kruel (lkruel) I'm a bit afraid this is the same issue @Sean Olson (liquidape) faced (which propably would be a major showstopper), but let's stay optimistic and try a normal troubleshoot first. Could you test if resetting to factory settings and doing the above steps again shows any difference? If that doesn't help, do the Stickies TAB and Z work fine without any strange toggeling back and forth issues?

Hey Severin,

Just tested with factory reset, and Tab and Z work fine. The only "weird" behavior is that if you let go of Z or Tab without making a selection, the pie menu stays up until you click on something. I'd expect the menu to go away on release of the key, not sure if it's doable or desired behavior.

It seems like the issue that we're seeing is with multiple commands is happening in main, so it shouldn't be a showstopper. Although since you're already in the input code, would it be an easy change to either add an option or disable multiple press commands being sent during a hold event?

I'd expect the menu to go away on release of the key

I would also expect this behavior on default.

on the linux build I get a strange bug where it wont let me connect material nodes by dragging the connection dots to make a connection

Just as a general note, I talked quite a bit with @Luiz Kruel (lkruel) on IRC and we found out that the issues he reported aren't related to my patch and are in master as well.

@Paweł Łyczkowski (plyczkowski), this behaviour is also used in master and is intended. It enables using click stlye interaction with pies where you can click and release the hotkey, and then select a Pie entry with the mouse. You can also exit the pie using escape or RMB

@Todor Imreorov (blurymind), thanks can confirm that here. These are exactly the issues why I'm trying to make sure everything is well tested ;) I'd prefer to not update the testbuilds for rather small issues like this one, as it requires me to use the experimental build branch which we're trying to use sparely.

I have tested the build, and I can't switch context with the Tab key. Sticky works well, but the normal click doesnt change the mode.
Also, holding some combinations (like shift+spacebar) toggles very quickly the manipulator. This also happens in normal builds, but now that held keys are part of the normal user interaction, these should be taken care of.

@David Gascueña (netich), could you check if the Tab shortcut is set to "Click" in the UserPrefs? You can also try using factory settings.

In fact, @Luiz Kruel (lkruel) has already created a patch that does exactly what you may want (talked with him on IRC quite a bit). It reuses sticky keys code for that.

Yes it is set to click, and it seems to enter to edit mode an exit very quickly. I have tried with factory defaults and with pies addon disabled, and it happens the same

Yeah, it bugged the hell out of me too. I have a patch but it's dependent on this one for one variable in wmEvent. I was waiting to submit it when this one goes in, but I can submit it with this one as a dependent (?)

Hi Julian,

Nice patch. Please follow the UI proposal from Brecht. He wanted to remove all hardcoded shortcut. With the actual community of Blender, there isn't a perfect keymap or workflow. Animators, sculptors, architects, high-schools, scientifics etc... they all have their own needs. Please leave the artists free to choose what is good for him, no C-Coded keys.
Would it be possible to add a check when an add-on or user change a shortcut, triggering a warning if another operator is already using the same shortcut in the same context?

Thanks