Godot: Add a new vector-based default editor theme

Would be nice if the editor/godot runtime is able to redraw all those vector icons on start or when resolution is changed :smiley:

i would like to help with this (i started to draw the elements some time ago), however @reduz once said that it will be too much work, i dont know if he was talking about the godot internals, but it those problems are solved i would be glad to help with the graphics.

this is what i have so far.

just another update, and also i think thats all, i have all the ui elements done in svg, next step might be to polish and improve this, even if it does not become the new default theme, someone can use the assets to create a new them or improve this one.

It looks great, I wonder how we could make it so the theme is generated
from SVG in real-time.

On Mon, Jan 23, 2017 at 10:58 PM, Daniel Ramirez notifications@github.com
wrote:

just another update, and also i think thats all, i have all the ui
elements done in svg, next step might be to polish and improve this, even
if it does not become the new default theme, someone can use the assets to
create a new them or improve this one.

[image: screenshot from 2017-01-23 19-50-01]
https://cloud.githubusercontent.com/assets/1103897/22230805/59a5eb96-e1a5-11e6-99be-eb98246996bb.png

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/7294#issuecomment-274678631,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z28L10ocXp5EEv3CRZC8JBX5dPopaks5rVVrLgaJpZM4LMKXr
.

@reduz that would be really cool, but i guess the SVGs must be optimized for that (maybe after the optimizations we can make sure that only a small subset of SVG is used, and then create a mini SVG parser for that subset).

BTW, the raphael.js SVG library (which I used a long time ago) countered the small-subset issue by converting everything to bezier curves when things like path collisions, lengths and so on had to be calculated.

damn looks really good and seems to be an amazing approach.
If it is possible to do a decent real time svg -> png converter for the icons also plugins would benefit a lot from it. Currently they usually don't support highDPi and are almost unusable.

It even could be used inside final games. So Godot would support svgs and just converts them to the correct sized png when the they are used in a game. #4826
(thats actually the same way iOS handles pdf vector graphics. just converts them to png at the right time)

@djrm the design you are approaching is beautiful. Helps focusing on the actual work (code 2d editor...). I think the green for the selected design is a little too heavy. why did you choose it over s simple grey shade? But thank you a lot! for the effort!

What about having all the svgs and the lowest res inside the Godot download. than ppl can choose whatever dpi they want (percentage based). The ui gets scaled but the default icons (pngs) are still used and just scaled (not resolution wise just stretched). so they are really low quality (blurred) but the correct size. than the svgs are getting converted to pngs with the correct size the images replaced.

But probably you already have a better idea... (or this approach Is more than obvious) still wanted to share it.

I made some tests. The conversion to svgs is pretty fast:
average time per icon (tested with all icons) to svgs: (i5 macbook)
10ms to 32X32
11ms to 64x64
13ms to 128x128
and this is for the icons. I guess the theme svgs are even simpler so it should be faster.

@djrm do you have that theme from the screenshots uploaded somewhere? I'd love to use it, I love the flat design!

What would compliment the new internals of 3.0? A fresh update to the default theme / UI, and this is in a fantastic direction. The ui concept calinou originally linked is incredibly fresh and would still be a great guide for continuing the progress djrm has made.

@karroffel no I'm still working on this, but I've been very busy, also it is no a downloadable theme, it has to be merged in order to be used but im still not convinced about it maybe in a few weeks I will give it another try

that visual graph editor looks so hot :D

feeel free to PR into 3.0 whenever you want

On Sat, Mar 25, 2017 at 8:02 PM, Nuno Donato notifications@github.com
wrote:

that visual graph editor looks so hot :D

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/7294#issuecomment-289245584,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z2-jomUzmkhc7Tjyk-0BQ0Cbvpqltks5rpZ0jgaJpZM4LMKXr
.

@djrm i guess you also know the huge thread about the ui concept.
they have no borders on the left and right. if you do a pr can u also do that?
I once did that and could show you the changes i made (if that helps)

@toger5 please show me the changes because im not sure what are you talking about.

@djrm the changes I mean can be seen in this screenshot:

there are no borders on the canvas editor (left right) and also for the other UI elements there are no borders: property editor ...

I tried that too for some UI approches i made:

And i think it looks good

@djrm I also made the effort now to search for the code of the theme I made.
This was before the time i was comfortable with git... so i needed to push it now.

this is the branch:
https://github.com/toger5/godot/commit/5e97449a15f0690e8bd584a256758c1b062ed22c

I dont exactly know what i did. but you can go through all the changes and decide what u like.
The commented section in line 5288 in editor_node gets rid of the border/margin (i think... maybe i also solved it with some settings in the editor_theme file. You have to try it out)

hope that helps

As i mentioned some time ago, i have cpp code for convertig simple svgs to png.
Its really fast and could be used for svg as a recource or for the theme.
Two approaches. Generating them once on startup in different resolutions (high low mid dpi).
Or we allow percentage base dpi lvls and the theme pngs get recreated after changing the ui size.
I wanted to know what to do with the code? Where should i implement it...

I really prefer the colors of the UIConcept. I think I know where you are coming from. the godot editor was using those dark violet like colors for some time now and it makes it stand out from any other editor. But It look kind of washed out for my eyes...
@djrm is there a chance that you will change the color?
what do others think about the colors?

@toger5 yes i will change the colors, in fact i already changed the colors and lost the old purpleish theme, now, the reason for a lighter color scheme is that when using the editor at daytime it i hard to identify things, but currently im looking for a better color scheme that is not too dark any suggestions are welcome.

the current theme looks like this (i dont like it)

I was thinking of doing some changes to the UI above, we discussed a few
things, but probably after alpha

On Fri, Mar 31, 2017 at 7:41 PM, Daniel Ramirez notifications@github.com
wrote:

@toger5 https://github.com/toger5 yes i will change the colors, in fact
i already changed the colors and lost the old purpleish theme, now, the
reason for a lighter color scheme is that when using the editor at daytime
it i hard to identify things, but currently im looking for a better color
scheme that is not too dark any suggestions are welcome.

the current theme looks like this (i dont like it)

[image: screenshot from 2017-03-31 15-40-25]
https://cloud.githubusercontent.com/assets/1103897/24571791/651e7756-1628-11e7-8a0a-4bead7215dd5.png

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/7294#issuecomment-290848860,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z21cXaM1wyZiOQHLk_2L24u_R27hLks5rrYD_gaJpZM4LMKXr
.

i mean to the top part of the UI (play, options, etc)

On Fri, Mar 31, 2017 at 7:42 PM, Juan Linietsky reduzio@gmail.com wrote:

I was thinking of doing some changes to the UI above, we discussed a few
things, but probably after alpha

On Fri, Mar 31, 2017 at 7:41 PM, Daniel Ramirez notifications@github.com
wrote:

@toger5 https://github.com/toger5 yes i will change the colors, in
fact i already changed the colors and lost the old purpleish theme, now,
the reason for a lighter color scheme is that when using the editor at
daytime it i hard to identify things, but currently im looking for a better
color scheme that is not too dark any suggestions are welcome.

the current theme looks like this (i dont like it)

[image: screenshot from 2017-03-31 15-40-25]
https://cloud.githubusercontent.com/assets/1103897/24571791/651e7756-1628-11e7-8a0a-4bead7215dd5.png

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/7294#issuecomment-290848860,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z21cXaM1wyZiOQHLk_2L24u_R27hLks5rrYD_gaJpZM4LMKXr
.

@djrm I really like the new highlight with green only at the bottom.
I still also would try just darker grey.

Although I see the point of making it easier to see it at daylight I'm missing the contrast. maybe you can at least make the background almost completely black

i want the buttons to be like this

i think there should be another node called FlatButton that does not have a box
an those buttons can be used in this thing

@djrm this should be really easy to do with just making a transparent style box. And changing the font of the active style.

@toger5 yes, this is what i have so far

of course this is not the final version (but as always im open to suggestions)

@djrm Nice this is looking really good. the idea of using just colors for the 3d 2d ... is really good. i also like the new coloring much better.
the only thin which is confusing is they the tab for thw 3d editor is kind of floating. but as you said its not final.
im currently putting together a new pr for some minor theme changes. ill post is as soon as im done and you can merge it to see how if u like it.

I tested @toger5's changes and I really like the left-aligned tabs

I also really like the colors in his theme, but @djrm's theme is really cool as well and I love it too!

Looks, great, planing to move it to Godot 3.0 ?

On Sat, Apr 1, 2017 at 5:49 PM, Thomas Herzog notifications@github.com
wrote:

I tested @toger5 https://github.com/toger5's changes and I really like
the left-aligned tabs

[image: theme]
https://cloud.githubusercontent.com/assets/5209613/24582312/195152b6-172d-11e7-94b6-488ef2abf245.png

I also really like the colors in his theme, but @djrm
https://github.com/djrm's theme is really cool as well and I love it
too!

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/7294#issuecomment-290946316,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z22kI6CkYXIbeJQmC-sPIMARvV0MUks5rrrhzgaJpZM4LMKXr
.

Yea i actually promised karroffel to make a pr for 3.0. I started working on it but im not done yet...
So hopefully tomorrow

Alright, its almost done

I created a pr which introduces some editor node changes to make the editor look more slick.
@karroffel this is compatible with 3.0 so you can just merge it into your version and add the theme png's you want.
@djrm I saw you already made some changes to the top part of the editor. this pr has similar changes. So you might have to merge manually. or you only add the textures in your commit and than we merge both, my pr and yours.

