X-Ray selection experiments build

[lcas]

Wow, so I am dumb

I am on 3.5 now and starting to go through splitting things into their own diffs, and first thing I decided to do was keymap direction. Could not let it go. First I had another try at making it work with some redundant direction enums, so it works exactly the same. Still will not set until after making a new keymap item, oh well.

But then I try a python operator workaround one more time. Problem with that was not being able to get an idividual keymap item. But this was so easy. All I needed to do was look at how the remove keymap item operator works and use the .item_id = kmi.id like it does so my own operator would finally see the keymap id instead of it showing up as none and erroring every time.

So, keymap direction isn’t ideal where it’s a 1:1 visual alternative. But it will be pretty ok. Should be able to do something more like the patches mentioned before as well.

[lcas]

First diff is up, they’re called pull requests now, it’s for 3.5 right now and not main / master. I really like the old way of just upload a diff and you’re done, was a bit convoluted to essentially do the exact same thing. I’ve heard of a pull request, branch, and all that. But have no idea what they are to be honest. Going to be interesting getting my bearings with this system.

[LudvikKoutny]

Is there any chance at least the directional selection will ever make it into the master? Hasn’t it been like half a year already?

[lcas]

I have no idea how things work. A lot of triage I imagine and only so many hours in a day sort of thing

[LudvikKoutny]

It’s still on the old phabricator site, not even migrated yet:
https://archive.blender.org/developer/D16282
The person assigned to review it did not contribute even once. I mean I can’t interpret it any other way than the patch is dead.

[lcas]

Anything form the old site has to be manually dragged over, and none of my stuff was done anyway so I’m not bothering. Will start from scratch on the new site.

The way I see it, anything I do is dead until further notice. There’s potential for somebody to like it enough to Frankenstein it to life, but it has to be in a finished state to be in any serious contention for approval. Getting there eventually, maybe, but I’m not coming at this from the usual angle. From what I read a long time ago you’re supposed to do little bugfixy things, get some experience, and then move on to adding features. I’m just a guy who doesn’t know much trying to get a few things done for myself, and take the occasional request.

Hasn’t been anything good enough from a technical standpoint for someone to drop what they’re doing and let it in. Nothing feature wise for anybody to pick up what I’ve done (or what I’ve borrowed from kio and the like) and make it blender-ready. The features not being good enough from an idea standpoint is a matter of opinion, but who cares.

[LudvikKoutny]

I don’t see anything about it that is not Blender ready. Or if there is anything, then at least someone should let you know. It’s important addition, so it makes no sense for it to be rotting there for half a year. I’d suggest migrating it to Gitea and pinging the reviewer to give you a reason as to what needs to be done for it to be accepted.

[lcas]

I am in the process of doing everything on gitea, will post links in this post, and in the first post once I’m done with the first upload of them. They need to be updated to main/master after I am done with 3.5 as well.

Diff for the custom build
This is just the first 3 features for now, will update it as I go through the remaining features.

1. Keymap Click-Drag Direction
2. Mesh Select Options - Keymap
3. Mesh Select Toolsettings with Directional Control
4. Auto X-Ray
5. Select Through
6. Viewport-Facing Select
7. Object Origin Select
8. Single-Click Mesh Radius
9. Repeat Tool

#3, Mesh Select TS w/Direction is an expanded version of userpref mesh options. Works for box, lasso, and circle. Optional directional control in either horizontal or vertical. 3 edge and 4 face select options for all 3 tools. Circle only has 2 edge options, because it doesn’t do that hybrid edge thing. By itself it sits underneath ToolSettings->Options->Mirror. In the next diff I’m putting the first 3 together into one thing. If I can figure out how to hide an entire toolsetting section for non-select tools, it will have it’s own section in toolsettings options like AutoMerge. Clicking the checkbox for whatever I wind up calling it will be the way to use the toolsettings mesh select and directional control for box, lasso, and circle instead of the keymap. The problem with having its own section like AutoMerge is it won’t completely dissappear when not using box. lasso, or circle, it will still show that section with nothing inside it last time I tried that.

[lcas]

I’m at an impasse, give me your thoughts on where and how these selection options should be accessed. Regardless of the following options, the toolsettings and their optional header button will hide themselves if not used. If something in these 4 choices doesn’t make any sense, it’s because it doesn’t make any sense. Read the ‘more info’ section if you want to know more.

