Dark UI theme for inline editors #8529

Merged
merged 20 commits into from Jul 25, 2014

Conversation

Projects
None yet
10 participants
Contributor

dangoor commented Jul 23, 2014

This is a spinoff of @larz0's work in #8362 with a goal of fixing #8379.

As of this initial push, I have done inline CSS and color editors. The timing editor is almost done, and quick docs remains.

cc @MiguelCastillo

Member

MiguelCastillo commented Jul 23, 2014

@dangoor quick edit is all styled!! Nice! One thing that's more about the coloring is that it is really hard for me to see where the quick edit widget starts/ends. Maybe a bit more contrast in background color? Not sure.

screen shot 2014-07-23 at 1 16 07 pm

@MiguelCastillo MiguelCastillo referenced this pull request in Brackets-Themes/RubyBlue Jul 23, 2014

Closed

Should I add Dark = true #3

Member

MarcelGerber commented Jul 23, 2014

I agree with MiguelCastillo, we should add a little more contrast. We can even do it by simply adding a light ruler before and after the widget.

Member

peterflynn commented Jul 23, 2014

@larz0 What do you think about the inline editor contrast? Personally I think changing the edge shadows from dark to light might look weird, but I defer to you... Any other ideas about how to improve the contrast?

One thought I had was to make the inline editor's bg slightly lighter than the main bg, rather than darker as we do in the light theme... but would that be enough to make the dark sufficiently shadows visible?

Contributor

mackenza commented Jul 23, 2014

adding contrast won't really help the other themes, as they will have their own variations of dark background. If I am understanding this, the dark inline editor will be triggered by dark: true in the package.json under the theme key.

If that is right, I agree with @saplayer 's suggestion to lighten the .top-shadow and .bottom-shadow

for top I used (255,255,255,0.2)(0,0,0,0.2)
bottom I reversed (0,0,0,0.2)(255,255,255,0.2)

image

Member

larz0 commented Jul 23, 2014

Give me 40 mins to try something. I'm on the streets right now.

Member

larz0 commented Jul 23, 2014

We should do this. (@dangoor, I think we missed a few spots because certain styles are coming from outside of the extensions in dark core UI PR).

Here's the code:

.dark .inline-widget {
color: #333;
background-color: #1b1b1b;
border-top: 1px solid rgba(255, 255, 255, 0.1);
}

screen shot 2014-07-23 at 11 31 59 am

screen shot 2014-07-23 at 11 29 00 am

screen shot 2014-07-23 at 11 30 02 am

screen shot 2014-07-23 at 11 30 22 am

Contributor

dangoor commented Jul 23, 2014

Thanks for the feedback, everyone (and @larz0 for the styling tweak). I'll get that incorporated and finish up the remaining bits so that we can see how it feels.

Contributor

redmunds commented Jul 23, 2014

@larz Don't forget there are 2 Timing Function Editors -- edit steps() to see the other one.

It's not a huge deal, but the bezier curve editor labels (Progression & Time) have different background colors, so it looks a bit awkward. A quick fix might be to give the text with dark bg color (Progression) a light color? Or maybe text for both labels is blue or lighter gray?

Member

larz0 commented Jul 23, 2014

@redmunds are you looking at #8362? Hopefully it's fixed in that PR. I'll need to check the step editor again though, think I missed that one.

Contributor

redmunds commented Jul 23, 2014

@larz I was just looking at screenshot in this PR.

InlineTimingFunctionEditor styling
Also includes a tweak to subtly set the inline editors off from the main editor.
Member

MarcelGerber commented Jul 23, 2014

@larz0 Imho, the bezier editor shortcuts should be brightened.
And the Quick Docs contrast makes it hard to read, even w/ good eyes. But I'm not sure whether the vertical ruler should be that flashy.

Member

larz0 commented Jul 23, 2014

@redmunds ok cool. @saplayer the final version should look like #8362. Ignore the screenshots for now.

Contributor

dangoor commented Jul 23, 2014

@saplayer I haven't done anything at all with Quick Docs yet.

@redmunds I hadn't gotten to step editor yet. I was just added the styles for that and was just about to test.

Contributor

dangoor commented Jul 23, 2014

I just pushed changes that finish the inline timing editor and Quick Docs. There are still some tweaks needed, and I'd like to go back through #8362 and see what else might be relevant, though a bunch of the changes that remain in there are other parts of the UI that we're not worried about right now.

I took some screenshots earlier today running with #8362 for comparison purposes and what I have in my branch seems closer to usable than what I saw there. I'll post some screenshots in a moment.

Contributor

mackenza commented Jul 23, 2014

I saw your changes and ran with them... I think they look pretty good. Nice work.

I am only running the default dark theme so far though... with custom themes, will the theme authors need to do anything with .inline-widget or the like?

Contributor

dangoor commented Jul 23, 2014

dark_bezier
dark_color_editor
dark_inline_css
dark_quick_docs
dark_steps

Contributor

dangoor commented Jul 23, 2014

@mackenza Thanks (though it's @larz0's design work, I'm just transcribing :)

At this point, theme authors should focus on their color scheme and just set the dark flag to true. If they wanted to provide an additional color scheme for the inline text editor, that would be okay. But, the other inline editors are considered "UI" (their DOMs can change any time).

Member

peterflynn commented Jul 23, 2014

@dangoor The designs @larz0 posted above this morning had light borders top & bottom, while your screenshots only have light borders on top. Intentional?

Contributor

dangoor commented Jul 23, 2014

@peterflynn No, not intentional. I'm guessing that's part of #8362 in the parts that are not in the extensions. I will be taking another look.

Contributor

mackenza commented Jul 23, 2014

@dangoor I am noticing some differences in the "neatness" of the pop up editors between the default dark and my Envy and Railcasts. I guess I need to reconcile them against the new dark and see what is different. For sure the default dark is looking pretty sweet now.

Contributor

dangoor commented Jul 23, 2014

@mackenza Yeah, it's not going to be a perfect fit with custom themes right now. We've thought that a nice partway point between full UI theming and the editor themes is that editor themes could be able to suggest some colors that could be used in place of some of the defaults. There is some infrastructure required for that first, though.

Contributor

dangoor commented Jul 23, 2014

This is what #8362's color editor looks like on my machine:

8362

Member

larz0 commented Jul 23, 2014

@dangoor that's weird, thought I styled those buttons. You even picked it up in this PR.

Contributor

dangoor commented Jul 23, 2014

@larz0 Oh, I see the problem... I didn't paste the variables into the extension.

Contributor

dangoor commented Jul 23, 2014

This is what #8362 looks like after I paste the variables into the extension. It doesn't have the lighter border at the top and bottom but does look like what I was expecting :)

real_8362

Member

larz0 commented Jul 23, 2014

@dangoor phew :)

Contributor

dangoor commented Jul 24, 2014

@larz0 In my screenshots from earlier today you can see that the buttons in the bezier editor have a gray background and those in the step editor have a black background (note that the step editor has the wrong foreground color though). I noticed in #8362 that you've got them with a black background, but the gray background ones look to me more like keys (I can hardly see the black). Should I stick with the black or the gray?

Member

larz0 commented Jul 24, 2014

@dangoor could you try #3D3D3D with white key symbols?

Contributor

dangoor commented Jul 24, 2014

@larz0 Sure, will do. Another question for you: the web platform docs logo is showing through in the Read More button in Quick Docs in the dark theme, but I don't see that logo at all in the light theme. The background is background:@bc-btn-bg url("logo.svg");. Is that logo supposed to appear somewhere?

Contributor

dangoor commented Jul 24, 2014

#3D3D3D with white looks good to me:

bezier_kbd_3d3d3d

Fix up the inline timing function styling.
Also adds the bottom border as seen in some screenshots from larz.
Member

larz0 commented Jul 24, 2014

@dangoor it's a CSS quirk, I think dark theme's background shorthand's defaults are overriding light theme's background-size and background-position, try replacing:

background:@dark-bc-btn-bg url("logo.svg");

with

background-color: @dark-bc-btn-bg;

We don't need to specify the URL again because dark theme uses the same image.

Contributor

redmunds commented Jul 24, 2014

@larz0

I'm not sure what's causing it. There's no border or padding on those match-boxes.

It looks like it may be a shadow gradient.

Member

larz0 commented Jul 24, 2014

@redmunds I commented that out and still got the same result.

Member

peterflynn commented Jul 24, 2014

