Tweaks & Fixes for Improved Left Click Select Support (Parent task) #57918

New Issue

Recently, an initial version of the updated approach to the left click keymap was added to Blender 2.8.

This makes it possible to use the active tools, as well as selection, both with the left mouse button. However, there are a few issues still with how it works. Here's a list of things we should improve:

High Priority

These are issues we should fix before the initial release of Blender 2.80

- {icon circle color=red} #63193 (Animation Editor Scrubbing Area)
- {icon circle color=red} #63996 (Click over a Gizmo to select items underneath it)
- {icon circle color=red} #63995 (Deselect by Clicking in Empty Area)
- 3D View
- UV Editor
- Node Editor
- Sequencer
- Markers
- Dopesheet
- Graph Editor
- NLA
- Clip Editor Clip view
- Outliner
- File Browser
- {icon circle color=red} Dragging in empty areas to box select:
- Node Editor
- Sequencer
- Markers
- Dopesheet
- Graph Editor
- NLA
- Outliner
- File Browser
- {icon circle color=red} Dragging on a selected item should move all selected items:
- Node Editor #63994 (Node Editor: Move All Selected Nodes when dragging)
- Sequencer
- Markers
- Dopesheet
- Graph Editor #70634 (Graph Editor: Reevaluate Key and Handle Selection Behavior)
- NLA
- Outliner

Recently, an initial version of the updated approach to the left click keymap was added to Blender 2.8. This makes it possible to use the active tools, as well as selection, both with the left mouse button. However, there are a few issues still with how it works. Here's a list of things we should improve: ## High Priority These are issues we should fix before the initial release of Blender 2.80 - - [x] {icon circle color=red} #63193 (Animation Editor Scrubbing Area) - - [x] {icon circle color=red} #63996 (Click over a Gizmo to select items underneath it) - - [x] {icon circle color=red} #63995 (Deselect by Clicking in Empty Area) - - [x] 3D View - - [x] UV Editor - - [x] Node Editor - - [x] Sequencer - - [x] Markers - - [x] Dopesheet - - [x] Graph Editor - - [x] NLA - - [x] Clip Editor Clip view - - [x] Outliner - - [x] File Browser - - [x] {icon circle color=red} Dragging in empty areas to box select: - - [x] Node Editor - - [x] Sequencer - - [x] Markers - - [x] Dopesheet - - [x] Graph Editor - - [x] NLA - - [x] Outliner - - [x] File Browser - - [x] {icon circle color=red} Dragging on a selected item should move all selected items: - - [x] Node Editor #63994 (Node Editor: Move All Selected Nodes when dragging) - - [x] Sequencer - - [x] Markers - - [x] Dopesheet - - [x] Graph Editor #70634 (Graph Editor: Reevaluate Key and Handle Selection Behavior) - - [x] NLA - - [x] Outliner

Added subscribers: @WilliamReynish, @0o00o0oo, @jeacom, @ThalesDavidsen, @nokipaike, @sebastianmroy, @L0Lock, @YAFU, @Fiendari, @Vinc3r, @Iscream3D, @cedriclepiller, @Znio.G, @DanPool, @WiresoulStudio, @PetterLundh, @Rawalanche, @JulienKaspar, @RainerTrummer, @mendio, @TheRedWaxPolice, @cyaoeu, @DuarteRamos, @JonDoe286, @brecht

#61229 was marked as duplicate of this issue

#56605 was marked as duplicate of this issue

Added subscriber: @Regnas

In 3D View, we should make Shift+doubleclick toggle loops, rather than always extend (consistent with alt-click behaviour, and makes it possible to deselect loops too)

Hi, Shift+doubleclick to toggle loops doesn't seem like a good thing. If you do this, then how we will be able to extend the loops by double clicking?
In softwares where they use the double click to select loops, the shift+doubleclick is always to extend and Ctrl+doubleclick is to deselect loop. This is very consistent, and imo this is how it should work in blender too.

> **In 3D View, we should make Shift+doubleclick toggle loops, rather than always extend (consistent with alt-click behaviour, and makes it possible to deselect loops too)** Hi, Shift+doubleclick to toggle loops doesn't seem like a good thing. If you do this, then how we will be able to extend the loops by double clicking? In softwares where they use the double click to select loops, the shift+doubleclick is always to extend and Ctrl+doubleclick is to deselect loop. This is very consistent, and imo this is how it should work in blender too.

@Regnas: You'll be able to do that by holding Shift. Shift-Alt-click to select more loops also works this way. The only described change her is to make the double-click feature consistent with the alt-click feature.

Alright.
Shift-Alt-click always felt a little heavy for that btw. I thought for the left click select mode you were willing to simplify that.

Alright. Shift-Alt-click always felt a little heavy for that btw. I thought for the left click select mode you were willing to simplify that.

@Regnas: Yes, it's Shift double-click. I'm confused by what you mean.

Added subscriber: @jendrzych

Shift mod. key adds to selection when used in companion with LMB Box Select and Ctrl + Box Select removes from so far made selection. But simple point and click with above mentioned mod. keys doesn’t work in consistent way. Shift adds to selection, while Ctrl makes last clicked object selected and active, cancelling the rest of so far made selection.
It should work the same way, no matter what kind of selection is performed - simple click, Box, Lasso, Paint (no-ides-why-it’s-called “Circle”) selection…
Simple click should wipe selection as well. In crowded scene it will start new selection, so as the Box Select does now.

Shift mod. key adds to selection when used in companion with LMB Box Select and Ctrl + Box Select removes from so far made selection. But simple point and click with above mentioned mod. keys doesn’t work in consistent way. Shift adds to selection, while Ctrl makes last clicked object selected and active, cancelling the rest of so far made selection. It should work the same way, no matter what kind of selection is performed - simple click, Box, Lasso, Paint (no-ides-why-it’s-called “Circle”) selection… Simple click should wipe selection as well. In crowded scene it will start new selection, so as the Box Select does now.

@jendrzych: yes, that's why I added that item to the list. It's the third item in the list.

Added subscriber: @ideasman42

Added subscriber: @michaelknubben

For my own reference, trying to figure out exact behavior of LMB in various cases. The logic can get quite complicated, and it may be best to implement some of these as modal Python operators that call other operators.

Planned

Animation Editors

PRESS
If over keyframe: select keyframe, deselect all others Else: deselect all
EVT_TWEAK
If keyframe(s) selected: tweak transforms Else: box select

This one prioritizes quick transform tweak of just the keyframes under the mouse.

Node Editor

