In T54943#553583, @William Reynish (billreynish) wrote:

@Ludvik Koutny (rawalanche): I'm not sure what you mean. If you use any of the transform tools, you drag and release to translate. The action ends when the user releases the mouse button.

In T57843#554108, @William Reynish (billreynish) wrote:

Hmm, to add further flavour, changing the 3D Cursor to Click makes it so it doesn't move under your mouse cursor. This may be a bit more difficult to fix than I thought.

I want to remind you that in 2.8, "Release confirms" in preferences is still set to be disabled by default, which results in quite default jarring behavior of tools for the new users, especially transform tools such as move, rotate and scale. Every time such an action is performed, the mode stick even upon releasing the mouse button, making it feel like the mouse has malfunctioned, requiring another click to confirm the action.

Yes, if there's not enough horizontal space, then let's just do two rows, but please don't keep it the way it currently is. It's beyond ugly.

Try this:

Is there any ETA on 2.8 tool system properly working with LMB? I'd like to start re-making my custom keymap for 2.8

What Blender truly needs is a proper tool for instancing and scattering objects. This looks just like a random object painter tool. There are already dozen of ways to do this in Blender, but there is not a single way to for example scatter 10 000 high poly trees along with 20 000 000 high poly grass patches. That's why you don't see pretty much any large scale environments ever done in Blender.

I'll spam this here too: https://devtalk.blender.org/t/angular-snap-needs-to-be-decoupled-from-incremental-snap/2161

I second the comment above. For me, local view-specific cursor position is a problem rather than help. Every single time I isolate selection, and then go back to global view, the cursor is in the wrong position. I'd simply completely remove the idea of global/local view specific cursor, and have one cursor position regardless of 3D view mode.

In T54943#541206, @William Reynish (billreynish) wrote:

Ludvik: I don't know what you mean. Release already confirms. If you enable the Move tool and drag, releasing then confirms the movement.

One of the defaults that definitely should be changed for 2.8 is that "Release confirms" in Preferences should be off. Current state has this really weird behavior where if you drag an item, it sticks to your mouse until you click again to drop it. This feels much more like a bug or mouse malfunction rather than a feature.

Unfortunately, there is an annoying usability issue with rotate widget (and rotate mode in general):

Meters and Centimeters is what I am used to. In fact, this is the first time in 27 years of my life that I got to know that "metre" and "centimetre" are actually valid words, and not a typo. I fact, even google doesn't think so, and considers it a typo :D :

One very unfortunate name in 2.8 is "Ornaments" in Overlays pop-over menu. Ornament refers to something very specific: https://www.google.com/search?tbm=isch&source=hp&biw=1920&bih=1058&ei=6jqzW7LsFIWQrgTfjpToAw&q=ornament&oq=ornament&gs_l=img.3..35i39k1j0l9.2998.3656.0.3943.11.11.0.0.0.0.125.732.5j3.8.0....0...1ac.1.64.img..3.8.727.0...0.6uDX_eHTVbA

Yep, I agree that rectangle select is a standard name for it, but in context of all the others listed, "Region" is the most appropriate name.

In T56939#538694, @Bastien Montagne (mont29) wrote:

That does not really sounds like a bug to me, but will let @Brecht Van Lommel (brecht) decide here.

Ah, nevermind then. I assumed that Shot Management addon wouldn't exactly be a 3D view specific one.

In T54582#536259, @Julien Kaspar (JulienKaspar) wrote:

I think it could very well work in an overhauled sidebar but the pinning will still be useful to implement in that one then. Sometimes you would want to have the interface of an addon that is more complex than a tool like Blenrig visible on the side even when going fullscreen but while also having the transform properties visible at the same time. So pinning them makes them both visible without switching tabs constantly in the future sidebar.
it's just a shame of not being able to use the space in the toolbar if available space on the sidebar would run out. The current way is more clean but the things that were removed were able to be more useful where they were.