1. Cram everything in the keymap all the time. One userpref will hide toolsettings, but not keymap

2. Show/hide everything from the keymap or toolsettings with one userpref. Keymap will need to be manually updated if you want to use the keymap option.

3. Show hide each selection feature with a bunch of userprefs. There’s a userpref to choose for each thing. Some combination of these different selection options will be visible in both keymap and toolsettings/viewport header depending what you want. Keymap will need to be manually updated if you want to use any of the keymap options.

4. Forget about the keymap, cram everything in toolsettings. Optional header buttons.

Those are my choices, going to decide after I wake up and read any opinions on this. Leaning towards door #4.

More info:

Selection dropdowns / enums for box, lasso, and circle.

auto xray (disable, object, edit, both) 
	xray turns on during drag select

select through (object, edit, both, disable)
	get xray selection without leaving solid shading

edge select (hybrid, touch, enclose) 
	select edges differently, hybrid = current blender 
face select (auto, touch, enclose, center) 
	select faces differently, auto = current blender 

mesh direction mode (disable, near, xray, both) 
	exclude mesh depending which direction their normals are facing 
vert direction (front vert, front vert of face, rear vert, rear vert of face, disable)
edge direction (front edge, front edge of face, rear edge, rear edge of face, disable)
face direction (front face, front face of vert, rear face, rear face of vert, disable)

object origin (these will be bools, off for box and on for circle by default) 

Might not do rear facing mesh normal selection. Nothing for object origin lasso because I haven’t worked on it, just use this addon by captain cirno in the meantime for non-origin lasso select.

These are for toolsettings and keymap. You will choose from one or more userprefs to decide whether you want to use toolsettings or keymap. Toolsettings will hide themselves if using keymap, they are fairly well behaved. Some toolsettings will have an optional viewport header button. Some toolsettings will use a collection of bools instead of an enum.

Keymap operator properties will always be visible. It does not care. Why? Because the keymap is a menace, a threat to all mankind. Listen, and understand. That keymap is out there. It can’t be bargained with. It can’t be reasoned with. It doesn’t feel pity, or remorse, or fear. And it absolutely will not hide operator properties, ever, unless you explicitly give it a true or false. It will not check userprefs or toolsettings to do this. It won’t even update your choice should you close blender and open it again.

This means that the best I can do is make additonal fake-ish selection operators that merely ask for box/lasso/circle select with the appropriate true and false pointers to show/hide the desired keymap operator properties. These can be assigned in keymap without any major changes, but will mean your imported keymaps need some updating. You would also need to do this manually, it won’t be in there until you add a new keymap item to whichever tool and input the correct operator name.

I could take this a step further in the future, because even with hidable keymap operator props, there is no distinction between object and edit mode selection tools. It’s all the same for some reason, you can’t even map them differently, whatever is done to mesh is done to object. I can make a new box select operator that has the operator properties I want to see, assign it however I want the different modifier keys to be set up in mesh, and then go to object mode and… everything is in there exactly as it is in mesh. Change object mode to how I want? Now mesh is the way object mode is. Can anybody explain to me why the keymap is set up this way? If we are going to have a different section / hierarchy for box, lasso, and circle select (View 3D → Object, View 3D → Mesh, etc) why do they affect each other?

[Hologram]

@lcas

4. Forget about the keymap, cram everything in toolsettings. Optional header buttons.

I also lean towards this one. I know people want the keymap, but I think it is moat important to get this merged first. The best way to do so, I suppose is to keep it simple. Julian Kaspar was in favour of the tool settings, so it would at minimum need to be there.

@lcas

These are for toolsettings and keymap. You will choose from one or more userprefs to decide whether you want to use toolsettings or keymap. Toolsettings will hide themselves if using keymap, they are fairly well behaved.

Why should the keymap and toolsettings be mutually exclusive? What’s your reasoning?

Isn’t there another option where they both co-exist? Then you get to choose whether the keymap or tool settings are leading. I am thinking that if you want the toolsettings to be saved to the keymap, you’d choose that. If you want the keymap to prevail over the toolsettings (upon tool invocation) set it to that. Basically it would be a checkbox: “remember tool settings”. I would put this in the tool settings and not in the preferences
It’s not THAT important.