PRESS
If over node: select node, don't deselect others. Else: deselect all
CLICK
** If over node: deselect other nodes.
EVT_TWEAK
If node(s) selected: tweak transform Else: box select

In this case, quick transform tweak does not deselect other nodes. It's inconsistent with animation editors, but maybe ok given different type of data being edited.

The complex logic with both PRESS and CLICK handling would be to avoid click delays, but is perhaps not needed and only CLICK may be ok.

3D Viewport Select Tool

PRESS
If over object: select object, deselect all others Else: deselect all
EVT_TWEAK_L
** If object(s) selected: transform Tweak

This tool is for users that want the 2.7x style interaction, like having no tool active.

3D Viewport Box Select Tool

CLICK
If over object: select object, deselect all others Else: deselect all
EVT_TWEAK_L
** Box select

This one suffers from click delay. It seems unavoidable, unless we accept box select changing the active object which is odd, and also unresponsive behavior in complex scenes where selecting an objects takes a while.

Ideas

3D Viewport Transform Tool with Auto Tweak

PRESS
** If nothing selected: select object, deselect all others, enter tweak mode
CLICK
** If not in tweak mode: select object, deselect all others
EVT_TWEAK
** Transform
RELEASE:
** If in tweak mode: deselect all

For my own reference, trying to figure out exact behavior of LMB in various cases. The logic can get quite complicated, and it may be best to implement some of these as modal Python operators that call other operators. ## Planned **Animation Editors** * PRESS **If over keyframe: select keyframe, deselect all others** Else: deselect all * EVT_TWEAK **If keyframe(s) selected: tweak transforms** Else: box select This one prioritizes quick transform tweak of just the keyframes under the mouse. **Node Editor** * PRESS **If over node: select node, don't deselect others.** Else: deselect all * CLICK ** If over node: deselect other nodes. * EVT_TWEAK **If node(s) selected: tweak transform** Else: box select In this case, quick transform tweak does not deselect other nodes. It's inconsistent with animation editors, but maybe ok given different type of data being edited. The complex logic with both PRESS and CLICK handling would be to avoid click delays, but is perhaps not needed and only CLICK may be ok. **3D Viewport Select Tool** * PRESS **If over object: select object, deselect all others** Else: deselect all * EVT_TWEAK_L ** If object(s) selected: transform Tweak This tool is for users that want the 2.7x style interaction, like having no tool active. **3D Viewport Box Select Tool** * CLICK **If over object: select object, deselect all others** Else: deselect all * EVT_TWEAK_L ** Box select This one suffers from click delay. It seems unavoidable, unless we accept box select changing the active object which is odd, and also unresponsive behavior in complex scenes where selecting an objects takes a while. ## Ideas **3D Viewport Transform Tool with Auto Tweak** * PRESS ** If nothing selected: select object, deselect all others, enter tweak mode * CLICK ** If not in tweak mode: select object, deselect all others * EVT_TWEAK ** Transform * RELEASE: ** If in tweak mode: deselect all

Sounds about right.

In #57918#557591, @brecht wrote:
For my own reference, trying to figure out exact behavior of LMB in various cases. The logic can get quite complicated, and it may be best to implement some of these as modal Python operators that call other operators.
==== Node Editor ====

EVT_TWEAK
** If node(s) selected: tweak transform
** Else: box select

Not sure if we can get this level of granularity with the current system, but in the node editor (and where meaningful) EVT_TWEAK would ideally only tweak transform when started from over selected items, even if a selection exists
If started elsewhere, over empty area or unselected objects, it would still box select.

This is looking quite promising!

Sounds about right. > In #57918#557591, @brecht wrote: > For my own reference, trying to figure out exact behavior of LMB in various cases. The logic can get quite complicated, and it may be best to implement some of these as modal Python operators that call other operators. > ==== Node Editor ==== > * EVT_TWEAK > ** If node(s) selected: tweak transform > ** Else: box select Not sure if we can get this level of granularity with the current system, but in the node editor (and where meaningful) EVT_TWEAK would ideally only tweak transform when started from over selected items, even if a selection exists If started elsewhere, over empty area or unselected objects, it would still box select. This is looking quite promising!

Not sure if we can get this level of granularity with the current system, but in the node editor (and where meaningful) EVT_TWEAK would ideally only tweak transform when started from over selected items, even if a selection exists
If started elsewhere, over empty area or unselected objects, it would still box select.

When starting over empty space, the logic as is would always box select. When starting over an unselected node, it would do transform tweak of that single node. We can't have both that and box select.

> Not sure if we can get this level of granularity with the current system, but in the node editor (and where meaningful) EVT_TWEAK would ideally only tweak transform when started from over selected items, even if a selection exists > If started elsewhere, over empty area or unselected objects, it would still box select. When starting over empty space, the logic as is would always box select. When starting over an unselected node, it would do transform tweak of that single node. We can't have both that and box select.

In #57918#557595, @brecht wrote:

When starting over an unselected node, it would do transform tweak of that single node.

Yes that is what I meant, sounds perfect that way. Thanks

> In #57918#557595, @brecht wrote: >> When starting over an unselected node, it would do transform tweak of that single node. Yes that is what I meant, sounds perfect that way. Thanks

In #57918#557595, @brecht wrote:
We can't have both that and box select.

Does this mean that dragging while over an object will box select? Shouldn’t box select only trigger if your drag starts over an empty space.

> In #57918#557595, @brecht wrote: >We can't have both that and box select. Does this mean that dragging while over an object will box select? Shouldn’t box select only trigger if your drag starts over an empty space.

In #57918#557613, @DanPool wrote:
Does this mean that dragging while over an object will box select? Shouldn’t box select only trigger if your drag starts over an empty space.

We could do either. What I'm proposing is to only do box select when starting over empty space.

> In #57918#557613, @DanPool wrote: > Does this mean that dragging while over an object will box select? Shouldn’t box select only trigger if your drag starts over an empty space. We could do either. What I'm proposing is to only do box select when starting over empty space.

re:

It should be possible to click over a Gizmo to select items underneath it, as long as you don't drag.

This has some implications:

Selection will have to happen on click, if only for the cases gizmo's overlay a selection. This may be annoying or seem glitchy if its only happening sometimes.
Either we limit gizmos never to respond of press/click events (making them less useful) or add a flag for gizmos not to respond to press events, only dragging.

re: > - [ ] It should be possible to click over a Gizmo to select items underneath it, as long as you don't drag. This has some implications: - Selection will have to happen on click, if only for the cases gizmo's overlay a selection. This may be annoying or seem glitchy if its only happening *sometimes*. - Either we limit gizmos never to respond of press/click events *(making them less useful)* or add a flag for gizmos not to respond to press events, only dragging.

Hmm, yes, I see. This was reported by users who want to keep the gizmo on, but also still be able to select things reliably, without the gizmo getting in the way and stealing the input while using LMB select.

Seems like a fairly basic thing, and is supported in some other apps (eg 3Ds Max)

Some apps solve this by having a fast way to hide gizmos (Maya)

Other apps don’t allow selection while using a tool at all (Modo)

Not sure which solution best.

Hmm, yes, I see. This was reported by users who want to keep the gizmo on, but also still be able to select things reliably, without the gizmo getting in the way and stealing the input while using LMB select. Seems like a fairly basic thing, and is supported in some other apps (eg 3Ds Max) Some apps solve this by having a fast way to hide gizmos (Maya) Other apps don’t allow selection while using a tool at all (Modo) Not sure which solution best.

Thinking more, making the gizmos respond only to dragging is more consistent with the general tools paradigm - the same applies to dragging in the viewport. But, if the gizmos feel sluggish it’s also not nice.

Making gizmos respond to dragging may be OK in general way but I don't think it's something we should enforce in all cases.

Enforcing dragging means for eg, you wont be able to click and make small changes to the cameras lens.

Depending on how its implemented it could break the view-axis click action where dragging orbits the view and click sets the view axis.

Making gizmos respond to dragging may be OK in general way but I don't think it's something we should enforce in all cases. Enforcing dragging means for eg, you wont be able to click and make small changes to the cameras lens. Depending on how its implemented it could break the view-axis click action where dragging orbits the view and click sets the view axis.

I've just tested 3ds Max, and it happens exactly as Campbell had described. If cursor is both over a gizmo handle and selectable item, then on click (mouse press and release) without cursor being moved, item is selected. When the mouse cursor is just on a selectable item, without gizmo on top, then the selection already happens on button down, not after the release.

I've been using 3ds Max for over 8 years and never noticed anything odd about this behavior. So any concerns about it appearing glitchy are probably not very relevant.

In general, it's crucial that there is very easy and straightforward way to very quickly and comfortably switch between selection tool and transform tools. Selection tool can currently be accessed conveniently using W key, but unfortunately, transform tools shortcuts are hidden behind weird spacebar+letter key combos which are a bit counter intuitive, making switching between transform tools and selection tool feel less accessible. If switching between selection and transforming is so easy it's effortless, then people are not going to be very concerned about switching back and forth in rare cases where this issue appears.

Regarding enforcing dragging. All the transform tool gizmos do absolutely nothing on click only. The only way to interact with them is to actually click and drag. If the issue is something as miniscule as adjusting camera lens using gizmo (which I can guarantee you almost no one will ever do), then simply apply this new behavior only to the tools in edit mode.

I've just tested 3ds Max, and it happens exactly as Campbell had described. If cursor is both over a gizmo handle and selectable item, then on click (mouse press and release) without cursor being moved, item is selected. When the mouse cursor is just on a selectable item, without gizmo on top, then the selection already happens on button down, not after the release. I've been using 3ds Max for over 8 years and never noticed anything odd about this behavior. So any concerns about it appearing glitchy are probably not very relevant. In general, it's crucial that there is very easy and straightforward way to very quickly and comfortably switch between selection tool and transform tools. Selection tool can currently be accessed conveniently using W key, but unfortunately, transform tools shortcuts are hidden behind weird spacebar+letter key combos which are a bit counter intuitive, making switching between transform tools and selection tool feel less accessible. If switching between selection and transforming is so easy it's effortless, then people are not going to be very concerned about switching back and forth in rare cases where this issue appears. Regarding enforcing dragging. All the transform tool gizmos do absolutely nothing on click only. The only way to interact with them is to actually click and drag. If the issue is something as miniscule as adjusting camera lens using gizmo (which I can guarantee you almost no one will ever do), then simply apply this new behavior only to the tools in edit mode.

In #57918#559078, @WilliamReynish wrote:
Other apps don’t allow selection while using a tool at all (Modo)

This function is a toggle in Modo.

> In #57918#559078, @WilliamReynish wrote: > Other apps don’t allow selection while using a tool at all (Modo) This function is a toggle in Modo.

In #57918#559090, @ideasman42 wrote:
Enforcing dragging means for eg, you wont be able to click and make small changes to the cameras lens.

This could be a good thing? Fewer possibilities for input error then.

> In #57918#559090, @ideasman42 wrote: > Enforcing dragging means for eg, you wont be able to click and make small changes to the cameras lens. This could be a good thing? Fewer possibilities for input error then.

In #57918#559091, @Rawalanche wrote:
If cursor is both over a gizmo handle and selectable item, then on click (mouse press and release) without cursor being moved, item is selected. When the mouse cursor is just on a selectable item, without gizmo on top, then the selection already happens on button down, not after the release.

That seems like a solution that would work. There are a lot of ifs and buts making it perhaps a bit complicated to implement, but it would make things more consistent and reliable for the user: Click to select, drag to use tool.

> In #57918#559091, @Rawalanche wrote: >If cursor is both over a gizmo handle and selectable item, then on click (mouse press and release) without cursor being moved, item is selected. When the mouse cursor is just on a selectable item, without gizmo on top, then the selection already happens on button down, not after the release. That seems like a solution that would work. There are a lot of ifs and buts making it perhaps a bit complicated to implement, but it would make things more consistent and reliable for the user: Click to select, drag to use tool.

Added subscriber: @elbox01

Added subscriber: @Coverty

Added subscriber: @JulienDuroure

Hello,

What about Pose Mode + Weight Painting on mesh?
With Left Click Select, LMB is always painting, without any action on bones

Hello, What about Pose Mode + Weight Painting on mesh? With Left Click Select, LMB is always painting, without any action on bones

It's Ctrl+LMB to select bones.

Uncertain if this is related to this change, but it feels harder to connect nodes now than before. I often activate box select by accident because the node connection hitbox is so small.

@PetterLundh Yes that is a problem. When I test it, it just seems random if it starts a node connection or a box selection. The two are fighting and a random one wins. Instead, box select should only fire if outside the hitbox margin defined by the socket connection.

Added subscriber: @Dheim

Added subscriber: @BintangPratama

Added subscriber: @fabioroldan

Drag action in tools should include box, circle and lasso selection. A bug is that none moves the object. And also this type of selection configuration must be shared by all the tools.

@fabioroldan Yes, indeed, the Drag Action = None behaviour is a bug, basically. Drag Action options could be added to other tools as well, yes.

Added subscriber: @GatisKurzemnieks

Added subscriber: @Meat