@toger5 i think, we will have to solve the conflicts, since i made some changes to expose some extra styleboxes and colors in the default theme file, as far as i can tell, the only difference between your PR and my current code is that you have left aligned tabs and made some stylebox changes, as you can see in my theme only the viewport has no borders but the rest of the docks still have borders, i would like to keep it that way, i dont know what you think maybe i can just implement some of your changes in my local code and then we just merge my PR and work on top of that?

@djrm i knew we will come wo the point where we have different opinions ;). I dont want to stomp into your work so you can decide. I prefer the way i get rid of the border since i still have the top section but there is just no border left and right. I think it has the biggest influence for the 3d view. So im fine when this is the only area where you remove the border. But looking at the mockup from the Ui concept thread i think it is a really good looking idea to remove it from the other tabs as well l. It simplefies the ui, gives a tiny amount of additional space. So I would love to see it implemented.
What about this approach: you try how it looks if you take my branch and add your pngs for the theme. This would work well when you have only little changes to the default_theme and editor_node file.
Otherwise i would propose, that u make a pr with the svg and all other changes you made. Ill look over it and see what we did differently. That we could try to merge my pr with yours. Since a lot of changes are similar we can just discuss the differnces and decide what to keep.
My initial thought was, that i only make changes to the code. I tried to do all the changes needed for your style. (i m refering to the dark top section) than we both could make a pr. My one including the code changes your one the svg -> pngs.
Otherwise i also like to just help u as much as i can with your pr. And than when your one is merged we can work on top of it as u proposed.

Oh i had the wrong screenshot in mind. Your top border is there.
Okay so your local version seems to almost have everuthong i would like to see.

Only things to discuss:

• no borders for docks?
• left aligned tabs
• intense border colors (i like them but maybe some ppl find them distracrting)

@toger5
I'm ok with no borders for docks it looks good borderless in the concept but in the actual engine not so much because if the tree like structure of the inspector and such

Left aligned tabs, I think I will change that.

And about the buttons, well yeah I'm also not sure about the colors, I will try another variation and see how it goes

I like the colors and overall design myself. Here's how I was planning to rearrange the UI for 3.0, so any ideas or changes welcome:

@reduz I think we don't need to move [2d, 3d, script, assetlib] buttons to there.
we can show more tabs without it.

@reduz i like the new position [2d 3d asseLib...] it makes much more sense beeing close to the main view since it only affects the main view.
I also see the concernt with the decreased max tab count. But practically no one uses more than 5 tabs. as soon as you have more you will just use the file browser for a lit of all scenes. so i tink its no big loss.

@djrm maybe you could try a dark bg for the ui elements with the colorful borders. especially for the search bars. which are just a floating blue line atm this could look good.
i think i wpuld prefer it with just dark bg no border. would make the ui look more simple, as if less stff would be going on -> less complex. which is a good thing.
But maybe im just too conservative and its nice to have a really outstanding element in the engine ui. makes it unique.
I Would still live to see how it looks.

@volzhs I'm kind of split on that one.. we can show more tabs, but it's not clear otherwise that they affect that part of the editor. Maybe it can be shrunk somehow

I also would lovw the look of rounded border dark bg instead of the bright color borders.
(for 30 height ui element. Png with 15 radius dark circle. Stylebox with margin 15)

@reduz we could use icons for 2d 3d asset lib. would fit well to the fullscreen button which also uses an icon.

@toger5
I often open more than 5 scenes at the same time and go back and forth while doing project actually.
@reduz
I like shrink tab like what Chrome, Firefox does. :smile:

@reduz I prefer (editor) settings on the top right because these are not related with the project, a fullscreen mode button instead of option could be there too to make use of that empty corner.

I just had to tweak it... I just had to xDDDD My eyes were bleeding... (Dialog setup not theme :P)

PS faded line above Cancel / Create is optional but would be nice I think for confirm dialogs.

@n-pigeon its beautifult!

@n-pigeon looks really good, @toger5, @n-pigeon i also wanted to fix the margins and other style related issues, but its a hard task, if you are willing to help we can split the work and get it done for 3.0

@djrm I will gladly help. But I'm aspiring junior programmer, so I will take junior jobs if there are any :)

@djrm what exactly do you mean by margin?
I think there are also a couple of positions which are a little odd. Too close to the border especially when making it borderless. Maybe we should make screenshots, draw on them what we would like to be changed and than split the work.

@toger5 yeah that what i mean by margins, and yes we should make some screenshots and then show what we want to change.

+1

Holy crap! If this is the design that Godot 3 will have, it's going to look like the most modern game engine on the market. The free market at that :-) Please don't say this is just playing around cause you might send me to tears.

It is looking great! I really dig flat design. :) Definitely better than those other engines.. :D
But I also agree with toger5 that it might be better to darken a little input fields which are now just a floating line (search fields, address field in filesystem, ...). It doesn't have to be much but little contrast might help to reduce missclicks.

I would like to try some rounded corner ones.
I really have fallen in love with the UI Concept. It just has a great balance, and just works really well as a ui style. I also like blender a lot and I think the number input in blender is one of the best i've ever tried (with the horizontal sliding for increasing/decreasing and the rounded style).

@toger5 i've actually made some test with rounded buttons, but im not convinced yet

now i have some concerns about them, first of all, since there are buttons with different height, rounded buttons dont look perfectly rounded in some cases, they dont look bad but its not like in the concept, now i thats other thing i would like to discuss, @toger5 i know you like the UI Concept but it is not a perfect fit for the engine, as you can see the concept is perfect for its idealistic use case, for example big buttons are not good for the engine (wasted space) and it simplifies the ui a lot (which may be a good thing) but unfortunately some engine menus are very complex, so i would suggest to take some elements from the ui concept but without making an exact copy of it. Also another reason why the editor does not look very good is because its weird metrics, the font rendering (the UI concept screenshot is a HiDPI one) and the great amount of data that needs to be handled in some menus, currently im working to improve some of those topics but it is proving to be a really big and annoying task (because of the workflow to change the ui, and the very nature of the toolkit itself), so i know that you are in love with the UI Concept but im not willing to implement it, im open to reasonable suggestions, but "because thats how it is in the UI Concept" is not a reasonable one, maybe i can create a PR and then people can comment on that and then we can iterate later on.

Currently im not convinced with my own theme but there are certain things that i like, and also im still working on it so things can be rough in the screenshots.

Dont like rounded much either.. i think it was better before too

On Apr 4, 2017 2:37 PM, "Daniel Ramirez" notifications@github.com wrote:

@toger5 https://github.com/toger5 i've actually made some test with
rounded buttons, but im not convinced yet
[image: screenshot from 2017-04-04 09-25-37]
https://cloud.githubusercontent.com/assets/1103897/24667812/86910612-1919-11e7-8109-fafe07398527.png
[image: screenshot from 2017-04-04 09-26-11]
https://cloud.githubusercontent.com/assets/1103897/24667817/8a6cf6f6-1919-11e7-9be6-ac67b9978d03.png

now i have some concerns about them, first of all, since there are buttons
with different height, rounded buttons dont look perfectly rounded in some
cases, they dont look bad but its not like in the concept, now i thats
other thing i would like to discuss, @toger5 https://github.com/toger5
i know you like the UI Concept but it is not a perfect fit for the engine,
as you can see the concept is perfect for its idealistic use case, for
example big buttons are not good for the engine (wasted space) and it
simplifies the ui a lot (which may be a good thing) but unfortunately some
engine menus are very complex, so i would suggest to take some elements
from the ui concept but without making an exact copy of it. Also another
reason why the editor does not look very good is because its weird metrics,
the font rendering (the UI concept screenshot is a HiDPI one) and the great
amount of data that needs to be handled in some menus, currently im working
to improve some of those topics but it is proving to be a really big and
annoying task (because of the workflow to change the ui, and the very
nature of the toolkit itself), so i know that you are in love with the UI
Concept but im not willing to implement it, im open to reasonable
suggestions, but "because thats how it is in the UI Concept" is not a
reasonable one, maybe i can create a PR and then people can comment on that
and then we can iterate later on.

Currently im not convinced with my own theme but there are certain things
that i like, and also im still working on it so things can be rough in the
screenshots.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/7294#issuecomment-291575521,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z2_8EulxUfY5Sa17KikXpv97iL4tGks5rsn_egaJpZM4LMKXr
.

@djrm really good statement. I aree that the ui concept shouldnt be just copied without good reason. I also sterted to do some minor ui adjustments and it is rally tidius since im not that familiar with the codebase. and just copying the ui concept might not be the bes approch. In addition i think im focusing on the visuals too much. :) and of course bigger -> less ui lements might look better but doesnt improove usability.

About the rounded corners: I think they look good in general. although I dont like them that much on buttons. maybe would use them in places where we have inputs. textfields, number inputs, color fields, paths...
About the differnt height problem (which actually makes rounded corners look weird) is ther a chance to implement that efficient with shaders?
Since its only a visual addition (and reduz doesnt like it !! ;) ) its definitly low priority.
@djrm I really like that you changed to icons for the [ 2d 3d script ] panel.
Overall the theme is coming along very well. A huge thanks for all the effort you put into the engines look. Especially when taking into consideration that you also did all the new icons. (didnt even than you for that yet)