@larz0 Re the match highlight -- the two issues I mentioned have slightly different causes:

  • 1px misalignment along the top edge of the highlight -- there are two colored DOM elements being overlaid: the selection highlight is the base color, and the translucent match highlight sits on top of that. It looks like there's a rounding problem where the selection div and the markText() span differ in height by 1px at certain font sizes.
  • two highlights that are on neighboring lines overlap by 1px -- each markText() span is slightly taller than the line spacing, so they overlap; no selection div is involved here. (May be the same rounding bug under the hood though, because again it's never more than 1px even at very large font sizes).
Member

peterflynn commented Jul 24, 2014

@redmunds Re "Use Theme Scrollbars" -- the LESS code in themes can style anything inside the editor area, including the editor scrollbars. This toggle lets users turn off that part of their styling if desired.

Member

larz0 commented Jul 24, 2014

@peterflynn I see. Sounds like it's a fact of life…

Member

peterflynn commented Jul 24, 2014

@larz0 The overlap is, but we may want to tweak the selection & highlight colors in the dark theme to try to make it look less noticeable. We've had the bug for a long time in Brackets core and most people can't spot it because of the color scheme we happen to be using.

This will suck for theme authors though -- every one of them will have to go through this same tweaking (and I'm guessing most will forget or not know how). Maybe we can pull in some of the work to clean up search highlighting... Originally we didn't need to tackle that until we did cross-newline searching or leaving the search bar open, but theming may make this more urgent...

Member

larz0 commented Jul 24, 2014

@peterflynn we need to keep the yellow transparent so the red can show through for the current match but that means we'll be able to see the overlap. If we make the yellow more opaque then the red won't be able to show through making the current match stand out.

Member

peterflynn commented Jul 24, 2014

@larz0 Yeah, but that's true in the light theme too.

Member

larz0 commented Jul 24, 2014

@peterflynn yeah it's probably less noticeable in the light theme because bright yellow and orange is closer to white than black.

Made blank view dark. Renamed themes so Brackets Light and Brackets D…
…ark can be together when there are more themes on that list. Added proper focus style for Select element.
Member

larz0 commented Jul 24, 2014

I've pushed the changes I made.

@dangoor dangoor changed the title from [REVIEW ONLY] Dark UI theme for inline editors to Dark UI theme for inline editors Jul 25, 2014

Contributor

dangoor commented Jul 25, 2014

I've incorporated @JeffryBooher's change which fixes inline editor code overlapping the gutter when you scroll horizontally (#8541).

Was this change intentional? It doesn't seem related to this PR and I'm wondering if this was an accidental "testing the step editor" change?

Contributor

dangoor replied Jul 25, 2014

Never mind. I see that this was reverted in the commit that followed.

Contributor

dangoor commented Jul 25, 2014

I'm not sure if this needs additional review at this point? This pull request has gone through a lot of testing, @larz0 has seen what I've done and I've seen what he has done. I think this is ready to go.

Contributor

mackenza commented Jul 25, 2014

I am looking to make sure my custom themes are reflective of these changes and in the new main.less for the darkTheme I see:

/* Inline editor styling */

.related-container .selection:before {
    border-top: 9px solid transparent;
    border-bottom: 9px solid transparent;
}

.inline-widget .CodeMirror, .inline-widget .CodeMirror-gutters {
    background: transparent;
}

are those going to remain in the actual theme stylesheet or move to the default styles? They don't seem to have anything theme specific in them so that's why I was wondering if I needed them in my theme stylesheet.

Member

larz0 commented Jul 25, 2014

@mackenza you don't need to add them to your stylesheet unless you want to override them on purpose.

Member

MarcelGerber commented Jul 25, 2014

@larz0 Some spots I found:

  • Quick View popver
    image
  • steps editor (and bezier editor) .info .hint color
    image
  • image custom viewer
    image

@dangoor There are still some issues left open, like the dark scrollbars in Dialogs.

Member

larz0 commented Jul 25, 2014

@saplayer Quick View and image viewer won't make it in 42 but I'll fix steps editor hint color. Nice catch!

It's not only the steps editor, but the bezier editor, too.

Member

larz0 replied Jul 25, 2014

This is fixed.

Member

larz0 commented Jul 25, 2014

@saplayer image viewer styling will be in release 42 👍

Contributor

redmunds commented Jul 25, 2014

Copyright date for LightTheme/main.less should be changed to 2014

Member

larz0 commented Jul 25, 2014

@redmunds fixed.

Contributor

redmunds commented Jul 25, 2014

I made a pass through the code. Looks good.

Contributor

dangoor commented Jul 25, 2014

I just pushed a change to constrain the dark scrollbars to #editor-holder. I tried testing by setting the class on body to .platform-win, but the editor wasn't showing custom scrollbars for me, though the styles seemed to have been applied in the dev tools. This change did fix the scrollbars in the dialogs.

Can someone test this? I'm going to be offline for a while now. As far as I can see, once the scrollbars look good, we can merge.

Member

MarcelGerber commented Jul 25, 2014

@dangoor The scrollbars are working fine and are only applied to the editor.

Contributor

redmunds commented Jul 25, 2014

That fixes all of the scrollbar cases I was seeing. Merging.

redmunds added a commit that referenced this pull request Jul 25, 2014

@redmunds redmunds merged commit b2fdb16 into master Jul 25, 2014

1 check passed

continuous-integration/travis-ci The Travis CI build passed
Details

@redmunds redmunds deleted the dangoor/inline-styling branch Jul 25, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment