New Editor Theme

Smaller fonts, yet takes up more vertical space. Not an improvement at all IMO. Components already take up tons of vertical space in the Inspector, if anything the goal should be using up less space. Also, the distinction where one component ends and another begins is very difficult to see now.

 

It should be noted that macOS 10.14 (Mojave) may cause certain applications to look much worse on non-retina displays: Apple disabled subpixel antialiasing by default (reference). This caused issues for several Electron-based apps (including Visual Studio Code) on low-DPI displays. A "fix" for this was eventually identified.

If you're on macOS Mojave and use Unity on a low resolution screen, you may want to try the following and see if it improves your font experience:

1. Open Terminal.app.
2. Type command: defaults write -g CGFontRenderingFontSmoothingDisabled -bool FALSE
3. Restart or Log Out/In of your account.

This may help with some font rendering issues...

 

That post is correct: Unity uses a different font on Windows than it does on macOS. Specifically:

1. Windows: Verdana
2. macOS: Lucida Grande

Hopefully whatever they decide to do going forward will unify things. It's annoying as sin to have to specifically size things for different platforms because they use different fonts...

 

+1 billlion trillion xegamillion !!!!

I hate flat design. It's a curse on the intellectual progress of entire humanity!!! Curse you Unity!!!

 

When SourceTree switched to flat design, I stopped upgrading it. I am still using a very old version of SourceTree for non-flat UI. I can use an old SourceTree because it's just a version control tool but Unity!!!

No Unity. Please don't do this to me NOOO!!!

 

I have to say I really like the new UI. It's very clean, I think information is much easier to parse visually.

There's only two exceptions:

1) I will agree with many other comments, the text is harder to read. The whole thing looks a bit blurry and is harder on the eyes.

2) There's some places on the UI where the flat design is not doing so great, it's lacking a bit of contrast. A good example would be in the different tabs of windows docked; the select tab does not contrast enough with the unselected ones. I think a little bit more contrast here and there would really help with the readability.

 

Kinda use Adobe's UI design as reference and it would be okay.
I hope this is not final yet.
Cheers for the hard work!

PS. GIFF US DARKER THEME!

 

Here is a full fontsettings.txt form 2018.3.0b4 windows:

Code (CSharp):

