-
Notifications
You must be signed in to change notification settings - Fork 15.8k
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
Comments
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). |
One difference is that brackets-shell uses CEF rather than Chromium. For more information and expertise on that topic, maybe @JeffryBooher could chime in? |
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) |
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 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());
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. |
@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. |
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. |
Maybe I misunderstood what you were looking for. You can turn on HTML menus in Brackets with just a switch. |
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") |
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. |
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. |
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. |
Adding support for native dark window chrome sounds good to me, but I think no one has time to port it for now. |
Out of curiosity, which steps are required for adding support for native dark window chrome? |
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: 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. |
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. |
Interested in this too. Perhaps just creating them yourself as opposed to a native fix would be faster. |
in #6250 it was brought up that windows 10 has an api for setting the window frame colours.. |
@lukeapage afaik this only will work if you have a UWP (Universal App) CoreWindow, whereas Electron has a Win32 Desktop window |
ah makes sense. Was just copying the comment over so #6250 can be closed without loss of information. |
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 |
I would appreciate if there was a css customizable menu option for electron. |
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 |
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
The text was updated successfully, but these errors were encountered: