Display Tab UI change

I have noticed that the display tab in WIP is no longer available, instead is shows as sub-tab under Properties.
Since I constantly use it the new organization makes is much less accessible and user friendly, especially that with any objects selected the Display tab is not accessible at all.

It makes some logical sense to have these options as sub-tab under view properties when nothing is selected, but could we also have the previous style, stand-alone Display tab that can be moved freely,docked and accessible all the time ?



Hi Jarek - This is an experiment at this point - I’m not sure how it will end up, but I think nothing is final about this change…


Thanks Pascal, the main problem for me is the access to it when having selection on… so my 2c when considering this UI change. Thanks!


Yep, that was my question/reservation as well - Pascal

Hi @Jarek and @pascal

I wholeheartedly second Jarek’s motion, although I haven’t got the WIP installed (company policy :frowning: ). But that doesn’t change the fact, that I use the display tab a lot - especially in conjunction with Neon - turning visibility (curves etc.) on and off.


I had the same initial reactions but admittedly I’ve gotten used to the act of deselecting (Alt+click) to access the Display section. @andy is running the big picture on this one, so he may have more to add.

Hi Brian,

For me the fact that you have to deselect to access the panel is a major step back.
If the Display needs to stay under revised Properties tab, please consider leaving the stand-alone version of it too for any-time access and screen location flexibility. This panel was a great addition and would be bad to see it go away.


There does appear to be a split in opinion on the new “Display properties in the view properties” UI - but at the moment it looks like the weight of opinion is that we should switch back to the display panel.

Is there anyone who would like to speak up for the new style before I change it back?


Note that the display panel is not “Gone” - it is moved.

  • Andy

My vote is to keep display as a separate tab/panel.

I preferred the way it was.

Hi @andy

I got that, yes. But I would still prefer the two (properties and disp. tab) as separate items, as I have them both on display, and - just like Jarek - find it cumbersome to deselect in order to access the display options… and quite often use the disp. tab mid-command - sort of visual selection filters.

So I’m all for going back to the way it was… oh, my… I’m getting old! :stuck_out_tongue_winking_eye:


My vote is also to keep the display setting on its own tab.

RH-37378 is fixed in the latest WIP - the display tab is back in it’s own page.

Hi Brian,
Giving Display Properties its own panel back is better, yes.

I generally find the double row of Tabs in Object properties (and now starting in Viewport Properties > nothing selected) a very poor UX decision. Actually I had already started writing a rant as I first discovered the change, but it was Christmas time and I thought I’d give you a break. But now, as the new year is almost over again – here it goes.

Reasons why those Sub-Tabs suck:

  • They are a isolated concept, an exeption from the rule.
    Only Object properties has them in V5. In V6 you are not trying to abolish this shortcoming but you sneak them in in Viewport Properties too.

  • Sub-Tabs are visually ugly.
    They don’t match the styling of parent Tabs – these are just buttons which load pages.

  • They lock features in place and that is by far worst of all:
    Users thus have no way to rearrange content of sub-tabs to areas which make more sense in their workflow. It happens to me practically on a daily basis that I need simultaneous access to features from one or more child Tab and the parent Tab (Object Properties). This can make some workflows, e.g. in texturing and material creation quite inelegant and way more clicky than actually needed. As I know the program well, I may help myself with Macros and such, but that’s likely not what most users will do. Another really bad consequence of locking functionality in place is that one can’t turn irrelevant stuff off. I’m sure that I won’t ever touch several of V6 object properties sub-pages and now also of Viewport Properties > Save Frames) but I will have to look at them nonetheless. That’s not nice.

Other programs handle this sort of challenge a lot better, among them is Blender. Users may collapse currently unused clusters of functionality within Panels, seldomly used stuff may get dragged to the very bottom of the Panel. One may let some vital feature appear in various places / work contexts or may build entirely custom Panels. Obviously one can reload the default setup as well.

Rhino also in V6 is unfortunately equally inflexible in terms of editing the default GUI as previous versions.
Overwritten default keyboard shortcuts still appear wrongly in the Menus (Make Ctrl+Shift+S SaveAs and
see the Keyboard Hint still appear in Edit/Split). Delayed context Menus still have some default entries users
can’t throw out… and in case someone has the idea to recolour the GUI to a darker scheme this still doesn’t
work properly.


Page-Item rearrangement in Blender

1 Like

Agree with the fact that ViewProperties still depend on nothing being selected. At least that part I would suggest moving into a separate, stand-alone tab so they can be accessed anytime (and perhaps grouped so there is no need for 2 sub-tabs; the safe frame could just go below.

The collapsible Panel tabs are a good idea obviously but much harder to implement. I vote yes for separating ViewProperties and ObjectProperties into 2 separate panels.


1 Like

Well - what applies for Cycles is also true for Blenders super-flexible GUI framework:
One could freely reuse it even in commercial apps ;o)

My problem with hard-coded Design of any larger fraction of Software work-spaces is a quite bold
inherent statement. It’s clearly nothing anyone @McNeel was willing to repeat, but it’s still there
nonetheless: “We think that our users will like all aspects of the product and happily use all tools
precisely in the way we once arranged them.”

The reality is likely quite plain. No proper idea where to put some elements after one got rid of pulldown
Menus for V4, users didn’t complain much > things stuck. Likely also the reason why this odd slide-out
for the UV Editor will make it to V6 as well. And once documented and translated, friction grows in terms
of touching even those areas of the program which aren’t exactly well thought out.

Hi Holger, I 100% agree, just trying to go for the ‘low hanging fruit’ with some easy tweaks that actually may happen in V6.
In a long run a more modern and customizable UI when it comes to panels and docking flexibility etc. would be great. I am sure this is V7 or later kind of conversation though…