Area viewed by view_all (home) operator has defaults:

In T54728#625368, @Braeden (B-Rae) wrote:

(ctrl+) Home and End seem pretty intuitive and logical - just googled the shortcuts for this because I realized the old ones no longer functioned and was getting pretty frustrated editing my timeline animation, appreciate that you guys are already on this. Thanks.

*although one thing: ctrl + home/end requires two hands, seeing as the in/out are marked using cursor location, it is a little clunky having to let go of the mouse to do this - just some food for thought.

(ctrl+) Home and End seem pretty intuitive and logical - just googled the shortcuts for this because I realized the old ones no longer functioned and was getting pretty frustrated editing my timeline animation, appreciate that you guys are already on this. Thanks.

i am Sory for the mass didn't intended to do it

Thanks for the report, but note the reporting guidelines, this is outside the scope of the bug tracker:

Blender Alt normally means remove, since this shared a keymap with the dope-sheet - which is more of a full animation editor, prefer to keep these keys free for keyframe related operators. Set this to Ctrl-Home/End.

@Campbell Barton (campbellbarton) @Pablo Vazquez (pablovazquez) et al:

It's in the playback dropdown.

Excuse me for such a simple question but, even when there is no keyboard shortcut any more to set the current frame as the start or end frame, there must be such option anywhere as an icon, context menu or something. Where is it in Blender 2.80?

In my computer desktop with geforce GTX 650, win 7 64 bit, I have the problem with the last build too. In this pc I have the 2.79 b version and whit this all work fine.

First of all, it is a separate system.
A quick content displaying system (QCD) - part of verical (hierarcial) navigation, alongside with Outliner and RenderLayers.
There are workflows that depends on it, it makes them possible, independently of layers, collections, selection groups or any other hierarcial units and their number.
It is a unique system in the software industry, that makes Blender out of the ordinary. It's demand depends on the industry to which the workflow of user belongs.

aight. i should point out that i actually have one of those nvidia 3d vision supporting displays, so your take on trying it out with a regular display is worth more.
thank you very much for taking time for all of this!

As Brecht pointed out, these adjustments only have to be made when the scaling of the lines do not match the scaling of the rest of the UI.

OMG, by pointing that out you have not only allowed me to fix it better, but also explain the entire issue better.

