replace OSX window title bar with custom title-bar #11790

Merged
merged 21 commits into from Aug 2, 2016

Projects

None yet
@brumm
Contributor
brumm commented May 19, 2016 edited

This pull request is intended to naively implement a custom titlebar on OSX.

I've included fallback styling to match El Capitan's titlebars, which is probably not necessary as I modified the four included themes to provide their own titlebar styling. I'll create PRs for these in their respective repositories if this PR gets considered.

I'd like to hear your thoughts on the implementation, I just banged on the code until it worked 😁

This is what it looks like by default:
image

This is the titlebar provided by one-dark-ui, with the oceanic-next syntax
image

This is one-light-ui, with the atom-light syntax
image

Things left to do:

  • βœ… specs

This is a partial continuation of #10208 albeit without the combined title-bar-and-tabs functionality, for which this would be the groundwork. (As requested in #4599 for example.)

@50Wliu 50Wliu added the needs-review label May 19, 2016
@FezVrasta
FezVrasta commented May 20, 2016 edited

@brumm Any chance to get rid of the black separation line between the title bar and the three file view? I think it would look much better.

image

@brumm
Contributor
brumm commented May 20, 2016

@FezVrasta These screenshots are just a first stab at theming the title-bar and intended to show what it could look like. At any rate, you could always remove that line by tinkering with your user stylesheet :)

@simurai Would you like me to go ahead and create some PRs on https://github.com/atom/one-dark-ui/ and https://github.com/atom/one-light-ui/?

@simurai
Member
simurai commented May 21, 2016

I wonder if the background should just be @base-background-color? So that "abandoned, but still in use" themes would adapt too. Then maybe make a PR with the current grey gradient for themes that try to stay close to OS X. Like unity-ui or native-ui.

@simurai simurai and 1 other commented on an outdated diff May 21, 2016
src/atom-environment.coffee
@@ -678,6 +684,7 @@ class AtomEnvironment extends Model
@deserialize(state) if state?
@deserializeTimings.atom = Date.now() - startTime
+ @document.body.appendChild(@views.getView(@titleBar)) if @titleBar
@simurai
simurai May 21, 2016 edited Member

Would it make sense to add the title bar into the atom-panel-container.header with addHeaderPanel().

Then eventually you could do some funky stuff like (visually) combining the title-bar with the tool-bar:

screen shot 2016-05-20 at 5 30 32 pm

Probably not by default, but maybe just restyle it in styles.less or as an option in the tool-bar package.

@brumm
brumm May 21, 2016 Contributor

Yeah, that's exactly what I was wondering as well. It seemed easier for now to stick the title-bar above the atom-workspace, but I was hoping to also support the combined title-bar as well.

I thought the combined titlebar might primarily be hosting the tab-bar, which might be pragmatic for a start, toolbars do sound funky though.

@simurai
simurai May 24, 2016 Member

I thought the combined titlebar might primarily be hosting the tab-bar, which might be pragmatic for a start, toolbars do sound funky though.

Only visually maybe, but tab-bars have to live inside panes. Because they can be split into different directions and each pane as its own tab-bar.

Anyways, I think for now it would be safer to add the title-bar into the .header. Because the changes to workspace-view.less might invite other packages to add their bars or other UI stuff outside of atom-workspace. With the addXXXPanel() all panels can be kept a bit more under control.