• yes > tool settings are updated to the keymap
• no > next time you invoke the tool through the keymap, the tool is reset to the way you had it in the keymap

@lcas

[…] the keymap is a menace, a threat to all mankind.

Yeah, it does require rework. Don’t be bothered with hiding the options in the keymap, I’d say. There are plenty of tools with many options, guess that’s the way it is until anyone dares reworking the keymap monster.

@lcas

This means that the best I can do is make additonal fake-ish selection operators that merely ask for box/lasso/circle select with the appropriate true and false pointers to show/hide the desired keymap operator properties.

Sounds like a hassle and prone to introducing bugs if you ask me.
I mean, if you hide any options, it also gets harder for people to change them.

Please keep it simple and try to submit some of your work and see how it goes. Have you tried discussing any of your ideas in the irc chat? Might also help to get some pointers from the devs…?

[lcas]

I should clarify, I’m just asking about the custom build, and it’s mostly to keep it simpler to look at and understand, without compromising flexibility. I could just hard-code it to be one way like blender is right now, but I think that’s pretty bad when the cost is some dropdowns / enums.

The stuff I am submitting to blender isn’t going to have a toolsettings vs keymap option in userprefs, or hideable header buttons. If it has a header button, like auto xray being in a dropdown next to the xray header button, that will be the only way that it works. I’ll either submit mutlple pull requests for each feature that are accessed different ways, or at least mention this is possible inside them while pointing at the custom build as an example of this.

So for the sake of serving as an example, and being useful to anybody who wants to use the keymap instead of toolsettings, I guess I’ll keep the keymap as an option. Also, probably just leave it cluttered with stuff. Better than the user having to manually edit their keymap for it to work right. Toolsettings users will be free to ignore the keymap options regardless, but I was hoping to be able to hide them if not being used. After the 3.5 build is done I’ll update all of the different pull requests, and take most of them out of WIP so it can get some eyes on it.

For the custom build my main issue is wanting to hide things in toolsettings when the user wants to use keymap, or the other way around, because they have to be mutually exclusive. They might not seem like they are, because they do the same thing, but toolsettings and keymap properties are totally different as far as what type of variable they are, where you have to point at to get them, and what sort of information you need in whatever script just to be able to point at them. If I want to offer both things, there has to be a way for the user to choose which one, and I’d rather hide the one that isn’t being used for confusion’s sake, if not to save some screen space. This works pretty ok for toolsettings, but not keymap without either completely, or at least partially, separating box select into different operators. This can be done, but not without having to manually edit your keymap, again, this would only be necessary if you want to use the keymap version of a feature instead of toolsettings.

Toolsettings and keymap function almost the same, the difference is that the keymap has more ways to set your shortcuts up, but cannot be toggled like toolsettings. To me this is a big deal because I would much rather toggle things on and off as needed instead of keeping my left hand mushed into some alt-shift whatever for the duration, or have to always drag left or right.

Keymap also comes with some strangeness as far as not being able to distinguish between object and edit mode, even from a mapping / setup perspective which I disagree with and don’t understand how it was ever like that. If you are going to separate them, separate them. Box, lasso, and circle might as well be in 3D View → 3D View (Global) instead of splitting it up like they are with 3D View → Object and 3D View → Mesh, because as far as I can tell it doesn’t matter what you do. Turn off ‘wait for input’, disable one of the keymap items, remap them to a different shortcut, add a different operator in there. If you do it in Mesh, go look at Object, they will be the same.

I never even noticed until I was testing out auto xray and select through, because they can happen in both Object and Edit mode, and they were just using a single bool inside the keymap. There was no auto xray mesh or auto xray object because with the keymap that shouldn’t be necessary. But it is. I was really confused why object and edit were in lock-step and thought I had done something wrong, but I come to find out it has been this way all along. Shows how little I mess with the object mode keymap. So now its an enum that specifys which mode instead of a bool.

[Hologram]

Interesting…
Disentangling mesh/ object/ curve selection seems logical (and have the default Blender keymap button options to configure them).