@djrm I think current trends are against rounded corners, currently rounded corners feel kind of old. If you check Windows, Android, and all other modern UIs, trends seem to be going towads mostly square corners but with some strong colors here and there. IMO this looks best:

and this:

https://cloud.githubusercontent.com/assets/6152134/24617960/c60297c2-1895-11e7-8eca-4d19dbf83d44.png

The left aligned tabs and darker theme definitely looks more appealing in my eyes, and kind of makes me think of Defold's dark editor, as well as Atom/VS Code. I don't mind rounded vs flat, but if tabs are going to be left or right aligned at least keep them flush with the side of the pane.

I agree with @reduz for sure. That looks like a beautiful, sleek and modern user interface that I could look at for hours. No rounded ftw :)

It's true that rounded corners are going away in current trends.

I am a huge fan of the new theme. The flatness is a huge step up and the new colors are fantastic. I only have one comment/suggestion:

There are WAY too many widgets using saturated colors at the same time. Specifically: the animation dropdown , AnimationPlayer button, the search boxes, the loc / rot / scl / key buttons.

Looking at the screen I have no clue where to direct my focus because there are so many widgets demanding my attention at the same time.

Here is a quick comparison of the original mockup's use of color to the current implementation:

Original:

Current:

Save that level of saturation for selected/focused things.

Contrast analysis (Created by bumping up the contrast to max in gimp then removing white. I also removed the viewport content):

Original Mockup (EDIT: I just realized I didn't use the same method for this one ... its fixed now!):

Current Godot 3.0:

Godot 2.0:

After updating my ancient godot version and solving all the conflicts, i've made some progress with the theme.

I know about the weird tab

Wow. Let's get this merged already :)

LOVE IT ! :heart_eyes:

Agreed! I love the new shade of blue for input items. It contrasts less with the background color and brings down the perceived urgency of the widget. The subtle curves on the input box underlines were also a nice touch. ❤️

merge <3

This really looks super sleek! Love this theme! Looking forward to it being merged!

Looks cool, tho the font used for the "db" numbers is a bit strange to me..

Maybe the underlines of the text inputs should be a bit grayer-ish when not focused?

I'm not big fan of new LineEdit controls. They are a bit heavy with this blue colour and rounded corners. IMHO there is too much blue everywhere - it's pretty distracting. Maybe only active controls (on hover, clicked) should have blue border? Beside this new theme looks fantastic :)

btw. how does the default 3d viewport look like? I really didn't like the green grid ^^

@ndee85

The bright (in contrast) blue lines and borders looks like all are focused controls.

The rest is good, also tested captures with some colorblind filters and everything stays visible and distinguishable.

@djrm damn, you introduced some really nice looking stuff. Its getting better.
I thint the text intput looks really cool with the blue line but i agree that the line only should be there when the input is fucused. Otherwise it gets too much attention compared to other inputs.
Although you made them really suddle i dont like the slightly rounded corners for te docks enough to make up for the issue with the small gap on the tabs for the main center dock.
I also think the docks look much better without the border.
Just some opinios. Ill also do a mock with the changes im thinking about so its easier to understand.

I changed a couple of minor things: position of buttons in docks, removed borders for docks (left right), removed color for input fields (I really like them they are asking for too much attentions so I would prefer them as the active stylebox), got rid of the green color to make the editor itself even more calm (keep in mind it's a screenshot without any content: node tree, scene, code, inspector/properties... so it should be really saddle since the content should get focus (coloured node icons...))

@djrm I love the 3 dots instead of the arrow on the top right of the docks!

I also would make the blue color brighter I think.

@djrm I love the 3 dots instead of the arrow on the top right of the docks!

The other background was to distracting and made it hard to compare the two...
I also would make the blue color brighter I think.

@toger5 i think the changes you've made makes the theme look more conventional and serious, the problem with the lineEdits you've proposed is that it is harder to distinguish between enabled and disabled inputs, also i like the green highlight instead of the blue and the borders for the docks, i know there are things in the editor that looks weird but i think thats a good thing like the bus numbers those things will make the engine look more crazy, different and unique unlike any other engine out there, also the rounded elements make the engine look more friendly (sharp edges are dangerous).

the only think i would probably change is the color for the widgets, will try grey (icon color) instead of blue.

@djrm Did you say that you know some things look weird and the bus numbers help the engine look more crazy? What did I just read? You WANT the engine to look crazy? Those bus numbers look totally off from the rest of the design and squished together. Sharp edges are dangerous? Are you serious..? Yes, on a knife, not in software.

The blue that @toger5 proposes actually offers some continuity as well. The overall theme looks great. Saying that @toger5 made changes that make the theme look conventional and serious is actually a good thing. The way Godot's theme is currently is the reason why conventional and serious is the way to go for 3.0

For 2D and 3D we can make them as icons that show "2D" and "3D", instead of
the vectors.. shoukd be clearer

On Apr 10, 2017 2:39 PM, "boogabelly" notifications@github.com wrote:

@djrm https://github.com/djrm Did you say you know things look weird
and the bus numbers help the engine look more crazy? What did I just read?
You WANT the engine to look crazy? Those bus numbers look totally off from
the rest of the design and squished together. Sharp edges are dangerous?
Are you serious..? Yes, on a knife, not in software.

The blue that @toger5 https://github.com/toger5 proposes actually
offers some continuity as well. The overall theme looks great. Saying that
@toger5 https://github.com/toger5 made changes that make the theme look
conventional and serious is actually a good thing. The way Godot's theme is
currently is the reason why conventional and serious is the way to go for
3.0

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/7294#issuecomment-293023522,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z22wNjUml05FV3FxId98rHDkJrn7bks5rumlTgaJpZM4LMKXr
.

Green grid ia because its the Y axis grid.. but does not need to be that
color..

On Apr 10, 2017 3:12 PM, "Juan Linietsky" reduzio@gmail.com wrote:

For 2D and 3D we can make them as icons that show "2D" and "3D", instead of
the vectors.. shoukd be clearer

On Apr 10, 2017 2:39 PM, "boogabelly" notifications@github.com wrote:

@djrm https://github.com/djrm Did you say you know things look weird
and the bus numbers help the engine look more crazy? What did I just read?
You WANT the engine to look crazy? Those bus numbers look totally off from
the rest of the design and squished together. Sharp edges are dangerous?
Are you serious..? Yes, on a knife, not in software.

The blue that @toger5 https://github.com/toger5 proposes actually
offers some continuity as well. The overall theme looks great. Saying that
@toger5 https://github.com/toger5 made changes that make the theme look
conventional and serious is actually a good thing. The way Godot's theme is
currently is the reason why conventional and serious is the way to go for
3.0

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/7294#issuecomment-293023522,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z22wNjUml05FV3FxId98rHDkJrn7bks5rumlTgaJpZM4LMKXr
.

I'd side with the vectors myself. I can contribute for vectors too, if required.
Sharp edges, left-aligned tabs and blue active textbars is what I'd get behind.
BTW, is basic theme support to be included in 3.0? Could solve a lot of opinion conflicts here itself. Maybe a JSON/XML theme value system would do it for 3.0?

@kn1ght99 yea theme support is already there. Godot has its own theme file. So saving as json is not necassary. Its a good point you bring up that this allows for personal adaption.

@djrm so you basically dont want to change anything based on my proposals? Which is fine since you definitly put most effort in it. I still was hoping that I could make a little influence since I also did work (probably wont get merged).
But I wanted to have some influence, because I have strong reasons. I like the unique touch you added and we should try to keep that wherever possible.
BUT some things just are more or less pracrical. In a software where i want to produce things (Games), it is important to have a non distracting ui:
This doesnt mean there cant be unique colors or crazy looking things as long as it has a perpus. For example for the 2d 3d ... Buttons its important to know what editor is used, or which edit mode (scale , move ...).
But the search bars are not a main action which has to be easy to find and understand when not yet used to the ui so they dont need a lot of additional attention.
I coild write thw same for the the green blue discussion: why two colors when they both have the same meaning ( they only say: "look this is important") for the nodes instead multiple colors make a lot of sense becaus of different node types, there is an additional message behind the color which is worth making the ui more distracting. I decided for blue because of the godot logo but using green as the highlight color is also fine. (just not both)

The reason why i really would love to see the borderless design is that this compleatly removes vertical lines in the ui. It seems as if there would be less things going on. In other words: we remove distraction, without loosing functionality and even the overview doesnt increse (which is often a disadvantage of removing lines). Another minor advantage ia that we gain a tiny amount of space... (almost negligible though).
I also know that there are some tiny issues that this approach introduces: some buttons are too close to the border. But even fixing the possitions would be worth the effort to give this tiny improovement. So it is not really an opinion based motivation and i think it should be taken into consideration even if it doesnt fit into everybodys personal preferences.
Djrm you would make me really happy with forfilling my whishes. But the theme how you have it right now makes me also happy :)

@toger5 Is it possible after merging for you to have your own theme and share it? Or will it be too late to customize the things you're talking about? I really like your approach. I like the stuff @djrm has done, but I think he's more or less designing it for himself now instead of for pure functionality, purpose and form. Once he said he's adding things cause it will make Godot look crazy, that's when he lost me. It's important to take design cues from elsewhere, see what works and then improve on them, not just add stuff cause of personal wants like weird db bus numbers or no sharp corners cause they're dangerous.

