cef/libcef/browser/views/view_util_aura.cc

139 lines
4.5 KiB
C++
Raw Normal View History

// Copyright 2016 The Chromium Embedded Framework Authors. All rights reserved.
// Use of this source code is governed by a BSD-style license that can be found
// in the LICENSE file.
#include "cef/libcef/browser/views/view_util.h"
#include "ui/aura/window.h"
#include "ui/aura/window_tree_host.h"
#include "ui/views/view_constants_aura.h"
#include "ui/views/widget/native_widget.h"
#include "ui/views/widget/native_widget_delegate.h"
#include "ui/views/widget/widget.h"
views: Add support for OS and Chrome themes (fixes #3610, fixes #3671) Controls now respect OS and Chrome themes by default for both Alloy and Chrome runtimes. Chrome themes (mode and colors) can be configured using the new CefRequestContext::SetChromeColorScheme method. Individual theme colors can be overridden using the new CefWindowDelegate:: OnThemeColorsChanged and CefWindow::SetThemeColor methods. The `--force-light-mode` and `--force-dark-mode` command-line flags are now respected on all platforms as an override for the OS theme. The current Chrome theme, if any, will take precedence over the OS theme when determining light/dark status. On Windows and MacOS the titlebar color will also be updated to match the light/dark theme. Testable as follows: - Run: `cefclient --enable-chrome-runtime` OR `cefclient --use-views --persist-user-preferences --cache-path=...` - App launches with default OS light/dark theme colors. - Change OS dark/light theme under system settings. Notice that theme colors change as expected. - Right click, select items from the new Theme sub-menu. Notice that theme colors behave as expected. - Exit and relaunch the app. Notice that the last-used theme colors are applied on app restart. - Add `--background-color=green` to above command-line. - Perform the same actions as above. Notice that all controls start and remain green throughout (except some icons with Chrome runtime). - Add `--force-light-mode` or `--force-dark-mode` to above command-line. - Perform the same actions as above. Notice that OS dark/light theme changes are ignored, but Chrome theme changes work as expected.
2024-03-29 17:48:33 +01:00
#if BUILDFLAG(IS_WIN)
#include <dwmapi.h>
#include "base/win/windows_version.h"
#include "ui/views/win/hwnd_util.h"
#endif
namespace view_util {
gfx::NativeWindow GetNativeWindow(views::Widget* widget) {
if (widget) {
views: Add support for modal browser dialogs A modal dialog is a child CefWindow that implements some special behaviors relative to a parent CefWindow. Like any CefWindow it can be framed with titlebar or frameless, and optionally contain draggable regions (subject to platform limitations described below). Modal dialogs are shown centered on the parent window (inside a single display) and always stay on top of the parent window in z-order. Sizing behavior and available window buttons are controlled via the usual CefWindowDelegate callbacks. For example, the dialog can have a preferred size with resize, minimize and maximize disabled (via GetPreferredSize, CanResize, CanMinimize and CanMaximize respectively). This change adds support for two modality modes. With window modality all controls in the parent window are disabled. With browser modality only the browser view in the parent window is disabled. Both modality modes require that a valid parent window be returned via GetParentWindow. For window modality return true from IsWindowModalDialog and call CefWindow::Show. For browser modality return false from IsWindowModalDialog (the default value) and call CefWindow::ShowAsBrowserModalDialog with a reference to the parent window's browser view. Window modal dialog behavior depends on the platform. On Windows and Linux these dialogs have a titlebar and can be moved independent of the parent window. On macOS these dialogs do not have a titlebar, move with the parent window, and do not support draggable regions (because they are implemented using sheets). On Linux disabling the parent window controls requires a window manager the supports _NET_WM_STATE_MODAL. Browser modal dialog behavior is similar on all platforms. The dialog will be automatically sized and positioned relative to the parent window's browser view. Closing the parent window or navigating the parent browser view will dismiss the dialog. The dialog can also be moved independent of the parent window though it will be recentered when the parent window itself is resized or redisplayed. On MacOS the dialog will move along with the parent window while on Windows and Linux the parent window can be moved independently. To test: Use the Tests > Dialog Window menu option in cefclient with Views enabled (`--use-views` or `--enable-chrome-runtime` command-line flag). Browser modal dialog is the default behavior. For window modal dialog add the `--use-window-modal-dialog` command-line flag.
2023-06-14 10:20:02 +02:00
return widget->GetNativeWindow();
}
return nullptr;
}
gfx::NativeView GetNativeView(views::Widget* widget) {
views: Add support for modal browser dialogs A modal dialog is a child CefWindow that implements some special behaviors relative to a parent CefWindow. Like any CefWindow it can be framed with titlebar or frameless, and optionally contain draggable regions (subject to platform limitations described below). Modal dialogs are shown centered on the parent window (inside a single display) and always stay on top of the parent window in z-order. Sizing behavior and available window buttons are controlled via the usual CefWindowDelegate callbacks. For example, the dialog can have a preferred size with resize, minimize and maximize disabled (via GetPreferredSize, CanResize, CanMinimize and CanMaximize respectively). This change adds support for two modality modes. With window modality all controls in the parent window are disabled. With browser modality only the browser view in the parent window is disabled. Both modality modes require that a valid parent window be returned via GetParentWindow. For window modality return true from IsWindowModalDialog and call CefWindow::Show. For browser modality return false from IsWindowModalDialog (the default value) and call CefWindow::ShowAsBrowserModalDialog with a reference to the parent window's browser view. Window modal dialog behavior depends on the platform. On Windows and Linux these dialogs have a titlebar and can be moved independent of the parent window. On macOS these dialogs do not have a titlebar, move with the parent window, and do not support draggable regions (because they are implemented using sheets). On Linux disabling the parent window controls requires a window manager the supports _NET_WM_STATE_MODAL. Browser modal dialog behavior is similar on all platforms. The dialog will be automatically sized and positioned relative to the parent window's browser view. Closing the parent window or navigating the parent browser view will dismiss the dialog. The dialog can also be moved independent of the parent window though it will be recentered when the parent window itself is resized or redisplayed. On MacOS the dialog will move along with the parent window while on Windows and Linux the parent window can be moved independently. To test: Use the Tests > Dialog Window menu option in cefclient with Views enabled (`--use-views` or `--enable-chrome-runtime` command-line flag). Browser modal dialog is the default behavior. For window modal dialog add the `--use-window-modal-dialog` command-line flag.
2023-06-14 10:20:02 +02:00
if (widget) {
return widget->GetNativeView();
}
return nullptr;
}
CefWindowHandle GetWindowHandle(views::Widget* widget) {
// Same implementation as views::HWNDForView() but cross-platform.
if (widget) {
return GetWindowHandle(widget->GetNativeWindow());
}
return kNullWindowHandle;
}
CefWindowHandle GetWindowHandle(gfx::NativeWindow window) {
// |window| is an aura::Window*.
if (window && window->GetRootWindow()) {
return window->GetHost()->GetAcceleratedWidget();
}
return kNullWindowHandle;
}
views::NativeWidget* CreateNativeWidget(
views::internal::NativeWidgetDelegate* delegate,
CefRefPtr<CefWindow> window,
CefWindowDelegate* window_delegate) {
return nullptr;
}
void SetHostView(views::Widget* widget, views::View* host_view) {
widget->GetNativeView()->SetProperty(views::kHostViewKey, host_view);
}
views: Add support for OS and Chrome themes (fixes #3610, fixes #3671) Controls now respect OS and Chrome themes by default for both Alloy and Chrome runtimes. Chrome themes (mode and colors) can be configured using the new CefRequestContext::SetChromeColorScheme method. Individual theme colors can be overridden using the new CefWindowDelegate:: OnThemeColorsChanged and CefWindow::SetThemeColor methods. The `--force-light-mode` and `--force-dark-mode` command-line flags are now respected on all platforms as an override for the OS theme. The current Chrome theme, if any, will take precedence over the OS theme when determining light/dark status. On Windows and MacOS the titlebar color will also be updated to match the light/dark theme. Testable as follows: - Run: `cefclient --enable-chrome-runtime` OR `cefclient --use-views --persist-user-preferences --cache-path=...` - App launches with default OS light/dark theme colors. - Change OS dark/light theme under system settings. Notice that theme colors change as expected. - Right click, select items from the new Theme sub-menu. Notice that theme colors behave as expected. - Exit and relaunch the app. Notice that the last-used theme colors are applied on app restart. - Add `--background-color=green` to above command-line. - Perform the same actions as above. Notice that all controls start and remain green throughout (except some icons with Chrome runtime). - Add `--force-light-mode` or `--force-dark-mode` to above command-line. - Perform the same actions as above. Notice that OS dark/light theme changes are ignored, but Chrome theme changes work as expected.
2024-03-29 17:48:33 +01:00
views::View* GetHostView(const views::Widget* widget) {
return widget->GetNativeView()->GetProperty(views::kHostViewKey);
}
views: Add support for OS and Chrome themes (fixes #3610, fixes #3671) Controls now respect OS and Chrome themes by default for both Alloy and Chrome runtimes. Chrome themes (mode and colors) can be configured using the new CefRequestContext::SetChromeColorScheme method. Individual theme colors can be overridden using the new CefWindowDelegate:: OnThemeColorsChanged and CefWindow::SetThemeColor methods. The `--force-light-mode` and `--force-dark-mode` command-line flags are now respected on all platforms as an override for the OS theme. The current Chrome theme, if any, will take precedence over the OS theme when determining light/dark status. On Windows and MacOS the titlebar color will also be updated to match the light/dark theme. Testable as follows: - Run: `cefclient --enable-chrome-runtime` OR `cefclient --use-views --persist-user-preferences --cache-path=...` - App launches with default OS light/dark theme colors. - Change OS dark/light theme under system settings. Notice that theme colors change as expected. - Right click, select items from the new Theme sub-menu. Notice that theme colors behave as expected. - Exit and relaunch the app. Notice that the last-used theme colors are applied on app restart. - Add `--background-color=green` to above command-line. - Perform the same actions as above. Notice that all controls start and remain green throughout (except some icons with Chrome runtime). - Add `--force-light-mode` or `--force-dark-mode` to above command-line. - Perform the same actions as above. Notice that OS dark/light theme changes are ignored, but Chrome theme changes work as expected.
2024-03-29 17:48:33 +01:00
void UpdateTitlebarTheme(views::Widget* widget) {
#if BUILDFLAG(IS_WIN)
// Value was 19 prior to Windows 10 20H1, according to
// https://stackoverflow.com/a/70693198
const DWORD dwAttribute =
base::win::GetVersion() >= base::win::Version::WIN10_20H1
? DWMWA_USE_IMMERSIVE_DARK_MODE
: 19;
const HWND widget_hwnd = views::HWNDForWidget(widget);
BOOL has_dark_titlebar = FALSE;
DwmGetWindowAttribute(widget_hwnd, dwAttribute, &has_dark_titlebar,
sizeof(has_dark_titlebar));
const BOOL dark_titlebar_enabled = ShouldUseDarkTheme(widget);
if (has_dark_titlebar == dark_titlebar_enabled) {
// No change required.
return;
}
// From BrowserFrameViewWin::SetSystemMicaTitlebarAttributes.
DwmSetWindowAttribute(widget_hwnd, dwAttribute, &dark_titlebar_enabled,
sizeof(dark_titlebar_enabled));
// Repaint the titlebar if the Widget is visible. None of the usual NC
// repaint techniques work with DwmSetWindowAttribute so use a workaround
// that nudges the window width.
// See https://stackoverflow.com/a/78269906/23991994
if (IsWindowVisible(widget_hwnd) && !IsIconic(widget_hwnd)) {
RECT rect = {};
::GetWindowRect(widget_hwnd, &rect);
if (IsZoomed(widget_hwnd)) {
// Window is currently maximized. Restore and then re-maximize the
// window. The restore position is changed temporarily to make the
// update less noticeable.
WINDOWPLACEMENT placement = {};
GetWindowPlacement(widget_hwnd, &placement);
const RECT oldrect = placement.rcNormalPosition;
placement.rcNormalPosition = rect;
placement.rcNormalPosition.right -= 1;
SetWindowPlacement(widget_hwnd, &placement);
LockWindowUpdate(widget_hwnd);
ShowWindow(widget_hwnd, SW_SHOWNORMAL);
ShowWindow(widget_hwnd, SW_SHOWMAXIMIZED);
LockWindowUpdate(nullptr);
placement.rcNormalPosition = oldrect;
SetWindowPlacement(widget_hwnd, &placement);
} else {
// Window is currently normal. Change and then restore the window width.
// Use Defer functions to make the update less noticeable.
HDWP defer = BeginDeferWindowPos(2);
DeferWindowPos(defer, widget_hwnd, NULL, 0, 0, rect.right - rect.left - 1,
rect.bottom - rect.top,
SWP_NOZORDER | SWP_NOMOVE | SWP_NOACTIVATE);
DeferWindowPos(defer, widget_hwnd, NULL, 0, 0, rect.right - rect.left,
rect.bottom - rect.top,
SWP_NOZORDER | SWP_NOMOVE | SWP_NOACTIVATE);
LockWindowUpdate(widget_hwnd);
EndDeferWindowPos(defer);
LockWindowUpdate(nullptr);
}
}
#endif // BUILDFLAG(IS_WIN)
}
} // namespace view_util