probably the most controversial change here is the removal of the rectangle that appears around the edit area when you click on it. since this deliberately implemented behavior, i assume that it's there for a reason. i'm not sure what though, and it looks kinda ugly. i disabled it, but the code is intact and can be re-enabled by editing a boolean.

probably the most controversial change here is the removal of the rectangle that appears around the edit area when you click on it.

I don't care about the rectangle, but I do care about a way to distinguish, quickly at a glance, between the editor box having focus and the post window having focus.

It wouldn't be valid, IMO, to suggest that users should look for the blinking insertion point because a/ it's small and hard to see and b/ with the scroll wheel, you might have scrolled so that the insertion point is outside the visible area. (I know, you're not putting that argument forth here -- I'm just handling a potential response in advance.)

FWIW the rectangle is not ugly in my Linux system.

I'll try the other changes in a minute (fetch and build...).

Sorry, how to resolve this error?

CMake Error at /opt/qt511/lib/cmake/Qt5/Qt5Config.cmake:28 (find_package):
  Could not find a package configuration file provided by "Qt5WebSockets"
  with any of the following names:

    Qt5WebSocketsConfig.cmake
    qt5websockets-config.cmake

sudo apt install qt511websockets?

Ok, yes, that was it. I just didn't have mental bandwidth at that moment to research it. Thanks.

Btw I generally like it. My only quibble is that, in a dark theme, it might make more sense for deselected tabs to be dark and the selected tab to be lighter (so that the deselected tabs recede into the background). Very minor point. Generally looks nice to me.

looks much better!
my only suggestion for an improvement is to only show the X button on a tab when mouse is hovering over it, not all the time. this is how the Atom editor behaves:

apparently the tabs bg-colour is coupled to the editor's text bg-colour.
I set my dark theme for maximum contrast, which now results in that:

top is before applying the patch.

@miczac i hear you. hiding the x-es might not be intuitive.

thinking about ui changes forward, i think generally it would be easier and less time consuming to produce a consistent ui for the ide if there was a design sketch proposed (an actual drawing) for the changes first, then have a discussion around that sketch, agree on the changes and at the end and then implement it. may be less time consuming. just a thought.

BTW, that's the current "Fonts & Colors" window. I adapted some settings, should cross-check w/ 3.9.3 if things still look sane.

sorry forgot: point is: it needs some boundaries! ;)

Using the syntax colors for the preferences panel is a little heavy - got to say, I don't much like that at all.

For the case @miczac described - I think for the tabs, we might need to have logic where -- when the value (the V in HSV) is >0.5 we dim unselected tabs, and for V<0.5 we brighten unselected tabs? No idea how to make that work, but miczacs screenshot is definitely a problem.

And: can you maybe post a screenshot with a bunch of split views? Differentiating between split views that have focus is a touch UI problem, it'd be good to see how it looks in this scheme.