@simurai simurai and 1 other commented on an outdated diff May 21, 2016
static/title-bar.less
+ background-image: linear-gradient(@title-bar-gradient-focused);
+ border-bottom: 1px solid @title-bar-border-color-focused;
+
+ .is-blurred & {
+ color: @title-bar-text-blurred;
+ background-image: linear-gradient(@title-bar-gradient-blurred);
+ border-bottom-color: @title-bar-border-color-blurred;
+ }
+
+ [title-bar-style="combined"] & {
+ display: none;
+ position: absolute;
+ }
+}
+
+[title-bar-style="combined"] .tab-bar {
@simurai
simurai May 21, 2016 Member

I guess these [title-bar-style="combined"] styles are meant be used as an option to show/hide the title-bar? Maybe we should wait with it and make a new PR once that dragging fix made it into Atom.

@brumm
brumm May 21, 2016 edited Contributor

Oh dang, these ended up in there by accident. You guessed correctly, I was already working on a compact/combined (hidden and hidden-inset) title-bar.
I'll remove them for now, since the dragging fix you mentioned is blocking any serious attempts at this.

@brumm
Contributor
brumm commented May 21, 2016

I wonder if the background should just be @base-background-color?

That's a much better idea than using the grey gradient! I'll change it.

@brumm
Contributor
brumm commented May 21, 2016

atom-dark with a title-bar gradient based on @base-background-color
image

@FezVrasta

What's the status of this PR? I think the top grey bar is one of the most annoying things of Atom. If I have to use it the whole day I need a pleasant environment, and that gray bar doesn't help at all πŸ˜“

In my opinion, this PR should have high priority.

@olegakbarov
olegakbarov commented May 22, 2016 edited

I just can't stress how awesome and cool this thing looks to me. Would love to see it!

@lee-dohm lee-dohm added needs-testing and removed needs-review labels May 23, 2016
@lee-dohm
Member

Let us know when you have the specs complete for this @brumm πŸ˜€

@simurai simurai commented on an outdated diff May 24, 2016
static/title-bar.less
@@ -0,0 +1,35 @@
+@import "./variables/ui-variables";
+
+.title-bar {
+ height: 23px;
+
+ flex-shrink: 0;
+ display: flex;
+ align-items: center;
+ justify-content: center;
+
+ font-family: -apple-system, BlinkMacSystemFont, "Helvetica Neue";
@simurai
simurai May 24, 2016 Member

Maybe we don't have to force a font-family and just let it inherit whatever the theme defined. The One themes use the system font, but some themes might wanna use something else.

@simurai simurai commented on an outdated diff May 24, 2016
static/title-bar.less
@@ -0,0 +1,35 @@
+@import "./variables/ui-variables";
+
+.title-bar {
+ height: 23px;
+
+ flex-shrink: 0;
+ display: flex;
+ align-items: center;
+ justify-content: center;
+
+ font-family: -apple-system, BlinkMacSystemFont, "Helvetica Neue";
+ font-size: @title-bar-text-size;
+ color: @title-bar-text-focused;
+ -webkit-user-select: none;
@simurai
simurai May 24, 2016 Member

I think it would be good to already add -webkit-app-region: drag;. See http://electron.atom.io/docs/api/frameless-window/#text-selection

Not 100% sure, but otherwise dragging might stop working once that dragging fix lands in Atom.

@simurai simurai commented on an outdated diff May 24, 2016
static/variables/ui-variables.less
@@ -79,6 +79,19 @@
@tab-height: 30px;
+// TitleBar
@simurai
simurai May 24, 2016 Member

Not sure about adding lots of new variables to ui-variables.less. Since this file gets loaded into many packages, we couldn't make any changes to it later. It's a bit like a public API. For now, or at least till we settle on the "combined" option, might be safer to just keep everything inside title-bar.less.

Another idea would be to use @tab-bar-background-color;. Since the tab-bar is just underneath, it should match most of the time? And maybe just flat without a gradient. Usually the core styles only style layout and sizing, but don't have much of an opinion on gradients, shadows etc. Maybe something like

.title-bar {
  color: @text-color;
  background-color: @tab-bar-background-color;
  border-bottom: 1px solid @tab-bar-border-color;

  .is-blurred & {
    color: @text-color-subtle;
  }
}

Then themes that don't like it, can override it with their own styles.

@simurai
Member
simurai commented May 24, 2016

Made a few more comments.. sorry.. πŸ˜‡ I tried to make a PR to your PR, but your fork somehow didn't show up in the list to compare against.

@brumm
Contributor
brumm commented May 24, 2016

Thanks for the comments! All good points. I'll be able to work on this in a few hours πŸ‘

@brumm
Contributor
brumm commented May 25, 2016

@simurai i made a couple of changes:

  • followed your advice and added title-bar as a headerPanel instead, which allowed me to undo the changes I made to workspace styling
  • moved title-bar variables into title-bars' less file and simplified the styling to a single background-color: @base-background-color. After much back-and-forth I decided against @tab-bar-background-color to preserve some contrast between title-bar and the rest of the UI, but I do like both.
  • cleaned up some superfluous code from title-bar-element and added a simple test
@FezVrasta
FezVrasta commented May 25, 2016 edited

I'm for @tab-bar-background-color, it would look much better

@brumm
Contributor
brumm commented May 25, 2016

@tab-bar-background-color
image

@base-background-color
image

@brumm
Contributor
brumm commented May 25, 2016

As far as I can tell, the failed travis build doesn't seem to be related to my changes.
Should I squash now or after another once-over?
@lee-dohm @simurai

@simurai
Member
simurai commented May 26, 2016

After much back-and-forth I decided against @tab-bar-background-color to preserve some contrast between title-bar and the rest of the UI, but I do like both.

Yeah, sounds good. For the bundled One + Atom themes, we can still thinking about customizing it. Also having a border by default should help make it clear where you can start dragging the window.

@FezVrasta In case your favorite theme doesn't look seamless, you could always make it transparent in your styles.less with:

.title-bar {
  background-color: transparent;
  border-color: transparent;
}

Should I squash now or after another once-over?

Only if you want, so far we haven't really bothered about it. Maybe one day we will enable it on the merge button, now that GitHub added that feature.

As far as I can tell, the failed travis build doesn't seem to be related to my changes.

Ya, looks like an unlreated timeout.

@simurai
Member
simurai commented May 26, 2016

ok, so the styling is πŸ‘

So hopefully we can get somebody from @atom/core to take a look at the code. And maybe @amytruong can give it another test drive?

@BinaryMuse BinaryMuse and 1 other commented on an outdated diff May 26, 2016
src/main-process/atom-window.coffee
@@ -23,6 +23,7 @@ class AtomWindow
options =
show: false
title: 'Atom'
+ titleBarStyle: 'hidden'
@BinaryMuse
BinaryMuse May 26, 2016 Member

Is there any chance of this ever doing something on platforms other than OS X? If so, I think it'd be nice to specifically check for the platform here, since we're also explicitly checking it in atom-environment, and we don't want it to accidentally get out of sync.

@brumm
brumm May 27, 2016 edited Contributor

I changed it to check for darwin as well, thanks for the heads up!

@BinaryMuse
Member

I love this! Other than my above comment, I say it's ready for πŸš€ !

@brumm
Contributor
brumm commented May 27, 2016

Thanks for the reviews and comments, everyone! :shipit:

@lee-dohm
Member

So, one thing that this doesn't appear to offer is the title bar icon:

screen_shot_2016-05-27_at_9_48_33_am

This would appear to be a regression. We would either need to maintain this functionality or come up with a way to enable/disable the feature. Both are pretty complex since we don't currently have a system for either having configuration options specific to a platform or restarting when a configuration option is changed.

Is this something that you would be able to cover @brumm?

@brumm
Contributor
brumm commented May 27, 2016 edited

Hah, I knew I was missing something ;)

I'd hazard a guess that while it would be possible to approximate the proxy icon, it'd be hard/impossible to really get right (a cursory google search suggests that getting a file icon from node is not a solved problem, for instance).

I'd be happy to work on providing a settings interface for this feature, which is something I wanted to do in a later PR anyway.

That would mean extending the config-schema with a way to

  • Define a platform for the setting
  • Indicating that this setting will need a restart/reopened window.
    We could probably get away with just mentioning the fact inside the setting description, and then reacting to a setting change with a dialog.

Maybe like this:

customTitleBar:
  platform: 'darwin' # 'darwin', 'freebsd', 'linux', 'sunos' or 'win32'
  type: 'boolean'
  default: false
  description: 'Use custom window and theme-aware title-bar. Note: This currently does not include a file icon or title context menu.<br />This setting will require a restart to take effect.'

If 'polluting' the config namespace is a concern, we could abstract these two new use cases for the config schema to mean

  • Setting visibility/applicability
  • Setting side effects
customTitleBar:
  show: { platform: 'darwin' }
  sideEffect: ['restart-app']
  type: 'boolean'
  default: false
  description: 'Use custom window and theme-aware title-bar. Note: This currently does not include a file icon or title context menu.'
@FezVrasta

What's the purpose of such icon?

@brumm
Contributor
brumm commented May 27, 2016

It's a representation (or in osx terms, proxy) of the currently opened file. Click-holding the icon allows you to drag the file out of the title bar to move/copy/alias it.
The title bar also provides a context menu of the currently opened file's parent directories on right-click.

On 27 May 2016, at 18:36, Fez Vrasta notifications@github.com wrote:

What's the purpose of such icon?

β€”
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

@FezVrasta

It's a bit tricky, but couldn't Electron provide the proxy icon directly from the OS X API like it does for the window control buttons?
Probably it would be difficult/impossible to position the icon on the left of the text, but you could just put in on the right corner maybe.

@thomasjo
Member

@zcbenz Do you think it would be feasibly (aka not too much work) to add an API for this in Electron? And by this, I mean an API that will allow us to basically re-implement the "proxy icon" functionality. We'd ideally need access to the icon somehow, as well as being able to trigger (and position) the menu.

@simurai
Member
simurai commented May 31, 2016

I can imagine positioning the native proxy icon would be pretty hard. Adding a config option, as proposed in ☝️ #11790 (comment) feels more realistic. Then people can choose to use the native title bar with all its functionality or use the simple, but customizable one.

Maybe depends if platform specific configs would be beneficial for other things too? Or added just for this use-case?

@brumm
Contributor
brumm commented May 31, 2016

Maybe depends if platform specific configs would be beneficial for other things too? Or added just for this use-case?

That's what I was wondering :)

I'll start with the simple platform version and see what others like @lee-dohm might say in the meantime.

@brumm
Contributor
brumm commented Jun 28, 2016

Right, finally got around to actually doing this.
There are some wording problems in promptForRelaunch, since we're not actually relaunching Atom, for which I'll happily accept better phrasing.

@lee-dohm
Member

I'm running into the same error message as the CI, badges.less isn't found.

@brumm
Contributor
brumm commented Jun 29, 2016

Ah, seems like a bad rebase conflict resolution. Weird that the build script did not complain about this...

@brumm
Contributor
brumm commented Jun 30, 2016

Looks like the cursor blink spec timed out, travis looks okay otherwise

@simurai
Member
simurai commented Jul 2, 2016 edited

Tried it out and works!!! πŸ‘

There are some wording problems in promptForRelaunch, since we're not actually relaunching Atom, for which I'll happily accept better phrasing.

Should the button say "Quit Atom"? I feel like the word "Relaunch" suggests that it will quit AND re-open Atom automatically.

title-bar

@simurai simurai and 1 other commented on an outdated diff Jul 2, 2016
static/workspace-view.less
@@ -1,4 +1,19 @@
@import "ui-variables";
+@import "octicon-mixins";
@simurai
simurai Jul 2, 2016 Member

Do you mind removing all these additions in this file?

Sorry, there has been some major reshuffling of the core styles and all these styles are now in scaffolding.less

It's probably also part of the:

seems like a bad rebase conflict resolution.

@brumm
brumm Jul 2, 2016 Contributor

Ah yes, absoutely πŸ‘

@brumm
Contributor
brumm commented Jul 2, 2016

Should the button say "Quit Atom"? I feel like the word "Relaunch" suggests that it will quit AND re-open Atom automatically.

Thanks, I changed it to

{
  message: "You will need to relaunch Atom for this change to take effect."
  buttons: ['Quit Atom', 'Cancel']
}

We'll be able to actually relaunch Atom once we're using electron 1.2.2

Philipp Brumm added some commits Jul 2, 2016
Philipp Brumm change dialog wording
6370db9
Philipp Brumm `setSheetOffset` to height of titlebar
29dab2e
Philipp Brumm hide titlebar in fullscreen mode
bda08c4
Philipp Brumm animate appearance and disappearance of titlebar when toggling fullsc…
…reen
3e53a03
Philipp Brumm fix `fullscreen` class on body not being set when toggling fullscreen…
… via window button

- move handling code to `window-event-handler`
91102cf
@brumm
Contributor
brumm commented Jul 2, 2016

Made sure that we set a sheet offset when using the custom titlebar:

image

@controversial

Is this almost ready to merge? If so, that'd be great; I can't wait to have this.

I also think that @tab-bar-background-color looks better, fwiw, so I hope that will be configurable.

Overall, great work πŸ‘

@brumm
Contributor
brumm commented Jul 2, 2016 edited

@simurai Hey, it'd be great if you could take a look at 3e53a03.

I decided to transition this instead of a hard display: none because the change doesn't happen until after the fullscreen animation finishes on OSX and is kind of abrupt.

@brumm
Contributor
brumm commented Jul 3, 2016

I found a weird bug: If .tree-view-directory is overflowing .tree-view, toggling treeview visibility causes <atom-workspace> to scroll down by at least the height occluded and at most the height of the titlebar, effectively hiding the titlebar.

As far as I can tell, this is not caused by programmatically setting scrollTop of <atom-workspace>.

Screencast: http://i.imgur.com/hG6Zl2Z.gifv

@hultberg
hultberg commented Jul 3, 2016

@brumm Can confirm this. I observed this behaviour when building atom with @paulcbetts PR on this same feature (#10208).

@lee-dohm
Member
lee-dohm commented Jul 5, 2016

Note: This currently does not include a file icon

This should read "Note: This currently does not include a proxy icon"

@simurai simurai and 1 other commented on an outdated diff Jul 6, 2016
static/title-bar.less
}
.title-bar {
- height: 23px;
+ height: @title-bar-height;
+ transition: margin-top 200ms ease-out 700ms;
@simurai
simurai Jul 6, 2016 Member

Ya, too bad the .fullscreen styles stay until after the "fullscreen animation" finishes.

How do you like just

transition: margin-top 160ms;

A bit shorter, default easing and no delay. That way the animation maybe still feels part of the fullscreen animation and doesn't call for too much attention.

@brumm
brumm Jul 6, 2016 Contributor

Yeah, I changed it as per your suggestion. 160ms is a tad on the short side, but it helps selling the part-of-fullscreen-animation feeling like you said.

@simurai
Member
simurai commented Jul 6, 2016

@brumm I found a weird bug

That feels like a deja-vu.. do you have the color-picker package installed? It looks like it's the same issue that tool-bar also has. A fix got merged, but I think it didn't get published yet?

Philipp Brumm added some commits Jul 6, 2016
Philipp Brumm adjust wording e65ccde
Philipp Brumm shorter and linear transition, without delay
e7ff266
@brumm brumm referenced this pull request in thomaslindstrom/color-picker Jul 6, 2016
Closed

Publish new version with 'Fix compatibilty with Tool Bar package' #188

@brumm
Contributor
brumm commented Jul 6, 2016

Thanks @simurai! This was indeed the problem. I opened a new issue and asked @thomaslindstrom to release a new version which includes the fix.

@thomaslindstrom

@simurai @brumm Sorry, I thought I'd done this already. It's out in 2.2.0!

Philipp Brumm added some commits Jul 6, 2016
Philipp Brumm check for `on` method
during `window-event-handler-spec`, `applicationDelegate.getCurrentWindow`
seems to return a truncated version of a browserWindow object, which does not include the `on` method
974995f
Philipp Brumm remove leftover console.log a9d554f
Philipp Brumm move title bar setting check into method and check for isSpec as well
08a3582
@thomaslindstrom

@simurai @brumm Just a quick update: v2.2.0 including the fix for this issue broke color-picker completely. I've published v2.2.1 that reverts the fix, but that means that this issue is still present.

@lee-dohm lee-dohm and 1 other commented on an outdated diff Jul 12, 2016
src/main-process/atom-window.coffee
@browserWindow = new BrowserWindow options
global.atomApplication.addWindow(this)
+ if @applyTitleBarSetting()
+ @browserWindow.setSheetOffset(23)
@lee-dohm
lee-dohm Jul 12, 2016 Member

This hard-coded value makes me nervous. If I change the height for the title bar, this will be off. Is there a way to calculate this and update it?

@brumm
brumm Jul 13, 2016 Contributor

Hey, good call. I think we might be able to read offsetHeight after the title bar has been rendered to account for CSS-induced height changes

@brumm
brumm Jul 13, 2016 Contributor

Fixed in 7635747

Philipp Brumm call `setSheetOffset` on `onDidChangeActiveThemes`
7635747
@hultberg
hultberg commented Aug 1, 2016

Whats the latest here?

@onbjerg
onbjerg commented Aug 2, 2016

Looking forward to this

@nathansobo nathansobo merged commit 7635747 into atom:master Aug 2, 2016

1 of 2 checks passed

continuous-integration/travis-ci/pr The Travis CI build failed
Details
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
@nathansobo
Contributor

Ugh, sorry, I was trying to push a branch based on this to to atom/atom and accidentally pushed to master. I'm making some adjustments and working toward merging this, but it's not there yet.

@nathansobo
Contributor

✨ Thanks @brumm for putting this together. I'm already enjoying the more stylish title bar in my dev environment. This should go out with Atom 1.11.0-beta0 in the next release cycle. ⚑

@onbjerg
onbjerg commented Aug 2, 2016

Now to wait for theme support once this is released 😁

@silvestreh

@onbjerg Material UI already supports it πŸ˜„

captura de pantalla 2016-08-03 a las 1 21 04 a m

@brumm
Contributor
brumm commented Aug 3, 2016 edited

Thanks you so much @nathansobo for picking this up! I'm stoked to see this get merged πŸŽ‰

@maxwellzdeamon

I'm trying to implement this work in my beta (1.10.0-beta1). When I add the below snippet to my style.less and save, restart atom, nothing happens. Is what I'm doing supposed to work?

Thanks!!

.theme-one-dark-ui {
.tree-view::before,
.tab-bar:before,
.tab.active:before {
display: none;
}
}

@nathansobo
Contributor

@maxwellzdeamon This won't land until 1.11.0, so you'll have to build from source until then if you want it.

@FezVrasta
FezVrasta commented Aug 22, 2016 edited

@brumm is there any way to change the position of the window controls using CSS?

Also, it would be extremely useful to have a way to define custom draggable areas instead of having the top of the window draggable without any configuration. This would allow us to define a custom shape and make easier the work on #10208

@brumm
Contributor
brumm commented Aug 22, 2016 edited

@FezVrasta The window controls are drawn by the OS and positions can't be changed indivdually.
You might get some milage out of changing titleBarStyle to hidden-inset which moves the controls a bit further down, but also increases the size of the title bar.

I always figured that we'd have to completely hide the titlebar to support the 'tabs-on-top' style proposed in #10208, and dynamically switch draggable areas on and off with css.

That's what I came up with the other day:

screen shot 2016-07-11 at 18 12 38

Edit: this stuff is not feasible yet because it needs this fix electron/electron#5557 which is available from electron@v1.1.1 and up

@FezVrasta
FezVrasta commented Aug 22, 2016 edited

Thanks for the reply. If it can be helpful I posted my custom CSS at #10208 (comment)

@paulcbetts
Contributor

@brumm We came up with that design too - it looks great but the problem is that objects in the non-client area (i.e. the invisible bar from the traffic lights onward) cannot be dragged, so reordering tabs is busted 😒

@controversial

Couldn't we hide the title bar altogether, and create fake window buttons with CSS, as shown here? @paulcbetts @brumm

@silvestreh

@controversial In Atom's case, window buttons are rendered by the OS and can't be changed.

@controversial

@silvestreh Why couldn't that be changed? This is a PR to the atom core...

@silvestreh

@controversial This is what the titlebar's DOM element looks like:

captura de pantalla 2016-09-02 a las 11 12 50 a m

As you can see, the buttons aren't part of the DOM. You can't style them with CSS because the window manager, not Chrome, is rendering them.

AFAIK, you can't move, resize, nor hide them.

@controversial

You can spawn a frameless window, which would hide the title bar completely, then you could emulate the buttons using custom CSS. https://github.com/electron/electron/blob/master/docs/api/frameless-window.md

Maybe this isn't available in the version of Electron atom is on though.

@thomasjo
Member
thomasjo commented Sep 2, 2016

Maybe this isn't available in the version of Electron atom is on though.

This does indeed require a more modern Electron. We're very close to shipping #12300 though πŸŽ‰

@controversial

Ah, great. I'll look forward to #12300 πŸ˜ƒ

@sveggiani

@controversial I think it's not a good practice to replace native OS UI controls. They are a hell to maintain and avoids OS level customization and third party software control over them.

@controversial

Yeah, you're probably right. Waiting for the newer Electron version will be a much better choice.

@keplersj
keplersj commented Oct 10, 2016 edited

I love this addition so much! I'm just trying it out right now but I've noticed a little bit of extra black under the bar with Nuclide. Not sure if this an Atom issue or a Nuclide issue.
screen shot 2016-10-10 at 12 17 00 pm
Not a huge issue, just thought it was worth noting.

Edit: I think it's definitely a Nuclide issue, the Buck task bar makes the black bar super apparent.
screen shot 2016-10-10 at 12 23 57 pm

Edit: Definitely Nuclide
screen shot 2016-10-10 at 12 29 23 pm

@abraham abraham referenced this pull request in atom-material/atom-material-ui Oct 12, 2016
Closed

Color new Mac custom title-bar to match tab bar color #334

@Daniel15

Any plans to have something like this for other operating systems, given 57% of the Atom userbase is on Linux or Windows? πŸ˜„

You can spawn a frameless window, which would hide the title bar completely, then you could emulate the buttons using custom CSS

I agree with @sveggiani... Emulating native OS controls is tricky and very difficult to maintain. It's better to use the native APIs to render the native controls (for example, I believe the title bar of Google Chrome does it this way). This used to be reasonably common with native apps on Windows, I don't know if Electron exposes this functionality though.

@controversial

@Daniel15 Electron does expose this, but only in a version of Electron that's later than the one Atom uses. I think a fake control would be good for the short term, using the native controls once we get to that version of Electron.

@controversial

Now that Atom is on a modern Electron version can we do this? I really like @brumm's solution, even though the tabs can't be reordered. Hyper does this and the tabs aren't reorderable, but it never really bothers me. If this was an option that could be enabled by users, I think it'd be great to include some kind of solution in the Atom core.

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