Blender UI paper cuts

user-interface

#789

A better layout, with less space between elements, remove or improve the arrows to use less space (or put a simple drag and drop element like any other panel) and use the icon of the modifier to activate or deactivate. These type of changes will help a lot.


#790

One thing I’ve had trouble with the UI is on a smaller monitor the header tabs don’t all display and control+middle mouse button doesn’t work to scroll like it normally does. I think this would be a good opportunity to have icons for common workspaces such as texture or sculpting, and only use text for custom ones. Icons would take up way less space which is important for smaller monitors and for people who have a lot of workspaces created.


#791

yes it would be great to improve modifiers UI more fundamentally, but it seems not worth it if nodal modifiers are coming soon-ish anyway.

There’s a lot of room for improvements, like:

  • Use UI-list for modifier list, with panels below
  • Drag and drop to re-order
  • Use real panels for modifiers so we can use sub-panels
  • Properly integrate particles and physics, so you don’t have to dance back and forth
  • Properly integrate textures into the modifiers that need them

etc.


#792

But any interface won’t work with nodal modifiers. And soon-ish could be ¿2-3 years?


#793

Shadows under icons, matching those under the text labels. It should get done before official stable release, as it will drastically improove local contrast and pictograms redability.
So - shadows under icons are urgently needed.


#794

Looking forward to that!


#795

Do they have to collapse to one line?

Wouldn’t this work?:


#796

The buttons don’t have to move around.

Here’s a quick mockup made on BGE lol (RIP)

MouseOver

The only thing required would be an editor width check to see if the properties editor width is less than X pixels. If it is, then hide the buttons and add the “gear” rollover button. (I think this code is already there being used on the responsive layout)

Another solution would be: If the editor width is less than X pixels, push the buttons to a line below.
This way, the collapsed modifier/constraint would naturally occupy two lines on a small screen, and uncollapsing it would reveal the main options of the modifier (not the reveal/activate/apply buttons etc).
It would require more scrolling, but at least the name and main options would be visible at all times.
EDIT: exactly like @enenra mentioned above. Thanks for making the mockup!!


#797

Other problem. Actual header doesn’t enter in the viewport in a 15’ laptop

The menus and words like Overlays and Shading need a lot of space.


#798

It would be nice to have more control over shadows while we’re at it.
It would help make some themes more readable.


#799

That doesn’t work for some pretty obvious reasons.

  1. you can’t see the state without rolling over each one carefully, one at a time, which is one of the main points of these.
  2. The buttons are then very hard to hit, because you must carefully roll over the cog icon to reveal the others, then carefully move over along the line.

#800

We will probably combine the two visibility popovers into one.

Earlier in 2.8, we had the transform settings inside the tool settings, where we typically have lots of space, and which left a lot more room inside the viewport.

But many users complained, so we relented and put them back in the viewport, which reinstated this problem. I still think it was better to have them in the Tool Settings - both because it makes sense, and because then we don’t duplicate these settings in every viewport, which is silly - even more so if you have multiple viewports.


#801

But transform settings are not in the header. I don’t understand you.


#802

They are. Orientation, Snap, Pivot etc.


#803

That controls are really important to move in the topbar, that made impossible to use it. For example, my monitor is a 27’ monitor, with actual topbar configuration is hard to use to use that controls outside the viewport because between my working zone in the viewport and that controls I have ¿30-40cm? of space.

If the topbar was a independent area that you can put in the toppart of the viewport that solution could be really good.


#804

Maybe this would do?:


#805

It changes the problem of scroll the header to open a new menu.

The Topbar in a editor could be a solution for this and other complains of users about topbar, that they want to put in other position…


#806

Not 100% sure if this fits here, but the trackpad support is superb… on OS X only. If we could have it work in windows (laptops) that would be excellent.


#807

I have to ask… how’d you get that companion cube in the view orientation widget??


#808

I would find it easier to reorder the modifiers if the arrows could be replaced with some drag system, same as the panels in the properties. I find it quite tedious to click a modifier from bottom to top by using the arrows. It should only recalculate the order of the modifiers when releasing the mouse button. Would be nice if it’s possible.