I believe adding these to the theme options won't do any harm and effectively remove all the conflicts here. @djrm and @reduz can decide what UI Godot 3.0 shall officially ship with but theming options are kind of becoming necessary now, otherwise different versions of Godot might also sprout up according to the UI the person prefers.

@boogabelly the minor changes i proposd are easy to do and also able to implement as optional theme without recompiling. Although im jot sure if djrm uses different colored icons or modulate color. Modulate color would make it a little less flexible for a alternative theme.
But the changes to the border needs some clean up in terms of spacing which is not possible to do without recompiling. Its still doable but would look missaligned in some places. (thats another reason why i would prefer to make and adapt the theme to no border. Because using a theme with borders on the editor adapted for no borders looks better than a no border theme in the current editor adapted for borders.)

@toger5 Aren't you the one who kinda pushed the UI theme change that @alelepd created in the beginning? I think your ideas should be heard more, and the borderless idea concept is definitely great. I think between you and @djrm you guys have done a good job making Godot look like an even more professional game engine with a sleek design. It's headed in the right direction. I just hope your input isn't being tossed to the side.

@toger5 first of all, i dont want to cause conflicts here, if you check the issue history you can see that when too many people have an opinion about something i try to do the best i can to match what they suggest with what i have in mind, now obviously it is impossible to please every, but as you probably know i do read what people comments, but the opinion of the users (many real godot users), im currently even thinking about what i can do to fix the most commented issue (too bright buttons and inputs). is what matters to me, for example now you and i have some personal preference over some insignifcant things, but it is just you and me if many people are on your side then i would gladly change it, second your previous suggestions have helped to shape the current theme so you essentially have participated in it, if you want to make the commit, honestly i dont care, im not doing this for fame or anything and you should not be either.

About the distraction argument, i do understand that focusing user atention to certain areas is important however that is applicable in case where there is little content, and it is trivial what is promary and what is not, in the case of the engine you are navigating through the different docks and panels very often, so i dont see what is primary action and what is not, for example if you are in the animation editor, that is your current context so obviously you have the focus there and the viewport and everything else might be a distraction, i dont want to have some almost imperceptible buttons and inputs, but again thats a preference.

Also as you can see i haven't created a PR, and thats because i want to make sure we create the best theme for godot.

@boogabelly Dont go there trying to cause problems between community members and please read the rest of the thread, you will see that i do consider users input.

@djrm Oh I'm not trying to cause anything. I've said numerous times how great it is that you created such a nice theme. I just remember @toger5 from years ago doing things with the theme that @alelepd created that started all this. It's just the last couple times he mentioned something, you kinda shot his ideas down and gave reasons to why you think they shouldn't be implemented, like making Godot crazy looking compared to other engines.

I like what you've done. Read things I've said. But there's a few things that you've said that shouldn't be overlooked. Keep on doing a good job. I just ask that @toger5 has more input since I've seen him mess with the UI since a long time ago. But then again, I'm no one important here so do what you want.

@boogabelly, first of all i think that every godot user is important, but the ones that have a "better opinion" are those that are willing to do something about it, it is so easy to say that things are ugly or doesnt fit, but i see too little people that suggest actual improvements, like @toger5, thats the reason why we both and the rest of the community are discussing about design decisions (i haven't created a PR yet).

@djrm That's fair enough. I wish I knew enough about the source code to make a contribution. The only things I can suggest are what @toger5 already said. I'm just using Godot to make games, or at least learn it the best I can. So I'm no one when it comes to helping to improve the engine.

It's not that I'm on his side; it's just that I agree with his aesthetic. Nothing personal. You did a lot of good things on this design that made me say "wow" when I first saw it on this page.

@djrm hell no you will do the pr ;). The way I wrote my complain that i didnt manage to bring my work into a state where it is ready to be merged sounds a little desperate ;). ( i can assure you thats not the case) Im more dissappointed by myself that i did so little lately...
I guess u already tried the no margin stylebox for the docks or looked ad screenshots. How much work do you think would it take to adapt to move things around so that there always is acceptable spacing?

Another topic: it seems that the property editor is almost not affected by the theme? Are there differnet styleboxes used? I know that the editor is a tree with two columns and coustom fields. But arent the coustom fealds the default ui elements which than also use the styleboxes from the theme? ... Checked the screenshot again. Are they special ones? Seems as if they are not the same than the default number inputs... Does someone has an idea how to modify them. Would look nice to also darken the input fields like it is with text fields.
Oh one tiny thing i wanted to mention some time ago: Maybe you could play with the expand arrows of the node tree. Maybe you find sth that fits better with the style of the back/forward arrows.

Maybe you can try to merge the commit with the border changes and your theme (or just do the changes yourself in another branch. Since you also already implemented the left aligned tabs there definitly would be conflicts). If you keep both versions update, it would be easy to decide later which one to use.

@toger5 about the borderless docks and containers, you need to see this

as you can see containers with rounded corners look more consistent with the rest of the interface (they would look better with the correct margins)

what is going to happen with those containers with borderless containers (they will look ugly)

about the tree widgets, i think they are custom buttons or some kind of hack, i will have to work on those things, currenlty they have problems (i dont know if i messed them up).

and yeah i will create new icons for the expand arrows.

i will also try to expose the button and highlight color (green vs blue thing) in the editor settings, in order to end the colors war.

Hello there!
Glad to see such great progress on the UI.
Here are my thoughts on some of your ideas and comments.

1. Color scheme
The goal with any color scheme is to be coherent, that means, to create a harmony of shades or color tones. The contrasting colors should always be used very carefully, they are supposed to highlight the important actions or selected tools. If too many elements are in contrast, there is no clue to decipher which ones are selected.

Example. If you decide to make a theme using the green as your base color, you need to create a color palette that works with that color. You could use the orange as a contrasting color and the blue as a key helper in the palette.

If we do an analysis of the current theme, you can easily see that the 3d view is off the color scheme because the lines and the background aren't based on the same blue of the interface. This is why I changed the way the 3d view looks in my initial UI concept to be coherent with the overall color scheme, the result is that you have an UI component that blends very well.

2. Visual Hierarchy
In this regard, it is good to understand that any design needs to have a visual hierarchy, a structure that establishes which elements are more important than others.

Some elements of the UI, like buttons, are more important than others like labels because a button has interaction and a label doesn't (only displays information). Also, some buttons are important than other buttons. For example, a button to increase a value is less relevant than a button to close or save the project, so the later should be bigger because of its higher position in the visual hierarchy.

The visual hierarchy also involves the understanding of the elements states. Let me give you an example on this with a simple button:
A button could have several different states: Normal, Hover, Pressed, Disabled. When a button changes its state, it also changes his position in the visual hierarchy. If is pressed, it means is going to do an action, if is disabled, it means is has no relevance anymore.

A change in the visual hierarchy means a change in the element itself. Most of the times this is accomplished by a change in color, but sometimes it can be a change in form too.

3. Design System & Visual Coherence
I often see that you have troubles to make a theme look coherent. This happens because this is actually the most complicated part of any design system, so it is not easy to get done properly.

To make a good design system you need to understand a fundamental part of the system: reusable components. Once you define a set of design rules that guides how your UI components should behave, it should always behave like that.

If some components are similar in their action, then they should look and behave similarly too. A common misconception is to think every single element in the UI needs to stand alone. Thinking like this will only get you bad results (see old UIs of Blender).

Summary

1. Use a coherent color scheme in all the UI elements, not just to some of then.
2. Give more relevance to the elements that require more attention.
3. Define a set of coherent rules that establish how the UI components work, how they are related to each other and how the should behave.
4. Don't do overdesign. Don't design something just because it looks fun or cool.

To consider

• Having bigger buttons can sometimes increase usability! This is a well-known fact in design. Just look how Github does. You just need to learn how and when to increase the size and give higher visual priority in the hierarchy.
• Just making a theme without making fundamental changes on the UI will never result in a complete improvement, in fact, it could be a step backward if you don't make changes in the way some elements behave; you may end up with some sort of Frankenstein.

Woohoo @alelepd if it weren't for you, this UI might not even be happening. Godot is gonna be so much nicer to work with just because it's​ nice on the eyes. @reduz has made it even better with all the new updates to 3.0. Exciting times :-)

Massive hype!

As i promised here is the version with neutral color buttons, also tweaked some other things.

It is looking better and better :) Great work!

But man, editor really needs tweaks to margins all over the place :/

@djrm i like the saddle xolors you are using now. But you are right it looks less special. But i think there is still a whole lot going on when a project is loaded and the inspector, nodetree is filled.

1. There is a blurred border in the 3d view when acrive. The blurr is strange for a flat theme. Maybe you could do a really thin green line. Although the green is kind of strong... Or just a grey thin line?

2. What if we dont use rounded corners for the docks and the tab container in there? Than there would be no issue with no borders and it also would fit to the flat overall style? We will run into issues with rounded corners anyways. The left aligned tabs would look better if they are aligned with the container. That would work by removing the borders (expand margins of the docks) or by moving the tabs to the left (dont know how that works tbh) but than we have a little gap between thw container and the tab since the container has a small rounded corner. Removing the borders would be much easier but would result in more fixes needed in terms of margins/positions. When keeping the borders we need to figure out how to move the tabs and fix the gaps. Or keep the offset but thats not an ideal solution in my opinion.

