Can you please stop with this non-sensical arguing?
We are working with this features for years on several 3d apps, there is no such thing as conflict between click and double click. If you can’t differentiate a click from a double click, that’s your problem.
Just stop with this crazy “babysitting” behavior.
Enough is enough… Damn…
A lot of us really enjoy our deterministic controls thankyou very much, they enable use to work faster.
As Blenditaway pointed out, Preferences are where this belongs. Don’t screw with the fast workflows. You can have your options that work like other software, but it shouldn’t jeopardise our deterministic ones.
Screw with what fast workflows? Nothing is screwed here. The removal of that feature was just a naive move, and the devs will realize that sooner or later.
Enough of this.
What is the use-case for cycle selecting while in Edit Mode?
All the time when any elements are overlapping?
For instance I’ll have verticies not merged on purpose often when working with circles, imagine if I couldn’t cycle between them (it works with ALT aswell to cycle edge-loops that overlap).
Not to mention consistency with object mode, power mode, armature edit-mode, as Campbell points out.
i use double click for loop cut it’s much better than ctrl+r since we have alt+click for edge loop selection…two options for one action is redundant.
I use it in Object mode and stuff, but Edit mode I don’t recall ever using it, nor do I recall seeing anyone else use it in a tutorial or anything. Edit Mode it’s easier to just switch to wireframes to select things.
This is typically for use whilst in wireframe mode. Like the one I pointed out, there’s plenty of instances where geometry either overlaps in the view, or in space and moving the view doesn’t help.
And?
I read that before, and no, everything works great, nothing is broken. I have double click select on my personal keymap for years, and yet I can do cycling just fine. I don’t really know the reason of the removal.
I can always live with my personal keymap, I just feel bad for the new users.
Because blender operates on the premise of low ambiguity, where keybinds don’t overlap, and always do the same thing, every time.
Blender is not an archaic app anymore. Open your eyes.
Great argument. Make blender worse so it’s not high on some arbitrary “archaic” scale you just made up.
We still can enable it in preferences, so not a big deal.
oh sorry wrong reply button.
I’m good. But like I said, will not be easy for new users, and worse for blender’s reputation.
i know something, that i know nothing.
I seriously doubt it would be the reason someone would give up, but it is one more straw not he camels back that would make someone turn back. The frustrations add up and eventually make people that would be interested, give up.
I understand the need to keep app. design as consistent as possible like the devs. do, but sometimes you have to wonder if the devs. are too willing to sacrifice usability on its alter. One example of this being how the Cycles baking workflow was initially coded and the changes made it to after being committed to master.
If an exception to the design is needed for user comfort, then it should be documented both in the code and the user docs. Unfortunately, many FOSS projects have a proud tradition where design comes first and usability comes last, and is one reason why the concept has struggled to really catch on in the content creation space.
Now I’m not arguing that design should be broken everywhere as that would make the code itself harder to work with, there should first be proof that the benefits to workflow is great enough to warrant. The more the design is broken the greater the argument needs to be. Double-click loop select only breaks a corner case that is not used often so the bar isn’t set that high.
I’d say put the double click into the industry standard keymap, assuming we’re still getting that.
Because other than being like other software, it is only redundant, less ergonomic, questionably slower, and breaks something else that works consistently.
Calling it a corner case depends entirely on what models you work on. I typically have quite the instance of overlapping elements, both in view and space. It’d be a serious restriction to have to purposefully click especially slowly to ensure the user doesn’t trigger a double click by accident in their zeal, it’d also break them out of that ‘flow’ zone.
I think Campbell is talking about defining an active element among a selection of several elements.
Imagine you have a Grid with all vertices selected.
You want to use a vertex of corner as active element as pivot for a scaling of the whole grid.
Every vertex is already selected.
You do a shift click. Vertex is deselect. You do another one. It becomes active element.
If you do that too quickly and obtain instead a loop deselection that may be disturbing.
But I think that can be integrated by users. Most of time, you have to change pivot point from median point to active and you will go back to median point after transformation.
That is not some tenth of a second on rare cases that will handicap experienced users.
Edit: I forgot if you want to select border of grid.
Alt click on border will only select one side of grid. Then, another Alt click select the whole border of grid.
Weird. But in theory, just a little latency before second double click should not disallow cycling.