Now we have a solid set of tools and a stable toolbox, we should revisit how the style of our tools work. Shorlander has been working hard on a round of new mockups: http://people.mozilla.org/~shorlander/mockups/devTools/ux-refresh-2013/ Things to consider: - we want to support a light theme and a dark theme - do we want to support regular themes? - do we want to split the theme in 3 directories (osx,linux,windows) - we want to share as much code as possible across the tools (checkboxes, twisties, ...) - fonts are hard - let's try to reduce the amount of files we need (7 kind of rules: 3 platforms * 2 themes + content) We might want to wait for bug 912121 to get fixed first.

(In reply to Paul Rouget [:paul] from comment #0) > - do we want to split the theme in 3 directories (osx,linux,windows) > - let's try to reduce the amount of files we need (7 kind of rules: 3 > platforms * 2 themes + content) I agree, having three separate directories adds to the overhead of making changes to the devtools frontend. Any time I've made changes I've just copy/pasted them across all of the files. There can also be some confusion about which file(s) should be modified for certain types of changes. I wonder (a) how often are there *any* changes across the OS themes, and (b) are there any places that have big differences across the OS themes (more than just a different value for the same property). If most changes across OS are minor, we could maybe have a class that gets applied to the root element (.osx, .windows, .linux) that would allow us to target changes. .some-widget { -moz-margin-start: 3px; } .linux .some-widget { -moz-margin-start: 1px; }

(In reply to Brian Grinstead [:bgrins] from comment #1) > I wonder (a) how often are there *any* changes across the OS themes, and (b) > are there any places that have big differences across the OS themes (more > than just a different value for the same property). There are some differences (different gradients / colors / border-radius). But things changed and we don't maintain them anymore. So any remaining differences are just legacy. The only major difference in the UI between osx and linux+windows is that OSX has controls on the left in the toolbox when linux and windows have them on the right. > If most changes across OS are minor, we could maybe have a class that gets > applied to the root element (.osx, .windows, .linux) that would allow us to > target changes. We prefer pre-processing instructions (descendant selectors are bad). For example: %ifdef XP_LINUX color: #F06; %else color: black; %endif

I would like to add a small extra detail to this bug related to doorhangers. When bug 765105 lands, new doorhangers will be available in the markup, rule and computed views, for some properties. For now, doorhangers use a mostly unstyled XUL panel (the only change made is the internal padding that has been reduced to 4px, other than that, the background and border are the native ones). When the new light and dark themes are implemented, can we check if doorhangers look ok?

Another thing to check: are we able to theme CodeMirror to match the dark and light themes, or does the default look good enough with either?

For sure we can theme CodeMirror to match our dark/light themes : http://codemirror.net/demo/theme.html

Here is a list of colors from the dark theme color scheme (may be outdated). Working with shorlander to get an up to date version for dark and light themes. Background - Editor #111315 rgba(17, 19, 21, 1) Background - Sidebar #181d20 rgba(24, 29, 32, 1) Chrome - Tab Toolbar #252c33 rgba(37, 44, 51, 1) Chrome - Toolbars #353c45 rgba(53, 60, 69, 1) Chrome - Select Highlight Blue #1a4766 rgba(26, 71, 102, 1) Foreground - Light #f5f7fa rgba(245, 247, 250, 1) Foreground - Grey #b6babf rgba(182, 186, 191, 1) Blue #46afe3 rgba(70, 175, 227, 1) Purple #6b7abb rgba(107, 122, 187, 1) Pink #b987bc rgba(185, 135, 188, 1) Red #eb5368 rgba(235, 83, 104, 1) Orange #d96629 rgba(217, 102, 41, 1) Light Orange #d99b28 rgba(217, 155, 40, 1) Green #70bf53 rgba(112, 191, 83, 1) Blue-Grey #5e88b0 rgba(94, 136, 176, 1)

OK, here is the official dark theme update: /*-- Chrome --*/ Tab Toolbar #252c33 rgba(37, 44, 51, 1) Toolbars #343c45 rgba(52, 60, 69, 1) Select Highlight Blue #1d4f73 rgba(29, 79, 115, 1) Foreground (Text) - Light #f5f7fa rgba(245, 247, 250, 1) Foreground (Text) - Grey #b6babf rgba(182, 186, 191, 1) /*-- Editor --*/ Background - Editor #14171a rgba(17, 19, 21, 1) Background - Sidebar #181d20 rgba(24, 29, 32, 1) Content (Text) - Light #b8c8d9 rgba(184, 200, 217, 1) Content (Text) - Grey #8fa1b2 rgba(143, 161, 178, 1) Content (Text) - Dark Grey #5f7387 rgba(95, 115, 135, 1) Blue #46afe3 rgba(70, 175, 227, 1) Purple #6b7abb rgba(107, 122, 187, 1) Pink #df80ff rgba(223, 128, 255, 1) Red #eb5368 rgba(235, 83, 104, 1) Orange #d96629 rgba(217, 102, 41, 1) Light Orange #d99b28 rgba(217, 155, 40, 1) Green #70bf53 rgba(112, 191, 83, 1) Blue-Grey #5e88b0 rgba(94, 136, 176, 1)

When the dark theme is applied, we should be using a dark default background for the toolbox iframe, otherwise switching tools causes flickering. Easiest way to notice is to set to dark theme, close the tools, then reopen. On each new tab the background starts out white before the iframe is loaded.

(In reply to Brian Grinstead [:bgrins] from comment #9) > OK, here is the official dark theme update: Where do these colors come from precisely? Should we use them in the toolbox? Because they look out of place. Should we use these values or the palettes? I'm worried because we are working on updating the toolbox design based on the palette, but the colors values keep changing. We just changed the look of the infobar and we are changing the colors of the toolbars. Can someone put somewhere (MDN?) the list of colors, and make sure that it won't change, or if it changes, add a diff somewhere? Or can we create a devtools-colors.inc file in /browser/theme/shared/devtools/?

I've created this: https://developer.mozilla.org/en-US/docs/Tools/DevToolsColors

Could we get the list of colors used in the light theme palette, similar to the list we have for the dark theme in Comment 9?

> Could we get the list of colors used in the light theme palette, similar to the list we have for the dark theme in Comment 9? Darrin, we have a list of the colors in the dark theme from https://developer.mozilla.org/en-US/docs/Tools/DevToolsColors (these were taken from Comment 9). Could we get the same list for light colors?

(In reply to Brian Grinstead [:bgrins] from comment #14) > > Could we get the list of colors used in the light theme palette, similar to the list we have for the dark theme in Comment 9? > > Darrin, we have a list of the colors in the dark theme from > https://developer.mozilla.org/en-US/docs/Tools/DevToolsColors (these were > taken from Comment 9). Could we get the same list for light colors? Added the Light Theme colors to the wiki.

I think we need a guide as to how to use the colors in the editor. Obviously it would make sense if we all used the same colors for comments, but there are other common concepts like strings, values, and maybe variables.

Paul, I'm doing a bit of prep work here before beginning to implement new designs. This patch makes the webconsole and option panels use the correct themes, and also prevents the flicker that can be seen when switching in between tabs (when loading it for the first time). I've also moved the toolbar colors into each theme (but not yet updated them to the new styles). Once these changes are made, I'll move on to loading the theme colors as preprocessor variables. Darrin, Can you please take a look at this build - especially the Web Console and Option panels? The downloads will be accessible in a few hours at: https://tbpl.mozilla.org/?tree=Try&rev=e4219d6b3c20. I didn't update the colors for the left bars in the console after all, since they ended up matching the severity icons here: https://mxr.mozilla.org/mozilla-central/source/browser/themes/osx/devtools/webconsole.png, so it looked a little weird with different colors. If you could get update those icons to the new dark theme colors, I will update the web console CSS and images to use them. I'll leave it up to you if you think it needs to be in this patch or could be landed later on as a follow-up.

Looks good as a placeholder until we get the whole new theme up and running :) I think until we start introducing the new colors across the board, let's hold off on updating icons, etc. I will update them as part of the larger redesign effort.

Same patch, except I updated theme-switching.js to use addon-sdk stylesheet utilities to fix test failures. Pushed to try: https://tbpl.mozilla.org/?tree=Try&rev=956e200e6725

Comment on attachment 831639 [details] [diff] [review] theme-prep.patch Paul, Can you have a quick look just at the changes I made in theme-switching.js? winUtils.addSheet was throwing exceptions, so I started using the addon-sdk Stylesheet utils instead. Diff of this file: https://bugzilla.mozilla.org/attachment.cgi?id=831639&action=diff#a/browser/devtools/shared/theme-switching.js_sec1. Source of utils.js: https://mxr.mozilla.org/mozilla-central/source/addon-sdk/source/lib/sdk/stylesheet/utils.js.

Paul, is this what you were thinking regarding using preprocessor to load colors instead of having them inlined in the theme files? I was thinking we could land a patch like this that just switches to the preprocessor without actually switching to the new theme colors, then have one that follows that actually implements the new theme.

Darrin, I need the toolbar icons in a darker color to match the logos for Inspector / Console / etc in this comp: https://people.mozilla.org/~shorlander/mockups/devTools/ux-refresh-2013/LightTheme-Inspector-Locked@2x.png. Shorlander may already have some of these, but I'm not sure. Right now all the images have white text, not the color matching the comps, which seems to be about rgb(130, 130, 130) or similar. Here is a directory with the existing icons: https://mxr.mozilla.org/mozilla-central/source/browser/themes/osx/devtools/ And the ones I need in the darker color to get the top bar done: toggle-tools.png tool-debugger.png tool-inspector.png tool-network.png tool-options.png tool-profiler.png tool-scratchpad.png tool-styleeditor.png tool-webconsole.png command-paintflashing.png command-responsivemode.png command-scratchpad.png command-tilt.png close.png undock.png inspect-button.png

Missed the Variables View and Scratchpad for adding the theme-switching.js file

Shorlander told me he would get you the icons, I think he has most of them already.

Comment on attachment 832955 [details] [diff] [review] theme-preprocess.patch Yep. Maybe we can wait until bug 773296 is fixed (but it might take a while).

Darrin, Can you have a quick look at the dark theme's terminal in the console in this image? Eventually we will want it to look more like this: https://people.mozilla.org/~shorlander/mockups/devTools/ux-refresh-2013/DarkTheme-Console-AllToggled@2x.png, but in the meantime I've updated the background and text color to match the comp, as opposed to the completely white background and black text we have in current nightlies. Note that the color is actually slightly different than the background of the top tab bar, at least until I finish styling the bar. It's hard for me to detect it just looking at it, but if you'd rather wait until the top bar is updated we can do that.

Brian, this looks awesome! I am definitely OK with incremental improvements, as long as they are in the right direction. Are you still waiting on the icons?

(In reply to Darrin Henein [:darrin] from comment #32) > Brian, this looks awesome! I am definitely OK with incremental improvements, > as long as they are in the right direction. Great, I'll go ahead and submit an updated patch for the variable preprocessing, along with these console changes. > Are you still waiting on the icons? Yes, once I get the icons I can start on styling the top tab bar.

Paul, This patch makes just a few style changes in webconsole: * Make jsterm input match dark theme better (Comment 31). * Use dark theme on autocomplete when dark theme is applied. * Update the page navigated message when 'persistent logs' are enabled to match dark theme better. I was going to also include the preprocessing stuff in this patch, but am now also thinking it may be best to wait for Bug 773296 to land before making these changes. I think it will suit our needs better. The problem with the current preprocessor in our case is that we can't access the *current* color variables from outside of the dark-theme.css or light-theme.css file (since we wouldn't know which color list to import from the context of webconsole.inc.css, for instance). I am actually able to work around this by including webconsole.inc.css from both light and dark themes, but then all of their styles end up getting loaded in all of the frames. From what I understand about CSS variables, we could define the custom variables in both light and dark theme files, and when one sheet is swapped out with the other, all of the other styles on the page will be updated with the new values for defined variables (even if these styles were living inside webconsole.inc.css, for example).

I think the console terminal could use more padding. :) Anyways, I think the font on the "code areas" should be Consolas, not Courrier New. This font is more similar to the mockup and is in many code editors. Courrier New could stay as fallback font.

BTW, the gray "description" text (like the Current page only, reloads the page text next to the Disable Javascript checkbox) in the settings panel in dark theme is kinda hard to read.

(In reply to ntim007 from comment #36) > BTW, the gray "description" text (like the Current page only, reloads the > page text next to the Disable Javascript checkbox) in the settings panel in > dark theme is kinda hard to read. Good catch - I will update this. (In reply to ntim007 from comment #35) > I think the console terminal could use more padding. :) For now I think we are actually trying to trim down the console height to support the split console UI until we are able to shrink the toolbars a bit. So I'm thinking wait on this. > Anyways, I think the font on the "code areas" should be Consolas, not > Courrier New. This font is more similar to the mockup and is in many code > editors. Courrier New could stay as fallback font. I will defer to Darrin on what font stack we should be using. I think right now, it may even be dependent on the OS you are running on.

> I will defer to Darrin on what font stack we should be using. I think right > now, it may even be dependent on the OS you are running on. Sorry, I forgot to mention it, the Courrier New font only affects Windows I think. And I think the Consolas font is availble by default on Windows.

Same changes as Comment 34, but moved the special CSS for light and dark theme in webconsole to webconsole.inc.css, so there aren't any changes to light-theme.css and dark-theme.css. Also went ahead and updated the sub text on options panel to use theme-comment class for coloring.

https://hg.mozilla.org/integration/fx-team/rev/56289707d830 https://tbpl.mozilla.org/?tree=Fx-Team&rev=56289707d830

(In reply to Ryan VanderMeulen [:RyanVM UTC-5] from comment #24) > https://hg.mozilla.org/integration/fx-team/rev/699f7f667d10 In .devtools-toolbar, bottom-border-style is missing. So the bottom border is not visisble. It caused bug 942112.

Updated the icons for the Light Theme. The opacity and darkness of the icons is based on the current CSS opacity changes we have on m-c. Things might need to be tweaked, just let me know.

Unassigning myself since this is just a meta bug