Removed subscriber: @Meat

Added subscriber: @Meat

In Blender 2.8 Beta: When saving a customized keybinding (adding a preset) the "Preferences" box where you can choose left/right click and spacebar Action disappears, I believe this is a bug?

@ThalesDavidsen, it's intentional, these only work for the builtin keymap. For custom presets it's not possible to make automatic changes to the keymap in a reliable way.

@ThalesDavidsen That's not a bug, no. The keymap preferences are only for the built-in keymap. It's some code in the keymap Python file.

I guess custom keymaps can add this too manually by adding the required logic.

@ThalesDavidsen That's not a bug, no. The keymap preferences are only for the built-in keymap. It's some code in the keymap Python file. I guess custom keymaps can add this too manually by adding the required logic.

@brecht , ok thats a pitty, but I if its a technical limitation I understand at least Blender have the option to choose left/right moste software do not have this choose anyway. Does this also apply to the Spacebar Action? I have found mysealf changing the keybinding and then later on forgot to change the spacebar action from "Play" to "search". Is their any way I can go back and change the spacebar Action after I have saved the new keybinding preset?

@ThalesDavidsen You can simply go to Preferences > Input to set this however you want. But this is not really relevant to the topic of improving left click selection.

@brecht: Here's a patch to fix three issues in the Node Editor: D4055

Shift-click to select multiple nodes
Re-route mapped to shift-RMB
Cut Connections mapped to Ctrl-RMB to fix conflict with Box Select.

@brecht: Here's a patch to fix three issues in the Node Editor: [D4055](https://archive.blender.org/developer/D4055) - Shift-click to select multiple nodes - Re-route mapped to shift-RMB - Cut Connections mapped to Ctrl-RMB to fix conflict with Box Select.

Added subscriber: @ikester_blender

Added subscriber: @cez

Added subscriber: @capnm

Added subscriber: @zaha

Added subscriber: @KartoonHead

Added subscriber: @orvb

Removed subscriber: @Iscream3D

Added subscriber: @yrrnn

Added subscriber: @clawjelly

Another thing to discuss related to the keymap, is that some users would like to be able to do box select while the transform gizmos are visible. I see two ways to do this:

Add Box Select to the Drag Action dropdown inside the transform tools
Add some new way to make transform gizmos visible while other tools are active

I strongly prefer solution #1. It fits neatly within the current paradigm and causes no conflicts. Solution #2 can potentially cause lots of confusion and conflicts, because what if you then have the transform gizmos enabled while enabling the Shear tool, for example. You get two gizmos on top of each other.

Also, from a user POV, the mental model is that the gizmo is part of the tool. Seeing the Move tool gizmo when the Move tool is not active will just create all sorts of confusion.

We already have the concept of Drag Action (some apps call this setting 'Haul') so all that is needed is to add selection there.

This is much more like what other DCC apps do. In short, if we are going to add this capability, #1 is how I think we should do it.

Another thing to discuss related to the keymap, is that some users would like to be able to do box select while the transform gizmos are visible. I see two ways to do this: - Add Box Select to the Drag Action dropdown inside the transform tools - Add some new way to make transform gizmos visible while other tools are active I strongly prefer solution #1. It fits neatly within the current paradigm and causes no conflicts. Solution #2 can potentially cause lots of confusion and conflicts, because what if you then have the transform gizmos enabled while enabling the Shear tool, for example. You get two gizmos on top of each other. Also, from a user POV, the mental model is that the gizmo is part of the tool. Seeing the Move tool gizmo when the Move tool is not active will just create all sorts of confusion. We already have the concept of Drag Action (some apps call this setting 'Haul') so all that is needed is to add selection there. This is much more like what other DCC apps do. In short, if we are going to add this capability, #1 is how I think we should do it.

Added subscriber: @ThinkingPolygons

In #57918#611187, @WilliamReynish wrote:
some users would like to be able to do box select while the transform gizmos are visible.

Yes. This is truly needed indeed, and I'd go with option #1 too.
But please consider adding to the Drag Action dropdown the Lasso and Circle select as well, so we don't get limited to just Box select. Like:

There are situations where the Lasso or the Circle are more handy than the Box select, so it would be great to have access to those as well.

> In #57918#611187, @WilliamReynish wrote: > some users would like to be able to do box select while the transform gizmos are visible. Yes. This is truly needed indeed, and I'd go with option #1 too. But please consider adding to the Drag Action dropdown the Lasso and Circle select as well, so we don't get limited to just Box select. Like: ![Complete Drag Action Options.jpg](https://archive.blender.org/developer/F6466919/Complete_Drag_Action_Options.jpg) There are situations where the Lasso or the Circle are more handy than the Box select, so it would be great to have access to those as well.

Yes, for sure, those could be in there too.

Great. ?

In #57918#611187, @WilliamReynish wrote:
Another thing to discuss related to the keymap, is that some users would like to be able to do box select while the transform gizmos are visible. I see two ways to do this:

Yeah, many users are waiting for this ability.
And yes, solution #1 seems to be the best.

> In #57918#611187, @WilliamReynish wrote: > Another thing to discuss related to the keymap, is that some users would like to be able to do box select while the transform gizmos are visible. I see two ways to do this: Yeah, many users are waiting for this ability. And yes, solution #1 seems to be the best.

Thanks for tackling the issue of not being able to box select while in transform mode, very welcome development!
Tried to replicate this myself by doing different things to the keymap before but I kept running into different problems, so quickly gave up. Glad to see it will officially be remedied.

Out of the two options, I think #2 is ideal, but #1 would be the quick(er) fix.

It's fine for hotkey users who enable tools via hotkey, but it's a little weird selecting a tool and seeing the manipulator going away.
For instance, the expected behavior for people coming from other programs might be like how Maya does extrusions: https://youtu.be/3mvIl3nyz7Q?t=31

If I extrude, being able to also quickly adjust transformation of that extrusion without having to switch tools is a much more fluid workflow.