About the margins:
We really should make a screenshot where we mark all the missalignments. I wpuld be interested in fiximg them when i have a list where work has to be done.

It looks way better! New 3d viewport is pretty. Edit boxes still stands out too much IMO.

We could do a lot if really cool things if we had bold font. I tried implementig it but gave up. If someone could write how font is handles in the editor would be cool.
My underastanding. Font files in a specific folder will be converted to data in a header file with global constants to access them. Than the default them gets created with one of those fonts as a parameter.
To have bold font we need to do a new theme creation function with bold_font as a paramerter. Than the passed value could be used for the theme... Bit this seems odd, not scaleable because it would require new parameters for eac special font (bigger, different type...)
Can we just acess the constants in the theme creation function without passing them? Or is that bad practise...

@toger5
we can make a fake bold font with Font Color Shadow(same color with Font Color) + Shadow offset x = 1, y = 0
how about this?

We could add a bold flag in DynamicFont maybe.. amd just draw the font
again with 1px offset to the right

On Apr 14, 2017 1:49 PM, "volzhs" notifications@github.com wrote:

@toger5 https://github.com/toger5
we can make a fake bold font with Font Color Shadow(same color with Font
Color) + Shadow offset x = 1, y = 0
how about this?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/7294#issuecomment-294141205,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z22QKAlEB1mgavTj5ukzVBXC5r9xYks5rv11ZgaJpZM4LMKXr
.

Not trying to start a color war here, my only question is why the need for that green accent color when Godot is blue? Well, the logo is blue, that is. Would it not make sense to use blue instead of green? Just wondering what the thought process is behind that. I know you don't have to adhere to the color of the logo, just wondering is all. I mean if you look at @alelepd first mock-up, the colors blend well overall.

@reduz maybe but it depends on font size or how font looks I guess.
hm... bold size maybe? :smile:

@toger5 About margins I can help. Mostly with mock-ups probably tho.

I will try to fix script creation dialog maybe, but I'm really inexperienced coder so I can't promise I will do it :D (C++ and Godot size are a bit intimidating for me, for now XD)

But first we need new theme in master I think :)

@n-pigeon
You should be able to do it without the theme merged i think. The theme does not really affect any ui sizes...

For starting with code, you only need the editor_node. Of course it is a lot of searching to find the appropritae section but there are some comments so you should find it. And than it is surprisingly similar to gdscript. Just search for the appropriate nodes and find where set_pos is called change it to make it beautiful. :)

The theme is looking really great, but I would prefer the script temperature color to still be used for the background, not the foreground.

@neikeq I think it looks really good and doesn't make it harder to read IMO. I like it the way it is in the screenshot.

maybe i should create a PR so we can fix all the remaining problems and avoid conflicts, what do you think?

also currently im tinting the button icon when pressed, i dont know if i should create a specific flag for this behavior.

Would be a decent addition for the button class. Maybe you can add it as aother parameter for different states. Normal pressed hover...
So every state has an optinal stylebox and an optional tintcolor.

I agree with @ghost. I think blue (the one from @djrm's original input design) should be used as the active color instead of green. Its much more harmonious with the other colors / less in your face.

There is a tiny black line under the scene tab title. It is an artifact ?

It is caused by the rounded corner and harder to solve. I know that djrm is aware of thet (he mentioned it in a post) and there will be a solution found.
Removing rounded corners compleatly (easiest)
Making the topnleft corner for the dock stylebox sharp. Couldnlead to unwanted bahaviour in some other places though.
Add a coustom stylebox for the controls where the "artifact" is present. (thats some work but maybe would lead to the cleanest solution)
I prefer remocing rounded corners compleatly (by far the easiest ;) )
But tbh i dont even think they are that annoying.

The alepd UI mockup has no rounded corners. If this mockup is the way to go, I think removing these rouded corners is acceptable.

Mother approach to make rounded corners without having a straight part on the left and right side is the following:
Margin top 0 margin left 32 margin right 32 margin bottom 0. and than use a 64*64 circle image.
this should look really good for anything between 50 and 80 height.

because I still think it is a good design direcition to distinguish between user input areas and information...
I just didn't like it that much jet because I only had weird looking or hard to implement solutions for rounded corners in mind...

@william01110111 also looked into styleboxes and gave me that tip.
He might also be interested on that thread.

Some thoughts:

Also the rotary ticker on the far right for UI updates is kinda of neat but also unnecessary. If we clear out all that stuff on the right, we can move the 2d/3d/script section to the right side. Or to the middle and then move the play buttons to the right. I think that will clean up the top a lot.

The colored bar is sound level IIRC, I don't know about the green tick.

Perhaps we could dispense with the sound level now that we have the audio bus interface.

@RodeoMcCabe The bar is a volume bar that will dissappear now if I understood right; the "settings" is editor settings, nothing to do with the project, I think is fine on the right; the other 2 icons (resource changes, now auto import and update wheel) I believe will have the same fate as the sound bar but not sure.

Wheel indicates that something is processed in Editor.

Maybe we could change the label to "Editor" then. I really think it belongs on the left since it's a labeled button that opens a menu, just like everything on the left is. It's nice to have one menu bar where all those type of menus are.

@n-pigeon I know, but I never found any use for it. It can stay there, I just don't see any reason for such a feature.

About the 3d/2d/script/fullscreen buttons:
I think the location proposed at the right top of the 3d/2dd/script view makes most sense since it is than obvious it affects the main windows and not the whole editor.

Renaming the settings to editor is a really good idea because settings is really confusing. how should I know it only holds editor settings...

moving it to the left is okay... But to be honest I like the separation: left side project, right side editor.
Although the right side becomes a little empty when the sound lvl gets removed...
but I still like the separation.

General approach of simplifying the top bar to only menu buttons + play/pause/stop... is a really good intention.

@RodeoMcCabe Maybe visually it would sit there nicely but not logically.
Just moving it would be bad idea, it could be moved but it would need to be differentiated.
Changing name to "Editor" is good idea tho.

it could be moved but it would need to be differentiated.

That's true, that's why I suggested changing the label. But I actually also really like the idea of "left side project, right side editor".

The main problem I see with the top right now is that it has four sections: the menu bar, the 2d/3d/assetlib, the play section, and the stuff on the right. It would be nice to have only three sections nicely on the left, middle and right.

Some places need space for plugins too, the menu on the left allow new top entries?

Is there a way to change the general fill color, or desaturate it more? I'm not fan of blue, it's one of the most energetic colors to the eye, and even at this brightness it's not neutral enough. I expected grey (absolute neutrality), or a subtle shade of orange (Sublime Text/Blender) or purple (Godot 2.x). If the choice was only about the Godot logo, then it could still be used as secondary color for icons or highlights.

blue looks modern and beautiful. (at least for a couple of ppl ;) ) but I see you concern. of course you could just use f.lux or similar.
But it also would be fairly simple to just recreate the theme with a different color to it. since it's all svgs the render code just could be modified to multiply the all the colors by something. all the shapes would stay the same and it could be polished as an alternative theme for the editor.

Apps having an neutral grey dark theme by default:

Blender, all Adobe products (Photoshop, Audition, AE...), Reaper, Discord (blue but way less saturated), Visual Studio and Code (blue but way less saturated), Sublime Text (orange but way less saturated), Unity3D, 3DSMax, Maya, CryEngine, UE4, Game Maker...

If this blue color stays the default, please make it changeable easily^^

Making a dark-grey version should be easy because all you need to change is the background colours.

I just made a quick example of how that may look like:

Btw. Another idea for transformation inputs:

On that dark grey theme it looks like the boarders are much smaller around the different workspaces...something I just recently started a topic about.
https://github.com/godotengine/godot/issues/8512

Now I'm a fan of the dark grey. Please reconsider.

@alelepd thank you for bringing the property list back.
I love the idea you proposed. And i think having rounded borders the indication for changeable/input is a great approach!
We dont even have to recreate a property list node. We can still use a tree but just change the coustom inputs give it new styleboxes and set the inset offset to 0. I started with that on a local branch. My approach was to implement a property for each row which determins if the row displays the collaps arrow.

I think rounded corners is the least important thing on those widgets.
The most usability wise difference is widgets themselves. It's such a pain editing popup window each time you want to tweak Vector3/2, Quat, Basis or Array type...

Maybe 3 could be shipped with official blue and dark (and light?) gray optional theme.

@n-pigeon here is a discussion about the inspector design #8196

Holy moly @alelepd are you kidding me? This looks like insane good. It's modern, easy on the eyes, and everything in between. Where is @reduz when you need him to look at this? He should see this. Not sure if he cares about stuff like the theme since he's caught up in code and making things work, but wow this is really something. /applause

So, disregarding the theme that actually gets used, what ever happened to the prospect of Godot being able to actually use SVG for theme assets and generates/caches pngs when it starts up? I'm particularly interested in the new theme using SVGs pretty much everywhere.

There are a few thing I don't like about the new theme:

• The transparent title bar. Looks pretty bad IMO.
• Some buttons at the top (2D/3D/Script, Run, Pause, Stop, etc.) lack feedback on mouse hover. It would be great if the icons were darker when the mouse is over the button.
• Buttons borders and its color on mouse hover look weird (I'm not sure how to explain it):
  
  Other than that, the new theme looks great to me :)

