Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for dark window chrome #1582

Closed
marcelgerber opened this issue May 5, 2015 · 24 comments
Closed

Support for dark window chrome #1582

marcelgerber opened this issue May 5, 2015 · 24 comments

Comments

@marcelgerber
Copy link

We're currently working on switching Brackets over to Electron (fork, Google Groups thread).
It's making steady progress, Electron is great and fits our needs very well, but one issue we face is that, while our old shell featured a dark UI (see screenshots: Mac, Win), we cannot implement that in Electron without creating a fork.

Thus, I'd like to ask if it would be possible to make Chrome Themes work in Electron, which could be (we're not sure yet) an easy solution to our problem?

cc @zaggino @ryanstewart

@anaisbetts
Copy link
Contributor

That's crazy hard. How does brackets do it? Do they just draw all menus themselves? Supporting Chrome Themes will not be any easier than other approaches to solve this problem. The easiest thing to do is to probably use a Frameless window and implement the menus and the window controls yourself based on the platform (but even that is going to be a real pain).

@marcelgerber
Copy link
Author

One difference is that brackets-shell uses CEF rather than Chromium.
Yeah, menus are drawn by our own shell (via native APIs), but I don't actually know much more about the shell side of things.

For more information and expertise on that topic, maybe @JeffryBooher could chime in?

@max-mapper
Copy link
Contributor

in playback we use a frameless window and implement UI in CSS

someone even extracted the titlebar code we wrote and put it into a standalone module https://github.com/kapetan/titlebar (demo)

@anaisbetts
Copy link
Contributor

@maxogden @kapetan Nice, you even got Alt-click the zoom button right, 👏

@JeffryBooher
Copy link

This is just based on just looking at the code but here are some suggestions of what to try. I haven't tried them so you're on your own.