At this point, I think it’s getting hard for people to follow without a hands-on test to fully understand you. Since you know about all the inns-and-outs and potential caveats, I trust you on whatever decision you are going to make.
Your plan to keep the keymap as is sounds best indeed.

[lcas]

[BUILD] Blender 3.50 Custom Build
[DIFF] 350 custom

The latest commit to that diff has some binary junk either from doing a make icons or something else icon related, so you’ll have to scroll through a few things. Go have a look at this diff to get a better idea what is going on. That one will be updated to main (currently 3.6) but doesn’t have a couple ui things in it yet. Mainly it doesn’t show the mesh options thing if you are using the move, scale rotate tools with box, lasso, or circle.

I’ll probably make some videos for the different features, so I might as well make one for this build as well. Will be a few days at least though. For now I’ll just post a few screenshots with some descriptions

First thing, I’ve setup defaults, but they won’t apply if you already have a startup file for Blender 3.5. You’d either manually set them or start fresh if interested in seeing what the defaults are. My intention is to not alter vanilla Blender, but have some optional extensions of existing behaviour.

Second thing, a lot of these options are available as either a toolsetting or from the keymap. It’s an all or nothing thing, either all from keymap or all from toolsetting / header button. There’s a Userpref -> Input -> Mouse -> Drag Select Control to choose which way you want to use. Default is toolsettings. The toolsettings / header areas should disappear when you choose keymap, and the Mesh Options is collapsable.

The keymap options will only disappear if you use one of my optional box or lasso operators that merely hide the new operator props. Circle is also there but it doesn’t work right, you’ll see if you try to use it, the radius doesn’t update. Don’t really care about this, was a last minute idea, but wanted to at least attempt to make the keymap more dynamic. You can try these by changing the keymap id, just add a _toolsetting to the end of box and lasso. From view3d.select_box to view3d.select_box_toolsetting

1. Keymap Click-Drag Direction

Simplify mouse drag direction to left/right or up/down. Userpref to choose which one, Eight = no change (N, NE, E, SE, S, SW, W, NW) and then you have either Left Right or Up Down. If you use LR or UD you will have some operators that show up in the keymap to pick the direction for that keymap item. If you have something mapped to a non-applicable direction like South-East it will tell you it doesn’t have a direction for that keymap item. The only thing in the default keymap I’ve seen that uses anything like that is view3d.view_axis that does an Alt + Middle Mouse + North etc. No big loss especially if you have a numpad available. I actually thought directional keymap options were a new thing that was done after this and this were made, but turns out these directional options have been in keymap the whole time. Not interested in using directional drag for now, but it was interesting and relatively easy except for the adding to keymap part.

2. Mesh Select Options

Edges and Faces have new ways to select them with box, lasso, and circle. If you use the toolsetting version, you have directional control available in toolsettings. This area is collapsable.

Edges:

1. Hybrid - Blender default for box and lasso. If any edge is fully inside the selection area, select fully enclosed edges. Otherwise select any edges touched by the selection area. Not available for circle.

2. Touch - edges that are touched by the selection area, default for circle

3. Enclose - edges that are fully inside the selection area

Faces:

1. Auto - Blender default. If in solid shading, select any faces that are touched by the selection area. If in X-Ray, select faces when the selection area touches their center / facedot.

2. Touch - faces touched by the selection area

3. Enclose - faces fully inside the selection area

4. Center - faces whose center is touched by the selection area

3. Auto X-Ray
Turn on X-Ray during box, lasso, and circle. Either keymap or in a new popover next to the xray header button. Object and/or Edit mode, each tool can be opted out of individually. Optional header button that can either replace or sit next to the existing xray header button. Both this and select through have a custom icon provided by AlexeyAdamitsky

4. Select Through
Select unseen objects and mesh elements. Technically, this is just using X-Ray selection without the X-Ray visual change. In vanilla, you are forced to use select through in object, and are forbidden to use it in mesh. Now you have control over this. It works, and is located, exactly the same as Auto-Xray. If you turn off all 3 buttons in the xray popover, it will keep the xray button up there. You could have all 3 buttons visible if you wanted, but is it worth the risk? Who knows what would happen to your brain if you did this for very long? I hereby indemnify myself from all liability resulting from any psychological damage you incur should you ignore my warning and have all 3 xray header buttons visible. I will not show you this, I wouldn’t dare.

