Magic-Mirror/gecko-dev
1
0
Fork 0
mirror of https://github.com/mozilla/gecko-dev.git synced 2024-11-23 04:41:11 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity
6027d1d91f
gecko-dev/widget/Theme.h

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

207 lines
9.3 KiB
C
Raw Normal View History

Bug 1381938: Add native theme for Windows that avoids native system calls. r=mstange,dbaron Differential Revision: https://phabricator.services.mozilla.com/D33310 --HG-- extra : moz-landing-system : lando
2020-02-10 19:26:01 +00:00
/* -*- Mode: C++; tab-width: 2; indent-tabs-mode: nil; c-basic-offset: 2 -*-
*
* This Source Code Form is subject to the terms of the Mozilla Public
* License, v. 2.0. If a copy of the MPL was not distributed with this
* file, You can obtain one at http://mozilla.org/MPL/2.0/. */
Bug 1749645 - Rename nsNativeBasicTheme{,Cocoa} to Theme{,Cocoa}. r=mstange We have this situation right now where all the themes are inheriting from nsNativeBasicTheme. Rename it to a nicer name, and clean up some code while at it. In the future I'd like to simplify the inheritance chain to remove nsNativeTheme altogether (so that all nsITheme implementations use mozilla::widget::Theme). That's not hard to do mechanically, but rather than dumping all of nsNativeTheme into Theme I'd like to do it a bit more carefully, to hopefully remove a lot of the helpers that nsNativeTheme has to deal with XUL and so on and use something nicer. Eventually the inheritance chain will be something like: * nsITheme : public nsISupports * Theme : public nsITheme, public nsITimerCallback, public nsINamed * ThemeCocoa : public Theme * nsNativeThemeCocoa : public ThemeCocoa * nsNativeThemeWin : public Theme * nsNativeThemeGtk : public Theme Differential Revision: https://phabricator.services.mozilla.com/D135668
2022-01-12 16:33:31 +00:00
#ifndef mozilla_widget_Theme_h
#define mozilla_widget_Theme_h
Bug 1381938: Add native theme for Windows that avoids native system calls. r=mstange,dbaron Differential Revision: https://phabricator.services.mozilla.com/D33310 --HG-- extra : moz-landing-system : lando
2020-02-10 19:26:01 +00:00
Bug 1640195 - Remove using namespace from nsNativeBasicTheme.h. r=nical Sorry, should've caught this during review. Differential Revision: https://phabricator.services.mozilla.com/D85566
2020-07-31 12:04:29 +00:00
#include "Units.h"
#include "mozilla/gfx/2D.h"
#include "mozilla/gfx/Rect.h"
#include "mozilla/gfx/Types.h"
Bug 1381938: Add native theme for Windows that avoids native system calls. r=mstange,dbaron Differential Revision: https://phabricator.services.mozilla.com/D33310 --HG-- extra : moz-landing-system : lando
2020-02-10 19:26:01 +00:00
#include "nsITheme.h"
#include "nsNativeTheme.h"
Bug 1719427: Refactor scrollbar drawing code across platforms. r=emilio Differential Revision: https://phabricator.services.mozilla.com/D129265
2021-11-15 12:39:38 +00:00
#include "ScrollbarDrawing.h"
Bug 1640195: Address UX feedback for non-native widget styling. r=geckoview-reviewers,emilio,agi Differential Revision: https://phabricator.services.mozilla.com/D76509
2020-07-30 17:02:02 +00:00
namespace mozilla {
Bug 1697467 - Push the high contrast code from nsNativeBasicThemeWin to nsNativeBasicTheme. r=mstange Linux can also have high contrast (and mac, if you tweak prefs, but let's assume that doesn't happen), so no reason we shouldn't share this code. One related simplification while I was doing this code move is that I managed to remove the scrollbar "border" code. Turns out that Windows was overriding ComputeScrollbarColors so that border and track colors were always the same, and Linux was ignoring the border anyways, so with this we can simplfiy the implementation a bit (as the Linux scrollbar track / corner code can be shared with Windows now). Differential Revision: https://phabricator.services.mozilla.com/D107863
2021-03-12 14:44:13 +00:00
enum class StyleSystemColor : uint8_t;
Bug 1749645 - Rename nsNativeBasicTheme{,Cocoa} to Theme{,Cocoa}. r=mstange We have this situation right now where all the themes are inheriting from nsNativeBasicTheme. Rename it to a nicer name, and clean up some code while at it. In the future I'd like to simplify the inheritance chain to remove nsNativeTheme altogether (so that all nsITheme implementations use mozilla::widget::Theme). That's not hard to do mechanically, but rather than dumping all of nsNativeTheme into Theme I'd like to do it a bit more carefully, to hopefully remove a lot of the helpers that nsNativeTheme has to deal with XUL and so on and use something nicer. Eventually the inheritance chain will be something like: * nsITheme : public nsISupports * Theme : public nsITheme, public nsITimerCallback, public nsINamed * ThemeCocoa : public Theme * nsNativeThemeCocoa : public ThemeCocoa * nsNativeThemeWin : public Theme * nsNativeThemeGtk : public Theme Differential Revision: https://phabricator.services.mozilla.com/D135668
2022-01-12 16:33:31 +00:00
namespace widget {
Bug 1381938: Add native theme for Windows that avoids native system calls. r=mstange,dbaron Differential Revision: https://phabricator.services.mozilla.com/D33310 --HG-- extra : moz-landing-system : lando
2020-02-10 19:26:01 +00:00
Bug 1749645 - Rename nsNativeBasicTheme{,Cocoa} to Theme{,Cocoa}. r=mstange We have this situation right now where all the themes are inheriting from nsNativeBasicTheme. Rename it to a nicer name, and clean up some code while at it. In the future I'd like to simplify the inheritance chain to remove nsNativeTheme altogether (so that all nsITheme implementations use mozilla::widget::Theme). That's not hard to do mechanically, but rather than dumping all of nsNativeTheme into Theme I'd like to do it a bit more carefully, to hopefully remove a lot of the helpers that nsNativeTheme has to deal with XUL and so on and use something nicer. Eventually the inheritance chain will be something like: * nsITheme : public nsISupports * Theme : public nsITheme, public nsITimerCallback, public nsINamed * ThemeCocoa : public Theme * nsNativeThemeCocoa : public ThemeCocoa * nsNativeThemeWin : public Theme * nsNativeThemeGtk : public Theme Differential Revision: https://phabricator.services.mozilla.com/D135668
2022-01-12 16:33:31 +00:00
class Theme : protected nsNativeTheme, public nsITheme {
Bug 1669131 - Size and paint non-native theme scrollbars to emulate native non-overlay Gtk scrollbars. r=spohl This doesn't yet use theme-derived colors, and also doesn't yet support window active state dependent colors. Differential Revision: https://phabricator.services.mozilla.com/D92368
2020-10-05 21:15:18 +00:00
protected:
Bug 1749645 - Rename nsNativeBasicTheme{,Cocoa} to Theme{,Cocoa}. r=mstange We have this situation right now where all the themes are inheriting from nsNativeBasicTheme. Rename it to a nicer name, and clean up some code while at it. In the future I'd like to simplify the inheritance chain to remove nsNativeTheme altogether (so that all nsITheme implementations use mozilla::widget::Theme). That's not hard to do mechanically, but rather than dumping all of nsNativeTheme into Theme I'd like to do it a bit more carefully, to hopefully remove a lot of the helpers that nsNativeTheme has to deal with XUL and so on and use something nicer. Eventually the inheritance chain will be something like: * nsITheme : public nsISupports * Theme : public nsITheme, public nsITimerCallback, public nsINamed * ThemeCocoa : public Theme * nsNativeThemeCocoa : public ThemeCocoa * nsNativeThemeWin : public Theme * nsNativeThemeGtk : public Theme Differential Revision: https://phabricator.services.mozilla.com/D135668
2022-01-12 16:33:31 +00:00
using sRGBColor = gfx::sRGBColor;
using DrawTarget = gfx::DrawTarget;
using Path = gfx::Path;
using Rect = gfx::Rect;
using Point = gfx::Point;
using RectCornerRadii = gfx::RectCornerRadii;
using Colors = ThemeColors;
using AccentColor = ThemeAccentColor;
Bug 1773070 - Unify Gecko and Servo EventState/ElementState bits. r=smaug Add a dom/base/rust crate called just "dom" where we can share these. Most of the changes are automatic: s/mozilla::EventStates/mozilla::dom::ElementState/ s/EventStates/ElementState/ s/NS_EVENT_STATE_/ElementState::/ s/NS_DOCUMENT_STATE_/DocumentState::/ And so on. This requires a new cbindgen version to avoid ugly casts for large shifts. Differential Revision: https://phabricator.services.mozilla.com/D148537
2022-06-07 23:09:52 +00:00
using ElementState = dom::ElementState;
Bug 1640195 - Remove using namespace from nsNativeBasicTheme.h. r=nical Sorry, should've caught this during review. Differential Revision: https://phabricator.services.mozilla.com/D85566
2020-07-31 12:04:29 +00:00
Bug 1381938: Add native theme for Windows that avoids native system calls. r=mstange,dbaron Differential Revision: https://phabricator.services.mozilla.com/D33310 --HG-- extra : moz-landing-system : lando
2020-02-10 19:26:01 +00:00
public:
Bug 1749645 - Rename nsNativeBasicTheme{,Cocoa} to Theme{,Cocoa}. r=mstange We have this situation right now where all the themes are inheriting from nsNativeBasicTheme. Rename it to a nicer name, and clean up some code while at it. In the future I'd like to simplify the inheritance chain to remove nsNativeTheme altogether (so that all nsITheme implementations use mozilla::widget::Theme). That's not hard to do mechanically, but rather than dumping all of nsNativeTheme into Theme I'd like to do it a bit more carefully, to hopefully remove a lot of the helpers that nsNativeTheme has to deal with XUL and so on and use something nicer. Eventually the inheritance chain will be something like: * nsITheme : public nsISupports * Theme : public nsITheme, public nsITimerCallback, public nsINamed * ThemeCocoa : public Theme * nsNativeThemeCocoa : public ThemeCocoa * nsNativeThemeWin : public Theme * nsNativeThemeGtk : public Theme Differential Revision: https://phabricator.services.mozilla.com/D135668
2022-01-12 16:33:31 +00:00
explicit Theme(UniquePtr<ScrollbarDrawing>&& aScrollbarDrawing)
Bug 1719427: Move scrollbar size information from prefs to C++ and allow sizing to be overridden via prefs. r=emilio Differential Revision: https://phabricator.services.mozilla.com/D130671
2021-11-15 12:39:39 +00:00
: mScrollbarDrawing(std::move(aScrollbarDrawing)) {
mScrollbarDrawing->RecomputeScrollbarParams();
}
Bug 1719427: Refactor scrollbar drawing code across platforms. r=emilio Differential Revision: https://phabricator.services.mozilla.com/D129265
2021-11-15 12:39:38 +00:00
Bug 1690778 - Derive accent color from theme highlight color in GTK. r=mstange This makes form controls match the rest of the GTK theme like selection colors, etc. An alternative to this would be to just use non-native colors on GTK for all content, but that seems somewhat unfortunate and we do the right thing for scrollbars so... I've tried on a variety of themes and this looks nice so far. Differential Revision: https://phabricator.services.mozilla.com/D104496
2021-02-10 00:47:38 +00:00
static void Init();
static void Shutdown();
static void LookAndFeelChanged();
Bug 1749645 - Rename nsNativeBasicTheme{,Cocoa} to Theme{,Cocoa}. r=mstange We have this situation right now where all the themes are inheriting from nsNativeBasicTheme. Rename it to a nicer name, and clean up some code while at it. In the future I'd like to simplify the inheritance chain to remove nsNativeTheme altogether (so that all nsITheme implementations use mozilla::widget::Theme). That's not hard to do mechanically, but rather than dumping all of nsNativeTheme into Theme I'd like to do it a bit more carefully, to hopefully remove a lot of the helpers that nsNativeTheme has to deal with XUL and so on and use something nicer. Eventually the inheritance chain will be something like: * nsITheme : public nsISupports * Theme : public nsITheme, public nsITimerCallback, public nsINamed * ThemeCocoa : public Theme * nsNativeThemeCocoa : public ThemeCocoa * nsNativeThemeWin : public Theme * nsNativeThemeGtk : public Theme Differential Revision: https://phabricator.services.mozilla.com/D135668
2022-01-12 16:33:31 +00:00
using DPIRatio = CSSToLayoutDeviceScale;
Bug 1679208 - Improve non-native theme with fractional scaling. r=heycam This greatly improves non-native theme on Windows in presence of fractional DPI (see bug 1657191). This matches what the Windows native theme does, to my knowledge, see ScaleForFrameDPI in nsNativeThemeWin.h. However I think the right fix is to not make these LayoutDeviceInt* things but LayoutDevice*. That's a bigger fix, and fits well as a follow-up to this bug, so let's land this in the meantime. Differential Revision: https://phabricator.services.mozilla.com/D97937
2020-11-30 04:48:07 +00:00
Bug 1381938: Add native theme for Windows that avoids native system calls. r=mstange,dbaron Differential Revision: https://phabricator.services.mozilla.com/D33310 --HG-- extra : moz-landing-system : lando
2020-02-10 19:26:01 +00:00
NS_DECL_ISUPPORTS_INHERITED
// The nsITheme interface.
Bug 1694059 - Pass draw target by reference in non-native widget code. r=mstange And remove some useless argument names. This is just preparation for the next patch and shouldn't change behavior. Differential Revision: https://phabricator.services.mozilla.com/D105930
2021-02-22 16:18:33 +00:00
NS_IMETHOD DrawWidgetBackground(gfxContext* aContext, nsIFrame*,
StyleAppearance, const nsRect& aRect,
Bug 1699937 - Don't draw focus outlines for box-shadow in the non-native theme. r=mstange This is a relatively easy way to improve the rendering with the non-native theme while not regressing anything. In the future, once non-native-theme is shipped and default everywhere, I think we could provide something like: bool nsITheme::GetShadowRect(nsIFrame*, StyleAppearance, LayoutDeviceRect&, RectCornerRadii&) or such, where we can provide a precise rect + radii, and we would avoid painting the shadow if the function returned false. That would allow us to remove the native theme box shadow code path, and avoid WR fallback, all at once. Differential Revision: https://phabricator.services.mozilla.com/D109209
2021-03-20 23:08:11 +00:00
const nsRect& aDirtyRect,
DrawOverflow) override;
Bug 1694059 - Use WebRender to render most non-native-theme widgets when possible. r=mstange We basically use a couple primitives to draw these (PaintRoundedRectWithRadius, FillRect), so making the code a bit generic implementing stuff with WebRender seems straight-forward. I've kept using the fallback codepath for the bits that draw complex paths like arrows and such, but the rest of the things should work with this patch. A thing I'm not too happy about is the scrollbar painting setup (requires a lot of boilerplate), but modulo template hacks make nsNativeBasicTheme a template that receives its super class as a parameter or something) it seems hard to do better. Differential Revision: https://phabricator.services.mozilla.com/D105931
2021-02-23 10:49:37 +00:00
bool CreateWebRenderCommandsForWidget(
Bug 1749645 - Rename nsNativeBasicTheme{,Cocoa} to Theme{,Cocoa}. r=mstange We have this situation right now where all the themes are inheriting from nsNativeBasicTheme. Rename it to a nicer name, and clean up some code while at it. In the future I'd like to simplify the inheritance chain to remove nsNativeTheme altogether (so that all nsITheme implementations use mozilla::widget::Theme). That's not hard to do mechanically, but rather than dumping all of nsNativeTheme into Theme I'd like to do it a bit more carefully, to hopefully remove a lot of the helpers that nsNativeTheme has to deal with XUL and so on and use something nicer. Eventually the inheritance chain will be something like: * nsITheme : public nsISupports * Theme : public nsITheme, public nsITimerCallback, public nsINamed * ThemeCocoa : public Theme * nsNativeThemeCocoa : public ThemeCocoa * nsNativeThemeWin : public Theme * nsNativeThemeGtk : public Theme Differential Revision: https://phabricator.services.mozilla.com/D135668
2022-01-12 16:33:31 +00:00
wr::DisplayListBuilder& aBuilder, wr::IpcResourceUpdateQueue& aResources,
const layers::StackingContextHelper& aSc,
layers::RenderRootStateManager* aManager, nsIFrame*, StyleAppearance,
const nsRect& aRect) override;
Bug 1694059 - Use WebRender to render most non-native-theme widgets when possible. r=mstange We basically use a couple primitives to draw these (PaintRoundedRectWithRadius, FillRect), so making the code a bit generic implementing stuff with WebRender seems straight-forward. I've kept using the fallback codepath for the bits that draw complex paths like arrows and such, but the rest of the things should work with this patch. A thing I'm not too happy about is the scrollbar painting setup (requires a lot of boilerplate), but modulo template hacks make nsNativeBasicTheme a template that receives its super class as a parameter or something) it seems hard to do better. Differential Revision: https://phabricator.services.mozilla.com/D105931
2021-02-23 10:49:37 +00:00
// PaintBackendData will be either a DrawTarget, or a WebRenderBackendData.
//
// The return value represents whether the widget could be painted with the
// given back-end.
template <typename PaintBackendData>
bool DoDrawWidgetBackground(PaintBackendData&, nsIFrame*, StyleAppearance,
Bug 1699937 - Don't draw focus outlines for box-shadow in the non-native theme. r=mstange This is a relatively easy way to improve the rendering with the non-native theme while not regressing anything. In the future, once non-native-theme is shipped and default everywhere, I think we could provide something like: bool nsITheme::GetShadowRect(nsIFrame*, StyleAppearance, LayoutDeviceRect&, RectCornerRadii&) or such, where we can provide a precise rect + radii, and we would avoid painting the shadow if the function returned false. That would allow us to remove the native theme box shadow code path, and avoid WR fallback, all at once. Differential Revision: https://phabricator.services.mozilla.com/D109209
2021-03-20 23:08:11 +00:00
const nsRect&, DrawOverflow);
Bug 1694059 - Use WebRender to render most non-native-theme widgets when possible. r=mstange We basically use a couple primitives to draw these (PaintRoundedRectWithRadius, FillRect), so making the code a bit generic implementing stuff with WebRender seems straight-forward. I've kept using the fallback codepath for the bits that draw complex paths like arrows and such, but the rest of the things should work with this patch. A thing I'm not too happy about is the scrollbar painting setup (requires a lot of boilerplate), but modulo template hacks make nsNativeBasicTheme a template that receives its super class as a parameter or something) it seems hard to do better. Differential Revision: https://phabricator.services.mozilla.com/D105931
2021-02-23 10:49:37 +00:00
Bug 1694059 - Pass draw target by reference in non-native widget code. r=mstange And remove some useless argument names. This is just preparation for the next patch and shouldn't change behavior. Differential Revision: https://phabricator.services.mozilla.com/D105930
2021-02-22 16:18:33 +00:00
[[nodiscard]] LayoutDeviceIntMargin GetWidgetBorder(nsDeviceContext* aContext,
nsIFrame*,
StyleAppearance) override;
bool GetWidgetPadding(nsDeviceContext* aContext, nsIFrame*, StyleAppearance,
Backed out changeset 3e90a3759639 (bug 1679208) for scrollbars-no-margin.html failures CLOSED TREE
2020-12-02 23:11:32 +00:00
LayoutDeviceIntMargin* aResult) override;
Bug 1694059 - Pass draw target by reference in non-native widget code. r=mstange And remove some useless argument names. This is just preparation for the next patch and shouldn't change behavior. Differential Revision: https://phabricator.services.mozilla.com/D105930
2021-02-22 16:18:33 +00:00
bool GetWidgetOverflow(nsDeviceContext* aContext, nsIFrame*, StyleAppearance,
Bug 1640195: Address UX feedback for non-native widget styling. r=geckoview-reviewers,emilio,agi Differential Revision: https://phabricator.services.mozilla.com/D76509
2020-07-30 17:02:02 +00:00
nsRect* aOverflowRect) override;
Bug 1793689 - Make GetMinimumWidgetSize work properly on non-XUL flexbox. r=TYLin,layout-reviewers The XUL behavior in nsBox.cpp is fairly different to what the non-XUL layout code paths do. In particular, canOverride=false means that the min-{width,height} properties cannot go under the min widget size of the widget, but that doesn't mean that intrinsic sizes don't affect the final size of the widget. This is very visible if you turn on flex emulation on Windows or macOS, where the toolbar has an appearance that returns width=0,height=N,canOverride=false. With flex emulation we'd collapse the item to be zero-width, which is not good at all. The good thing is that this is no longer exposed to the web (non-native-theme always returns canOverride=true), and our front-end code doesn't seem to rely on this, so we can just remove support for canOverride=false. Differential Revision: https://phabricator.services.mozilla.com/D158608
2022-10-05 19:09:29 +00:00
LayoutDeviceIntSize GetMinimumWidgetSize(nsPresContext*, nsIFrame*,
StyleAppearance) override;
Bug 1694059 - Pass draw target by reference in non-native widget code. r=mstange And remove some useless argument names. This is just preparation for the next patch and shouldn't change behavior. Differential Revision: https://phabricator.services.mozilla.com/D105930
2021-02-22 16:18:33 +00:00
Transparency GetWidgetTransparency(nsIFrame*, StyleAppearance) override;
Bug 1918762 - Simplify theme attribute/state change invalidation. r=jwatt We had the same list of attributes in multiple places, put it in Theme.cpp. Only a few states can change widget state. Just hardcode them in RestyleManager.cpp (where there was already some of it) instead of reusing a weird API. Shouldn't have any behavior change. Differential Revision: https://phabricator.services.mozilla.com/D222160
2024-09-16 22:02:05 +00:00
bool WidgetAttributeChangeRequiresRepaint(StyleAppearance,
nsAtom* aAttribute) override;
Bug 1381938: Add native theme for Windows that avoids native system calls. r=mstange,dbaron Differential Revision: https://phabricator.services.mozilla.com/D33310 --HG-- extra : moz-landing-system : lando
2020-02-10 19:26:01 +00:00
NS_IMETHOD ThemeChanged() override;
Bug 1694059 - Pass draw target by reference in non-native widget code. r=mstange And remove some useless argument names. This is just preparation for the next patch and shouldn't change behavior. Differential Revision: https://phabricator.services.mozilla.com/D105930
2021-02-22 16:18:33 +00:00
bool WidgetAppearanceDependsOnWindowFocus(StyleAppearance) override;
Bug 1640195: Address UX feedback for non-native widget styling. r=geckoview-reviewers,emilio,agi Differential Revision: https://phabricator.services.mozilla.com/D76509
2020-07-30 17:02:02 +00:00
/*bool NeedToClearBackgroundBehindWidget(
Bug 1694059 - Pass draw target by reference in non-native widget code. r=mstange And remove some useless argument names. This is just preparation for the next patch and shouldn't change behavior. Differential Revision: https://phabricator.services.mozilla.com/D105930
2021-02-22 16:18:33 +00:00
nsIFrame*, StyleAppearance) override;*/
ThemeGeometryType ThemeGeometryTypeForWidget(nsIFrame*,
StyleAppearance) override;
Bug 1696988 - Support tooltips in nsNativeBasicThemeCocoa. r=mstange Not sure if you prefer to go this way, your call. Depends on D107574 Differential Revision: https://phabricator.services.mozilla.com/D107575
2021-03-09 00:05:51 +00:00
bool ThemeSupportsWidget(nsPresContext*, nsIFrame*, StyleAppearance) override;
Bug 1694059 - Pass draw target by reference in non-native widget code. r=mstange And remove some useless argument names. This is just preparation for the next patch and shouldn't change behavior. Differential Revision: https://phabricator.services.mozilla.com/D105930
2021-02-22 16:18:33 +00:00
bool WidgetIsContainer(StyleAppearance) override;
Bug 1741495 - Make ThemeDrawsFocusForWidget return the right thing when drawing non-native widgets on Linux and Windows. r=spohl Noticed this while digging into bug 1741359. Differential Revision: https://phabricator.services.mozilla.com/D131277
2021-11-17 00:55:26 +00:00
bool ThemeDrawsFocusForWidget(nsIFrame*, StyleAppearance) override;
Bug 1381938: Add native theme for Windows that avoids native system calls. r=mstange,dbaron Differential Revision: https://phabricator.services.mozilla.com/D33310 --HG-- extra : moz-landing-system : lando
2020-02-10 19:26:01 +00:00
bool ThemeNeedsComboboxDropmarker() override;
Bug 1813046 - Simplify scrollbar sizing code. r=spohl This removes the capability of having differently-sized vertical and horizontal scrollbars (which is only potentially used in windows, and in practice almost-never used). For that case, we choose the larger of vertical/horizontal scrollbar sizes. This is in order to be able to realistically expose the scrollbar size to CSS, see blocked bug. We make RecomputeScrollbarParams the central place where each scrollbar style decides its sizes, and make GetDPIRatioForScrollbarPart handle the cocoa special-case of scaling to 1 or 2, but nothing else. Differential Revision: https://phabricator.services.mozilla.com/D168080
2023-01-28 21:35:51 +00:00
LayoutDeviceIntCoord GetScrollbarSize(const nsPresContext*,
StyleScrollbarWidth, Overlay) final;
Bug 1381938: Add native theme for Windows that avoids native system calls. r=mstange,dbaron Differential Revision: https://phabricator.services.mozilla.com/D33310 --HG-- extra : moz-landing-system : lando
2020-02-10 19:26:01 +00:00
Bug 1918838 - Make CSS zoom apply to themed widgets properly. r=dshin Differential Revision: https://phabricator.services.mozilla.com/D222320
2024-09-19 09:56:50 +00:00
CSSCoord GetCheckboxRadioPrefSize() override;
Bug 1693688 - Make the non-native theme not return minimum sizes for checkboxes (and most other widgets). r=spohl,mstange This matches closer what Chrome and Safari do (Safari paints outside of the box when this happens, but the layout box still respects the author), see: data:text/html,<button style="padding: 0; width: 0"> data:text/html,<input type=checkbox style="width: 0"> Etc. For checkboxes, this matches what OSX does, too. Since we still want checkboxes to be slightly larger than what they'd be otherwise, we add a hook to tweak it when non-native theme is enabled. Differential Revision: https://phabricator.services.mozilla.com/D105798
2021-02-20 00:13:10 +00:00
Bug 1749645 - Rename nsNativeBasicTheme{,Cocoa} to Theme{,Cocoa}. r=mstange We have this situation right now where all the themes are inheriting from nsNativeBasicTheme. Rename it to a nicer name, and clean up some code while at it. In the future I'd like to simplify the inheritance chain to remove nsNativeTheme altogether (so that all nsITheme implementations use mozilla::widget::Theme). That's not hard to do mechanically, but rather than dumping all of nsNativeTheme into Theme I'd like to do it a bit more carefully, to hopefully remove a lot of the helpers that nsNativeTheme has to deal with XUL and so on and use something nicer. Eventually the inheritance chain will be something like: * nsITheme : public nsISupports * Theme : public nsITheme, public nsITimerCallback, public nsINamed * ThemeCocoa : public Theme * nsNativeThemeCocoa : public ThemeCocoa * nsNativeThemeWin : public Theme * nsNativeThemeGtk : public Theme Differential Revision: https://phabricator.services.mozilla.com/D135668
2022-01-12 16:33:31 +00:00
static UniquePtr<ScrollbarDrawing> ScrollbarStyle();
Bug 1719427: Move scrollbar size information from prefs to C++ and allow sizing to be overridden via prefs. r=emilio Differential Revision: https://phabricator.services.mozilla.com/D130671
2021-11-15 12:39:39 +00:00
Bug 1381938: Add native theme for Windows that avoids native system calls. r=mstange,dbaron Differential Revision: https://phabricator.services.mozilla.com/D33310 --HG-- extra : moz-landing-system : lando
2020-02-10 19:26:01 +00:00
protected:
Bug 1749645 - Rename nsNativeBasicTheme{,Cocoa} to Theme{,Cocoa}. r=mstange We have this situation right now where all the themes are inheriting from nsNativeBasicTheme. Rename it to a nicer name, and clean up some code while at it. In the future I'd like to simplify the inheritance chain to remove nsNativeTheme altogether (so that all nsITheme implementations use mozilla::widget::Theme). That's not hard to do mechanically, but rather than dumping all of nsNativeTheme into Theme I'd like to do it a bit more carefully, to hopefully remove a lot of the helpers that nsNativeTheme has to deal with XUL and so on and use something nicer. Eventually the inheritance chain will be something like: * nsITheme : public nsISupports * Theme : public nsITheme, public nsITimerCallback, public nsINamed * ThemeCocoa : public Theme * nsNativeThemeCocoa : public ThemeCocoa * nsNativeThemeWin : public Theme * nsNativeThemeGtk : public Theme Differential Revision: https://phabricator.services.mozilla.com/D135668
2022-01-12 16:33:31 +00:00
virtual ~Theme() = default;
Bug 1640195: Address UX feedback for non-native widget styling. r=geckoview-reviewers,emilio,agi Differential Revision: https://phabricator.services.mozilla.com/D76509
2020-07-30 17:02:02 +00:00
Bug 1813046 - Simplify scrollbar sizing code. r=spohl This removes the capability of having differently-sized vertical and horizontal scrollbars (which is only potentially used in windows, and in practice almost-never used). For that case, we choose the larger of vertical/horizontal scrollbar sizes. This is in order to be able to realistically expose the scrollbar size to CSS, see blocked bug. We make RecomputeScrollbarParams the central place where each scrollbar style decides its sizes, and make GetDPIRatioForScrollbarPart handle the cocoa special-case of scaling to 1 or 2, but nothing else. Differential Revision: https://phabricator.services.mozilla.com/D168080
2023-01-28 21:35:51 +00:00
DPIRatio GetDPIRatio(nsIFrame*, StyleAppearance);
Bug 1640195: Address UX feedback for non-native widget styling. r=geckoview-reviewers,emilio,agi Differential Revision: https://phabricator.services.mozilla.com/D76509
2020-07-30 17:02:02 +00:00
Bug 1790670 - Fix color of high-contrast checkboxes. r=morgan This restores behavior from before my patch, and makes it so that it's easier to see which color pair ends up getting used. Differential Revision: https://phabricator.services.mozilla.com/D157271
2022-09-14 23:14:30 +00:00
std::tuple<sRGBColor, sRGBColor, sRGBColor> ComputeCheckboxColors(
const ElementState&, StyleAppearance, const Colors&);
Bug 1734723 - Don't use transparent borders for checkbox/radio when focused. r=mstange As those don't draw the outline on top. Differential Revision: https://phabricator.services.mozilla.com/D127890
2021-10-08 10:59:02 +00:00
enum class OutlineCoversBorder : bool { No, Yes };
Bug 1773070 - Unify Gecko and Servo EventState/ElementState bits. r=smaug Add a dom/base/rust crate called just "dom" where we can share these. Most of the changes are automatic: s/mozilla::EventStates/mozilla::dom::ElementState/ s/EventStates/ElementState/ s/NS_EVENT_STATE_/ElementState::/ s/NS_DOCUMENT_STATE_/DocumentState::/ And so on. This requires a new cbindgen version to avoid ugly casts for large shifts. Differential Revision: https://phabricator.services.mozilla.com/D148537
2022-06-07 23:09:52 +00:00
sRGBColor ComputeBorderColor(const ElementState&, const Colors&,
Bug 1734723 - Don't use transparent borders for checkbox/radio when focused. r=mstange As those don't draw the outline on top. Differential Revision: https://phabricator.services.mozilla.com/D127890
2021-10-08 10:59:02 +00:00
OutlineCoversBorder);
Bug 1697467 - Push the high contrast code from nsNativeBasicThemeWin to nsNativeBasicTheme. r=mstange Linux can also have high contrast (and mac, if you tweak prefs, but let's assume that doesn't happen), so no reason we shouldn't share this code. One related simplification while I was doing this code move is that I managed to remove the scrollbar "border" code. Turns out that Windows was overriding ComputeScrollbarColors so that border and track colors were always the same, and Linux was ignoring the border anyways, so with this we can simplfiy the implementation a bit (as the Linux scrollbar track / corner code can be shared with Windows now). Differential Revision: https://phabricator.services.mozilla.com/D107863
2021-03-12 14:44:13 +00:00
Bug 1773070 - Unify Gecko and Servo EventState/ElementState bits. r=smaug Add a dom/base/rust crate called just "dom" where we can share these. Most of the changes are automatic: s/mozilla::EventStates/mozilla::dom::ElementState/ s/EventStates/ElementState/ s/NS_EVENT_STATE_/ElementState::/ s/NS_DOCUMENT_STATE_/DocumentState::/ And so on. This requires a new cbindgen version to avoid ugly casts for large shifts. Differential Revision: https://phabricator.services.mozilla.com/D148537
2022-06-07 23:09:52 +00:00
std::pair<sRGBColor, sRGBColor> ComputeButtonColors(const ElementState&,
Bug 1734009 - Pass color-related arguments down to the non-native theme in a more convenient way. r=dholbert This avoids adding yet another parameter for the light/dark color-scheme. This shouldn't have any behavior change, but is a prerequisite to implement dark form controls on the non-native theme. Differential Revision: https://phabricator.services.mozilla.com/D127482
2021-10-05 09:40:00 +00:00
const Colors&,
Bug 1697467 - Push the high contrast code from nsNativeBasicThemeWin to nsNativeBasicTheme. r=mstange Linux can also have high contrast (and mac, if you tweak prefs, but let's assume that doesn't happen), so no reason we shouldn't share this code. One related simplification while I was doing this code move is that I managed to remove the scrollbar "border" code. Turns out that Windows was overriding ComputeScrollbarColors so that border and track colors were always the same, and Linux was ignoring the border anyways, so with this we can simplfiy the implementation a bit (as the Linux scrollbar track / corner code can be shared with Windows now). Differential Revision: https://phabricator.services.mozilla.com/D107863
2021-03-12 14:44:13 +00:00
nsIFrame* = nullptr);
Bug 1773070 - Unify Gecko and Servo EventState/ElementState bits. r=smaug Add a dom/base/rust crate called just "dom" where we can share these. Most of the changes are automatic: s/mozilla::EventStates/mozilla::dom::ElementState/ s/EventStates/ElementState/ s/NS_EVENT_STATE_/ElementState::/ s/NS_DOCUMENT_STATE_/DocumentState::/ And so on. This requires a new cbindgen version to avoid ugly casts for large shifts. Differential Revision: https://phabricator.services.mozilla.com/D148537
2022-06-07 23:09:52 +00:00
std::pair<sRGBColor, sRGBColor> ComputeTextfieldColors(const ElementState&,
Bug 1734723 - Don't use transparent borders for checkbox/radio when focused. r=mstange As those don't draw the outline on top. Differential Revision: https://phabricator.services.mozilla.com/D127890
2021-10-08 10:59:02 +00:00
const Colors&,
OutlineCoversBorder);
Bug 1773070 - Unify Gecko and Servo EventState/ElementState bits. r=smaug Add a dom/base/rust crate called just "dom" where we can share these. Most of the changes are automatic: s/mozilla::EventStates/mozilla::dom::ElementState/ s/EventStates/ElementState/ s/NS_EVENT_STATE_/ElementState::/ s/NS_DOCUMENT_STATE_/DocumentState::/ And so on. This requires a new cbindgen version to avoid ugly casts for large shifts. Differential Revision: https://phabricator.services.mozilla.com/D148537
2022-06-07 23:09:52 +00:00
std::pair<sRGBColor, sRGBColor> ComputeRangeProgressColors(
const ElementState&, const Colors&);
std::pair<sRGBColor, sRGBColor> ComputeRangeTrackColors(const ElementState&,
Bug 1734009 - Pass color-related arguments down to the non-native theme in a more convenient way. r=dholbert This avoids adding yet another parameter for the light/dark color-scheme. This shouldn't have any behavior change, but is a prerequisite to implement dark form controls on the non-native theme. Differential Revision: https://phabricator.services.mozilla.com/D127482
2021-10-05 09:40:00 +00:00
const Colors&);
Bug 1773070 - Unify Gecko and Servo EventState/ElementState bits. r=smaug Add a dom/base/rust crate called just "dom" where we can share these. Most of the changes are automatic: s/mozilla::EventStates/mozilla::dom::ElementState/ s/EventStates/ElementState/ s/NS_EVENT_STATE_/ElementState::/ s/NS_DOCUMENT_STATE_/DocumentState::/ And so on. This requires a new cbindgen version to avoid ugly casts for large shifts. Differential Revision: https://phabricator.services.mozilla.com/D148537
2022-06-07 23:09:52 +00:00
std::pair<sRGBColor, sRGBColor> ComputeRangeThumbColors(const ElementState&,
Bug 1734009 - Pass color-related arguments down to the non-native theme in a more convenient way. r=dholbert This avoids adding yet another parameter for the light/dark color-scheme. This shouldn't have any behavior change, but is a prerequisite to implement dark form controls on the non-native theme. Differential Revision: https://phabricator.services.mozilla.com/D127482
2021-10-05 09:40:00 +00:00
const Colors&);
std::pair<sRGBColor, sRGBColor> ComputeProgressColors(const Colors&);
std::pair<sRGBColor, sRGBColor> ComputeProgressTrackColors(const Colors&);
Bug 1697467 - Push the high contrast code from nsNativeBasicThemeWin to nsNativeBasicTheme. r=mstange Linux can also have high contrast (and mac, if you tweak prefs, but let's assume that doesn't happen), so no reason we shouldn't share this code. One related simplification while I was doing this code move is that I managed to remove the scrollbar "border" code. Turns out that Windows was overriding ComputeScrollbarColors so that border and track colors were always the same, and Linux was ignoring the border anyways, so with this we can simplfiy the implementation a bit (as the Linux scrollbar track / corner code can be shared with Windows now). Differential Revision: https://phabricator.services.mozilla.com/D107863
2021-03-12 14:44:13 +00:00
std::pair<sRGBColor, sRGBColor> ComputeMeterchunkColors(
Bug 1773070 - Unify Gecko and Servo EventState/ElementState bits. r=smaug Add a dom/base/rust crate called just "dom" where we can share these. Most of the changes are automatic: s/mozilla::EventStates/mozilla::dom::ElementState/ s/EventStates/ElementState/ s/NS_EVENT_STATE_/ElementState::/ s/NS_DOCUMENT_STATE_/DocumentState::/ And so on. This requires a new cbindgen version to avoid ugly casts for large shifts. Differential Revision: https://phabricator.services.mozilla.com/D148537
2022-06-07 23:09:52 +00:00
const ElementState& aMeterState, const Colors&);
Bug 1734009 - Pass color-related arguments down to the non-native theme in a more convenient way. r=dholbert This avoids adding yet another parameter for the light/dark color-scheme. This shouldn't have any behavior change, but is a prerequisite to implement dark form controls on the non-native theme. Differential Revision: https://phabricator.services.mozilla.com/D127482
2021-10-05 09:40:00 +00:00
std::array<sRGBColor, 3> ComputeFocusRectColors(const Colors&);
Bug 1697467 - Push the high contrast code from nsNativeBasicThemeWin to nsNativeBasicTheme. r=mstange Linux can also have high contrast (and mac, if you tweak prefs, but let's assume that doesn't happen), so no reason we shouldn't share this code. One related simplification while I was doing this code move is that I managed to remove the scrollbar "border" code. Turns out that Windows was overriding ComputeScrollbarColors so that border and track colors were always the same, and Linux was ignoring the border anyways, so with this we can simplfiy the implementation a bit (as the Linux scrollbar track / corner code can be shared with Windows now). Differential Revision: https://phabricator.services.mozilla.com/D107863
2021-03-12 14:44:13 +00:00
Bug 1694059 - Use WebRender to render most non-native-theme widgets when possible. r=mstange We basically use a couple primitives to draw these (PaintRoundedRectWithRadius, FillRect), so making the code a bit generic implementing stuff with WebRender seems straight-forward. I've kept using the fallback codepath for the bits that draw complex paths like arrows and such, but the rest of the things should work with this patch. A thing I'm not too happy about is the scrollbar painting setup (requires a lot of boilerplate), but modulo template hacks make nsNativeBasicTheme a template that receives its super class as a parameter or something) it seems hard to do better. Differential Revision: https://phabricator.services.mozilla.com/D105931
2021-02-23 10:49:37 +00:00
template <typename PaintBackendData>
void PaintRoundedFocusRect(PaintBackendData&, const LayoutDeviceRect&,
Bug 1734009 - Pass color-related arguments down to the non-native theme in a more convenient way. r=dholbert This avoids adding yet another parameter for the light/dark color-scheme. This shouldn't have any behavior change, but is a prerequisite to implement dark form controls on the non-native theme. Differential Revision: https://phabricator.services.mozilla.com/D127482
2021-10-05 09:40:00 +00:00
const Colors&, DPIRatio, CSSCoord aRadius,
CSSCoord aOffset);
Bug 1694059 - Use WebRender to render most non-native-theme widgets when possible. r=mstange We basically use a couple primitives to draw these (PaintRoundedRectWithRadius, FillRect), so making the code a bit generic implementing stuff with WebRender seems straight-forward. I've kept using the fallback codepath for the bits that draw complex paths like arrows and such, but the rest of the things should work with this patch. A thing I'm not too happy about is the scrollbar painting setup (requires a lot of boilerplate), but modulo template hacks make nsNativeBasicTheme a template that receives its super class as a parameter or something) it seems hard to do better. Differential Revision: https://phabricator.services.mozilla.com/D105931
2021-02-23 10:49:37 +00:00
template <typename PaintBackendData>
void PaintAutoStyleOutline(nsIFrame*, PaintBackendData&,
Bug 1734009 - Pass color-related arguments down to the non-native theme in a more convenient way. r=dholbert This avoids adding yet another parameter for the light/dark color-scheme. This shouldn't have any behavior change, but is a prerequisite to implement dark form controls on the non-native theme. Differential Revision: https://phabricator.services.mozilla.com/D127482
2021-10-05 09:40:00 +00:00
const LayoutDeviceRect&, const Colors&, DPIRatio);
Bug 1694059 - Use WebRender to render most non-native-theme widgets when possible. r=mstange We basically use a couple primitives to draw these (PaintRoundedRectWithRadius, FillRect), so making the code a bit generic implementing stuff with WebRender seems straight-forward. I've kept using the fallback codepath for the bits that draw complex paths like arrows and such, but the rest of the things should work with this patch. A thing I'm not too happy about is the scrollbar painting setup (requires a lot of boilerplate), but modulo template hacks make nsNativeBasicTheme a template that receives its super class as a parameter or something) it seems hard to do better. Differential Revision: https://phabricator.services.mozilla.com/D105931
2021-02-23 10:49:37 +00:00
Bug 1694059 - Pass draw target by reference in non-native widget code. r=mstange And remove some useless argument names. This is just preparation for the next patch and shouldn't change behavior. Differential Revision: https://phabricator.services.mozilla.com/D105930
2021-02-22 16:18:33 +00:00
void PaintCheckboxControl(DrawTarget& aDrawTarget, const LayoutDeviceRect&,
Bug 1773070 - Unify Gecko and Servo EventState/ElementState bits. r=smaug Add a dom/base/rust crate called just "dom" where we can share these. Most of the changes are automatic: s/mozilla::EventStates/mozilla::dom::ElementState/ s/EventStates/ElementState/ s/NS_EVENT_STATE_/ElementState::/ s/NS_DOCUMENT_STATE_/DocumentState::/ And so on. This requires a new cbindgen version to avoid ugly casts for large shifts. Differential Revision: https://phabricator.services.mozilla.com/D148537
2022-06-07 23:09:52 +00:00
const ElementState&, const Colors&, DPIRatio);
Bug 1790670 - Fix color of high-contrast checkboxes. r=morgan This restores behavior from before my patch, and makes it so that it's easier to see which color pair ends up getting used. Differential Revision: https://phabricator.services.mozilla.com/D157271
2022-09-14 23:14:30 +00:00
void PaintCheckMark(DrawTarget&, const LayoutDeviceRect&, const sRGBColor&);
Bug 1694059 - Pass draw target by reference in non-native widget code. r=mstange And remove some useless argument names. This is just preparation for the next patch and shouldn't change behavior. Differential Revision: https://phabricator.services.mozilla.com/D105930
2021-02-22 16:18:33 +00:00
void PaintIndeterminateMark(DrawTarget&, const LayoutDeviceRect&,
Bug 1790670 - Fix color of high-contrast checkboxes. r=morgan This restores behavior from before my patch, and makes it so that it's easier to see which color pair ends up getting used. Differential Revision: https://phabricator.services.mozilla.com/D157271
2022-09-14 23:14:30 +00:00
const sRGBColor&);
Bug 1694059 - Use WebRender to render non-native range inputs and radio buttons. r=mstange The only thing missing now are things that draw arrows / checkmarks. Make the disabled range thumb opaque, to avoid dealing with clipping (also matches all other browsers, fwiw). Differential Revision: https://phabricator.services.mozilla.com/D106011
2021-02-23 23:22:19 +00:00
template <typename PaintBackendData>
void PaintStrokedCircle(PaintBackendData&, const LayoutDeviceRect&,
const sRGBColor& aBackgroundColor,
const sRGBColor& aBorderColor,
const CSSCoord aBorderWidth, DPIRatio);
void PaintCircleShadow(DrawTarget&, const LayoutDeviceRect& aBoxRect,
const LayoutDeviceRect& aClipRect, float aShadowAlpha,
const CSSPoint& aShadowOffset,
CSSCoord aShadowBlurStdDev, DPIRatio);
void PaintCircleShadow(WebRenderBackendData&,
const LayoutDeviceRect& aBoxRect,
const LayoutDeviceRect& aClipRect, float aShadowAlpha,
const CSSPoint& aShadowOffset,
CSSCoord aShadowBlurStdDev, DPIRatio);
template <typename PaintBackendData>
void PaintRadioControl(PaintBackendData&, const LayoutDeviceRect&,
Bug 1773070 - Unify Gecko and Servo EventState/ElementState bits. r=smaug Add a dom/base/rust crate called just "dom" where we can share these. Most of the changes are automatic: s/mozilla::EventStates/mozilla::dom::ElementState/ s/EventStates/ElementState/ s/NS_EVENT_STATE_/ElementState::/ s/NS_DOCUMENT_STATE_/DocumentState::/ And so on. This requires a new cbindgen version to avoid ugly casts for large shifts. Differential Revision: https://phabricator.services.mozilla.com/D148537
2022-06-07 23:09:52 +00:00
const ElementState&, const Colors&, DPIRatio);
Bug 1694059 - Use WebRender to render non-native range inputs and radio buttons. r=mstange The only thing missing now are things that draw arrows / checkmarks. Make the disabled range thumb opaque, to avoid dealing with clipping (also matches all other browsers, fwiw). Differential Revision: https://phabricator.services.mozilla.com/D106011
2021-02-23 23:22:19 +00:00
template <typename PaintBackendData>
void PaintRadioCheckmark(PaintBackendData&, const LayoutDeviceRect&,
Bug 1773070 - Unify Gecko and Servo EventState/ElementState bits. r=smaug Add a dom/base/rust crate called just "dom" where we can share these. Most of the changes are automatic: s/mozilla::EventStates/mozilla::dom::ElementState/ s/EventStates/ElementState/ s/NS_EVENT_STATE_/ElementState::/ s/NS_DOCUMENT_STATE_/DocumentState::/ And so on. This requires a new cbindgen version to avoid ugly casts for large shifts. Differential Revision: https://phabricator.services.mozilla.com/D148537
2022-06-07 23:09:52 +00:00
const ElementState&, DPIRatio);
Bug 1694059 - Use WebRender to render most non-native-theme widgets when possible. r=mstange We basically use a couple primitives to draw these (PaintRoundedRectWithRadius, FillRect), so making the code a bit generic implementing stuff with WebRender seems straight-forward. I've kept using the fallback codepath for the bits that draw complex paths like arrows and such, but the rest of the things should work with this patch. A thing I'm not too happy about is the scrollbar painting setup (requires a lot of boilerplate), but modulo template hacks make nsNativeBasicTheme a template that receives its super class as a parameter or something) it seems hard to do better. Differential Revision: https://phabricator.services.mozilla.com/D105931
2021-02-23 10:49:37 +00:00
template <typename PaintBackendData>
void PaintTextField(PaintBackendData&, const LayoutDeviceRect&,
Bug 1773070 - Unify Gecko and Servo EventState/ElementState bits. r=smaug Add a dom/base/rust crate called just "dom" where we can share these. Most of the changes are automatic: s/mozilla::EventStates/mozilla::dom::ElementState/ s/EventStates/ElementState/ s/NS_EVENT_STATE_/ElementState::/ s/NS_DOCUMENT_STATE_/DocumentState::/ And so on. This requires a new cbindgen version to avoid ugly casts for large shifts. Differential Revision: https://phabricator.services.mozilla.com/D148537
2022-06-07 23:09:52 +00:00
const ElementState&, const Colors&, DPIRatio);
Bug 1694059 - Use WebRender to render most non-native-theme widgets when possible. r=mstange We basically use a couple primitives to draw these (PaintRoundedRectWithRadius, FillRect), so making the code a bit generic implementing stuff with WebRender seems straight-forward. I've kept using the fallback codepath for the bits that draw complex paths like arrows and such, but the rest of the things should work with this patch. A thing I'm not too happy about is the scrollbar painting setup (requires a lot of boilerplate), but modulo template hacks make nsNativeBasicTheme a template that receives its super class as a parameter or something) it seems hard to do better. Differential Revision: https://phabricator.services.mozilla.com/D105931
2021-02-23 10:49:37 +00:00
template <typename PaintBackendData>
void PaintListbox(PaintBackendData&, const LayoutDeviceRect&,
Bug 1773070 - Unify Gecko and Servo EventState/ElementState bits. r=smaug Add a dom/base/rust crate called just "dom" where we can share these. Most of the changes are automatic: s/mozilla::EventStates/mozilla::dom::ElementState/ s/EventStates/ElementState/ s/NS_EVENT_STATE_/ElementState::/ s/NS_DOCUMENT_STATE_/DocumentState::/ And so on. This requires a new cbindgen version to avoid ugly casts for large shifts. Differential Revision: https://phabricator.services.mozilla.com/D148537
2022-06-07 23:09:52 +00:00
const ElementState&, const Colors&, DPIRatio);
Bug 1694059 - Use WebRender to render most non-native-theme widgets when possible. r=mstange We basically use a couple primitives to draw these (PaintRoundedRectWithRadius, FillRect), so making the code a bit generic implementing stuff with WebRender seems straight-forward. I've kept using the fallback codepath for the bits that draw complex paths like arrows and such, but the rest of the things should work with this patch. A thing I'm not too happy about is the scrollbar painting setup (requires a lot of boilerplate), but modulo template hacks make nsNativeBasicTheme a template that receives its super class as a parameter or something) it seems hard to do better. Differential Revision: https://phabricator.services.mozilla.com/D105931
2021-02-23 10:49:37 +00:00
template <typename PaintBackendData>
void PaintMenulist(PaintBackendData&, const LayoutDeviceRect&,
Bug 1773070 - Unify Gecko and Servo EventState/ElementState bits. r=smaug Add a dom/base/rust crate called just "dom" where we can share these. Most of the changes are automatic: s/mozilla::EventStates/mozilla::dom::ElementState/ s/EventStates/ElementState/ s/NS_EVENT_STATE_/ElementState::/ s/NS_DOCUMENT_STATE_/DocumentState::/ And so on. This requires a new cbindgen version to avoid ugly casts for large shifts. Differential Revision: https://phabricator.services.mozilla.com/D148537
2022-06-07 23:09:52 +00:00
const ElementState&, const Colors&, DPIRatio);
Bug 1858349 - Remove now-unused menuarrow code. r=spohl,mac-reviewers,win-reviewers,rkraesig The windows bits were already unused. Depends on D190663 Differential Revision: https://phabricator.services.mozilla.com/D190664
2023-10-11 19:37:40 +00:00
void PaintMenulistArrow(nsIFrame*, DrawTarget&, const LayoutDeviceRect&);
Bug 1694059 - Pass draw target by reference in non-native widget code. r=mstange And remove some useless argument names. This is just preparation for the next patch and shouldn't change behavior. Differential Revision: https://phabricator.services.mozilla.com/D105930
2021-02-22 16:18:33 +00:00
void PaintSpinnerButton(nsIFrame*, DrawTarget&, const LayoutDeviceRect&,
Bug 1773070 - Unify Gecko and Servo EventState/ElementState bits. r=smaug Add a dom/base/rust crate called just "dom" where we can share these. Most of the changes are automatic: s/mozilla::EventStates/mozilla::dom::ElementState/ s/EventStates/ElementState/ s/NS_EVENT_STATE_/ElementState::/ s/NS_DOCUMENT_STATE_/DocumentState::/ And so on. This requires a new cbindgen version to avoid ugly casts for large shifts. Differential Revision: https://phabricator.services.mozilla.com/D148537
2022-06-07 23:09:52 +00:00
const ElementState&, StyleAppearance, const Colors&,
Bug 1697467 - Push the high contrast code from nsNativeBasicThemeWin to nsNativeBasicTheme. r=mstange Linux can also have high contrast (and mac, if you tweak prefs, but let's assume that doesn't happen), so no reason we shouldn't share this code. One related simplification while I was doing this code move is that I managed to remove the scrollbar "border" code. Turns out that Windows was overriding ComputeScrollbarColors so that border and track colors were always the same, and Linux was ignoring the border anyways, so with this we can simplfiy the implementation a bit (as the Linux scrollbar track / corner code can be shared with Windows now). Differential Revision: https://phabricator.services.mozilla.com/D107863
2021-03-12 14:44:13 +00:00
DPIRatio);
Bug 1694059 - Use WebRender to render non-native range inputs and radio buttons. r=mstange The only thing missing now are things that draw arrows / checkmarks. Make the disabled range thumb opaque, to avoid dealing with clipping (also matches all other browsers, fwiw). Differential Revision: https://phabricator.services.mozilla.com/D106011
2021-02-23 23:22:19 +00:00
template <typename PaintBackendData>
void PaintRange(nsIFrame*, PaintBackendData&, const LayoutDeviceRect&,
Bug 1773070 - Unify Gecko and Servo EventState/ElementState bits. r=smaug Add a dom/base/rust crate called just "dom" where we can share these. Most of the changes are automatic: s/mozilla::EventStates/mozilla::dom::ElementState/ s/EventStates/ElementState/ s/NS_EVENT_STATE_/ElementState::/ s/NS_DOCUMENT_STATE_/DocumentState::/ And so on. This requires a new cbindgen version to avoid ugly casts for large shifts. Differential Revision: https://phabricator.services.mozilla.com/D148537
2022-06-07 23:09:52 +00:00
const ElementState&, const Colors&, DPIRatio,
Bug 1734009 - Pass color-related arguments down to the non-native theme in a more convenient way. r=dholbert This avoids adding yet another parameter for the light/dark color-scheme. This shouldn't have any behavior change, but is a prerequisite to implement dark form controls on the non-native theme. Differential Revision: https://phabricator.services.mozilla.com/D127482
2021-10-05 09:40:00 +00:00
bool aHorizontal);
Bug 1694059 - Use WebRender to render most non-native-theme widgets when possible. r=mstange We basically use a couple primitives to draw these (PaintRoundedRectWithRadius, FillRect), so making the code a bit generic implementing stuff with WebRender seems straight-forward. I've kept using the fallback codepath for the bits that draw complex paths like arrows and such, but the rest of the things should work with this patch. A thing I'm not too happy about is the scrollbar painting setup (requires a lot of boilerplate), but modulo template hacks make nsNativeBasicTheme a template that receives its super class as a parameter or something) it seems hard to do better. Differential Revision: https://phabricator.services.mozilla.com/D105931
2021-02-23 10:49:37 +00:00
template <typename PaintBackendData>
void PaintProgress(nsIFrame*, PaintBackendData&, const LayoutDeviceRect&,
Bug 1773070 - Unify Gecko and Servo EventState/ElementState bits. r=smaug Add a dom/base/rust crate called just "dom" where we can share these. Most of the changes are automatic: s/mozilla::EventStates/mozilla::dom::ElementState/ s/EventStates/ElementState/ s/NS_EVENT_STATE_/ElementState::/ s/NS_DOCUMENT_STATE_/DocumentState::/ And so on. This requires a new cbindgen version to avoid ugly casts for large shifts. Differential Revision: https://phabricator.services.mozilla.com/D148537
2022-06-07 23:09:52 +00:00
const ElementState&, const Colors&, DPIRatio,
Bug 1734009 - Pass color-related arguments down to the non-native theme in a more convenient way. r=dholbert This avoids adding yet another parameter for the light/dark color-scheme. This shouldn't have any behavior change, but is a prerequisite to implement dark form controls on the non-native theme. Differential Revision: https://phabricator.services.mozilla.com/D127482
2021-10-05 09:40:00 +00:00
bool aIsMeter);
Bug 1694059 - Use WebRender to render most non-native-theme widgets when possible. r=mstange We basically use a couple primitives to draw these (PaintRoundedRectWithRadius, FillRect), so making the code a bit generic implementing stuff with WebRender seems straight-forward. I've kept using the fallback codepath for the bits that draw complex paths like arrows and such, but the rest of the things should work with this patch. A thing I'm not too happy about is the scrollbar painting setup (requires a lot of boilerplate), but modulo template hacks make nsNativeBasicTheme a template that receives its super class as a parameter or something) it seems hard to do better. Differential Revision: https://phabricator.services.mozilla.com/D105931
2021-02-23 10:49:37 +00:00
template <typename PaintBackendData>
void PaintButton(nsIFrame*, PaintBackendData&, const LayoutDeviceRect&,
Bug 1868338 - Improve non-native toolbarbutton appearance. r=dao,stransky Differential Revision: https://phabricator.services.mozilla.com/D195546
2023-12-06 08:33:33 +00:00
StyleAppearance, const ElementState&, const Colors&,
DPIRatio);
Bug 1640195: Address UX feedback for non-native widget styling. r=geckoview-reviewers,emilio,agi Differential Revision: https://phabricator.services.mozilla.com/D76509
2020-07-30 17:02:02 +00:00
Bug 1719427: Move scrollbar size information from prefs to C++ and allow sizing to be overridden via prefs. r=emilio Differential Revision: https://phabricator.services.mozilla.com/D130671
2021-11-15 12:39:39 +00:00
static void PrefChangedCallback(const char*, void*) {
LookAndFeel::NotifyChangedAllWindows(ThemeChangeKind::Layout);
}
Backed out 4 changesets (bug 1719427) for causing build bustages. CLOSED TREE Backed out changeset d6948ef7f495 (bug 1719427) Backed out changeset 4df7017f6bc9 (bug 1719427) Backed out changeset 8c5bb08f80e9 (bug 1719427) Backed out changeset e32004dd2014 (bug 1719427)
2021-11-15 11:46:20 +00:00
Bug 1749645 - Rename nsNativeBasicTheme{,Cocoa} to Theme{,Cocoa}. r=mstange We have this situation right now where all the themes are inheriting from nsNativeBasicTheme. Rename it to a nicer name, and clean up some code while at it. In the future I'd like to simplify the inheritance chain to remove nsNativeTheme altogether (so that all nsITheme implementations use mozilla::widget::Theme). That's not hard to do mechanically, but rather than dumping all of nsNativeTheme into Theme I'd like to do it a bit more carefully, to hopefully remove a lot of the helpers that nsNativeTheme has to deal with XUL and so on and use something nicer. Eventually the inheritance chain will be something like: * nsITheme : public nsISupports * Theme : public nsITheme, public nsITimerCallback, public nsINamed * ThemeCocoa : public Theme * nsNativeThemeCocoa : public ThemeCocoa * nsNativeThemeWin : public Theme * nsNativeThemeGtk : public Theme Differential Revision: https://phabricator.services.mozilla.com/D135668
2022-01-12 16:33:31 +00:00
void SetScrollbarDrawing(UniquePtr<ScrollbarDrawing>&& aScrollbarDrawing) {
Bug 1719427: Move scrollbar size information from prefs to C++ and allow sizing to be overridden via prefs. r=emilio Differential Revision: https://phabricator.services.mozilla.com/D130671
2021-11-15 12:39:39 +00:00
mScrollbarDrawing = std::move(aScrollbarDrawing);
Bug 1749531 - Move RecomputeScrollbarParams call to SetScrollbarDrawing. r=mstange Depends on D136127 Differential Revision: https://phabricator.services.mozilla.com/D136128
2022-01-25 21:31:43 +00:00
mScrollbarDrawing->RecomputeScrollbarParams();
Bug 1719427: Move scrollbar size information from prefs to C++ and allow sizing to be overridden via prefs. r=emilio Differential Revision: https://phabricator.services.mozilla.com/D130671
2021-11-15 12:39:39 +00:00
}
Bug 1719427: Refactor scrollbar drawing code across platforms. r=emilio Differential Revision: https://phabricator.services.mozilla.com/D129265
2021-11-15 12:39:38 +00:00
ScrollbarDrawing& GetScrollbarDrawing() const { return *mScrollbarDrawing; }
Bug 1749645 - Rename nsNativeBasicTheme{,Cocoa} to Theme{,Cocoa}. r=mstange We have this situation right now where all the themes are inheriting from nsNativeBasicTheme. Rename it to a nicer name, and clean up some code while at it. In the future I'd like to simplify the inheritance chain to remove nsNativeTheme altogether (so that all nsITheme implementations use mozilla::widget::Theme). That's not hard to do mechanically, but rather than dumping all of nsNativeTheme into Theme I'd like to do it a bit more carefully, to hopefully remove a lot of the helpers that nsNativeTheme has to deal with XUL and so on and use something nicer. Eventually the inheritance chain will be something like: * nsITheme : public nsISupports * Theme : public nsITheme, public nsITimerCallback, public nsINamed * ThemeCocoa : public Theme * nsNativeThemeCocoa : public ThemeCocoa * nsNativeThemeWin : public Theme * nsNativeThemeGtk : public Theme Differential Revision: https://phabricator.services.mozilla.com/D135668
2022-01-12 16:33:31 +00:00
UniquePtr<ScrollbarDrawing> mScrollbarDrawing;
Backed out 4 changesets (bug 1719427) for causing build bustages. CLOSED TREE Backed out changeset d6948ef7f495 (bug 1719427) Backed out changeset 4df7017f6bc9 (bug 1719427) Backed out changeset 8c5bb08f80e9 (bug 1719427) Backed out changeset e32004dd2014 (bug 1719427)
2021-11-15 11:46:20 +00:00
Bug 1719427: Refactor scrollbar drawing code across platforms. r=emilio Differential Revision: https://phabricator.services.mozilla.com/D129265
2021-11-15 12:39:38 +00:00
bool ThemeSupportsScrollbarButtons() override;
Bug 1381938: Add native theme for Windows that avoids native system calls. r=mstange,dbaron Differential Revision: https://phabricator.services.mozilla.com/D33310 --HG-- extra : moz-landing-system : lando
2020-02-10 19:26:01 +00:00
};
Bug 1749645 - Rename nsNativeBasicTheme{,Cocoa} to Theme{,Cocoa}. r=mstange We have this situation right now where all the themes are inheriting from nsNativeBasicTheme. Rename it to a nicer name, and clean up some code while at it. In the future I'd like to simplify the inheritance chain to remove nsNativeTheme altogether (so that all nsITheme implementations use mozilla::widget::Theme). That's not hard to do mechanically, but rather than dumping all of nsNativeTheme into Theme I'd like to do it a bit more carefully, to hopefully remove a lot of the helpers that nsNativeTheme has to deal with XUL and so on and use something nicer. Eventually the inheritance chain will be something like: * nsITheme : public nsISupports * Theme : public nsITheme, public nsITimerCallback, public nsINamed * ThemeCocoa : public Theme * nsNativeThemeCocoa : public ThemeCocoa * nsNativeThemeWin : public Theme * nsNativeThemeGtk : public Theme Differential Revision: https://phabricator.services.mozilla.com/D135668
2022-01-12 16:33:31 +00:00
} // namespace widget
} // namespace mozilla
Bug 1381938: Add native theme for Windows that avoids native system calls. r=mstange,dbaron Differential Revision: https://phabricator.services.mozilla.com/D33310 --HG-- extra : moz-landing-system : lando
2020-02-10 19:26:01 +00:00
#endif
Reference in New Issue Copy Permalink