I support the idea of left toolbar being exclusively dedicated to tools. The mockup by @Julien Kaspar (JulienKaspar) looks like a step back in a scope of cleanup that has been done since 2.8 development started. It would allow the left toolbar to again become "everything bar" of random buttons, which was a big pain in 2.79.

"We could combine Extrude Region, Extrude Individual, Extrude Along Normals into same tool, and simply add a tool setting to switch between the various extrusion methods"

In T56702#535982, @Julien Kaspar (JulienKaspar) wrote:

Another thing I noticed is when assigning Ctrl + RMB to setting the 3D Cursor, then there needs to be a new shortcut for the lasso tool. Actually I'd like the lasso selection to get a simple key like B & C for Box & Circle select. These work fine for them so it can work for Lasso select as well.
But maybe that's not really possible since most are already taken in Edit Mode and reassigning it to a key might require reassigning of other keys as well.
Maybe the shortcut for the 3D Cursor can be Ctrl + Alt + RMB but this likely just involves too many keys.

@Brecht Van Lommel (brecht)
Click anywhere is useful. I actually love how fluidly Blender allows you to work, not having to always travel your mouse cursor all the way to the transform gizmo to start working. Being 8 year 3ds Max user and only 1 year Blender user, not having to travel my mouse to gizmo to do transforms was very relieving. Click anywhere pretty much unifies current freeform transform tools (GRS) and gizmo based tools into one.

In T56702#535655, @Julien Kaspar (JulienKaspar) wrote:

True, I think users that don't have a keyboard or are used to a more industry standard approach are better served.
And as long as all major tools have easy shortcuts to quickly switch between them, it can still work very fluently. I also like the suggestion that when using the operators instead, the related tools light up to show the connection so that the shortcuts and tools are not entirely disconnected in the old way of using Blender.
I also like the idea of the difference of tapping the G key to set the tool as active and holding G to execute it immediately, as described in the Tool Design Task. This can also work nicely.

But I think it's important to tread carefully (And I know you are) when changing essential operators into mandatory tools such as select, 3D cursor and all transform tools since these become on a basic level slower versions of the old operators because of this inherent switching between them which is forced on every user and wasn't there before.
It's not as bad as having pan, zoom & rotate of the view as mandatory tools but a selection tool is very uncomfortably close but as far as I can see at this point, with how everything works, regrettably necessary. Maybe this as perfect of a solution that we can get for LMB select.

I agree with all of these. Very good choices.

In D3206#75836, @Campbell Barton (campbellbarton) wrote:

Unfortunately we won't be accepting new modifiers that instance geometry many times.

This is inefficient and in general we should be using an instancing system for this (duplicators):

Added section in the anti-features page for this:
https://wiki.blender.org/index.php/Dev:Source/Architecture/AntiFeatures#Modifiers_that_Instance_Geometry