Hi! I made a video of the whole bug. I can also confirm that turning on stereoscopic mode does not solve the problem for me. Flickering is still there. Also please note that for some reason, when I capture the video, the flickering (black screen) is being recorded/captured for a couple of seconds (I guess when the flickering appears OBS( software that I've used to capture the video) has to reconnect to the monitor to start recording again that's why there's a bigger lag ), when in reality it just a fraction of a second of a black screen. But, as you can see in the video, preferences window and quit window prompts are still appearing behind the main window in full-screen mode.

Since I do not have commit rights, would anyone want to commit this one?

The original purpose of pixel size is retina screens, where everything is scaled up exactly 2x.

This seems to be a feature request then. The outliner is still going through quite a few design iterations so things will probably change a few time more.

right in my opinion of two cents ....

Yes, the exact order I'm not too worried about either, but I do like the idea of having four separate sections, rather than our current three.

I do like this order a lot more, it seems more organized and logical.

Doesn't the idea of categorizing the Properties icons in the way that you have suggested also imply that the current order of them could be improved? Why not have them in the order that better reflects the organization you want?

When using a Retina display (so greater than 1x scale) this patch makes very little difference since there are more pixels to play with. But it does help a lot when using blender at 1X.

This is a very small difference in veneer, with a very small upside, but even so, the negative space around the icons are better preserved with this change.

In T59802#621970, @Chingiz Jumagulov (Krayzmond) wrote:

That's really weird, considering the fact that you can turn it on only when you use specific hardware for stereoscopic 3d, also turning this option on will distort the image on your monitor in a very severe way. There has to be another more orthodox solution, this is a very pesky bug indeed.

you dont need specific hardware to turn it on, just choose the "3D Vision Discover" type of display, it will not try to detect it, as it is just a regular display using red/blue glasses.
but your are right, it will switch to 3d vision mode on some games, not on blender or regular applications, though.
@Chingiz Jumagulov (Krayzmond) could you give it a shot and try to confirm that it would get rid of the flickering?

There are more cases there it does not make sense to show topbar like full screen outliner, properties...
I was working to hide and restore topbar on fullscreen (ctr+space), but I think it should be done more generic way

In T59802#619632, @Fred Feuerstein (boogiwoogie) wrote:

i had the same issue as OP, as well as the screen flickering in black when opening preferences.
enabling nvidia stereoscopic 3d in the nvidia driver settings fixed it for me.

In T59802#619632, @Fred Feuerstein (boogiwoogie) wrote:

i had the same issue as OP, as well as the screen flickering in black when opening preferences.
enabling nvidia stereoscopic 3d in the nvidia driver settings fixed it for me.

@Campbell Barton (campbellbarton) I m in love with the ctrl+tab in the graph editor-> dope sheet and vice versa. I don't know how long it had been like this. Thanks you very much :)

it is confusing when i select object in the outliner and then selecting in the 3d viewport because in the outliner the selection line
remains on the previous object that i selected in the outliner
i think that it needs to jump to the active object but it is only my opinion .

@Brecht Van Lommel (brecht) - You ask, You get.

I thought this “line width” was intended to only affect lines in the 3D editor? With it changing everything it makes it more complex to determine how big something is since this is independent of user scale. We currently have a very large number of unnoticed “off by a pixel” errors because of this.

+1 for return key (and i've never used mac...). In windows, After effects uses it that way and it works well, and it's a prominent key we're not currently using.

@Matjaž Lamut (lamoot) Good point, updated above.

macOS uses return key to rename - F2 is not actually used universally. It would be best to perhaps leave this unmapped or choose a blender specific key for a popup. Using F2 (windows), return (macOS), ???? (Linux) on selected items in Outliner, Collections and other lists would be very welcome as that would mimic the OS - rename a sselected item. Using such a key to invoke a popup would not feel at all natural.

I agree with adding these items into the header. Putting them into the sidebar to keep the timeline clean, would make for a less clean workflow.

Operating systems use F2 to enter rename mode on files and folders. Using this key would add to consistency, but means the File Context Menu would need to be mapped to something else.

That looks very nice, great proposal. Probably out of the scope of this task, a way to set a custom falloff curve would be welcome at some point too.

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.

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

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.

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

I guess I'm the only one who thinks this is not an issue

In T57918#611187, @William Reynish (billreynish) 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:

1. Add Box Select to the Drag Action dropdown inside the transform tools
2. 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.

I guess I'm the only one who thinks this is not an issue.
A tooltip would be more than enough. I mean, there are plenty of apps with similar feature and yet there's nothing fancy happening with their buttons.

Add test for pulldown menu type.

In D4359#98915, @Mikhail Rachinskiy (alm) wrote:

This is how it always been implemented, my patch does not influence menu title positioning.

Right, it's just a consequence of the patch that the title is now at the bottom most of the time instead of the top. Which I think is acceptable, but it's a slight downside.

Putting the enum menu title at the bottom is a bit odd, but seems fine to me anyway.

This is how it always been implemented, my patch does not influence menu title positioning.

Well ignoring any political aspects to it (just don't mention my name. LOL), the parts to be thought through carefully are mostly about "extending" selection while changing modes.

Putting the enum menu title at the bottom is a bit odd, but seems fine to me anyway.

In D4359#98906, @Pablo Vazquez (pablovazquez) wrote:

In D4359#98903, @Duarte Farrajota Ramos (duarteframos) wrote:

PS: Please always use 2.8 for screenshots as it can get confusing for users and developers.

This is not just a cosmetic issue...

In D4359#98903, @Duarte Farrajota Ramos (duarteframos) wrote:

Not sure if it can be addressed by this patch, but it seems related.
In the RGB curves node, the wrench icon menu opens sideways to the right of the button, unlike any other, which can get annoying.

I would happily aprove of this change. It would single handedly solve the problem by making it immediately discoverable, at the (IMHO small) expense of a little a little getting used to the new behavior.

@Harley Acheson (harley) I don't see why that would be an issue. To me it seems like a fine solution to make it add to the selection by default. It makes it immediately obvious that you can select multiple items. We don't use this widget type many places - I think that would ok, a nice improvement even.

To be honest, I don't think the first solution could be implemented in practice because the howls of protest would be unbearable. LOL. But it could be thought through. I had suggested using ctrl-click for current behavior, but that was wrong. That suggestion was really about just swapping the default behavior with the current Shift behavior. And we do have some (fairly) consistent rules on how shift, ctrl, and alt change selection behaviors.

@Duarte Farrajota Ramos (duarteframos) That is unrelated. This task is about enums.

Not sure if it can be addressed by this patch, but it seems related.
In the RGB curves node, the wrench icon menu opens sideways to the right of the button, unlike any other, which can get annoying.

The exact colors and saturation is secondary. This would be defined in the theme anyway.

may reduce saturation?

The main reason would be to provide a visual way to find the shortcuts G, R and S.

Does other software have transform operators in the UI? After all, we have gizmos, so this seems somewhat redundant, and would clutter the UI imo.

@Harley Acheson (harley) These ideas seem very good to me. I actually agree with both of your ideas, which are not mutually exclusive.

Yes, that would be a lot more work to do. Still, it’s something to keep in mind for later. For now I think opening downwards is at least nicer.

But that would also require to write a new widget type, which is far beyond the scope of this patch.

Just to add some more flavour here.

In D4359#98890, @Mikhail Rachinskiy (alm) wrote:

does it also affect color picker-type popups?

It does not, color picker is a different widget type.

does it also affect color picker-type popups?

It does not, color picker is a different widget type.

Sounds like an improvement for sure! I remember it being mentioned in the past multiple times.