As stated, JonathonW had cleared up the basis of my questioning, so your complaints in IRC had some good effect, but I do appreciate the effort in explaining everything clearly. As I understand it, the lack of sticky keys does remove some options from the new keymap but if JW has stated that’s not a problem, I 100% believe he knows what he’s talking about! It did seem to be a “nice to have” option above & beyond what (I believe) is needed in the new keymap.
Is there a list of the hardcoded keyboard shortcut stuff? I’d be interested to know what hardcoded limitations (outside sticky keys) the UI Team has to work around when (re)assigning keys to various operations.
The bigger issue beyond direct hard-coded keys are the hard-coded modal keymaps, such as those for the Knife Tool. Bastien has been working on the initial API for this, though: https://developer.blender.org/D780 < this does not block the new keymap, but would further improve it.
Thank you for clarifying @JulianSeverin. I have a much better understanding of where things are right now.
Could you explain a bit more about this? I’m just a bit curious what exactly is being refactored here. Is this just the buttons and the gui, or does it also effect the key maps and the event system?
As I said, there are not many hardcoded shortcuts left, the only list I know about is here and I’m not sure if it’s complete. So everyone is invited to keep an eye open for them and complete the list
Edit: Ahh, maybe I should’ve refreshed the page earlier, Jonathan already answered
@TARDIS_Maker, first off, this is only back-end stuff, for now, nothing will change for users (well should :P).
NOTE: I’m using the term “widget” here, but this has nothing to do with the widget project, we’re talking about things like buttons, menus, scrollbars, containers, …
For now this only touches drawing code, but we’re basically following 3 different goals:
Modern, isolated standalone widget module:
My idea is to make widget code a completely independent library, which can be reused for Blender Player, Cycles standalone, etc (even 3rd party applications could use it ). We also might port this to a more modern language like C++11.
“Widget Draw Style” theme option:
An option to change widget drawing based on presets like flat, classic, edged, rounded, … more info here
Refactor our widget handling and make it a part of the new widget module:
Currently interface and widget handling is mixed up in a gigantic file, everything is old and code is mostly bad. Instead, this should be a part of the new widget module, well structured, callback-based and ready for future ideas. This is also the point where hardcoded keymap items could be tackled afaics at the current state of the project.
I’m well aware that this is really uninteresting stuff for users (except of the option to change widget draw styles), but it’s also important for future work on Blender’s UI. I’m really taking care that this refactor doesn’t take away the priority from improving the work on the users end, I’m trying to balance it out well. The issue is just, that we’ve reached the point where adding features is really dangerous because of possible breakages, and where coding is basically hacking, so it’s really time that we do some spring cleanup.
This applies to all parts of Blender’s UI code (and others), not just the widget code, but this looks like a promising starting point and its importance has grown due to some current UI projects.
Edit: Also note, that this is my current plan on how I would like to do things, I started the actual work on the code-site 2 days ago and a proper design document doesn’t even exist (although I started with it). Just saying that so people don’t stone me if things don’t go as “announced” here.
I know that it won’t change much on the users side, but I like seeing refactors anyway, because they always seem to open doors for future development, improve handling, etc.
@ JulianSeverin
For starters, an easy one, Circle Select.
As I had reported (https://developer.blender.org/T43253) Circle Select needs to Pass Navigation.
I know you said it would conflict with some other key combo (MMB is already used for unselecting), but what does that mean … is that really a valid excuse not to fix an incomplete tool?
The goal is to expose the Modal of the Circle Select so we can set our own keymaps for it, with navigation included and everything. As I said, like the Knife Tool Modal. Who cares if it conflicts with MMB deselect?! You don’t have to map it by default, but expose it and let us fix it by asigning our own keymap. In my case I don’t even use the default navigation, you should take that into consideration!
That’s the first step. But what PLyczkowski is saying would be the proper way to do it, actually not even proper - but just normal.
Circle Select is an incomplete tool, period. So it’s really funny when BF does not want to include some awesomeness because it’s ‘incomplete’, just take a look at Circle Select.
There is no reason not to include [Add-on] rSelection as one of the drop down choices for the key input. That would be a sign of good will in regards to UI UX universe.
All other points aside, the last person that has to “show good will” in regards to UI is Julian. He is doing many great things at the moment, fixing little annoyances, improving interaction and doing an overall awesome job on Blender’s UI.
Apart form that, I totally agree about circle select and navigation
It’s late in my time zone, and obviously I wasn’t clear there … this is not directed towards Julian at all. Nor any other devloper per se, but the way BF/BI, or whatever the thinktank is, handles it.
To be clear again, I’m thankful for all the hard work and the good will the developers are doing. But if I’m going to be honest, from my personal point of view, with all the AWESOMENESS blender comes packed with, it still fails miserably because of the default interaction (interaction is part of UI = UI)
Without my custom keymap (setup), Wazou’s Pie Menus, and a bunch of other community addons, I would not touch blender with a ten foot pole. Just being honest and outspoken here. But anyway, who cares what one person thinks, right.
Oh yes, and in all fairness, with all these customizations that I have mentioned, blender is my go to tool for both personal and professional work. Judging by reaction, I’m the first person in my studio who asked to have blender on the workstation. That’s on top of having access to pretty much most of the ‘top’ industry tools out there.
As I understood it, the point wasn’t that Julian specifically needed to show good will, but that allowing/directing work on those features would show good will from those prioritising Blender development resources. After all, it’s not a secret that initial excitement at the UI Team & UI work has soured somewhat since 2013.
Yeah, pretty sure this is something we all agree would be good to solve, even those that don’t want to see any large changes to the keymap & UI.
I’m in the same boat. I am hanging out for this addon to make it to the official key map. The selection method is familiar to any 3ds max user or anyone that’s used windows explorer.
Those keys PLyczkowski used in his addon sound very good and consistent, and intuitive for a lot of computer users, I believe. I should try it, thanks for mentioning.
Julian and Jonathan, thank you for explaining and clarifying the sate of work on UI and keymaps, it is much clearer for me now.
Julian, your widget project sounds very interesting, looking forward to it. Also thank you for tackling ugly code and making it more managable. I can imagine it’s hard work, but so necessary for a project as big as Blender.
Re Circle Select This is still something I’d like to resolve asap of course, but afaics, a proper solution for the MMB conflict would require reworking the entire selection which is not a quick “fix” and which can’t just be done if you feel like doing it. At first it needs a good design that all agree on. There is Pawel’s proposal, and I don’t see a big issue with it, but without any feedback we can’t move such things forward.
Also, I consider reworking selection as a part of the keymap project, so fixing Circle Select is basically waiting on this.
[, just trying to make clear that this is not an “easy one”. If I learnt one thing in the time I’m working as a dev, it’s that in such a complex application like Blender nothing is an “easy one”, you always have to consider a dozen of corner cases, compatibility issues, performance issues, … and after all you want to create a good user experience (ignoring more technical difficulties for now).
Two recent examples of projects that sounded easy but turned out to be quite tricky: Support for changing all selected items (objects, strips, bones, …) and absolute grid snapping. For both we had to open a design task ([URL=“https://developer.blender.org/T44666”]T44666](/u/0rAngE
0rAngE[/URL) & T45212).
Actually, these are the kind of things that make Blender (UI) development tedious and slow and I for my part spend more time on searching solutions for these things than anything else.
Ehm I am just wondering why dont you share you remapping and thoughts behind it ?.
Talk with UI team or so
You see maybe you stumbled on some general logic, so that some things in different views bhave for you more like wise.
I myself also tend to forget the not so often used keys, so there is improvement possible maybe.
in the same perspecitve i’ve been wondering why we can scale video horizontal zoom in zoom out over time.
but we cannt scale it vertical, that would be very usefull for working with audio tracks.
because then you can pinpoint the exact right moments to do something (if you work with real film).
It’s quite well documented also, I made sure to write as many hotkeys as I could remember that I had changed/added. There’s a video demo also, outdated as I had changed a number of things in the meantime, but still descriptive of what the setup is.
It’s not only Circle select, anything that utilizes the MMB in the middle of something, hampers continuous navigation. I could give up the MMB constraints and be satisfied with pressing X, Y and Z on the keyboard…
). We also might port this to a more modern language like C++11.