Also, customized manipulator per tool giving quick access to useful tool options in the viewport would be fantastic. For tools where transform manipulator would actually hinder (though I frankly can't think of one), it could be hidden when it makes sense. But even with Shear, for me, it's welcome to have the transform manipulator.

Another approach
Or maybe another approach to explore is if the user can [Shift]+select/enable multiple tools? It would basically allow for one tool per category.
For instance, Shift selecting Transform, Extrude, and Box Select. If user selects the Knife tool, Extrude would be toggled off, but Transform and Box Select are still enabled.

Thanks for tackling the issue of not being able to box select while in transform mode, very welcome development! Tried to replicate this myself by doing different things to the keymap before but I kept running into different problems, so quickly gave up. Glad to see it will officially be remedied. Out of the two options, I think #2 is ideal, but #1 would be the quick(er) fix. It's fine for hotkey users who enable tools via hotkey, but it's a little weird selecting a tool and seeing the manipulator going away. For instance, the expected behavior for people coming from other programs might be like how Maya does extrusions: https://youtu.be/3mvIl3nyz7Q?t=31 ![image.png](https://archive.blender.org/developer/F6474052/image.png) If I extrude, being able to also quickly adjust transformation of that extrusion without having to switch tools is a much more fluid workflow. Also, customized manipulator per tool giving quick access to useful tool options in the viewport would be fantastic. For tools where transform manipulator would actually hinder (though I frankly can't think of one), it could be hidden when it makes sense. But even with Shear, for me, it's welcome to have the transform manipulator. **Another approach** Or maybe another approach to explore is if the user can [Shift]+select/enable multiple tools? It would basically allow for one tool per category. For instance, Shift selecting Transform, Extrude, and Box Select. If user selects the Knife tool, Extrude would be toggled off, but Transform and Box Select are still enabled.

Added subscriber: @AnadinX

One more thought would be that PS And Affinity use shift+shortcut to do the toggle. E.g w to change to select tool. Shift+w toggles select mode?

Added subscriber: @Nomo

@WilliamReynish Could it be possible to place the 3D cursor at the world axis when Shift+RMB clicking an empty area? Effectively creating a context-sensitive way to reset the cursor orientation. I think that this could be implemented by creating a secondary orientation method using empty selection.

Added subscriber: @blenderUser0803

In #57918#611187, @WilliamReynish wrote:
Another thing to discuss related to the keymap, is that some users would like to be able to do box select while the transform gizmos are visible. I see two ways to do this:

Add Box Select to the Drag Action dropdown inside the transform tools

Add some new way to make transform gizmos visible while other tools are active

I strongly prefer solution #1. It fits neatly within the current paradigm and causes no conflicts. Solution #2 can potentially cause lots of confusion and conflicts, because what if you then have the transform gizmos enabled while enabling the Shear tool, for example. You get two gizmos on top of each other.

Also, from a user POV, the mental model is that the gizmo is part of the tool. Seeing the Move tool gizmo when the Move tool is not active will just create all sorts of confusion.

We already have the concept of Drag Action (some apps call this setting 'Haul') so all that is needed is to add selection there.

This is much more like what other DCC apps do. In short, if we are going to add this capability, #1 is how I think we should do it.

Maybe this deserves a new separate task, don't you think?
I mean, this is truly needed.

> In #57918#611187, @WilliamReynish wrote: > Another thing to discuss related to the keymap, is that some users would like to be able to do box select while the transform gizmos are visible. I see two ways to do this: > > # Add Box Select to the Drag Action dropdown inside the transform tools > # Add some new way to make transform gizmos visible while other tools are active > > I strongly prefer solution #1. It fits neatly within the current paradigm and causes no conflicts. Solution #2 can potentially cause lots of confusion and conflicts, because what if you then have the transform gizmos enabled while enabling the Shear tool, for example. You get two gizmos on top of each other. > > Also, from a user POV, the mental model is that the gizmo is part of the tool. Seeing the Move tool gizmo when the Move tool is not active will just create all sorts of confusion. > > We already have the concept of Drag Action (some apps call this setting 'Haul') so all that is needed is to add selection there. > > This is much more like what other DCC apps do. In short, if we are going to add this capability, #1 is how I think we should do it. Maybe this deserves a new separate task, don't you think? I mean, this is truly needed.

Hey, thanks for addressing this. Here's my recommendation.

Another thing to discuss related to the keymap, is that some users would like to be able to do box select while the transform gizmos are visible.

I think dragging on a blank area action should not be limited to Box select. The blank area drag action should use whatever selection method is active on the left-side toolbar. So if I choose lasso select mode, then activate the move gizmo, then start dragging on a blank area, I would expect a lasso selection to start. Here it is in action in 3ds Max.

blankDragSelectMax.mp4

I was able to tweak the current keymap in Blender to achive this functionality to some degree. See here, (first the original functionality, then my tweak):

blankDragSelectBlender.mp4

The problem is that I can only specify one selection mode in the keymap editor (either box, lasso, circle). It would be ideal to have for example a 'view3d.select_modal' operator that uses whatever selection mode is active on the left-side toolbar.

Add Box Select to the Drag Action dropdown inside the transform tools

If such an operator were available, I think most of the problems would go away, and you wouldn't need an extra dropdown on the status bar, because the active selection method is already indicated on the left-side toolbar (see image, sorry for the serial-killery lettering :) )

If I as a user took the time to pick a selection method on the toolbar, I don't want to have to specify it at yet another place on the GUI, especially if I can cycle through the selection methods with a shortcut (also worth a recommendation, but that's another story :) ).