5. Viewport Facing Select
Can select mesh based on the direction of their normal, relative to the viewport. Box, lasso, and circle, near and/or xray select. This can filter for either facing toward the viewport, or away from it. It is toolsettings only, for box, lasso and circle. It is on/off for all 3 tools, but can do solid shading, xray, or both. Each mesh element (vert, edge, face) can be opted out of, and set differently. For me personally, I just wanted near select to not be so unreliable, because it almost always selects stuff that it should not. At least edge and face, verts seem good. I’ll make a video later, probably youtube for all the videos I am going to make because I can’t imagine they’d like that much space being used.

Verts

1. Front Verts - select verts that have normals facing the viewport
2. Vert of Front Face - select verts if they are part of a face that has a viewport-facing normal
3. Rear Verts - select verts that have normals that are facing away from the viewport
4. Vert of Rear Face - select verts if they are part of a face that has a normal that faces away from the viewport
5. All Verts - select verts regardless of their normal direction

Edges
Same as above, just replace vert with edge

Faces
Front and rear faces, same as vert and edge. Then there is Faces of Front Vert and Faces of Rear Vert. Faces of front vert will select a face if it contains at least one vertex that has a normal pointed at the viewport. Faces of rear vert is the same, just in reverse.

The All Faces etc are a way to opt out of a particular mesh element being calculated. This is for performance. The way I plan on using this would be in near select only, threshold seems to matter less than previous build so I think it’s fine at 0. This doesn’t mean it isn’t effective, it just doesn’t seem as necessary to give it a little padding to filter out unwanted edges and faces. Based on a very small amount of testing though. If you set the threshold higher, the mesh needs to be facing more and more in the direction of the viewport.

This still does not do exactly what I had hoped for, with faces you are stuck in a middle ground where you have to choose between not being able to select something visible but technically not pointed at the viewport, or having a more reliable (but still selects unseen faces so who cares) version. I think I will opt for the more reliable but sometimes annoying (because you can’t select something you can see) Front Faces rather than getting the same wonky behaviour that vanilla offers, just less of it and less often. Edges are either following the lead of Front Faces (reliable but not perfect) or they will actually look at the edge normals and not select things at the edges of your mesh. Verts don’t seem to have any problems as far as selecting unseen verts in near select. So I just leave them on All to save performance. Otherwise they will behave the same as edges do, follow how Front Face works or not select things on the edges of your mesh.

This feature also does not change anything about the other side of “select what you see” being wishful thinking. Flip some normals on your mesh and turn on backface culling. You can probably “see” some interior mesh elements that are behind a now invisible bit of mesh that has rear-facing normals. Near select (aka not X-Ray) will still not select what you can see. It will hit an unseen exterior bit of mesh and stop dead without proceeding to what is actually visible.

This is just how bitmap selection works, at least for now. I would not hold my breath for anything on that front. Like I had said a while back, maybe the planned use of Vulkan will affect the 3d Viewport and maybe that would actually change at least some of the really unusable and inconsistent aspects of near select.

Regardless, I think this can serve some purpose outside of my intentions. I don’t expect to see it getting any serious consideration for real blender, but you never know.

Second picture is how I plan on using this feature, if interested.

6. Select Object Origin
Keymap or toolsetting for box and circle. Can choose to select by object origin or not. Sorry, lasso don’t work right. But there’s good news, because this addon can get you what you want for lasso object select and probably other things you might not even know you needed. I’m not the one to ask about this addon though, because I’m not very familiar with it.

7. Single-Click Radius for Mesh
Selecting mesh with a single click has a radius that is a little excessive in my opinion, too big. Now it has an adjustable range in Userprefs -> Editing -> Miscellaneous -> Adjustable Click-Select. The default value will be the same as it is in vanilla Blender, but this is an opt-in feature. Why? Because despite this large radius for verts and edges, Blender has no love for single-clicking faces. Your cursor is either on top of the face, or you get nothing. This feature will change this so the three mesh elements behave the same. The radius itself is adjustable from “act like faces and make me click exactly on top of everything” to “please send help, the selection radius is twice as big as before”. Can also disable the small bias that is given to unseleced mesh elements. That is something that likely wouldn’t even be noticed, but it is there and can be seen if you put your cursor out in empty space at the limit of the selection radius. You can select something, but until you move the cursor a little closer, you won’t be able to deselect it.