In general, though, this is a HUGE improvement on the look of both tabs and docklet bar. Can we maybe try underlining the tab titles perhaps, to separate tab header text from code (since there's no line now)?

re: editor focus, i think it would be cool to indicate editor focus by putting a highlight bar over the top of the active tab. stylish, easily visible, doesn't get in the way.

re: contrast. for dark themes, the contrast between tab and background is not so bad on my screen, so i am probably not the best person to adjust it. @miczac or @scztt if you'd like to adjust it yourselves and report back on a reasonable difference, the code is in editors/sc-ide/widgets/app_palette.cpp, here:

bool dark_on_light = window_text.value() < window.value();
if (dark_on_light) {
    mid = color::darken(window, 23);
    highlight = color::darken(window, 50);
    disabled_text = color::darken(window, 20);
    disabled_shadow = color::darken(window, 20);
} else {
    mid = color::lighten(window, 23); // <----- increase this
    highlight = color::lighten(window, 30);
    disabled_shadow = color::lighten(window, 40);
    disabled_text = color::lighten(window, 40);
}

part of distinguishing inactive tabs is the text color, which i will also experiment with.

by the way, i'd prefer if this github PR doesn't get cluttered up with minor design adjustments, so small tips on improving the design are best sent over slack.

re: editor focus, i think it would be cool to indicate editor focus by putting a highlight bar over the top of the active tab. stylish, easily visible, doesn't get in the way.

👍

For the case @miczac described - I think for the tabs, we might need to have logic where -- when the value (the V in HSV) is >0.5 we dim unselected tabs, and for V<0.5 we brighten unselected tabs?

I would argue against brightening unselected tabs in all cases. If you have 4 tabs open, only one can be selected. If it's a dark theme and you brighten unselected tabs, then 75% of the tab bar is brighter than the surrounding regions... exactly what we were trying to avoid.

I think @snappizz's idea of a highlight bar is a much better idea. As I think about it, I'd prefer this over messing with background colors.

If we must use background color to differentiate the active tab, I'd suggest in bright themes to darken the active tab and in all themes to lighten the active tab -- slightly. The lighter color draws the eye. Perhaps with the exception that a single open tab could be darker in dark themes.

Also, I'm not sure if my earlier comment about the editor area rectangle registered attention or not.

i assume that it's there for a reason. i'm not sure what though

It's there when the editor panel has focus, and it's not there when another panel has focus (for example, if you're selecting text in the post window, or if you accidentally clicked in the post window, documents, find/replace/commandline/goto-line bar).

I don't mind getting rid of the rectangle, but it would be good to have some other mechanism, then, to know which panel has focus. But I can't think of anything less intrusive than the rectangle. Perhaps reduce the contrast on it.

i haven't messed with the background contrast yet. feel free to pull the latest version and then adjust.

it shouldn't look like that at all -- are you sure you're on the right branch and you've rebuilt SC?

(sorry! branch & build was ok, overlooked an error when applying the patch, had files from previous patch floating. Should have noticed the similar gui look :(
Deleted the previous comments.)

I created both with a fresh profile in an arrangement which is about the same as I do have currently.
To get the black one I transferred sc_ide_conf.yaml from my actual profile to the white profile.

In general, the black one is a tad too much in the dark, IMHO.

the contrast is not so bad to me, but as previously suggested, maybe you'd like to adjust it for your screen by visiting editors/sc-ide/widgets/app_palette.cpp and editing this line:

bool dark_on_light = window_text.value() < window.value();
if (dark_on_light) {
    mid = color::darken(window, 23);
    highlight = color::darken(window, 50);
    disabled_text = color::darken(window, 20);
    disabled_shadow = color::darken(window, 20);
} else {
    mid = color::lighten(window, 23); // <----- increase the 23
    highlight = color::lighten(window, 30);
    disabled_shadow = color::lighten(window, 40);
    disabled_text = color::lighten(window, 40);
}

tried it, IMHO a value of 29 is fine:

BTW: what's this line doing?
disabled_text = color::lighten(window, 40);

FWIW, I found that to my sore eyes reducing the brightness of the inactive tab's text has more effect than increasing the brightness of the bg-colour.

yeah, to make it more clear i have drawn the active tab text in bold and reduced the opacity of the inactive tab text. hopefully, even with lightening the background color, i've made it crystal clear what's highlighted and what's not. i would also like to hide the X's for inactive tabs until mouseover as @htor suggested, but that's surprisingly tricky to do in qt. maybe for a later PR.

thanks for adjusting. i still like +23 value for dark-but-not-black backgrounds like on dracula or solarized dark, but it seems that we need to threshold the minimum value to 29 to prevent a sea of black when we have a really dark background color.

only thing left to do here is to replace the rectangle for editor focus. i already mentioned that an overline on the selected tab would be nice, but this is actually very hard to write in qt. i think to hold james over we can draw a big translucent rectangle on defocus, or reduce the rectangle to a line at the bottom.

@jamshark70 the latest commit redesigns the focus rectangle as a thin translucent bar at the bottom of the editor. it's not a perfect solution, but it's less disruptive than the rectangle imo, especially for light themes.

with that, this PR is feature complete. i don't want this to stall too much, so reviewers please keep in mind that the point here is to improve the design, not necessarily perfect it.

👍 Thanks!

OK, the focus bar at the bottom of the editor is fine.

I have to admit, I'm still confused in the dark theme by the fact that the selected tab has a darker background than deselected tabs. If there are two documents, I can't help but read the lighter one as selected (despite the boldface for the really-selected one). I strongly suggest that the selected tab should have a lighter background.

Firefox tabs, for reference. The github tab (second) is active.

i tried out darkening and you're right, it does look nicer. here's "dracula" theme:

however, some people set really dark backgrounds, and we can't go darker than that. in my opinion, nearly-black backgrounds are just not attractive color choices. but for people who do use them, i will use an overline. here is the vomitous "dark" theme:

let's please push this one through and adjust later, thanks. colors are kinda subjective and there's only so much i can do to accommodate everyone's tastes. in the future can expand our theme system so that these options can be adjusted manually by the user rather than automatically from the colors.

Thanks!
I'm afraid I got a problem here:

/Users/mz/dev/sc3.git/3.9/editors/sc-ide/widgets/style/style.cpp:250:43: error: call to 'abs' is ambiguous
        int window_mid_value_difference = std::abs(
                                          ^~~~~~~~
In file included from /Users/mz/dev/sc3.git/3.9/editors/sc-ide/widgets/style/style.cpp:25:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/cmath:664:1: note: candidate function
abs(float __lcpp_x) _NOEXCEPT {return fabsf(__lcpp_x);}
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/cmath:668:1: note: candidate function
abs(double __lcpp_x) _NOEXCEPT {return fabs(__lcpp_x);}
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/cmath:672:1: note: candidate function
abs(long double __lcpp_x) _NOEXCEPT {return fabsl(__lcpp_x);}
^
1 error generated.

just checked: travis complains about the same error.
https://travis-ci.org/supercollider/supercollider/jobs/421298235

thanks, should be fixed now

Ah, I just included cstdlib to get it to compile, that's what it looks like here:

oh dear -- that overline looks wrong. i'll fix in a separate PR.

I fetched and compiled the original branch Patrick just merged.
Somethings 'counting' wrongly regarding the bar's length, I'm afraid:

Since I work with detached windows I just checked in monolith-mode. ;)

I'm sorry - github kept telling me "You can't comment at this time. "
Deleted the excess comments.
BTW, notifications appear pretty late, too late - or are we just too quick for github? ;)

i think github was wigging out, i was getting 500 errors not long ago. seems to be alright now.

yeah no prob, thanks for your feedback as well!

let's please push this one through and adjust later, thanks. colors are kinda subjective and there's only so much i can do to accommodate everyone's tastes.

FWIW I agree with this. My comment about darker-vs-lighter for focus is, I think, about a functional issue. I'm not fussing about specific color choices.

Overall, some major improvements in these PRs!

A bit of a rush now but I'll try the new commits later this afternoon.