me feels like the only person on earth who’s happy with Blender’s UI.
count me too.
Not exactly happy, well, it’s a 3d package after all. What should we expect? Miracles?
I had said before here, if I had to choose a priority list of things to improve, UI would be almost the last of the list. I love Blender 3D UI, it seems very configurable/customizable and professional. The work area is well optimized, without big annoying buttons or other things that take up space in the work area.
I think before that improve the UI, more useful for newbies (and for all) would be that Blender has a good system for storing and sharing (import, export, preview) materials, nodes, brushes, etc.
A lot of love for the UI today, which is great. I always thought it was pretty good too.
Really? You don’t see much difference between 2.49 and now in terms of the UI? Not sure I can agree with that at all. 
Thing is, I never found the whole sunk investment line of thinking terribly convincing. There is a reason it’s considered a fallacy in finance and project management after all.
I understand and appreciate that you learned the interface one way and don’t want to change that. Thing is, the way some of us see it, Blender currently had the low notes mixed amongst the high notes and we’re looking forward to them being placed in order left-to-right. 
Careful, that’s a double-edged sword you’re wielding there. I can just take it and turn it around like this:
Blender has an excellent UI which is better than all other applications! (I’m asserting this based on countless anecdotes! Want one? ;)) Just because you learned general interaction from all those other apps doesn’t mean you should change Blender to conform to them. In fact since Blender has the better UI, we should change all the other apps to conform to Blender. Yes it’d be a lot of work, but I don’t find the sunk investment line terribly convincing. It’s a known fallacy!*
*note this is sarcasm and not a real argument I’m making. I don’t particularly care to get too deep into a UI debate 
Once the new keymap is in, I’ll adapt of course, maybe file a few bug reports for stuff that really annoys me, customize the rest. I just find the exchange of one set of arbitrary (but pretty comfy) keybindings for another equally arbitrary set almost entirely pointless.
Right, you posted an argument that’s not a real argument because you don’t care to get into an argument… about sum it up? The sword indeed as two edges, but making assumptions that changes are based solely on what everyone else does just means you hit with the flat of your blade (to torture the analogy). 
As you don’t want to get deep into a UI debate, I’ll refrain from going into detail about tablets & their left-click behaviour, the issues with 3D Tool Positioning taking up a primary input, the benefits of a keyboard home row for most common operations, and the variety of other reasons behind planned user interface changes - none of which rely on the sunk investment line. Wouldn’t want to waste your time on a debate you don’t want to have. 
Of course, if you do choose to take your “not a real argument” further - I’d be happy to go into that detail in another thread. 
Meh, I’ll pass. We’d just waste a perfectly good afternoon and it’s very likely neither of us would come out convinced. 
Who knows, maybe the new keymap won’t be so bad. I may not find the idea terribly exciting, but I’ll certainly give it a chance.
Problems with sticky keys or new keymap are hardcoded keymaps that a user can not change.
Any exception will complicate user task to adapt keymap to its preferences.
If a set of 3 complementary actions cannot be assigned to 3 keymaps that are next to each other on his keyboard because the one on the middle is locked as an hardcoded keymap, the nightmare beguns. User have to think of another place for the set. But he realizes that more important operators used in all modes should be kept at their important places in keyboard.
And finally, with a very low amount of exceptions; user can renounce to several groupings he had in mind and stay stuck with scattered operators.
Blending is like playing the piano, it takes a fair bit of practice before you stop looking at the keyboard and just think about the music/image. But it’s immensely satisfying when you get there.
I just wanted to say that I love how you said it! I can relate to both, and for me it’s the same.
I still would give another default keymap a chance, though, why not. If it’s better, and it may very well be, I’ll learn it. If not, I’ll keep the old or customize. With that said, I also totally agree with zeauro about hardcoded key bindings, ideally all keys should be customizable. I think the devs are aware of it and I trust that we’ll get there eventually.
Re: Hardcoded keymap:
I said this a couple of times already, but hardcoded keymaps or keymap items aren’t really an issue. There are a couple of hardcoded items that should become configurable, for sure, but there are really not a lot (see T37520).
For the new keymap, they are also no big issues. If an issue with them would occur that had to be fixed for further work on the new keymap, I (and other devs) would be available to fix.
IMHO hardcoded keymaps are rather low priority compared to the actual keymap project.
To quickly describe the problem I had with sticky keys: This was mostly due to overlapping shortcuts which started to conflict. Note this: The current event system, which handles user input and decides what to do with it, basically roots back to 2007. Meaning for about 8 years, developers added shortcuts to work with this system and they used every strength and weakness of the event system for hacking in things so they would work like they wanted them to work (and I don’t blame anyone for this, I did it myself).
So with this in mind, I think it’s understandable that even a slight an very carefully planned change in the event system - like done with sticky keys - can break a lot of things. Most of them were fixable, but things like overlapping shortcuts are hard to fix without refactoring big heaps of code or changing the shortcuts to make them at least work in an unconfigured state.
Example of overlapping keymap items/shortcuts that caused conflicts: Holding Ctrl while transforming to snap and Ctrl+LMB to extrude to cursor position (see fix). This was a really bad conflict, one of the main reasons I reverted stickies, and both shortcuts were not hardcoded.
With all that being said, I think the opposite, allowing customization, is much more difficult to support nicely. We always have to keep in mind that users might tweak the shortcuts when designing features, because in some cases this has an influence. Again, sticky keys are a good example: We could hack in some fixes so that everything works fine, but that would only be an option if keymaps wouldn’t be configurable.
All devs say it’s easy to do. It has been officially agreed on more than a year ago. So why not do it now? I mean, Jonathan said himself that he doesn’t find the time to make the new keymap. If you unlock the last parts for customization now, it’s a low hanging fruit, it makes people happy and it solves what the hypotetical new keymap will never do: make animators, sculptors, compositors, architects, physic and archeology scientist, casual users and all the other happy with one configuration for all. Even 2 people of the same category have different addons and workflows. So please, don’t just speak about it more than a year long for something that could take less than a week and where everybody agree even Ton! You are not the only one not wanting to hear about hardcoded keymaps anymore
I didn’t say it’s easy to remove hardcoded keymap items, I said that I don’t see a big issue with them.
Thing is, with the current system there’s only a quite ugly way to “fix” the currently hardcoded items (which in fact is the reason why they are hardcoded, this is not done out of laziness) so if there’s no really reasonable or urgent need to fix them, I’d prefer to wait until we have a better system (or start writing this system first).
However, I also only hear people cry: “fix hardcoded keymaps” but nobody - except of the people in T37520 - helped us by telling us “shortcut x, y and z are hardcoded, it would make sense to change that”.
Having a list of hardcoded shortcuts would be really handy and it’s something a non-dev can start doing (there are a few more than listed in T37520 afaik).
It’s the usual thing we tell people: Stop just complaining and asking for features, think about what you could do to help us and start doing it! Dreaming
@Julian:
Not sure I fully understand your earlier post. It seems that you are aware that sticky keys are desired for moving the keymap project forward, but you are also not going to fix that problem because there is no “really reasonable or urgent need” to fix it.
This doesn’t sound right to me because, even if a dev believed that, I can’t see them saying that on the forums! Could you explain the contradiction here please? I’m thinking I must’ve missed something here.
I think I have a solution , remove the whole UI and start over 
Contextual OOP boxes…
Container = contains some code and properties
Mouse over container = accepts key inputs into container and defines shortcuts based on context
Mouse over and click widget = freeze mouse cursor and operate sliders etc
Container accepts drag and drop sub widgets, like slider, dial, list, output text box, output image etc.
???
Poorly coded example in the bge
<a href=“https://www.youtube.com/watch?v=RIS9VdWj5Yw” target="_blank">
https://youtu.be/RIS9VdWj5Yw
no keypress inputs yet but it’s actually easy for me in the bge
I guess I should code a addon to get familiar with BPY?
Attachments
WidgetDemo.blend (517 KB)
It’s what I have suspected. The intro of sticky keys slowed things down to the point of other devs losing interest. (It’s the nature of open source. Introduce new things, then rely on others to complete the job. That’s why there are hundreds of distros in the Linux world.) I’m not even a fan of sticky keys. I can’t imagine not getting slowed down pressing all those keys.
To me the discussions on defaults have always been about LMB vs RMB configs. If you can’t transition to LMB completely based on the available customization, then something must be broken somewhere. And that’s imho where they should shift focus.
I had little problem transiioning to LMB because I only currently use Blender for modeling and sculpting, and Blender has lots of modes and have different config system. So I can’t help with that.
My point is they need to implement the LMB defaults now using the current customization system. Let the sticky keys be an option and work on it for ten years, I don’t care.
The sticky keys have had no impact on the progression of the new keymap, or for LMB/RMB defaults. None. Sure sticky keys can improve the keymap possibilities, but the only thing stopping the new keymap right now is time. End of story.
I was talking about things that can already be implemented like clicking on empty space should desselect selected objects, execute on release, consistent LMB selection, assign the RMB to a popup menu, not pivot relocation of the cursor, etc. These and many others can already be implemented. You guys are waiting for something that might take decades to appear.
My point was that we are not waiting for these other things. We are just trying to find the time to actually build the keymap. You are correct, all of those things you mentioned can already be done.
@Julian:
Nevermind. JonathonW has mentioned that the keymaps are not waiting on sticky-keys so the basis of my question is flawed. Feel free to clarify if desired, but I’m good.
@BTolputt, yeah, I was complaining a bit on IRC that people keep mixing up these things so Jonathan stepped in I’m not even sure why people think they are tightly connected with each other, maybe just bad communication (I regret a bit that I never wrote a proper explanation for the failed sticky keys merge, maybe that would’ve helped)
Alright, let’s clarify things short and to the point:
- Main issue with the keymap project is time, it’s not waiting for anything, neither stickies nor removing hardcoded keymap items
- Main issue with stickies are that they cause conflicts within the current keymap
- I see two possible solutions for this: Either make event system, or keymap more solid (both keeping things like stickies in mind)
- Hardcoded keymap items are no big issue for both projects, and since tackling them requires doing ugly stuff in code, I prefer to wait with that until we either have a system that makes this less ugly, or until it becomes a “real” issue
My current plan to continue all this looks as follows:
- Get new keymap design done
- Put together new keymap step by step, with developers+designers working closely together and on top of a sticky keys build to make sure everything works fine together (doesn’t mean the new keymap will use stickies - that’s a different topic)
- Keep removing hardcoded keymap items a separate project, goal is solve in a not ugly way
I’ve started working on a button/ui-widget code refactor some days ago, with Campbell supervising me a bit, that should later allow us to get rid of the remaining hardcoded keymap items in a nice way, but it’s too early to know this for sure.
So! That’s basically everything I can think of without getting into too much details, I may have made things more complicated but I hope its more clear instead Just ask if I managed to confuse you again.