Just tried the new theme and feels too strong, energetic like @Zylann said, 2.x theme is a lot better for the eyes (or at least what is left of my eyes).

I like it, would just get rid of rounded corners, as they feel like old
software. Nothing mainstream nowadays use them.

On Apr 27, 2017 5:55 PM, "eon-s" notifications@github.com wrote:

Just tried the new theme and feels too strong, energetic like @Zylann
https://github.com/Zylann said, 2.x theme is a lot better for the eyes
(or at least what is left of my eyes).

[image: godottheme2vs3]
https://cloud.githubusercontent.com/assets/10215987/25492224/bd7c4b32-2b48-11e7-8332-aaa601b244c6.png

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/7294#issuecomment-297757206,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z2xmx4kUf33pUyJqwywtAvWOj7U7Jks5r0LqOgaJpZM4LMKXr
.

While I think @djrm did a good job with the new theme, @alelepd provided a theme for the ages. I agree with @reduz about the rounded corners. They don't seem right and make things look off balance. I'll be happy once we can get customizable themes so I can use the theme @alelepd posted recently, that is unless the new theme kind of adopts stuff from his. I love Godot's simplicity. Everything is where you hope it'd be. With a new modern theme that's nice on the eyes, it will just make the engine that much more enjoyable. Great time to be a Godoter.

Saturation isn't too bad (though it could be decreased a tad), but the hover colors of scroll bars (bright green) are too strong and could easily distract the user. Some other hover/pressed colors should be reviewed as well.

Comparison of normal scroll bar and hovered scroll bar:

I guess scroll bars could be modified to use the blue "hover" shade when hovered, and the green "pressed" scheme when pressed (which also gives a visual hint of the fact the user can move it around).

+1 to gray UI background and +1 to blue hover and green pressed on scroll bars.

^^ and +1 for no rounded corners and +1 to no borders between everything, at least not as wide as they are now anyway..

really hot issue recently. I tried a little thing.

I agree the borders should be more square, also the 2px borders are a bit too much, they also make the docks look kind of blurry. Also, if possible, reduce margins a little bit^^
and for some reasons the main control has a thicker margin than the others... but I see you fixed it^^

@volzhs Took me a while to find the difference :stuck_out_tongue: Looks better.

more closer to mock-up...

what do you thing everyone?
if it's good enough, I will do the rest...

The filesystem and the top of the scene dock need some padding, and tabs are still rounded. Can the space between docks be reduced by a few pixels? (I'm getting latest at the same time so I can experience it live^^)
The glowy frame around the main viewport looks weird now that scrollbars are transparent...

Note about rounding... while I agree round corners feel a bit "old school", I'm not sure completely square borders are better. Having a subtle rounding would be ok too (shape like Godot 2 actually, but without the outlines)

here is live feed. :smile:

@volzhs I like it! 👍 The alignment of tabs as they are now annoys me a bit, your latest screenshot is awesome! PR maybe? 😛

@karroffel yeap. need more time. :smiley:

I guess you could reduce the margins between containers by a few px more to satisfy #8512. Looks pretty good, I like the aligned tabs :)

@akien-mga yeap. I will try that too.

The margins need to be reduced for sure. Can you go with grey like the theme from @alelepd above? It looks so clean. The margins are just right in that theme too.

@riirii I will try, but can't promise it because some images are used.
I will stick to current color theme first.

Its good to see people trying new variations, about the mock-up thing, you have to know that I did not tried to implement the alepd mock-up it was not my target to create something like his mock-up, but rather to create a theme that was unique and different and more importantly that was easy to use on day and night that's the reason for the high contrast colors and buttons and the blueish background, also I took the decision of rounded borders because it looks more friendly, but less rounded corners can work too, however you will have to replace the radius for all the widgets otherwise it is going to look incoherent, also the green is not distracting, I mean there is a lot of content in the interface for example the scene dock, control color is very similar to the highlight green, the transparent window title its a current problem I mentioned that in my PR. Also I don't currently have time to fix those issues that's why I created the PR is this state, also I really think that script temperature must be the foreground color, otherwise it is really hard to read the text, and since the color is customizable many colors won't work with the default text color, that's no the case with colored foreground. Anyway​ I will try to improve the theme, but it is important to note that the key principles are there and ate the for a reason, if those principles does not fit the community vision we could try something more conventional like the alepd concept.

Just tried the theme currently in master, my subjective notes:

• Transparent title bars are just wrong, please reconsider^^ I don't like them being "blend-in" either
• The top menus should have a "rect background" hover, the slight text hover is not enough
• I don't like "neon-like" buttons, also their background should have a different colour.
• Many borders are 2px wide (around buttons, docks and windows), that's a bit too much
• Hover effects missing/not strong enough, feels like the UI is not responsive / rough
• Menu separators are invisible
• This blue!
• ...

I could go on and describe a lot in text but I think it's better to tinker with the actual visual, because it's worth a thousand words anyways^^

I think you did great @djrm .. it got the ball rolling. I wouldn't say the @alelepd theme is conventional. It's modern and light and has continuity. It's definitely something that shouldn't be overlooked.

@djrm first of all, thank you for your work.
I don't intent to rework what you have done.
and you made changes for "default theme" and this is about "editor theme".
I guess we should not change your the default theme.
it's used prototyping also.

@volzhs 1. have you checked the pr I did with the border removals? probably you did it the same way, but it still might help. Honestly I'm not planning to merge it but it might be used as recource.

1. can u try to adapt the tab for the main window to be the same height than the other tabs (and no rounded corners)

@toger5 yeap. doing it now...
and I checked your PR and I'm doing it a little different way not to touch default theme.

I think it's almost done.
note that, this does not change default theme, only affects on editor.

@volzhs looks really good, we may need to add some margins

Like this?

Smaller margins look great. Left aligned tabs are better too.

@Zylann done !

now need to clean up codes a little bit.

Nice. I don't like the small margins that much. adds an unnecessary lines.
The dark background should be enough to separate the content.
I see why they are necessary right now. Some icons/elements almost drop out of the screen without them. but I think a better solution would be to move them in a little bit (for example the script list just needs to get moved a little (6 px) to the right)
I would prefer removing them for now and than one by one adapt the position of elements that look odd. Thoughts?

That's looking fantastic

On Apr 28, 2017 9:01 AM, "Timo" notifications@github.com wrote:

Nice. I don't like the small margins that much. adds an unnecessary lines.
The dark background should be enough to separate the content.
I see why they are necessary right now. Some icons/elements almost drop
out of the screen without them. but I think a better solution would be to
move them in a little bit (for example the script list just needs to get
moved a little (6 px) to the right)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/7294#issuecomment-297923645,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z25j6CUG1AfAZ5Gac7D04WfGAKJGFks5r0Y7AgaJpZM4LMKXr
.

In the old theme, when selecting an item in a tree and pressing the up and down keys, the current item selected would be marked with a thin border. In the new theme this doesn't exist any more, making it a little hard to tell which item's information is displayed in the Inspector.

I think after seeing the @alelepd concept, especially the dark one from a couple of days ago, no other UI is going to live up to that. It's the sleek modern UI that Godot deserves and my eyeballs crave.

I'm with @Zephilinox on this one. The theme from @alelepd is the premier UI solution but seems to be avoided for some reason. Maybe it's impossible to create? Either way, hopefully Godot 3 will have enough custom options that I can at least mimic the colors cause I sure can't program the UI that way. Unfortunately :( But at least people are trying to improve the Godot UI. It's just not the one I prefer. But I guess everyone has a preference.

Hopefully users should be able to set a custom theme if they want, that option is present in editor settings. But apparently needs a fix? https://github.com/godotengine/godot/issues/5998
(also how is the next theme tested? Recompiling everytime a change is made?)

I prefer the smaller margins, but this is still a lot better IMHO...I want to personally thank everyone involved...I only have one monitor(hey...wife & kids..means my extra resources go elsewhere) and having at least slightly smaller boarders and margins makes my day easier. I will be looking into customizing mine more later...atm I will stick with 2.x for my current project.

Guys, the concept from alepd is a good reference, but it's not the Godot
UI. A lot of things are missing or wrong. It may be good as inspiration,
but we can't make something like it.

On Apr 28, 2017 3:10 PM, "justinbarrett" notifications@github.com wrote:

I prefer the smaller margins, but this is still a lot better IMHO...I want
to personally thank everyone involved...I only have one monitor(hey...wife
& kids..means my extra resources go elsewhere) and having at least slightly
smaller boarders and margins makes my day easier. I will be looking into
customizing mine more later...atm I will stick with 2.x for my current
project.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/7294#issuecomment-297993389,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z2w2dqXWMjdOc0vfBaJgvN4tP_nAWks5r0eUngaJpZM4LMKXr
.

I made some test with new default theme.

as you can see in this screen shot,
button is not filled, V/HSeparator is not visible, progress bar has no background texture, etc...
the default theme is used for prototyping game also.
so, I think we should provide proper default theme.

this is old theme.

Guys, the concept from alepd is a good reference, but it's not the Godot
UI. A lot of things are missing or wrong. It may be good as inspiration,
but we can't make something like it.

@reduz As long as there's a custom option to change that purplish blue UI color to dark grey, that's fine with me. thumbs up

It's pretty hard to see the separation lines, never had problems with this before maybe adding a feature like this could be handy.

Disabled buttons are also not easy to read

Any chance we will be able to use the old theme?

The direction this is taking a refreshing break from the gaudy purple gradients and shadows from 2.x we've all become far too accustomed to, and not only that and more importantly, many UX tweaks, e.g. the settings button moved next to the rest of the menus, will help many users. Too many times I've helped someone find the editor settings for them to say that they never even knew it existed on the top right. Great work ✨ to everyone who has worked on this thus far. 3.0 deserves an improved UI and fresh face to show off the amazing internals everyone has worked on in the engine.

Agreed @riirii, @alelepd currently has the concept that is easiest on the eyes, although if it was that direction, we may want to ease up on some rounded corners and make the coffee brown slightly less saturated. The dark blue would be nice optionally, but the current values of blue and green, especially the neon, highlights quickly wear on the eyes. In many ways, everyone is heading in good directions, but before it goes further, this can help reduce missteps and save some of everyone's precious free time spent on tweaking colors too soon into the process.

Focusing on a default grayscale palette is incredibly useful in all types of design and art, as one can limit themselves to a limited values to keep focus on readability/usability. Highlights would be white or a light grey, etc. The bonus is that grey themes are muted and may come off as bland at first, but they are generally easier on the eyes for long periods of time, inoffensive/safe, and creates less of a chance to detract from the project's art and design on the canvas.

Palettes and tinting should come at the end, especially to stay focused on the long-term usability of user experience without becoming distracted with minor color tweaks for a theme color (blue) that many appear to be adverse to. Both the purple and the blue miss a bit of the point of being muted in a workspace, so going with a default blue that is this saturated is similarly a misstep as godot's current purple is.

The following examples are not specifically for layout / theme ideas. Expect some feature creep in the rest of this, but focus mostly on why it may be worth forgetting finding a specific color palette as of right now and what that could bring to both devs/designers and users.

Material design (ignore that the background on these screenshots is similarly blue. Greyscale in the adobe screenshots and alelepd's coffee theme are closer) has some guidelines that are worth taking into consideration, but I am not recommending the UI turn into material design. More specifically, take note of how it deals with primary and accent colors. The following is a material UI inspired theme for atom editor. It's also worth considering implementing the flexibility for preset colors and a handful (1-3) of custom tweaks that reliably affect the rest of the UI's accents and highlights. The flexibility is not only worth it to users, but also preparing a framework with a palette of balanced grey values to work from for anyone else who wants to contribute, tweak, and offer their own minimal and balanced palettes (even if they do not know C++) for a final default godot theme or for the preset options.

Grey

Blue Grey

Amber

Photoshop has a decent idea for dealing with grayscale themes which could be expanded upon, ignoring the gaudier parts of their UIs. There are four shades of grey which can be chosen, each one tested with the other values. By default the detail/highlight color is grey, but you may select, only one, blue highlight/accent color which is mostly underwhelming albeit preferably muted.

(ow that brightness burns)

Something that Ableton does with their (far from perfect) vector UI is allowing the user to have a HSV slider for the UI; however, this can be difficult to implement for every different value of text and icon and most settings end up being incredibly ugly in ableton. Mentioning this only in case someone has an idea to prevent the caveats, but I am doubtful.

After Effects implements a brightness slider, but truthfully it's yet another example of where sliders are generally unreliable, unlike the material design inspired atom theme which gives options to change the accent colors primarily.

tl;dr

Use a dark grey theme for the UI during development to ensure that focus is kept on usability (e.g. moving the settings button to the rest of the menus as seen so far), readability (e.g. tweaking only values of grey for balance, using a single light grey or white for highlights, tweaking margins in the editor, etc), and flexibility for color palette tweaks for presets and user/dev edits after the rest of the UI is finalized.

Either way this feedback is received, hopefully its kept in consideration.

Keep up the wonderful collaboration 💕

@memoryruins I agree with everything you just said. However, I think most of it will fall on deaf ears. Not in a bad way. It's just I think the people doing the UI have a concept in mind and that's what they're going to do whether people mention other design concepts or changing the purple UI to dark grey by default. Ultimately I think it's all up to @reduz and what he wants to see. If it's purple, people will have to live with it and just change it in whatever theme settings we get after release.

The fact that people have made the improvements that they have should be applauded. The theme already looks better and has moved things around especially up top to help with usability. I'm happy for that. A few more improvements and a change to the overall color scheme would make happy since I know I can never have Godot with the theme from @alelepd

@djrm current changes is mostly about "Default theme", not about "Editor theme".
personally, I like to have old theme for prototyping game and new theme for only editor.
what do you think?

@volzhs I like the idea and also it would be cool to offer a default theme better suited for prototyping (something really simple), but I don't know if I would have to create a Godot theme (for the current theme), I don't like the theme editor that much

@djrm I have an idea for that. it mostly about codes. I will make a demonstration and would like have your opinion then. :)

If there are considerations for creating a prototyping theme, I'd like to throw out my IsoDark theme for a starting point. It's not perfect, but I designed it to be minimalist and easily modified.

I'd actually been planning to update it once we get closer to 3.0, but if there's interest I might be able to get started sooner.

How are you changing the theme as a user? I tried creating a .tres theme that just changes the color of buttons, saved it in my project, but when I load it in the custom theme editor setting, nothing happens, no console message, even if I restart the editor.

@GalanCM This is a great idea. Especially since your theme is really saddle. no specific color, style... fits almost everywhere! much better for prototyping, than the simple theme for the editor!

@Zylann the installation is a little bit wired. You need to run a script to setup paths. not exactly sure anymore how it worked but it is more complex than it should be.

@MakeGodotGreatAgain: The beauty of open source is anyone can spend time on whatever suits their fancy. There are plenty of people here that think the current theme needs a refresh (including @reduz himself from what I've seen) and you have no right to "forbid" their efforts. If you think you have valid concerns you should voice them in a less incendiary way. Nobody will listen to you with your current attitude.

Regarding hidpi: It isn't currently the norm, but it is rapidly becoming it. 4k is the newest buzz word and many people (including myself) are jumping on the bandwagon. A large percentage of current laptops are "retina", "QHD", or "4k". 5 years from now if godot does not support hidpi we will be alienating a large group of developers. Also im pretty sure most of the hidpi work has already been done so this is basically a non-issue anyway.

Related: There are a lot of people here with both good and bad opinions about the new theme. While its good to get input from people invested in the product, I think it would be wise for some of the godot leadership to pick a small team (or individual) in charge of design, if that hasn't been done already. This would:
1) Prevent the shortcomings of Design by Committee. Consistency is way more important than attempting to make everyone happy (because thats impossible).
2) Reduce redundant "competing" efforts
3) Resolve disputes about design direction
4) Ensure that future ui contributions / additions fit in with the design team's methodology

