Caused by rBe49d9555418d: Wireframe: Refactor to use GL_LINES instead of triangles with alpha blend.

Problem is, that blocked area is absolute, regardless of timeline zoom and it can block lower channels., as you can not pan below zero.

I'm pretty sure this was introduced on rB5f2b4002f49b0 (@Sergey Sharybin (sergey)).

This comment here (from rBc6e3a20ab60b):

Confirmed, for me this already hangs in node_clipboard_copy_exec
(probably endless loop because new node is automatically selected....)

Great. I largely agree with the updated task description here. To me this sounds like a nice list of small improvements to make the UI clearer for this.

I have no read all of this task yet. But I think an important missing piece is improving the dependency graph so that hidden objects are never evaluated, while keeping toggling visibility fast. Users shouldn't have to worry about the distinction.

In conclusion, I think a few things are becoming clear:

@Julien Kaspar (JulienKaspar): Yes, that was simply my point too. The checkmark makes the feature more obvious and clear.

I would oppose removing the ability to set render and viewport visibility independently.
There are several cases where you want objects visible in the viewport but not renderable. Here is a few:

@carlos (c17vfx) It's an interesting proposal but this kind of menu would be a nightmare to manage.
Imagine having to click through potentially hundreds of collections and objects to change these settings. Keeping this in the outliner makes it very easy to manage.

this section could help to separate things a bit from the viewer / render

@William Reynish (billreynish)
I absolutely agree. The eye and checkmark/excluding should be front and center to make clear what should be used the most. Good tooltips can clear up any remaining confusion.

@Ali (Ali6): That's why I proposed to promote the hidden exclude/disable toggle as a checkmark to disable visibility in both the viewport and render. In many many cases, disabling for both is exactly what you want - it's the WYSIWYG philosophy.

I'm a bit new to Blender but couldn't you just merge everything into the eye icon? Surely if you're disabling it from the viewport you would probably want to disable it from rendering as well? I don't see when you would need to do one or the other. I understand the disable collection from viewport selection but couldn't everything else could be merged into one?

They way those states relate to the other features are and presented in the UI is so hidden and confusing that very few people will find them, and if they do, it's completely non-obvious how they work,

@Brecht Van Lommel (brecht), we used to have, there is prepare_xubuntu_14_10.sh. We also had studio-related distro with silent install which was taking care of everything. But those things becomes out if date very soon, and with heterogenous distro environment such things becomes rather PITA to maintain and nobody does it :(

The current system 'works' but is very confusing if you factor in the Include/exclude and enable/disable states.

I'm going full circle. The current way the visibility system works is the most functional for all cases. If we attempt to simplify, remove or merge any of the toggles we would need to make certain use cases still possible by introducing hidden features like locking, more options in object/collection tabs in the properties, leaving the user to do a lot more collection management & potentially more.

It appears Blender was being built without libxi-dev on @Pablo Vazquez (pablovazquez)'s system, which means there was no tablet detection. I've installed that now.

@Brecht Van Lommel (brecht) indeed, reverting rB2778ecb58cd23 seems to fix it.

More likely my fault.

This is more an interface/Python issue, not sure why it was assigned to me.
@Jacques Lucke (JacquesLucke) wants to look at this?

Damnit ... in a lot of cases when keeping collections or objects always hidden in the viewport, either in the current file or for linking, is to hide high res geometry that will be used for rendering but is too taxing for the viewport performance. But since the eye icon doesn't improve performance, this becomes impossible.
With view layers and checkmark setups this can still be achieved in my version of the proposal but this setup couldn't be linked over to other files and needs to be set up every time.
Neither of these solutions with 3 toggles and locking can work for these cases.

• Ideally, we could make it so it the linked visibility is set in the scene you link TO, not FROM
  
  ...
• We could set the linked visibility inside the Object > Collections panel

@Julien Kaspar (JulienKaspar): Posted at the same time :)

In T61361#618103, @Julien Kaspar (JulienKaspar) wrote:

@William Reynish (billreynish) I like the proposal but I think we still need to be careful how to implement it exactly. The current visibility system is at least usable in a lot of ways but when attempting to simplify the complexity we could lose important functionality.
When thinking longer about it, I can see one big issue with the proposal as an example:

When linking a collection/object, how does Blender know if the Eye or Camera is toggled off or on.
Since these 2 icons would be per view layer toggles, a collection/object could be seen as hidden in one view layer while shown in another. Because of this, would the icons be always toggled on when linked into another file instead of inheriting the setting?

Ok how about this:

@William Reynish (billreynish) I like the proposal but I think we still need to be careful how to implement it exactly. The current visibility system is at least usable in a lot of ways but when attempting to simplify the complexity we could lose important functionality.
When thinking longer about it, I can see one big issue with the proposal as an example:

It's indeed a duplicate.

Can you see if this is still an issue with the latest commit? Sergey just fixed a issue that this seems to be a duplicate of: T61362