Shouldn't this be consulted with William? It seems that the purpose of status bar is lacking a coherent vision. There's now way too much clutter. Re-introducing per-editor status bars is a big step backwards :(

In T55386#510416, @Sergey Barabanov (huggaida) wrote:

• in edit mode press LMB to cycles between v/e/f (for example alt+LMB- cycles backwards). Since people used to Click/doubleclick LMB you will see how it easy to learn clicking once to switch from ver to edge, doubleckick to v->f

In T55386#509928, @justin barrett (justinbarrett) wrote:

In T55386#509748, @DIGVIJAY (DJAY) wrote:

hey, nice work guys. keep it up.

just for the suggestion ;

1. if the Properties editor's tab will be on the right side instead of the left it will be good
   
   and
2. it will be much easier and faster if the clicking is removed means just by hovering the mouse or as zebus (ofuscado) said by mouse wheel to the Properties editor's tabs (Render, Modifier, physics etc) it will open the relative tabs settings.
   
   
   

I agree, for single workspaces this very logical to have the buttons on the right...
A concern for me is dual monitor and mouse over events...I tend to have mine on monitor 1 with it dressed to the right...if I move to my second monitor I may accidentally activate an unwanted property mode....
I still agree with them being on the right though.

Currently, having search on tilde and view menu on hold tilde makes very little sense. Search and viewport switching are extremely different actions. Having them on same key doesn't make much sense.

When I've designed Corona UI, I've found out that just a simple introduction of proper vertical and horizontal UI element alignment can greatly aid readability of multi column layouts. So it's not that multi column layouts are inherently messy and less readable, but that they require a good, grid like alignment to be readable :)

In T54943#508047, @Campbell Barton (campbellbarton) wrote:

In T54943#508025, @William Reynish (billreynish) wrote:

They should, yes. Currently, Blenders has no way to distinguish the various windows, but we are aware of the issue, and it can be solved.

What would be the logic for solving this?

For preferences it's obvious, for two windows each the same size on a different monitor - its not. maybe this should get its own design task.

In T54711#506861, @Okavango (Okavango) wrote:

@William Reynish (billreynish) , @Campbell Barton (campbellbarton)

Guys, you might wanna check this out. This might be the first functional App Template, and with a lot of nice UI concepts for 2.8 to take inspiration from:

https://blenderartists.org/t/blender-pro-improving-blenders-interface-and-usability/1113152

Hi, any news on this bug? It really makes it impossible to use Blender as generator of fluid simulations for use in other apps. This should be high priority, because all the work spent by someone to make Blender support VDB is negated by this unwise file naming. I mean if you are doing sims to be used in Blender, you can just use the default point cache. VDB makes sense mainly because of interoperability with other 3D packages, yet this interoperability is broken for exactly this reason :(

I think that one of the included material preset should be thin, translucent foliage for materials such as tree leaves and grass blades (almost no high poly tree models have leaf meshes with thickness, otherwise it would be ridiculously highpoly model).

In T54963#505360, @KiJeon (0o00o0oo) wrote:

@Ludvik Koutny (rawalanche) It looks like context-sensitive menu is being developed as a whole anyways for 2.8 according to T55162.

In T55162#505355, @Campbell Barton (campbellbarton) wrote:

Regarding using number keys to select submodes.

While it is elegant in some ways to press a key to enter the mode, then the same key again to select a sub-mode,
I think users muscle memory for each individual number key won't be all that accurate, meaning the user will have to be extra careful not to accidentally enter a different mode.
It also means you don't end up with muscle memory for quickly tapping the sub-mode key (since it moves about depending on your mode).

Suggest to use a single, more easily accessible key for sub-mode switching.

In T55162#504999, @William Reynish (billreynish) wrote:

We discussed the number keys and decided to simplify it, so that the number keys simply reflect the main mode selector. This way, the order can be the same and be mirrored both in the mode selector and in the number keys. Other modes also have submodes and we want to make this work in a consistent way.

In T55162#504971, @Manuel Grad (manitwo) wrote:

@Ludvik Koutny (rawalanche) sorry, it wasn't my intention to suggest you're dissmissing exotic keyboard layouts. I just wanted to say that the number of users that would have to change the new proposed default would probably be pretty high. And the thing with defaults is that probably 95% of the people tend to stick with it. So they won't have a button for Object Mode. How many countries are affected by this? How many keyboard layouts are commonly used all over the world that don't have that key on that position? I don't know the answer. Does the Blender Foundation have statistics where the users are coming from?

In T55151#504978, @Philipp Oeser (lichtwerk) wrote:

This is actually working as intended, so calling this "corrupted" is not really appropriate.
I agree though that flipping index and framenumber would probably have benefits in a pipeline involving other software.
This could certainly be done [would need to take care of reading both naming-conventions then...].

Dont think this is a bug [more of a TODO - if at all], but maybe @Brecht Van Lommel (brecht) or @Sybren A. Stüvel (sybren) have a comment?

@Manuel Grad (manitwo)
Well if you see EDIT section of my last post, you will see I am actually not dismissing exotic keyboard layouts, but instead proposing a solution that would make such keymap work even with the exotic layout. The way you formulate your reply sounds like I am dismissing exotic keyboard layouts, which I am not.

In T55162#504930, @Campbell Barton (campbellbarton) wrote:

Regarding number keys for modes.

• Pose-Mode, Grease Pencil Edting - are missing from the list.
• Not sure we should give vertex/edge/face their own number keys.
  
  It's limited to edit-mesh, would we do the same for other modes? (particle also has selection modes similar to mesh, would we support sub-modes for particle editing... also how would this be used in the UV window?).
• If you mix multiple modes at once (vertex/edge/face), will there be a way to enter edit-mode without loosing the mode you had set?
  
  Also...
• How to handle having more than 10 modes? (which seems likely since you're already mapped nearly all keys).
• How to these keys be set when using non mesh objects?
• Not sure Search needs to be Tab (a very prominent key), we could use an F-Key for example.

Looks really good. I know this is not the industry standard keymap, but I would still suggest to shuffle it around a little so that 1 2 and 3 keys do Vertex, Edge and Face edit modes respectively. There are quite a few Blender users who have set it up that way, and it's just much more common. I do understand the reasoning of the current proposal though, as having object mode at 4 feels a bit random.

In T54963#504594, @William Reynish (billreynish) wrote:

Context-sensitive menus for right-click is not out of scope - it's exactly the kind of thing we want to enable with this keymap.

In T54963#504272, @William Reynish (billreynish) wrote:

Ludvik: Yes. This discussion got mixed in confusing ways with general features for switching tools. In the default Blender keymap, the space bar is uses for switching tools. In this Industry Standard keymap, I don't expect it to work like that, and for most tools it's not necessary, because users can simply use the shortcuts directly to switch active tools.

For this Industry Standard keymap, we should properly define how the right-click menus should work, and how the space-bar feature should work. We should analyze what all the apps do here to determine the most standard approach. Help in this area is much appreciated.

In T54963#504116, @William Reynish (billreynish) wrote:

Julian: In Blender 2.8 you can already switch tools in a popup menu by pressing the space bar. If you prefer to work full screen with a hidden toolbar, you can use this method to switch tools. It works in any mode, with all the active tools.

I see that the proposal to have "Sky" map defaulting as background was indeed removed, as I suggested. I know resources for Code Quest are limited, but I would actually be very happy if Sky map was finally finished with proper Physical Sun light and easy to do linking between Physical Sun and Physical Sky, so that it could indeed become a default. There's already an Omni light present in the factory default Blender scene. That Omni could be replaced by Physical Sun once implemented, and background could default to Physical Sky linked to that sun. So every new user, who would just hit render straight away would get a nice simple day lighting in his scene out of the box :)

In T54661#503597, @William Reynish (billreynish) wrote:

Extrude manipulators are unfinished still. They are too big, and secondary axes are too prominent. We have plans to make improvements in this area.

As for the multi-tool manipulator, it’s an interesting idea, but most likely not something we’d like to pursue. The different tools have different options and work in different ways, so it’s not as straightforward as one might think to combine them.

Also, we want to avoid error prone behaviors, where users might hit the wrong handle. This kind of thing could be implemented as an addon, though.

In T54963#503609, @André Savik (klutz) wrote:

For the Search/Quick Find function, I suggest the F1 key. As per today, it's being used in a non-standard way (Open File) by Blender (as so many other shortcuts), but this suggestion might actually keep the door open for implementing a "real" help system.

Initially, by pressing F1 you'd open the dialog that's now bound to the space bar. Later on, however, one might want to implement a new choice in that box so that you can choose between executing the command and opening a help function.

Implementation: Press F1, type Flip Normals into the text box, <Enter>. Just as today the selected faces will ble flipped.

Possible future implementation: Press F1, type Flip Normals into the text box, <Enter>. The selected faces will ble flipped.
But now, the dialog also gives you a second option: Instead of pressing <Enter> you can press F1 (or another assigned key) again and open up the help context.

I know I am probably old fashioned, but I really like back faces being shaded black, because I can constantly see the normal orientation. When one of the new 3ds Max versions made double sided material drawing default, at it was no longer possible to switch it back, I found that it was not an advantage, but a drawback, as I had to spend time constantly toggling diagnostic shading mode to see orientation of the normals.

In T54336#502722, @Philipp Oeser (lichtwerk) wrote:

@Ludvik Koutny (rawalanche): could you report the other inconsistencies as well? (just post into this report, I'll take care of them -- and see if it makes sense generalize some code here)

I would strongly suggest to have just one global border and lasso selection implementation which is referenced by all the editors, rather than having unique implementation for each editor and trying to keep its codebase manually in sync. There are quite a few more inconsistencies of lasso and border selection keymap properties between the different editor. This bug report is just a small example of it.

sorry for commenting on already closed task. There's one thing that won't stop bugging me, and it's somewhat related to the new manipulators:

Also, the best way to reproduce it after the input type is changed to "Any" is to switch the focus away from Blender's Window to a different one and then switch back. Then it should happen almost every time.

In T55012#501359, @Philipp Oeser (lichtwerk) wrote:

Hm, yes, I imported that back in, but ANY doesnt seem to produce issues here?

• I can CTRL+G to group, CTRL+Tab to enter weightpaint, I can SHIFT+click to add to selection, etc...
  
  It would be the same as changing it from 'blank' to ANY in the default keymap as well, right? (so we wouldnt need the step of export/import keymap to reproduce...) Do you have issues, setting all these 'blank' entries in the Screen\Screen Editing section to ANY in the default keymap as well?
  
  I havent had a look at the code yet (I'm a little bit surprised myself), just saying: ANY doesnt seem to be an issue for these entries on my side...

In T55012#501350, @Philipp Oeser (lichtwerk) wrote:

Not sure I follow correctly:

• I changed the "Toggle Header" shortcut to Ctrl+F9 (instead of Alt+F9)
• exported keymap

When keymap is exported, these fall back to the incorrect "Press" action

Here I cant reproduce, my exported keymap file looks contains this:

kc = wm.keyconfigs.new(os.path.splitext(os.path.basename(__file__))[0])

# Map Screen Editing
km = kc.keymaps.new('Screen Editing', space_type='EMPTY', region_type='WINDOW', modal=False)

kmi = km.keymap_items.new('screen.actionzone', 'LEFTMOUSE', 'PRESS')
kmi_props_setattr(kmi.properties, 'modifier', 0)
kmi = km.keymap_items.new('screen.actionzone', 'LEFTMOUSE', 'PRESS', shift=True)
kmi_props_setattr(kmi.properties, 'modifier', 1)
kmi = km.keymap_items.new('screen.actionzone', 'LEFTMOUSE', 'PRESS', ctrl=True)
kmi_props_setattr(kmi.properties, 'modifier', 2)
kmi = km.keymap_items.new('screen.area_split', 'NONE', 'ANY')
kmi = km.keymap_items.new('screen.area_join', 'NONE', 'ANY')
kmi = km.keymap_items.new('screen.area_dupli', 'NONE', 'ANY', shift=True)
kmi = km.keymap_items.new('screen.area_swap', 'NONE', 'ANY', ctrl=True)
kmi = km.keymap_items.new('screen.region_scale', 'NONE', 'ANY')
kmi = km.keymap_items.new('screen.screen_full_area', 'NONE', 'ANY')
kmi_props_setattr(kmi.properties, 'use_hide_panels', True)
kmi = km.keymap_items.new('screen.area_move', 'LEFTMOUSE', 'PRESS')
kmi = km.keymap_items.new('screen.area_options', 'RIGHTMOUSE', 'PRESS')
kmi = km.keymap_items.new('screen.header', 'F9', 'PRESS', ctrl=True)

They fall back to ANY here (not PRESS) [which doesnt seem to produce issues -- but havent looked further]

Could you share your exported keymap?
Did I misunderstand something?

Marking as incomplete for the time being...

In T54963#501261, @William Reynish (billreynish) wrote:

We want to find a way to enable pie menus by default in Blender 2.8, both in the default keymap and in the industry standard keymap.

The main reason why it hasnt been on by default, is that is disrupts old habits, because you can no longer just hit, say, Tab to go to Edit Mode, because it now spawns a pie menu with all the modes. While that is mostly superior, because it allows you to quickly jump to any mode, we want to make it so that we can detect the difference between a tap and a hold+drag. This way the tab key can work as it did, but holding it will spawn a pie menu instead. This will require some testing and fine tuning to make sure both are equally fast, otherwise it defeats the purpose.

In T54963#501165, @Luciano Muñoz Sessarego (looch) wrote:

Maybe im off the line here,

But I'd try to keep these multiple hotkeys for similar actions under a pie menu (wasnt that the idea of implementing them after all), like one hotkey with the pie menu for cameras (like Q in 2.79), one hotkey with a pie menu for mode (like tab in 2.79), or like pivot point with "." or manipulators with "ctrl+space"

I thought the idea was to keep the standard default keymap to a minimum so you dont need to learn 10 keymaps only to change modes, just one that quickly gets you there.

thanks

In T54943#501167, @Luciano Muñoz Sessarego (looch) wrote:

Why render display "new window", I thought one of the base ideas of blender was no obstructing overlapping windows... ?
I totally agree with the rest of your defaults, I've set them like this myself for years in 2.79

Since people prefer to have mesh element keys not offset by object mode, so that 1 is always vertex, 2 always edge and 3 always face, perhaps ~ (tilde) key could toggle object mode.

One question: Why have you decided to default background to Sky when Sky in Cycles has remained unfinished in years?

Being a 3ds Max user for almost 10 years, I can with confidence say that 3ds Max unit system is one of the worst way to go about it. It creates more problems than good. I find the best scale systems to be the ones that define precision of the scenes based on viewport/camera near and far clipping planes :)

Here is another, practical example why turning off reflective and refractive caustics won't save us from noise:
https://forums.unrealengine.com/development-discussion/rendering/1460002-luoshuang-s-gpulightmass?p=1465988#post1465988

Cycles reflective and Refractive caustics should definitely not be off by default. This goes against the usability, as renderer should deliver visually pleasing output by default. You won't achieve that by making sure glass shadows turn out completely black and metallic materials won't bounce a bit of light.

In T54963#500085, @Timur Ariman (myclay) wrote:

I find the proposed alternative Keymap intriguing and clever for the most part but since majority of those which do Sculpting and Texturing tend to use Tablets, It would be nice if that big chunk of users could be taken into consideration too for the Viewport Navigation.

3D View:
Object mode:
Viewport navigation:

ZBrush has this as its primary keymap;

• Panning: Alt+Click & drag Background
• Orbit: Click & drag Background
• Zoom: Alt+Click, Release Alt, drag Background
• Center on selection: F
  
  While I agree for the most part with the proposed Keymap, it would be quickly fatiguing and imo counter intuitive for tablet users to have to use alt+MMB and Ctrl+MMB, mouse wheel with a tablet pen.

In T54963#500039, @Okavango (Okavango) wrote:

@Ludvik Koutny (rawalanche) How about doubleclik for entering / exiting edit mode? I have it in my keymap, it is fast and intuitive as an eyeblink and it could free spacebar for something else important...

In T54963#500035, @Bram Eulaers (Leukbaars) wrote:

Oh I think the reasoning is sound, and it's a good control scheme! But it's not exactly industry standard, which would be the goal of this keymap :)

Actually here's some more reasoning:

In T54963#500030, @Bram Eulaers (Leukbaars) wrote:

This is really awesome, I have gone to great lengths to set up my current blender install to similar shortcuts already. This should make blender very appealing to new users.

I would really reconsider the Maya viewport controls though, many consider them industry standard by now. It's used in quite a few game engines and editors. You mentioned unreal, but unity, source2 and substance painter/designer use it as well, and many others. In fact it's available as an option in 3dsmax after popular demand and pretty much every industry professional using max I've talked to uses the maya standard.
I really think industry standard camera controls should probably take priority over other shortcuts, it's the primary interaction you do in Blender.

In T54963#500024, @YAFU (YAFU) wrote:

I completely agree with Alberto.
But, does this pretend to be behavior by default? If so, I'm a little confused right now. I understood that there would be changes to improve consistency between all the modes/editors within the same Blender, and make things easier for new users who use Blender as the first 3D program ever, not to satisfy users coming from other programs. I entered/know the 3D world with Blender as firts program. Then I have tried other programs and I think Blender has the best mode for viewport navigation with mouse button wheel (and the pen on a graphic tablet). Only noticed the problem of the LMB select that we all know.

Anyway, please do not touch shortcuts that are really intuitive because they are related to the English name that have tools/elements in Blender.

In T54963#500020, @Duarte Farrajota Ramos (duarteframos) wrote:

If I may add I'd like to suggest a consistent use of modifier keys.
Currently in Blender the Alt key has become sort of a "reverse" or "opposite" operator for many keys like H hies Alt+H unhides, P Parents, Alt+P unparents, R Rotates, Alt+R clears rotation, you get the idea...

I really like this system; it is consistent and easy to remember, and I think it should be maintained and even expanded to other areas.
Selection modifiers for example if left click selects I think Alt+LMB should remove from selection, if border selection as a certain key, then Alt plus that key should remove too. Same applies to whichever keys are mapped to say circle select, and any other operators.

No more middle mouse button for deselection, potentially releasing this key for viewport navigation at all times, which is probably out of scope here but would really really love to see possible: Viewport navigation during operators or at least tools

@Alberto Velázquez (dcvertice)
Actually, this was adopted from Softimage XSI/Autodesk Softimage. It's a dead software now, but it had some very good concepts, with spacebar for object mode being one of them. It's written in the reasoning paragraph. Check the attached video example. You will see that edit mode exit/toggle action is frequent and useful enough to deserve key such as spacebar. Sure, search could be on spacebar, but as I already mentioned, when there is a quick search in CG software, it more often tends to be on Tab key.

In T54963#500012, @Alberto Velázquez (dcvertice) wrote:

One of the best things I saw in blender when I started using blender six-seven years ago was the search bar. You find her almost by chance, just by pressing space. In two seconds you understand its purpose. Thanks to it I had direct access to absolutely all the functions of blender at the time, completely unaware of the program, only needing to know what I wanted to look for. I learned half the program thanks to this. Is it good to remove it from its current location on a keymap for new users? it's hard for me to see it.

It is almost a wizard for fools, which unleashes the power of blender to any user.

I think Vyacheslav meant if it's going to be default. And it is explained near the top in the "Approach" paragraph that it won't :)

I agree with @Mantas Kuginis (MantasKuginis) 's suggestions. Many of other pieces of software solve this issue by having an UI element specifically for dragging the timeline. In Video editor it's usually a small arrow on the top or the bottom of active frame cursor. It would be nice to simply be able to left click and drag the green frame number indicator. It's a bit slower than right click, since you first need to move your cursor at that exact spot and then drag it, but it's what users are generally used to.

In T54661#498925, @William Reynish (billreynish) wrote:

For sure, we would want to make it easy to switch on startup.

Looking at your keymap might be helpful, although Blender 2.8 allows for us to actually emulate the industry standard interaction method much better than before, so we might want to solve things somewhat differently than you did for the 2.7 version, in which you had to work within the old limitations.

In fact, we may need help to actually create this 'industry standard' keymap. As you know, it's a fairly big job in itself.

The goal would be to make it truly like industry standard apps, where the W key activates the Move tool and lets you drag to move. Q for the select tool, and so on. RMB for context menus.

If you agree with this goal, and seeing as you experience doing this, would you be be interested in working with us to make it?

If so, we would create a Design Task here on developer.blender.org, where we can keep track of the Industry Standard keymap design. You could then start by implementing basic things like viewport controls, and QWER. Only add things that truly work. We could then keep a list of issues that might be needed to be changed in Blender to make sure the Industry Standard keymap works properly.

By then end, we could ship Blender 2.8 with the two keymaps. What do you say? Blender 2.8 might still be too rough to really make the final keymap, but we could start with a few basic things to get the ball rolling.