1. English|default=Verdana, Tahoma, Arial
2. English|Lucida Grande=Verdana, Tahoma
3. English|Lucida Grande Bold=Verdana Bold, Tahoma Bold
4. English|Lucida Grande small=Verdana, Tahoma
5. English|Lucida Grande small bold=Verdana Bold, Tahoma Bold
6. English|Lucida Grande Big=Verdana, Tahoma
7. English|Lucida Grande Warning=Verdana, Tahoma
8.  
9. Japanese|default=Yu Gothic UI, Meiryo UI, Verdana, Tahoma, Arial
10. Japanese|Lucida Grande=Yu Gothic UI, Meiryo UI, Verdana, Tahoma
11. Japanese|Lucida Grande Bold=Yu Gothic UI Bold, Meiryo UI Bold, Verdana Bold, Tahoma Bold
12. Japanese|Lucida Grande small=Yu Gothic UI, Meiryo UI, Verdana, Tahoma
13. Japanese|Lucida Grande small bold=Yu Gothic UI Bold, Meiryo UI Bold, Verdana Bold, Tahoma Bold
14. Japanese|Lucida Grande Big=Yu Gothic UI, Meiryo UI, Verdana, Tahoma
15. Japanese|Lucida Grande Warning=Yu Gothic UI, Meiryo UI, Verdana, Tahoma
16.  
17. Chinese|default=Lucida Grande, Microsoft YaHei, SimHei, STHeiti, Verdana, Tahoma, Arial
18. Chinese|Lucida Grande=Lucida Grande, Microsoft YaHei, SimHei, STHeiti, Verdana, Tahoma
19. Chinese|Lucida Grande Bold=Lucida Grande Bold, Microsoft YaHei Bold, SimHei, STHeiti, Verdana Bold, Tahoma Bold
20. Chinese|Lucida Grande small=Lucida Grande, Microsoft YaHei, SimHei, STHeiti, Verdana, Tahoma
21. Chinese|Lucida Grande small bold=Lucida Grande Bold, Microsoft YaHei Bold, SimHei, STHeiti, Verdana Bold, Tahoma Bold
22. Chinese|Lucida Grande Big=Lucida Grande, Microsoft YaHei, SimHei, STHeiti, Verdana, Tahoma
23. Chinese|Lucida Grande Warning=Lucida Grande, Microsoft YaHei, SimHei, STHeiti, Verdana, Tahoma
24.  
25. ChineseTraditional|default=Microsoft YaHei, SimHei, STHeiti, Verdana, Tahoma, Arial
26. ChineseTraditional|Lucida Grande=Microsoft YaHei, SimHei, STHeiti, Verdana, Tahoma
27. ChineseTraditional|Lucida Grande Bold=Microsoft YaHei Bold, SimHei, STHeiti, Verdana Bold, Tahoma Bold
28. ChineseTraditional|Lucida Grande small=Microsoft YaHei, SimHei, STHeiti, Verdana, Tahoma
29. ChineseTraditional|Lucida Grande small bold=Microsoft YaHei Bold, SimHei, STHeiti, Verdana Bold, Tahoma Bold
30. ChineseTraditional|Lucida Grande Big=Microsoft YaHei, SimHei, STHeiti, Verdana, Tahoma
31. ChineseTraditional|Lucida Grande Warning=Microsoft YaHei, SimHei, STHeiti, Verdana, Tahoma
32.  
33. ChineseSimplified|default=Microsoft YaHei, SimHei, STHeiti, Verdana, Tahoma, Arial
34. ChineseSimplified|Lucida Grande=Microsoft YaHei, SimHei, STHeiti, Verdana, Tahoma
35. ChineseSimplified|Lucida Grande Bold=Microsoft YaHei Bold, SimHei, STHeiti, Verdana Bold, Tahoma Bold
36. ChineseSimplified|Lucida Grande small=Microsoft YaHei, SimHei, STHeiti, Verdana, Tahoma
37. ChineseSimplified|Lucida Grande small bold=Microsoft YaHei Bold, SimHei, STHeiti, Verdana Bold, Tahoma Bold
38. ChineseSimplified|Lucida Grande Big=Microsoft YaHei, SimHei, STHeiti, Verdana, Tahoma
39. ChineseSimplified|Lucida Grande Warning=Microsoft YaHei, SimHei, STHeiti, Verdana, Tahoma
40.  
41. Korean|default=Yu Gothic UI, Meiryo UI, Verdana, Tahoma, Arial
42. Korean|Lucida Grande=Yu Gothic UI, Meiryo UI, Verdana, Tahoma
43. Korean|Lucida Grande Bold=Yu Gothic UI Bold, Meiryo UI Bold, Verdana Bold, Tahoma Bold
44. Korean|Lucida Grande small=Yu Gothic UI, Meiryo UI, Verdana, Tahoma
45. Korean|Lucida Grande small bold=Yu Gothic UI Bold, Meiryo UI Bold, Verdana Bold, Tahoma Bold
46. Korean|Lucida Grande Big=Yu Gothic UI, Meiryo UI, Verdana, Tahoma
47. Korean|Lucida Grande Warning=Yu Gothic UI, Meiryo UI, Verdana, Tahoma
48.  
49. Russian|default=Lucida Grande, Arial
50. Russian|Lucida Grande=Lucida Grande
51. Russian|Lucida Grande Bold=Lucida Grande Bold
52. Russian|Lucida Grande small=Lucida Grande
53. Russian|Lucida Grande small bold=Lucida Grande Bold
54. Russian|Lucida Grande Big=Lucida Grande
55. Russian|Lucida Grande Warning=Lucida Grande

As you can see, English language uses Verdana (then Tahoma, etc.). And for many years, every time I run the editor on Windows I keep seeing Verdana, not Lucida Grande

 

