Blender 2.8 development thread

22 posts were split to a new topic: Customizable UI Discussion

They’re using git, so there’s no need for swapping anything by devs. Designers pullrequests their changes and devs just click ‘accept’.

This is the github workflow, we’re using git with Phabricator which doesn’t work this way (see phabricator /arcanist docs if you’re interested in the details).

Currently the icon blend file is committed directly to subversion (which beats git for binary file handling), the rest of the generation is automated.


Hi, I know it’s a bit off topic from the current conversation, but here’s one of my concerns related to the new tool system based manipulators:

One problem with widget manipulators in 2.79 was that when you were rotating with manipulator, you still often had to resort to reaching for numpad to type precise rotation, because it happens very frequently that you want to rotate something exactly 90 or 180 degrees.

You can use snap for that, but a big problem with snap in Blender is that it groups incremental move snap with incremental rotation snap. Let’s say you are working on a precise scene so you use vertex snap very often. Every time you want to rotate something precisely, you have to first switch snapping mode to increment, then activate it while rotating, and once you finish rotation, you have to switch snapping mode back from increment to vertex. This is quite frustrating experience.

So my suggestion would be to have hard-coded snap for rotation widget, which is unrelated to the state of move tool snapping mode, so that when you hold down whatever is assigned as a snap key, in rotation mode, it will always snap to angular increments regardless of if the active snap mode is increment or not. It would help a lot with the workflow.


As for the icons, I am really, really sad to see those flat, washed out, high pass filter like icons in recent build.

I mean how could we possibly get from something as beautiful and professional looking as that to something as ugly and open-source looking like this?

Judging by all the mockups and design proposals on code quest task list, William is an astonishingly competent and talented designer. We should let him do his work for at least a few weeks to give him a chance to put all the visual design together before we start to fuck up his work with our uninformed feedback, so we avoid debacles like this.

EDIT: With this said though, I do find the new Move, Rotate and Scale icons better. The manipulator widget style ones really did not fit :slight_smile:


Aggreed. I liked the “old new icons” much much better.

1 Like

It’s just the flat icons set, you will be able to choose the ones you prefer I think.

That’s a very unfortunate family of colors, even for the iterated version.I wouldn’t mind neutral colors, but those are in the family of repulsive colors - like the color they started to put on cigarette packs.

Would be nice to not have to associate sculpting with … chocolate.

1 Like

sadly thou, Mud is already taken. :stuck_out_tongue_winking_eye:

Just hold CTRL

I don’t remember nobody asking for this type of icons to “fuck up” something.

The sculpt icons must had only few basic rules

  • Easy to read
  • Easy to generate new icons

All people in industry uses same icons style because it meets the requiriments

We have a lot of brushes really similar and it’s necessary that you can differenciate all brushes, with simple icons is not possible because it lack information.


Have you actually read my entire post? :slight_smile:

Try to switch snap mode to vertex instead of increment, and then try to hold down Ctrl while rotating. You will see that angle snap no longer works. So if you are working with vertex snapping, you actually have to switch to increment snapping mode every single time you want to rotate something with snapping, and then switch back from increment snapping to vertex snapping mode to carry on with your vertex snapped modeling.


Well, just take a look at your example and at the picture in my post. You can see that the older concept with plastic looking icons is much close to what’s on your example than the new flat look.

I think we are getting bogged down with the style of the icons…
The real task is to make things work better.
We don’t want William to spend all his code quest time redoing icons and never satisfy anyone in the process.
Plenty of other stuff to attend to.
(Incidentally I vote for the previous set…) :yum:


Yes, but they still generated with 2D program and nobody will keep the style. And those icons are also hard to read.

I though that you was working with UI team to give feedback.

Again, it’s not William who make the icons.

1 Like

If you are used to the forum or to download .blend files from different users, you can see that users have very different ways of dividing or configuring areas/editors, headers and properties locations. I guess those settings are not whimsical, but that they are chosen according to the convenience or taste of each user.
But with the new Top Bar design (at least how it works for now), does it make sense any other configuration of Areas/Editors where the 3D View is not exactly below Top Bar?. In any configuration where 3D View is somewhat away from Top Bar, it starts to be annoying because the long trail with the mouse. I do not know if there is a possible solution with the current design, because the lower part where the options appear in Top Bar are very related to the upper part of the menu because the tabs, so I do not think that the lower part with options in the bar could be separate for it to be a floating bar with the possibility of it being able to be placed always near where you decide to configure 3D View (or any other place where the bar might be necessary), to allow greater possibilities of configuration of areas/editors.

1 Like

That’s true. E.g. this is my default setup that has worked splendidly for me for quite a while:

I’ll be pretty annoyed if I have to change it because the topbar is immovable. They wouldn’t do that though, would they? Surely the bar is meant to work per area eventually, right?

1 Like

The top bar is for the active operator I think and you can only hide it.
It will show the options of the operator you use even if you’re in 3dview or image editor.

That’s quite bad. I often use node and image editors on top and have 3D view on the bottom of the screen. I would have very long travel distance to topbar (I use 2160p display).
Wouldn’t it make more sense if there’ll be one hideable topbar per 3dView?