Maybe this could be applied elsewhere to formalize other roles within the godot project? Just a thought. Maybe this already exists. Maybe nobody cares. Maybe I'm overthinking this :)

The logo was refreshed. It's basically the same goofy robot thing. Just looks a bit slimmer.

@MakeGodotGreatAgain
Forbid very much means "an order":

It sounds like you have some valid concerns. Your first post should have had more things like this:

not something with weird colors and buttons that have 25 pixel wide borders.

Also, why cant the current theme work with hiDPI?

Which start a dialogue and are much more actionable than comments like:

those buttons need to be fixed. I'm sorry but they look awful. I forbid and hope juan does not accept anything related to this theme for 3.0

apparently @Calinou thinks "mahh hiDPI" support is so amazing.

which is what the current theme does. stop wasting time and focus on issues that actually matter

Which are mean spirited and disrespectful of the hard work of the people in this thread.

Speaking of the old theme. Is it possible to get it back with the _Custom Theme_ option? Or are there still some parts hard-coded in the code?

@MakeGodotGreatAgain That PR is old. The logo will not change but only the slight refresh it was given. The buttons won't stick out that much in the updated theme. I'm sure the new theme manager will give everyone what they want.

@MakeGodotGreatAgain: You are right in saying that I called out one other community member for something similar. Tone is extremely important both for both the health of the community as a whole and for you to get your point across. I could have completely ignored your comment (as I'm assuming most would, again due to its tone), but I think there should be a minimum bar for courtesy and I'm pretty sure most people would agree that you crossed it.

You have voiced some valid feedback and I'm sure the people working on the theme appreciate that you took the time to voice it. But it is seriously in your best interest to be diplomatic if you want your voice to be heard.

Ok, so since this thread is turning into a bit of a drama, let me chime in. I'm not the kind of person that will hold back on giving shit to someone just because they got badge or whatever (you can ask almost anyone here, I got serious problems with respecting authority) but, sir, it seems like you got personal problem.

I personally like the new theme. A bit on androidish side but I can appreciate that. If you don't like default theme, just go and change it (or wait until I release my sweet creation). If you're the only one not liking it and you don't want to do anything about it, you can go sodomize yourself with a baton.

Also, isn't it's a bit too soon to judge theme by pre alpha state?

How is that objectively good whatsoever.

What, the fact that buttons are drawing attention? Well, I have a couple ideas about that.

there is nothing indicating you can click on the tabs adjacent to the active one.

I'm not sure where you live but if you've EVER interacted with ANY UI in past I dunno 3-4 years you should've noticed that. For fuck's sake, even github comment field background tabs don't have anything behind them. I don't see you complaining about that.

i'd rather do that, than use this theme.

Please do that on camera and post on youtube. I'm into some kinky stuff.

are all the unactive tabs just going to be horizontally spaced evenly with no bg/borders

Yes. Look at the reply to see why your complaint is extremely stupid.

and? i think github's tabs / ui is horrible and seems like it's still stuck in 2011

And that's why you got a personal problem. Choosing between you (considering your avatar with stale memes you do seem like a person from 2011) and everyone who actually moves with time and wants a slick theme is kinda simple. Spock taught us that much.
Don't like the direction godot is heading towards? Fork it and have fun.

And if you want more examples here are a couple: Apple products, google products, everything windows, a good part of linux desktop environments and a crap ton of proprietary programs.

Theme just follows actual 2017 trends. I'm not sure if you got android 6> in 2011 but you can look at screenshots and see where the inspiration came from.

I would never shun you.

Have fun being out there. And while you there you might look at some actual design docs https://material.io/guidelines/material-design/introduction.html

That will bring you back to 2017.

@MakeGodotGreatAgain First of all thank you for bringing up concerns. That is indeed appreciated.
Although I wanted to NOT comment on your communication I can't help myself.
You are right in almost everything you said. BUT you have to ask yourself the question:
What is it that you want to achieve with your comment. You will come to the result, that it is just not smart to use all your rights (calling things how you think about them) although it might feel appropriate. And I think this thread in particular is a great example where you can learn from. Although you did nothing wrong ppl started to judge you as disrespectful because of the way you phrased your concerns. You started to defend yourself (also your right but not smart) and it resulted in a lot of messages which I HEAD TO READ ;) because I'm (like you) interested in the way the godot theme looks. And in addition to that your points where almost completely overlooked.