8. Repeat Tool
New operator that will invoke the previous operator. Similar to repeat last except it will invoke instead of executing. Filters out stuff like delete, tranform, select all. Probably need to go through and do a proper filter list. If you ever need to undo, it loses memory of what was done before. Has to be added to keymap manually, id is screen.repeat_tool.

Why do this? Maybe you need to perform an awkwardly mapped, or unmapped, operator a handful of times on different things. And instead of executing it exactly the same way every time, you only want to invoke it, then proceed from there. Now you can do this a little easier. Perform the more obscure operator one time, then do a repeat_tool, which would ideally be mapped to something convenient.

9. Combine X-Ray and Shading Header Buttons
I don’t need a button to tell me when X-Ray is on, it’s usually pretty obvious. I also don’t need 4 buttons to pick a shading mode, I’ll use the pie menu or a keymap. And I definitely don’t need 4 buttons to tell me which shading mode I’m currently looking at, it’s usually pretty obvious and can be done with 1 button.

So, why not take 5 buttons I don’t need, and turn them into 1 button I don’t need? To be fair, I guess I need this button for one reason. It serves as an anchor for the Shading popover, because a floating myserty popover would just be weird. It is the usual X-Ray header button, except it changes its icon to reflect which shading mode you’re in. If enabled, the 4 clickable shading mode buttons will show themselves at the top of the Shading popover should you need them.

Finally, instead of having 2 X-ray header buttons, just replace the first one with a button to tell you if Select Through or Auto X-Ray is on. Not an option if you aren’t using toolsetting to control that, but not a big deal I imagine. You could always edit space_view3d.py to put the xray options back in the shading popover and remove the xray button + popover.

10. Frame Selected Distance
Sometimes view3d.view_selected puts the camera too close. I’d like to have control over that, and maybe even have different mappings for short and medium distance. This is an easy way to avoid extra scrolling, and scrolling, and scrolling, every time I use Frame Selected to get where I want it to be. The max offset I used was 1000, which is the edge of the default clipping.

11. Zoom Speed
Sometimes, you gotta go fast. Now you can. A bit sensitive though, careful how high you set this thing.

12. Header Highlights
The header of the active windows gets brighter. Don’t need this, can adjust it to be twice as bright or turn it all the way down. Userpref -> Interface -> Editors -> Header Highlight

13. X-Ray Facedot Toggle
Operator in Viewport Overlay Popover to turn off facedots for the current shading type (solid or xray).

14. Alternate Cursor(s)
This replaces the edit mode crosshair with a larger and more open one. The vanilla crosshair blocks what I am trying to look at, so I made this. I also included a bigger one, it’s too big but I had tried to mess with the one I already have and decided to make it optional. Userpref -> Editing -> Miscellaneous -> Alternate Cursor (and Large Cursor) PrtScn doesn’t capture cursor, so I’ll make a video and use a frame of that later.

I want to expand on this, make a handful of different cursor options for different things. Not a priority, but implementing should be pretty easy. I am thinking a dropdown list of cursors for each type that have options, with an icon representing what they look like (roughly).

Making a good cursor is very nitpicky and subjective work that I’m not terribly knowledgable about. If there’s any interest in this, I will likely ask for people to submit their own designs. Serious ideas or just nonsense for fun, who cares.

15. Python Macro / Operators
I put a few things I found useful inside of space_view3d.py. This is not where they should go, and should probably be some other place. Never figured out where that place is, and since they work fine I never looked very hard.

Gizmo Tweak / Move / Scale / Rotate
Show hide the translate tools, and depending which one is visible, you can do a tweak event instead of the usual click-drag on a gizmo thing. Taken from this, but I changed the names (can be mapped to whatever you want not just Q W E R) and just add them to the keymap manually instead of having icons / buttons for them.
ids
view3d.gizmo_tweak
view3d.gizmo_move
view3d.gizmo_scale
view3d.gizmo_rotate

Box Lasso
Cycle between box and lasso select instead of tweak → box → circle → lasso. id is view3d.box_lasso