I agree, Adobe CC is a very good example of crisp, pixel perfect dark UI with flat style and recognizable controls. Notice how readable every label is while being rendered at resolution similar to EditorStyles.miniLabel.

 

While on the subject of references, DaVinci Resolve 15 is another favorite of mine. I believe you already referenced it back when new controls for the post-processing stack were being created - it has a nice low-contrast dark theme with well styled buttons, good spacing, crisp labels, clear difference between disabled and enabled elements despite use of low-contrast palette etc.

 

Tried the new new version and still keep my opinion, I'd prefer increased size for everything, the close button is hard to even click here :

 

I've decided I don't like this. Even if you fix most of the issues, in my eyes you will have a theme that is as usable as the old one, which seems to me like wasted effort.

But whatever.

Here is my request: Can you at least make sure that input fields, dropdowns and buttons are visually distinct? I want to be able to tell what each is at a glance. You don't have to bring back the gradients if you don't want to, but you can not do nothing.

 

I've just confirmed that, as others also pointed out, Verdana is the font currently used in Unity Editor in Windows, not Lucida Grande.

Check out the file fontsettings.txt in the editor Editor\Data\Resources folder:

​

You may change "Verdana" with something different...

​

Surely many will hate me, but... Unity Editor 2018 in Comic Sans! (click to see full size).



The trick no longer works in 2019 alpha.

 

Well.. It's roughly as good as Roboto.

 

Replying to myself, the Package Manager in Unity 2019 alpha still applies the font substitutions in fontsettings.txt:

Spoiler: Pic of the Package Manager with Comic Sans text

 

Well, apart of minor smoothing issues with some characters (k, x, o, maybe e), to me the font is certainly better than what I've seen so far.



Surely those minor issues can be resolved by fine-tuning the font settings. Also, it looks like the bold texts are using the regular version.

 

This is a definite improvement, a proper display typeface with pixel perfect rendering makes a world of difference. A few points:

• Since font size was probably increased by a point only because Roboto had issues with readability at small sizes, it's worth reverting that change now - everything looks a bit needlessly cramped now
• I'd really like to ask for a little bit more transparent white labels - the brightness on the right is not an improvement over the old skin and would lead to more eye strain in longer sessions. I do like the idea of slightly differentiating the alpha of values and field names, though - just not at this intensity.

 

Alpha of field name labels can safely be divided by half without compromising readability - it would even make differently styled value text pop more:

 

There's just not enough visual hierarchy in most of these examples. The text is all too white, which is part of the problem.

This is a design I was playing with for our application, based on the old UI elements. I generally like a flatter style, but I think the new UI pushes it a little too far. Maybe pull back on the shading a little, but drop shadows make a big difference in distinguishing clickable elements from everything else.

My rationale for this mockup: (I've changed the names of the functions to something generic because, reasons)

We use lots of dropdowns for triggers and variables, then there are general functions for everything else. Here I've added a little outline color coding to differentiate between each kind of UI element:

Blue = Triggers
Gold = Variables
Green = General options for everything else

In addition, I put icons inline next to the triggers to define which are in and out. Made the section headers in a larger font. Also, as I said in previous posts, getting rid of this "always span the window" property for every field and dropdown helps readability as well.

It may not be for everyone and every use case, but for us, this will help our users parse what they're looking at much easier than what is currently a bit crowded and homogenous looking UI.

When you have to look at a giant stack of inspector panels (and they do!), these enhancements help a lot.

 

This is a clear example of how varying the intensity of the white text not only provides another method to visually group and categorize elements, but also improves readability. I was finding the newer UI to be harder to read because every text element seems so white with little contrast to help guide you.

 

Have you guys seen the Blender 2.8 UI options:

I find it a bit silly that Unity holds a dark theme hostage behind a paywall for most users.

 

just a random thought.. how about just upgrading the UI (backend) system,
but aiming for the same look as in the current version?
(that means, using old fonts, colors, icons etc. Why not, since they are not broken?)

then start working on customization,
to allow users to keep old style if they wish (or to customize at least some of the main things),
all those would come before new style is forced on users (as i doubt its usable anytime soon..)

this would save unity's time and money
- no need keep going back and forth adjusting (and fixing) things, also since there is not clear goal how it should look..
- no need to do panic-revert-patches when broken UI is released (as in lithium_scale*9000)
- no angry customers or switching engines when UI is messed up in the released version

and save time and money for users
- save time, from no need to start manually hacking unity interface, trying to make it not hurt your eyes

and in general everyone would be happy!

 

Allow me to level some more criticism by cutting and pasting a bit from your screenshots:



Which one above is a label, which is a button and which is a text field?

Which one allows interaction and which one doesn't?

Am I wrong, or is the difference is literally 4 pixels and a slight value shift?

 

To play devils advocate for a bit, if editable elements have a distinct alpha value, then passive text like field name labels is easy to separate. With that in place, borders and background fills are no longer the only visual cue separating editable text from non-editable text and a button becomes quite distinct from a dropdown or an input field even if their styling is very minimal. Possible style can go as follows:

• Passive text: halved text alpha, no border
• Button: border, slightly brighter background (as if "raised" above the surface), halved text alpha (also, buttons typically have centered text, separating them from editable fields further)
• Dropdown: border, slightly brighter background (as if "raised" above the surface), full text alpha (indicating editable value), dropdown icon in the corner
• Input field: border, slightly darker background (as if "cut" into the surface), full text alpha (indicating editable value)

 

Here is an edit of a screenshot Edy posted higher up: with halved alpha on all non-editable labels, a text button and some fixes to messy padding of borders. Most importantly, every input field is now darker than the background (as if cut into the background as opposed to protruding from the background like brighter elements). This improves readability by a ton - see how easy it is to separate buttons from inputs and to find the right field at a glance now?



Minor notes on existing in-editor style:

• Bool field borders are offset 1px to the right relative to the rest of the input fields, which looks somewhat messy - worth a quick fix
• It might be best to avoid using a separate background color on top of the inspector - doing so is a path to having to support separate styling for every element inhabiting the top section, since they won't necessarily work exactly as well as on component background color
• Every single input field could use a bit of left side padding for its content - right now every number hugs the left edge of the field quite closely, which harms readability a bit
• X, Y, Z text next to vector fields should me moved a few pixels to the right - as it stands it is quite a bit closer to the fields on the left rather than to the fields they are supposed to label
• There are some cases where input fields stick together, like near/far inputs of a probe - but that is probably caused not by the style but by the drawer itself incorrectly calculating line offset for these fields

 

@bac9-flcl
That's pretty awesome!
But what about the button text? It looks like the button is disabled (maybe that's actually the case).

I'd prefer the font size of the inspector labels to be one tick smaller still, but that's just me.

 

I guess I can see that semi-transparent passive style can be misinterpreted as disabled if there are no neighboring labels to compare it to. But when there is more than one labels on the screen, I think that halving of halved alpha reads pretty well - like on the "Blend Distance" field on the screenshot above, which clearly reads as a disabled field in contrast to surrounding fields.

But maybe disabled buttons can also remove their background color ("moving flush" with the background), removing possible ambiguity between enabled and disabled buttons? "Raised", lighter background color is what makes a button read as "clickable", so removing that in the disabled state can be a strong differentiating feature even if the passive semitransparent text style used on buttons can't always communicate that alone.

Yeah, I agree - I think current size is a recent change introduced as an attempt to fix readability of Roboto and can be reverted, as I mentioned in one of my previous posts.

 

Oh, no no, sorry for the misunderstanding.
The labels themselves are perfect with the reduced alpha.

I was exclusively talking about the button.

 

I don't actually care myself, but I can't help but notice that locking the professional dark theme behind a paywall seems to go against every goal you've stated here. All professional modern software programs use a dark theme, so it's something users are most familiar with. Darker themes are also more accessible for users with vision disabilities and also improve usability in general. So just unlocking the dark theme for all users would seem to satisfy most of your stated goals.

p.s.

You've also stated that you plan to allow customization of themes, font sizes, etc. in the future. Will these accessibility features also be locked behind a paywall? That combined with a brighter personal theme would probably only exacerbate the frustrations of some visually impaired users.

I suppose you could then unlock the dark theme for all users and only lock the customization features behind a paywall, but that sill seems like a bad move and these issues will probably only become more problematic as you progress and add additional features.

 

Sorry, you're right, I shouldn't have post about it. Please, keep begging.

Spoiler: Original post

It's incredibly boring to read all the begging for the dark theme guys...
Really.
You're behaving like Unity asks for your arm and leg for the Plus. And we all know they don't.

 

Before this thread devolves into a flame war about "Dark Skin for Unity Personal users", please vote for that issue here. The request has been registered on this thread and a Unity employee even liked it. Let's keep the discussion to the New Editor Theme issues... because there's still a lot of those that should be worked out and time is ticking!

 

I totally agree. The only thing worse than those people are those unaware self-righteousness hypocrites that complain about people complaining. Even when they're not!

 

@SonicBloomEric I was simply pointing out an obvious issue with their stated goals for the new theme. That was it. Like I said before, I don't personally care. I'm sorry that pointing this issue out upset LurkingNinjaDev or anyone else.

 

Does anyone know how to choose the uss element which should be used when creating new button.

 

@jonathans42 : Is there a way to access the legacy font (used before 2019.1) via script?Or are the *.ttf files of the legacy font available?

The editor windows of my asset use completely custom styles except for the font where it's using the default one. The changes of the font in 2019.1 are visually not really compatible with my custom styled editor windows so I would like to keep using the legacy one.

Thanks

 

Is the path passed to resource in USS handled in the same way as EditorResources.Load? Ie. will it pick up stuff in Assets/Editor Default Resources before it goes looking for built-in resources?

I think a lot of people would be happier if your sales people or whoever's in charge of this actually gave a final "no" on having a free dark theme rather than just having no official response whatsoever from Unity on the issue. There's almost 15k votes on the feedback section for the dark theme.

Just checked that feedback page's comment section, and, ouch. It's a mix of very angsty "don't waste your breath, they don't listen anyway" messages, and discussions about how to mod the Unity binary with a hex editor to get a dark theme. I can't imagine that not breaking the terms and services

Of course, having a "pro" theme when everyone can just mod their theme to their own liking might make the issue somewhat moot?

 

By "full raw path", do you mean Asset-relative or drive-relative? Ie. Assets/SomeOtherFolder or C:/MyProject/Assets/SomeOtherFolder?

Or both?

 

Thank you very much for your response. Seems like Unity still uses the regular font even after loading "Lucida Grande" via script:


This is the code of the editor window:

Code (CSharp):

1. using System.Collections;
2. using System.Collections.Generic;
3. using UnityEngine;
4. using UnityEditor;
5.  
6. public class TestWindow : EditorWindow
7. {
8.     GUIStyle style = null;
9.  
10.     // Add menu named "My Window" to the Window menu
11.     [MenuItem("Window/My Window")]
12.     static void Init()
13.     {
14.         // Get existing open window or if none, make a new one:
15.         TestWindow window = (TestWindow)EditorWindow.GetWindow(typeof(TestWindow));
16.         window.Show();
17.     }
18.  
19.     void OnGUI()
20.     {
21.         if (style == null)
22.         {
23.             style = new GUIStyle("CoolerStyle");
24.             style.font = UnityEditor.Experimental.EditorResources.Load<Font>("Fonts/Lucida Grande.ttf", true);
25.             style.fontSize = 0;
26.             style.fontStyle = FontStyle.Normal;
27.             style.normal.textColor = Color.black;
28.         }
29.  
30.         GUILayout.Label("Hello World", style);
31.     }
32. }
33.  

Am I missing something? Is it possible that the "Lucida Grande" font has been replaced (or accidentally overwritten) in Unity 2019.1.0a5?