Could you please read the forum FAQ, specifically the part about “Ad-hominem attacks”.
Because there is no double clicking in blender, you don’t have to be aware of this in blender. This speeds you up, and lets you think about things other than 'how fast am I clicking and how fast is the double click speed?". It get’s worse when you instead have “No, dammit I’m not clicking that fast stupid computer, ugh, I wanted that vertex.”
Indeed in many other pieces of software you need to be aware of this. Blender you don’t, as such it improves your ability to be in that flow state I mentioned and your ability to focus on things other than how the computer is interpreting your inputs. Blender’s input design is specifically created in contrary to other software in this way, and no double clicking only scratches the surface of that design.
What’s the problem with it being in the industry standard keymap? since it’s an industry standard convention that only flies in contrary to blender’s typical input design.
And you really think not supporting double click is a good thing?
This is some serious backwards thinking that is happening here. In fact that’s one of the reasons blender’s hotkeys are weirdly convoluted. There are tons of things that could be done on double click, and yet everything is thrown into hotkeys. This is insane.
I have told you the reasons for this. There are reasons behind most if not all of blender’s “weirdly convoluted” hotkeys, you refuse to accept it.
But, as I have said, there’s an industry standard keymap being made to support anyone who decides that for themselves familiarity is the most important factor. Blenders normal keymap and control systems have other priorities.
I literally just gave a bunch of reasons as to why.
Evolution of a software and workflows, progress and improvement, relies on being different, thinking outside the box, stretching the boundaries. Copying the industry is the opposite of that, copying and following is backwards thinking, what blender’s workflow is and was, is forward thinking. It came about in the pursuit of a better way, not the way it’s been done before, not a way which is familiar - those things fell aside in pursuit of speed and flow.
Double click adds a layer of ambiguity to the mouse button. Ambiguity is what breaks flow and changes focus from what you’re doing, to how you’re doing it.
Please, I encourage you, come up with some concrete workflow points that could prove double click is worth adding into the default keymaps, even though it damages flow and causes ambiguity.
If there are reasons it should be included, I’m willing to listen and agree with you, but you have presented none so far that go beyond gaining an extra 1-2 keybinds, which is not significant enough to warrant such destruction to the deterministic control setup we get in the default blender keymaps.
I understand it is difficult to understand the flow state, and how the removal of ambiguity is a big deal, if you haven’t experienced it. I assure you it is, I’m sure you can find plenty of users in here that can attest to that, quiet though they can be when drowned out.
But that’s ok, even if you can’t accept that, if you really, absolutely, must have double click available for something, you can have it in the industry standard keymap, a solution the devs already came up with, which gives both of us the things we want. And, I’m sure with a turorial or quick help from someone you’ll no doubt be able to find, or by copying it from the industry standard keymap, you could quite easily add it with the keymap editor to your default keymap.
The factor that isn’t mentioned is that unless you have ultra-flexible hands, it is physically easier to be able to just press one key and a mouse button to select as many loops as desired compared to pressing two in addition to the mouse button.
The control scheme was due for an overhaul anyway, as some tools had combos involving 4 keys and that can be a little stressful on the joints if you need to do it often, especially once you leave your first few decades of life.
The reason to have it in the LMB workflow as opposed to the industry standard keymap is that the latter is set to completely change the keymap while LMB just makes a few changes while keeping most of the existing 2.8 keymap intact. Then there’s the fact that the 2.7x way of selecting loops will still be there if you choose the RMB workflow (which I think should be enough for those who are strong advocates of RMB and the pre-2.8 Blender way of doing things).
The fact that we have these arguments is the point of the multiple workflow options to begin with, 2.8 is supposed to be the workflow release so a light amount of relearning is expected as the devs. deliver on it.
some people have trouble pressing shift and alt together briefly?
How does that compare to the amount of injury, strain, and general issues people get from nonstop using the left mouse button? double left clicks are a lot of clicks, spread out across a grand total of 1 finger and 1 hand, added ontop (for the LCS people) of all the other left-clicks they’re doing.
These buttons are also used commonly, the user should have found a rest position that lets them press these for brief periods without strain.
You can even bring your hand down and to the left slightly and you won’t even have to move very far from a natural rested hand to press them, just bring a thumb in a bit. That’s hardly “ultra-flexible”.
The LMB workflow isn’t supposed to be wildly different from the RMB one. Workflow changes that happen there that aren’t related to the LCS system of doing things are highly likely to be implemented in the RCS keymap aswell. Hence keeping most of the 2.8 keymap intact as you say.
Here’s a secret, you’re already doing a lot of clicking using the left-mouse button
Opening an app. in your OS requires a double left-click, this very forum (as well as every other website) is based on the use of the left-mouse button. Your post-production program (including the GIMP) is based on the left-mouse. Even Blender 2.7x itself uses left-click for everything except in areas involving polygons.
Unless you managed to change the preferences of everything from the paint program to your OS so as to be based on the right mouse, you already did a lot of left-clicking even today.
And it’s not possible for fingers to get tired doing a lot of right-clicking?
Sometimes I end up finding it difficult to keep selecting geometry and I have to take a break from working.
On another point, while it is true that the LMB workflow is not supposed to be wildly different, I have doubts that the criteria in itself would’ve been broken from double-click loop select alone. In addition with the whole thing about ambiguity being a no-go in terms of Blender’s design, I will point to an earlier post of mine that asks whether design should always come before usability and whether a (well documented) exception or two can be made for ease-of-use purposes.
It is, I don’t see what bearing that has on this though. If anything that only reinforces that double-clicks should be avoided if we’re talking about avoiding strain.
The points are still valid even if the keymaps don’t mirror eachother. That doesn’t make the double click any better.
Exceptions are the gateway to a flood of change. The industry standard keymap is the solution to that flood.
Nevertheless, an exception that has a very good reason isn’t a problem, but it also depends how much it conflicts with the design goal. This example doesn’t have a very good reason though.
It doesn’t improve usability or ease-of-use significantly, because alt is not difficult to press. All it offers is some familiarity, familiarity which, anyone should know, they can find in the industry standard keymap if they’re looking for it - and then can copy from that keymap into whichever one they want to use, or can quite easily go into the 3d view section and change the Alt requirement to a ‘double click’ requirement.
My two cents: I certainly do work in edit mode faster than the double-click speed. If I select several vertices on top of each other, then I do sometimes activate the loop select. Which is frustrating.
Meaning this really is an ambiguous command. I do not understand why this would be good.
While I am of the belief that slippery-slope arguments can actually be valid because of documented chains of events, I’m not sure if it applies as much in software development as it is in certain real life topics.
I’m also not certain as to whether it’s even all that possible for the LMB workflow to mirror the RMB one without blowing up the chance of making something intuitive (if a true mirror was done, the keys would just be swapped and that would be it, no context menu as right-click would just move the 3D cursor).