Hey, thanks for addressing this. Here's my recommendation. > Another thing to discuss related to the keymap, is that some users would like to be able to do box select while the transform gizmos are visible. I think dragging on a blank area action should not be limited to Box select. The blank area drag action should use whatever selection method is active on the left-side toolbar. So if I choose lasso select mode, then activate the move gizmo, then start dragging on a blank area, I would expect a lasso selection to start. Here it is in action in 3ds Max. [blankDragSelectMax.mp4](https://archive.blender.org/developer/F6620484/blankDragSelectMax.mp4) I was able to tweak the current keymap in Blender to achive this functionality to some degree. See here, (first the original functionality, then my tweak): [blankDragSelectBlender.mp4](https://archive.blender.org/developer/F6621411/blankDragSelectBlender.mp4) The problem is that I can only specify one selection mode in the keymap editor (either box, lasso, circle). It would be ideal to have for example a 'view3d.select_modal' operator that uses whatever selection mode is active on the left-side toolbar. > 1. Add Box Select to the Drag Action dropdown inside the transform tools If such an operator were available, I think most of the problems would go away, and you wouldn't need an extra dropdown on the status bar, because the active selection method is already indicated on the left-side toolbar (see image, sorry for the serial-killery lettering :) ) ![image.png](https://archive.blender.org/developer/F6620531/image.png) If I as a user took the time to pick a selection method on the toolbar, I don't want to have to specify it at yet another place on the GUI, especially if I can cycle through the selection methods with a shortcut (also worth a recommendation, but that's another story :) ).

I have another thinks, like maya user, I love possibilities with move, scale and rotate gizmos, when I tweak on empty area and have access to grave scale etc. on maya that’s works by tweaking on empty area with middle button, but tweaking with lmb works like box, lasso etc. selection. With shift you extend selection and with Ctrl you deselect. Can create some gifs if you need that.

I use maya viewports navigation now so I have mmb free for me. But if it will be possible to tweak with some hotkey and access to gizmos middle round functionality on blank area it will be awesome for new blender users.

I have another thinks, like maya user, I love possibilities with move, scale and rotate gizmos, when I tweak on empty area and have access to grave scale etc. on maya that’s works by tweaking on empty area with middle button, but tweaking with lmb works like box, lasso etc. selection. With shift you extend selection and with Ctrl you deselect. Can create some gifs if you need that. I use maya viewports navigation now so I have mmb free for me. But if it will be possible to tweak with some hotkey and access to gizmos middle round functionality on blank area it will be awesome for new blender users.

@ThinkingPolygons

This is actually very easily achieved with some minor keymap tweaks.

![Untitled-1.jpg](https://archive.blender.org/developer/F6621122/Untitled-1.jpg) @ThinkingPolygons This is actually very easily achieved with some minor keymap tweaks.

Selection (box, laso) from the empty space.
Move, scale and rotate only when you click and drag on the object. It should be optional at least.
In Maya you can choose the type of interaction as blender with the middle button.

Selection (box, laso) from the empty space. Move, scale and rotate only when you click and drag on the object. It should be optional at least. In Maya you can choose the type of interaction as blender with the middle button. ![3dmax.gif](https://archive.blender.org/developer/F6621095/3dmax.gif)

Added subscriber: @Oskar3d

Added subscriber: @Garlash

Added subscriber: @gentleclockdivider

What I can not fathom is why the left click remains inaccurate , when the right click is not
When vertices fall under a part of the transform/move gizmo these are perfectly selectabnnle with the right click approach , the left click is not
See screen shot , the vertices that have boxes around them are not selectable with mouse click ,
I honoustly can not believe this is not a priority.

What I can not fathom is why the left click remains inaccurate , when the right click is not When vertices fall under a part of the transform/move gizmo these are perfectly selectabnnle with the right click approach , the left click is not See screen shot , the vertices that have boxes around them are not selectable with mouse click , I honoustly can not believe this is not a priority.![left click.jpg](https://archive.blender.org/developer/F6787417/left_click.jpg)

@gentleclockdivider
it is a priority, which is why it is mentioned in this task already. It’s the first item under the 3D View section even.

@gentleclockdivider it is a priority, which is why it is mentioned in this task already. It’s the first item under the 3D View section even.

Hello,

In Pose mode + Weight Painting, selection of bones is now on CTRL + LMB,
but how to select multiple bones ? Seems SHIFT + CTRL + LMB doesn't work

Hello, In Pose mode + Weight Painting, selection of bones is now on CTRL + LMB, but how to select multiple bones ? Seems SHIFT + CTRL + LMB doesn't work

Added subscriber: @StroBlend

Since this issue occurs only when you try to do multiple selection right ? Why not de-activate or hide the gizmo when hold shift ? It can be a good way to fix it what you think ?

![vivaldi_uQG4NaMj3E.png](https://archive.blender.org/developer/F6853844/vivaldi_uQG4NaMj3E.png) Since this issue occurs only when you try to do multiple selection right ? Why not de-activate or hide the gizmo when hold shift ? It can be a good way to fix it what you think ?

In #57918#644565, @StroBlend wrote:

Since this issue occurs only when you try to do multiple selection right ? Why not de-activate or hide the gizmo when hold shift ? It can be a good way to fix it what you think ?

Shift-Click is used for constraining to two axes when using transform handles.

> In #57918#644565, @StroBlend wrote: > ![vivaldi_uQG4NaMj3E.png](https://archive.blender.org/developer/F6853844/vivaldi_uQG4NaMj3E.png) > > Since this issue occurs only when you try to do multiple selection right ? Why not de-activate or hide the gizmo when hold shift ? It can be a good way to fix it what you think ? Shift-Click is used for constraining to two axes when using transform handles.

In #57918#644576, @ideasman42 wrote:

Shift-Click is used for constraining to two axes when using transform handles.

I don't get it... To me shift is used to do fine adjustment when using transform handles. We have the little square on the gizmo if we want to constraint 2 axes. Also when we are doing the transform, we are not doing the selection. Transform is after the selection (once you clicked on the handle). Before that Shift is to add something else to the selection.

> In #57918#644576, @ideasman42 wrote: > Shift-Click is used for constraining to two axes when using transform handles. I don't get it... To me shift is used to do fine adjustment when using transform handles. We have the little square on the gizmo if we want to constraint 2 axes. Also when we are doing the transform, we are not doing the selection. Transform is after the selection (once you clicked on the handle). Before that Shift is to add something else to the selection.

In #57918#644565, @StroBlend wrote:

Since this issue occurs only when you try to do multiple selection right ? Why not de-activate or hide the gizmo when hold shift ? It can be a good way to fix it what you think ?

This issue also occurs when trying to select a single vertex that is under the gizmo, so this would be another reason to stay away from using shift.

@ideasman42 and @WilliamReynish the key binding for Offset Edge Loop Cut should be changed from a "Mouse>Left>Press" event to a "Tweak>Left>Any" event like that used in loop slide. Right now it is impossible to make a new selection with that tool active.

> In #57918#644565, @StroBlend wrote: > ![vivaldi_uQG4NaMj3E.png](https://archive.blender.org/developer/F6853844/vivaldi_uQG4NaMj3E.png) > > Since this issue occurs only when you try to do multiple selection right ? Why not de-activate or hide the gizmo when hold shift ? It can be a good way to fix it what you think ? This issue also occurs when trying to select a single vertex that is under the gizmo, so this would be another reason to stay away from using shift. @ideasman42 and @WilliamReynish the key binding for Offset Edge Loop Cut should be changed from a "Mouse>Left>Press" event to a "Tweak>Left>Any" event like that used in loop slide. Right now it is impossible to make a new selection with that tool active.

@DanPool yes. We also should make it so you can click to select and shift-click to select more even when clicking on top of the gizmos.

We can do this by differentiating between a click event and a drag event, as we already do outside the gizmos.

@DanPool yes. We also should make it so you can click to select and shift-click to select more even when clicking on top of the gizmos. We can do this by differentiating between a click event and a drag event, as we already do outside the gizmos.

During the work on the Industry Compatible Keymap, I discovered that we aren't actually all that far off from solving the left-click animation player issue.

It's already possible to use the Marker area at the bottom of the animation editors to scrub the playhead, while keeping the rest of the editor for selecting and moving keys,

So, 'all' that's needed then, is to make this marker area more visually prominent, so that it's more obvious:

{F6903303, size=full}

Here I moved it to the top, and added the frame numbers there too. This way it's more obvious that you can drag the playhead here.

@brecht: Depending on how you look at it, just modifying the marker area a bit could solve the issue?

During the work on the Industry Compatible Keymap, I discovered that we aren't actually all that far off from solving the left-click animation player issue. It's already possible to use the Marker area at the bottom of the animation editors to scrub the playhead, while keeping the rest of the editor for selecting and moving keys, So, 'all' that's needed then, is to make this marker area more visually prominent, so that it's more obvious: {[F6903303](https://archive.blender.org/developer/F6903303/Screenshot_2019-03-31_at_12.24.53.png), size=full} Here I moved it to the top, and added the frame numbers there too. This way it's more obvious that you can drag the playhead here. @brecht: Depending on how you look at it, just modifying the marker area a bit could solve the issue?

Added subscriber: @RDrehmer

In #57918#651994, @WilliamReynish wrote:
During the work on the Industry Compatible Keymap, I discovered that we aren't actually all that far off from solving the left-click animation player issue.

It's already possible to use the Marker area at the bottom of the animation editors to scrub the playhead, while keeping the rest of the editor for selecting and moving keys,

So, 'all' that's needed then, is to make this marker area more visually prominent, so that it's more obvious:

Here I moved it to the top, and added the frame numbers there too. This way it's more obvious that you can drag the playhead here.

@brecht: Depending on how you look at it, just modifying the marker area a bit could solve the issue?

Looking good!

In addition to that top area for the playhead, it could have some keystroke assignment that transforms EVERYTHING in a scrub area.
While you hold [KEY], you can drag anywhere on 3D View or Animation editors to scrub back and forth. It's very handy for animators not having to point at somewhere else to scrub. Just press a key and scrub right where you (your pointer) are.

For instance, it could be like:

Quick press [SPACEBAR]: Playback/Stop Animation
Hold [SPACEBAR]: Click'n'drag to "scrub anywhere"

> In #57918#651994, @WilliamReynish wrote: > During the work on the Industry Compatible Keymap, I discovered that we aren't actually all that far off from solving the left-click animation player issue. > > It's already possible to use the Marker area at the bottom of the animation editors to scrub the playhead, while keeping the rest of the editor for selecting and moving keys, > > So, 'all' that's needed then, is to make this marker area more visually prominent, so that it's more obvious: > > > > Here I moved it to the top, and added the frame numbers there too. This way it's more obvious that you can drag the playhead here. > > @brecht: Depending on how you look at it, just modifying the marker area a bit could solve the issue? Looking good! In addition to that top area for the playhead, it could have some keystroke assignment that transforms EVERYTHING in a scrub area. While you hold [KEY], you can drag anywhere on 3D View or Animation editors to scrub back and forth. It's very handy for animators not having to point at somewhere else to scrub. Just press a key and scrub right where you (your pointer) are. For instance, it could be like: Quick press [SPACEBAR]: Playback/Stop Animation Hold [SPACEBAR]: Click'n'drag to "scrub anywhere"

Added subscriber: @lamoot

@WilliamReynish the design for the marker area is nice and appealing. One thing though, in the graph editor, there are two of these numbered sliders (horizontal and vertical). Would the design of the vertical slider change as well, to fit the overall style?

@WilliamReynish the design for the marker area is nice and appealing. One thing though, in the graph editor, there are two of these numbered sliders (horizontal and vertical). Would the design of the vertical slider change as well, to fit the overall style? ![graph_editor_sliders.png](https://archive.blender.org/developer/F6909474/graph_editor_sliders.png)

@RDrehmer
Sure, yes, that kind of thing is in fact already possible to set up inside the marker area.

@lamoot

It could be solved like so?

Either next to scrollbar

Or opposite:

Has the advantage of not using vertical text too.

@RDrehmer Sure, yes, that kind of thing is in fact already possible to set up inside the marker area. @lamoot It could be solved like so? Either next to scrollbar ![Screenshot 2019-04-03 at 23.41.00.png](https://archive.blender.org/developer/F6909728/Screenshot_2019-04-03_at_23.41.00.png) Or opposite: ![Screenshot 2019-04-03 at 23.40.44.png](https://archive.blender.org/developer/F6909730/Screenshot_2019-04-03_at_23.40.44.png) Has the advantage of not using vertical text too.

As far as my preference, I'd go for values next to the scroll bars. It's close to the list of fcurves, which makes it's easier to glance at rather than at the other end of the editor.

Thinking about this some more, you don't only scrub through time in the graph editor but also up-down along values. The time indicator is also a cursor. I mainly use it when I wish to transform curves from a specific pivot (like you'd use the 3d or 2d cursors in other editors).

How would the user adjust vertical position of the time slider/cursor?

Through the additional vertical area.
Through the horizontal area, where you can adjust the frame as well as move the cursor up-down.
A combination of the two, where both areas allow you to scrub up-down and left-right?

As far as my preference, I'd go for values next to the scroll bars. It's close to the list of fcurves, which makes it's easier to glance at rather than at the other end of the editor. Thinking about this some more, you don't only scrub through time in the graph editor but also up-down along values. The time indicator is also a cursor. I mainly use it when I wish to transform curves from a specific pivot (like you'd use the 3d or 2d cursors in other editors). How would the user adjust vertical position of the time slider/cursor? 1. Through the additional vertical area. 2. Through the horizontal area, where you can adjust the frame as well as move the cursor up-down. 3. A combination of the two, where both areas allow you to scrub up-down and left-right?

Added subscriber: @LucianoMunoz

In #57918#655571, @lamoot wrote:
As far as my preference, I'd go for values next to the scroll bars. It's close to the list of fcurves, which makes it's easier to glance at rather than at the other end of the editor.

next to it, sure, just not on top of like it is now., but i do like how @WilliamReynish 's proposal looks, and maybe make the scrollbars a bit thicker and more obvious (in general), for us tablet users is very hard to use the new ones because the area to click is very small.
and regarding the scrollbar particularly in time editors, I tend to forget it even exists because its sort of hidden.

Thinking about this some more, you don't only scrub through time in the graph editor but also up-down along values. The time indicator is also a cursor. I mainly use it when I wish to transform curves from a specific pivot (like you'd use the 3d or 2d cursors in other editors).

How would the user adjust vertical position of the time slider/cursor?

Through the additional vertical area.

yeah why not?

Through the horizontal area, where you can adjust the frame as well as move the cursor up-down.

that could work

A combination of the two, where both areas allow you to scrub up-down and left-right?

better.

or maybe we leave that as secondary functionality, and use the mouse cursor as default pivot for scaling keyframes in the editor, and though it might be a tad less precise, it'd be a much much faster workflow.

anyways, it all seems to be going the right direction.

> In #57918#655571, @lamoot wrote: > As far as my preference, I'd go for values next to the scroll bars. It's close to the list of fcurves, which makes it's easier to glance at rather than at the other end of the editor. next to it, sure, just not on top of like it is now., but i do like how @WilliamReynish 's proposal looks, and maybe make the scrollbars a bit thicker and more obvious (in general), for us tablet users is very hard to use the new ones because the area to click is very small. and regarding the scrollbar particularly in time editors, I tend to forget it even exists because its sort of hidden. > > Thinking about this some more, you don't only scrub through time in the graph editor but also up-down along values. The time indicator is also a cursor. I mainly use it when I wish to transform curves from a specific pivot (like you'd use the 3d or 2d cursors in other editors). > > How would the user adjust vertical position of the time slider/cursor? > 1. Through the additional vertical area. yeah why not? > 2. Through the horizontal area, where you can adjust the frame as well as move the cursor up-down. that could work > 3. A combination of the two, where both areas allow you to scrub up-down and left-right? better. or maybe we leave that as secondary functionality, and use the mouse cursor as default pivot for scaling keyframes in the editor, and though it might be a tad less precise, it'd be a much much faster workflow. anyways, it all seems to be going the right direction.

Removed subscriber: @Vinc3r

Added subscriber: @EitanSomething

I think change frame in the animation editor types should be left click instead of right. It doesn't make sense for the selecting and changing of a frame to be right click when selecting an object or buttons is generally left.

@EitanSomething That's what the top high priority item is about "#63193: Animation Editor Scrubbing Area."

When did we agree to put this on my desk? I don’t mind spending time on that, but that won’t be an efficient spending, I did not work on this since ages (and not at all in 2.8)…

@mont29, we agreed on this at the homestretch workshop, that you would look at the high priority left click select issues except for the animation scrubbing one.

Added subscriber: @mont29

Okay so now that we have sub-tasks, no need to be assigned that whole one then. :)

Removed subscriber: @Dheim

Since there are subtasks now, only leave those at high priority.

Removed subscriber: @yrrnn

Is it possible to use same hotkey for loop select and pick shortest path, but differentiate them using a number of edge selection? For instance: if one edge is selected, do loop select. But if two edges are selected, enable pick shortest path between those two edges.

@Nomo in theory that’s possible yes, although I’m not sure we should do that by default.

In my opinion, it is as intuitive as using box select by holding click and dragging. But I can see that it may not be wanted by some users who prefer to keep things separate.

In #57918#654342, @WilliamReynish wrote:
@RDrehmer
Sure, yes, that kind of thing is in fact already possible to set up inside the marker area.

@lamoot

It could be solved like so?

Either next to scrollbar

Or opposite:

Has the advantage of not using vertical text too.

the text is sideways in Graph/VSE..etc now, is it by design or just due to the new changes? can we get it back to straight so it's easily readable.

> In #57918#654342, @WilliamReynish wrote: > @RDrehmer > Sure, yes, that kind of thing is in fact already possible to set up inside the marker area. > > @lamoot > > It could be solved like so? > > Either next to scrollbar > ![Screenshot 2019-04-03 at 23.41.00.png](https://archive.blender.org/developer/F6909728/Screenshot_2019-04-03_at_23.41.00.png) > > Or opposite: > ![Screenshot 2019-04-03 at 23.40.44.png](https://archive.blender.org/developer/F6909730/Screenshot_2019-04-03_at_23.40.44.png) > > Has the advantage of not using vertical text too. the text is sideways in Graph/VSE..etc now, is it by design or just due to the new changes? can we get it back to straight so it's easily readable. ![Value.jpg](https://archive.blender.org/developer/F7061142/Value.jpg)

In #57918#685427, @Znio.G wrote:

the text is sideways in Graph/VSE..etc now, is it by design or just due to the new changes? can we get it back to straight so it's easily readable.

It never was straight. It was like that in 2.79 also:

The issue with horizontal text, is that it can eat into the content area. So for now, this is by design.

> In #57918#685427, @Znio.G wrote: > > the text is sideways in Graph/VSE..etc now, is it by design or just due to the new changes? can we get it back to straight so it's easily readable. > > ![Value.jpg](https://archive.blender.org/developer/F7061142/Value.jpg) It never was straight. It was like that in 2.79 also: ![Screenshot 2019-05-22 at 17.13.43.png](https://archive.blender.org/developer/F7061152/Screenshot_2019-05-22_at_17.13.43.png) The issue with horizontal text, is that it can eat into the content area. So for now, this is by design.

@WilliamReynish for 2.80 seems possible though the text is always on top and the scaling bars are on the opposite side, can't see the issue to be honest.

The issue with horizontal text, is that it can eat into the content area. If you go to 10.000 for eg, it takes up a lot more horizontal space then, which the editors need to account for.

excuse me for being thick, but i made a mock-up and acutally if u have VSE as part of the workspace the vertical text actually gets skewed

excuse me for being thick, but i made a mock-up ![gp.jpg](https://archive.blender.org/developer/F7061211/gp.jpg) and acutally if u have VSE as part of the workspace the vertical text actually gets skewed

Added subscriber: @tintwotin

Maybe unrelated to this question, but channel numbers and time codes can overlap, and become unreadable:

Maybe unrelated to this question, but channel numbers and time codes can overlap, and become unreadable: ![image.png](https://archive.blender.org/developer/F7061225/image.png)

Removed subscriber: @zaha

Added subscriber: @VaclavCermak

Removed subscriber: @nokipaike

At this point the graph editor changes (#70634) are too late to do in 2.81 I think, so moving to next.

Added subscriber: @AndreaMonzini

Changed status from 'Open' to: 'Resolved'

Finally got the last part of this, the Graph Editor select/transform changes in, b037ba2665.

Closing this, yaay!

Finally got the last part of this, the Graph Editor select/transform changes in, b037ba2665. Closing this, yaay!

This issue was referenced by 926f7612fd

This issue was referenced by 926f7612fd75078f5fb802d165f9c25af0bdb0df

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Tweaks & Fixes for Improved Left Click Select Support (Parent task) #57918

High Priority

Planned

Ideas

Add Box Select to the Drag Action dropdown inside the transform tools

Add some new way to make transform gizmos visible while other tools are active