Brackets doesn't rely on any 3rd party code for its dark shell implementation. Electron implements its native windowing using aura and then has some platform specific and non-platform specific code to manage those windows, their creation and styling in the code found in https://github.com/atom/electron/tree/browser/. I presume you could fork Electron and
handle this natively similarly to the way Brackets handles it (there isn't a "node" way to do it which is what I had originally thought)

For Windows you could try adding the code which handles native window drawing (cef_window, cef_dark_window, cef_host_window, etc...) into your fork and subclassing the native window in https://github.com/atom/electron/blob/master/atom/browser/native_window_views.cc with code similar to:

      cef_popup_window *w = new cef_popup_window();  // gets destroyed in cef_popup_window::PostNcDestroy
      w->SubclassWindow(GetAcceleratedWidget());

NativeWindowViews::NativeWindowViews is where wIndow styles are applied to the window on Windows so this would be a good place to try hacking the code.

Our cef_window code is built in layers so we could turn features on and off as needed which is why there are so many classes and preprocessor flags but it relies very little on cef and don't make much use of cef directly so electron should slip right in. The top level classes in the hierarchy will depend on cef to some degree but I think those dependencies could just be removed or made to work with atom... There are the png resources for the buttons that you'll need to bring in and the window title that you may need to figure out as well. Hopefully WM_SETTEXT works in that case.

For Mac you would need to copy our cocoa UI Builder xml files into the atom project and add them to the project then modify https://github.com/atom/electron/blob/master/atom/browser/native_window_mac.mm directly to support the dark ui much the way we did in client_handler_mac.mm then bring over TrafficLights_, CustomView_ and FullScreen* into the project.

@anaisbetts
Copy link
Contributor

@JeffryBooher I feel like you jumped to "custom fork with custom native rendering code" pretty quickly here, which would certainly work but would be unfortunate compared to staying on shipped Electron and trying to improve Electron together.

Like, even if menus in HTML/CSS are hard and you had to put a lot of work into getting the details right, I bet it's still an order of magnitude easier than what you're suggesting, where you owner draw the world on three platforms.

@zaggino
Copy link

zaggino commented May 5, 2015

Yes, let's definitely stay focused on being able to ship non-forked Electron - for me as a developer the custom titlebar is a nice thing to have but not that much I'd want to maintain a fork and deal with fork-specific issues.

@JeffryBooher
Copy link

Maybe I misunderstood what you were looking for.

You can turn on HTML menus in Brackets with just a switch.

@anaisbetts
Copy link
Contributor

Perfect! So basically, with the Frameless window support, you just get a blank window (no titlebar, no frame, etc), and you can control which parts of the window are draggable (i.e. what in Windows terms would be the "Non-client area")

@JeffryBooher
Copy link

The Native GitHub app (which used the Atom Shell) had no window chrome but I'm not sure where or how it was implemented. There may be a command line switch in Electron to turn off the window chrome but i didn't dig to deep. There is a command-switch to turn on "Dark UI' (which looked like was only be implemented for the Linux code path) so there may be a switch that will turn off the native window chrome as well.

If you can turn off the native window chrome and do, however, you'll have to implement those features in Brackets somewhere or you lose some basic window functionality like minimize, maximize and drag. Brackets only implements HTML menus.

Electron may not give you the option to turn off the native window chrome, however, so you may just be stuck with the native chrome.

@anaisbetts
Copy link
Contributor

Electron may not give you the option to turn off the native window chrome, however, so you may just be stuck with the native chrome.

This is what I'm talking about with Frameless window support. Check out https://github.com/atom/electron/blob/master/docs/api/frameless-window.md. You don't have to implement drag, but you do have to implement wiring up the window buttons to call methods on the Window, but that's pretty easy.

@JeffryBooher
Copy link

We can put those buttons on the Brackets HTML Menu Bar. Someone should tweak the HTML and move the menu bar to the top of the Window, though. I think right now it only occupies the space above the editor. Also you want to detect which platform you're on so that you can have native looking UI images for each platform and place them on the correct side of the window. That means making images for Linux.

One thing to note -- you may want different traffic lights for Yosemite so that it looks like a Yosemite app. When Yosemite came out we had to back-pedal a bit on the traffic lights because designers wanted it should look like Yosemite when running on Yosemite.

@zcbenz zcbenz changed the title Support for Chrome Themes? Support for dark window chrome May 7, 2015
@zcbenz
Copy link
Contributor

zcbenz commented May 7, 2015

Adding support for native dark window chrome sounds good to me, but I think no one has time to port it for now.

@ficristo
Copy link

Out of curiosity, which steps are required for adding support for native dark window chrome?

@jasmussen
Copy link

Probably in relation to this issue, it would be nice if it was possible, on Windows 10, to have a white background to the file menu, like Notepad has:

white-file-menu

By default the file menu gets a slate gray color.

Attaching to this issue as I get the vibe that the solutions to dark window Chrome and white file menus require similar fixes.

@montanaflynn
Copy link

I would also love a dark window chrome theme, I especially like the aesthetic of FirefoxDeveloperEdition:

screen shot 2015-12-17 at 4 55 50 pm

@rafaelcastrocouto
Copy link

Trying to get this working in electron ... https://github.com/mauricecruz/chrome-devtools-zerodarkmatrix-theme but the input 'Devtools' > 'Settings' > 'Experiments > [x] 'Allow custom UI themes' don't work.

@mscreenie
Copy link

Interested in this too. Perhaps just creating them yourself as opposed to a native fix would be faster.

@lukeapage
Copy link
Contributor

in #6250 it was brought up that windows 10 has an api for setting the window frame colours..
https://msdn.microsoft.com/library/windows/apps/windows.ui.viewmanagement.applicationviewtitlebar.aspx?cs-save-lang=1&cs-lang=cpp#code-snippet-1

@anaisbetts
Copy link
Contributor

@lukeapage afaik this only will work if you have a UWP (Universal App) CoreWindow, whereas Electron has a Win32 Desktop window

@lukeapage
Copy link
Contributor

ah makes sense. Was just copying the comment over so #6250 can be closed without loss of information.

@FezVrasta
Copy link

FezVrasta commented Jul 27, 2016

On Atom they are just implementing a custom title bar in HTML/CSS, It's not the best way because you lose some functionalities like the proxy icon on Mac, but it's better than having a grey bar on a black app..

I think they have a way to switch between the native title bar and the custom one also.

Related PR: atom/atom#11790

@Johnz86
Copy link

Johnz86 commented Jan 4, 2017

I would appreciate if there was a css customizable menu option for electron.
If there was a html/css application Menu build in electron as option it would be nice.
Does anybody know about some node module, which handles this?

@stale stale bot added the wontfix label Mar 15, 2017
@zeke zeke removed wontfix labels Mar 15, 2017
@codebytere
Copy link
Member

Given that this isn't currently something very tenable in a cross-platform way and that this isn't currently on our roadmap, i'm going to go ahead and label this a wontfix. However, should someone determine a workable solution we would be very open to accepting a PR!

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

No branches or pull requests