I think that’s everything. Build has been updated. Depending how far out it is, any new fixes will be implemented in 3.51

[Hologram]

Really nice, thanks. Will give it a spin this week, I hope. Looks great based on the screenshots, no remarks other than that I would have preferred to pick left/ right or up/ down directions from within the keymap. That way, you could customise, mix and match them based on the tool. That is useful to mimic other software which has this all hardcoded. For instance you could do left/right for select touch/ enclosed or chose to use up/down if you feel daring. Bad example, but you get the point. But knowing you, you probably already tried to do this.
Big thanks for keeping this alive and expanding the featureset.

E: Do you want to ping Julien Kaspar already? Or what’s the plan on that?

[lcas]

Going to update the individual features to main so it can be taken out of work-in-progress. Will be done in a week or two, need to look for anything weird that I can fix and then send it. Things are supposed to get looked at within a few days, so we’ll see what happens

Guidelines for Reviewers

• The pull request text should be usable as the git commit message (see the guidelines for details).
• Be explicit when some changes are to be addressed before committing, without the need for a review iteration.
• If the pull request is not approved the author is expected to make another iteration.
• If the change needs agreement on the design task first, put the pull request on hold by adding a "WIP: " prefix in the title, indicating the author considers the pull request not ready to be merged. No review is expected unless the author specifically asks for it.
• Developers are expected to reply to pull requests in 3 working days.
• Add relevant modules/projects to tags.
• Assign individuals (instead of modules/projects) for reviewers, to avoid too much noise.
• Encourage new developers to do code review, it’s a good way to learn and important to grow the project

Some of it isn’t complete / fully functional but I will do auto xray, select through, mesh select options, some of the smaller stuff like header highlights and frame selected distance. Which of the mesh options I do I don’t know yet, maybe both toolsettings and keymap and see what if anything they have to say.

The directional stuff isn’t able to do both up down and left right at the same time without there being overlap. I could split things up more but I figured it’s best to keep it simple as possible. I could split the xray stuff (auto xray and select through) and the mesh select stuff (edge and face touch, enclose, center) so that you can use toolsettings/ header button for one and keymap for the other. Keymap can do the improved directional stuff for anything that can be assigned to a click-drag, but with mesh select options I added the ability to do the same thing from the toolsettings as well, because it was necessary if both options are available. This can lead to a situation where you assign a direction other than ‘any’ in the keymap, and have a directional assignment in toolsettings that wont work right, because it is only going to use the tool going one way or another based on the keymap being set in a somewhat incompatible way.

To keep it short there’s an order of things:

1. Detect what mouse direction is being done
2. Check which version to calculate (8way, LeftRight, UpDown)
3. Check if the userpref is set to use the keymap or toolsettings.
   A. If toolsettings, do an event match after checking which direction is assigned, but first it sets a toolsetting from the direction calulation in step 2 (this is weird, but works fine). Then it looks at a direction toolsetting inside view3d_select and gets the corresponding value depending what was done in step 2.
   B. If keymap, do an event match but only calculate direction for the sake of detecting which keymap item to look at, then it just looks at the operator prop directly from whichever keymap item that matches the event that was detected, instead of doing this little relay race thing that toolsettings does.

The event match is what determines the tool that is being used, and the calculation done in step 2 is mutually exclusive. Since the directional part comes before it knows what tool is being used, I don’t know what I would do to split things up where you could mix and match 8way, up/down, and left/right. Maybe some dead-zone where it wouldn’t look until after a certain distance, and then base the calculation type on which direction (vertical vs horizontal) is being moved in more. I think this dead-zone is already done to some degree to detect drag vs click. Not going to look into though

[Hologram]

@lcas

Going to update the individual features to main so it can be taken out of work-in-progress. Will be done in a week or two, need to look for anything weird that I can fix and then send it. Things are supposed to get looked at within a few days, so we’ll see what happens

Hope that’s indeed the case now that the old system is archived.

@lcas

To keep it short there’s an order of things:

1. Detect what mouse direction is being done
2. Check which version to calculate (8way, LeftRight, UpDown)
3. Check if the userpref is set to use the keymap or toolsettings.
   A. If toolsettings, do an event match after checking which direction is assigned, but first it sets a toolsetting from the direction calulation in step 2 (this is weird, but works fine). Then it looks at a direction toolsetting inside view3d_select and gets the corresponding value depending what was done in step 2.
   B. If keymap, do an event match but only calculate direction for the sake of detecting which keymap item to look at, then it just looks at the operator prop directly from whichever keymap item that matches the event that was detected, instead of doing this little relay race thing that toolsettings does.

And what about a simplified as a single drop down in the keymap from which you infer step 2. and step 3b? The dropdown would display all options (N, NE, E, SE, S, SW, W, NW, Left, Right, Up, Down), in which if you choose the Left or Right option, you’d set the calculation method to LeftRight and if you choose Up or Down you set the calculation method to Up or Down, else, 8way.
But you probably already tried that and found out it wasn’t that trivial. You’d have to be able to specify not to use tool settings on this particular keymap item (idk how if toolsettings precede keymap settings) It would yield the largest flexibility for the user. You already have so many options, so I see why you wouldn’t want to add this to the pile as well. This has very low priority, just noting it down for future reference maybe when things already got merged. Or just not and leave as is

[lcas]

I had made left and right, up and down, in addition to the existing directions. It has problems with assignment though. You’d have to manually recreate every single keymap item that intended to use these new directions. So instead, I made LR UD work in name only. They are still East West North and South behind the scenes to avoid unecessary reconfiguration and all that.

Could just have keymap directions, but I wanted to emulate what the other patches did with useprefs, but make it more accessible by putting in toolsettings. The toolsettings directions are only applicable for mesh selection stuff for box, lasso, and circle. The keymap click-drag directions will apply regardless, and supercede toolsettings. You could set the userpref to Up Down, and make a corresponding keymap direction to fit that. Then keep the mesh drag control userpref on toolsettings, set the direction in there to Left Right. The keymap won’t affect mesh stuff, but things like mode (set, extend, subtract, intersect, difference) and “wait for input” would be determined by the keymap still. Up and to the Left would then be a thing, but not affect the same aspects of box, lasso, and circle. I think so anyways, I’ll check it and see.

This aspect is part of why I would like the keymap to dynamically look at userprefs to show/hide different operator props. But no matter what I told it, this would not be done. I had to tell it true or false in a redundant operator props init thing, which required a different operator that I called the same name with a “_toolsetting” at the end.

Using the keymap vs toolsetting for mesh options, and determining a direction isn’t that weird or complicated, but I’ll call it that anyways. Best as I understant it at least, Blender tries to match an event with whatever it can find in the keymap. To check click-drag direction, it has to do this before matching anything, otherwise the keymap couldn’t set it. It would be like Blender predicting what you were going to do ahead of time.

[Hologram]

Basically, I was thinking, perhaps it’s possible to change brush presets and such through Left/ right movement to decrease/ increase the settings respectively. Something like that might also be applicable to the “Rotate an HDRI addon”. I see why you want to set this using the preferences, but I understand you can still set a different direction in the keymap and use that regardless of the preference direction method setting. Isn’t that confusing? Maybe add a tooltip that this is indeed possible?

In Krita, there now is an addon to dynamically change settings/ slider values by moving the mouse/ pen:

Shortcut Composer v1.5.4 - Plugin for Pie menus, Multiple key assignment,...

It works great and I think it would be neat to do this too in Blender. That’s why I’m asking about possibilities. Perhaps a similar Blender addon could be made for Blender in the future when your directional patch is accepted.

[lcas]

As long as you make the extra keymap items, and the toolsettings direction is either set to “Any” direction, or set to match what you wanted in the keymap, it should be good to go. Like you couldn’t control mesh options from the keymap with it setup this way, its looking at toolsettings, but it would be the same thing with extra steps and you’d control the non-mesh stuff in the keymap. At that point you might at well set it to be keymap controlled because nothing is being gained from it being toolsetting controllable.

The amount of toolsettings vs keymap stuff doing the same thing isn’t ideal and not intended for real blender, I’m just providing both things in one build. Adjusting other settings with drag left and right might be something that could be done with keymap gesture stuff, I don’t know much about any of that though.

I remade the build, everything should be in there now. Depending how far out it is, any new fixes will be implemented in 3.51, top post updated.

[1D_Inc]

Hi! Can you remind where I can take the latest build?