It cost you some energy me and a lot of others some time and your points where still not appropriately evaluated.
Although it might be against your personality it is better to respect others work and being polite. It will result in better conversations and makes the community more appealing to work with which than results in higher motivation for the ppl who actually can code and as a consequence in a better Godot engine. (maybe it might even become great as you (judged by your name) might be interested in).

And another point: READ BEFORE COMMENT. I see that I'm asking for A LOT considering the thread length... But it is fair to spend this extra amount of time.
You need to read 40+ comments and than can talk about the issues which haven't yet been solved.
Or all the contributors who read that thread (including ppl who's time is extremely valuable to the engine because they are fast and efficient coders), need to spend time reading your messages not anymore existing topics. (I'm referring to the Extremely saturated button border and the logo).

To sum up: Always evaluate how your comment will affect the behaviour of the community and evaluate if that effect helps you in succeeding whatever you are aiming for!

I know society seems to be extremely backwards but humans are just not objective enough to play the simple game :) so you need to put in some effort to achieve whatever you want to achieve.

back to topic:
@neikeq providing the current theme as an importable theme is cool. Basically the icons are still there. But someone needs to make the effort to convert it into a theme file... maybe we should open an issue for that mark it as a junior task. I can provide an explanation how to do it. So anyone can start working on it. I sadly don't have enough time to do it myself. Some changes are hardcoded (like the gap between docks) but you can almost get it back with a custom theme just some minor "improvements" are hardcoded.

@mcanders I think the approach of a dedicated team for the theme is good but not executable. It is hard to give open source contributors that amount of responsibility. ppl get not payed or similar. so they just do things which they enjoy working on (also answers the @MakeGodotGreatAgain why things which are working get changed) and don't like in the current version soo much that they were willing to spend time on and everybody should be thankful about it ;) djrm recently made the decision to not spend that much time anymore. And this kind of freedom is important to keep motivation up.
Although I like the idea I think the current approach with motivated ppl working on it and getting influenced by the community and getting help from each other is the best approach.

@riirii theme manager? I was thinking something like that could be achieved without too much work, are you working on it?

@toger5 I'm not a fan of the blue nor of the weird green stuff. I've been messing around with the theme but one issue I'm having is that changing the pngs has no effect, I'm having to replace texture styles with flat styles which isn't ideal. Any idea where I'm going wrong?

@Zephilinox The pngs have no effect because the paths need to be correct, otherwise they point to the res:// folder which is relative to the current opend project (at least thats the way I understand it)
see also: #8605

to get a deeper understanding checkou this install script

Thanks that explains a lot.

@toger5: There are definitely benefits to both approaches. The community driven approach is more organic, encourages more participation, and allows for competition (the good kind), but it is also less focused and competition (the bad kind) could result in some people getting hurt or having their work "thrown out".

Like what if someone else spun up another design thread and spent just as much work as you, @djrm, and @alelepd implementing their own proposal? (sorry if i forgot to mention someone in this thread) Only one design can be chosen and someone will get burned. Who has the final say? Is it @reduz or do the "core developers" vote? A formalized hierarchy and organization structure actually protects contributors and reduces redundant efforts.

Apologies for derailing things, this is well in the realm of off topic. If anyone is interested in continuing this conversation elsewhere, I'm often around on the discord channel under this handle.

@mcanders this is why godot should have several selectable themes instead of just one

@Zephilinox we still need one as the default without choosing. One of godots core advantages is the small size so there I doubt ppl will appreciate it being shipped with multiple themes. And installing one requires downloading... point being a lot of ppl will still use default theme

@mcanders I hope that anybody who works on it mentions it to the community (other than me at the beginning ;) )
As soon as someone is willing to organise this kind of group. That wouldn't be a bad approach for sure.
Just monitoring all the ppl currently working on it. And collecting opinions.

Default theme matters a lot less than having some choice. I don't think a megabyte of images per theme is going to make anyone stop using godot, there only really needs to be 3 anyway

Two or three themes are highly unlikely to increase Godot's download size enough for it to matter for people downloading.

Wow. I just came back from trip and new theme in master! :D

NICE! Looks great.
Now only thing left is fixing margins and some dialogs.

@djrm Do you plan to change HTML5 icon? It looks a bit weird being so much orange among white icons :D

@toger5 about the pngs, I'm not understanding how paths are related to this. I'm not using a custom .tres theme, I'm editing the engine source. Am I supposed to place the pngs that are in /scene/resources/default_theme somewhere else?

Oh i see. This is how it works: there is a header with all the images as variables in hex (i think).
All the images get converted to vars inside that file on conpile time. I think scons takes care of it so you can just delete the file. And it will het recreated. (not sure anymore) Other option would be that there might be a script which you have to run before compiling to update the header.

@Zireael07 so you want multiple thems build into godot. Thats interesting. I alsways had the attitude that the ppl who care enough would also go and download one. But maybe that is indeed wanted.
Ps i agree that the file size argument is not strong at all. I still always try to keep it in mind. We are not where we are because the devs told themselves. "Wont get muuuch bigger if we just add this and that and..."

@toger5: They could also be available as (optional) assets but they'd have to be artificially kept in one place to not get lost in the list.

Basically I have no strong feelings regarding either a light or a dark theme, I think there should be a basic theme thing that's then tinted light or dark and made available to end users, so that's two (or maybe) three options for end users.

@toger5 ah I see, thanks, I think I figured it out:

Edit svg to whatever you want
Export them to scene/resources/default_theme, or use /misc/scripts/svgs_2_pngs.py
Go to /scene/resources/default_theme and run make_header.py
Compile & run

@Zireael07 @toger5 as I mentioned before, maybe the (blue) tinted as default and neutral (gray) dark and light as optional, most desktop environments come with light and dark grays as defaults nowadays and could be good to have them too.

@eon-s yeah that's pretty standard, problem is godot doesn't have this functionality right now.

If we get https://github.com/godotengine/godot/issues/8604 then changing themes could be as easy as modifying 4 colours in the editor settings.

Alright, this issue is going out of hand, time to stop that derailing train.

I'm glad to see many new names here of people getting involved in discussions, but you all need to know what your place is. As many free and open source projects, Godot is a meritocracy, and the decision goes to those who do the work. If you're never contributed to the project, you can't really burst in and tell every contributor that they're wrong and that you know better - you won't be heard, even if some of your concerns are valid.

Several contributors have been working on a new theme for months, namely @djrm, @toger5, @volzhs, @alelepd and a few others. Godot's core developers liked the WIP and decided that it will be the new visual branding for Godot 3.0, as it's modern and refreshing. Design changes will never please everyone, so it's normal that some prefer the 2.x theme and are annoyed at the change - but don't waste your breath, @djrm's work was a great base for what we want to have as default theme in 3.0, and we'll build upon that, not go backwards.

As I mentioned, what was merged is a work in progress, so it will still be improved. @volzhs already addressed some issues, I see on IRC that @n-pigeon is working on some improvements too - those are the kind of contributors that bring us somewhere. People just ranting about what they don't like aren't, and are likely to be ignored. Instead, implement the changes you have in mind, and make a PR showing how it looked before and how it looks after (especially for all the nit-picking on color choices, we don't really to start doing name calling for something so trivial...).

So if you genuinely want to help, please respect the work that has been done by existing contributors, and try to bring constructive feedback. Make mockups of what you have in mind, or best, implement it and show us the results. It will never be possible to please everyone, but we can find something most of us will be happy with.

I'll close this issue which has become unreadable. Please open specific issues for the various problems that still need to be addressed in the current editor theme (color palette, margins and borders, buttons, etc.), and also of course potential issues that might have been introduced in the default theme used when prototyping games.

And thanks a lot to all those who have worked on the current theme, you did an awesome job :)