mozilla
/
gecko-dev
зеркало из https://github.com/mozilla/gecko-dev.git
1
0
Форкнуть 0
Код Задачи Пакеты Проекты Релизы Вики Активность
gecko-dev/widget/nsNativeBasicTheme.h

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

410 строки
20 KiB
C
Исходник Обычный вид История

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 22:26:01 +03: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/. */
#ifndef nsNativeBasicTheme_h
#define nsNativeBasicTheme_h
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 15:04:29 +03: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 22:26:01 +03:00
#include "nsITheme.h"
#include "nsNativeTheme.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 20:02:02 +03: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 17:44:13 +03:00
enum class StyleSystemColor : uint8_t;
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 20:02:02 +03:00
namespace widget {
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 15:04:29 +03:00
static const gfx::sRGBColor sColorWhite(gfx::sRGBColor::OpaqueWhite());
static const gfx::sRGBColor sColorWhiteAlpha50(gfx::sRGBColor::White(0.5f));
static const gfx::sRGBColor sColorWhiteAlpha80(gfx::sRGBColor::White(0.8f));
static const gfx::sRGBColor sColorBlack(gfx::sRGBColor::OpaqueBlack());
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 20:02:02 +03: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 15:04:29 +03:00
static const gfx::sRGBColor sColorGrey10(
gfx::sRGBColor::UnusualFromARGB(0xffe9e9ed));
static const gfx::sRGBColor sColorGrey10Alpha50(
gfx::sRGBColor::UnusualFromARGB(0x7fe9e9ed));
static const gfx::sRGBColor sColorGrey20(
gfx::sRGBColor::UnusualFromARGB(0xffd0d0d7));
static const gfx::sRGBColor sColorGrey30(
gfx::sRGBColor::UnusualFromARGB(0xffb1b1b9));
static const gfx::sRGBColor sColorGrey40(
gfx::sRGBColor::UnusualFromARGB(0xff8f8f9d));
static const gfx::sRGBColor sColorGrey40Alpha50(
gfx::sRGBColor::UnusualFromARGB(0x7f8f8f9d));
static const gfx::sRGBColor sColorGrey50(
gfx::sRGBColor::UnusualFromARGB(0xff676774));
static const gfx::sRGBColor sColorGrey50Alpha50(
gfx::sRGBColor::UnusualFromARGB(0x7f676774));
static const gfx::sRGBColor sColorGrey60(
gfx::sRGBColor::UnusualFromARGB(0xff484851));
static const gfx::sRGBColor sColorGrey60Alpha50(
gfx::sRGBColor::UnusualFromARGB(0x7f484851));
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 20:02:02 +03: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 15:04:29 +03:00
static const gfx::sRGBColor sColorMeterGreen10(
gfx::sRGBColor::UnusualFromARGB(0xff00ab60));
static const gfx::sRGBColor sColorMeterGreen20(
gfx::sRGBColor::UnusualFromARGB(0xff056139));
static const gfx::sRGBColor sColorMeterYellow10(
gfx::sRGBColor::UnusualFromARGB(0xffffbd4f));
static const gfx::sRGBColor sColorMeterYellow20(
gfx::sRGBColor::UnusualFromARGB(0xffd2811e));
static const gfx::sRGBColor sColorMeterRed10(
gfx::sRGBColor::UnusualFromARGB(0xffe22850));
static const gfx::sRGBColor sColorMeterRed20(
gfx::sRGBColor::UnusualFromARGB(0xff810220));
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 20:02:02 +03:00
Bug 1615038: Fine-tune scrollbars in the non-native theme on Windows. r=emilio Differential Revision: https://phabricator.services.mozilla.com/D102094
2021-01-21 00:33:34 +03:00
static const gfx::sRGBColor sScrollbarColor(
gfx::sRGBColor::UnusualFromARGB(0xfff0f0f0));
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 15:04:29 +03:00
static const gfx::sRGBColor sScrollbarBorderColor(gfx::sRGBColor(1.0f, 1.0f,
1.0f));
Bug 1615038: Fine-tune scrollbars in the non-native theme on Windows. r=emilio Differential Revision: https://phabricator.services.mozilla.com/D102094
2021-01-21 00:33:34 +03:00
static const gfx::sRGBColor sScrollbarThumbColor(
gfx::sRGBColor::UnusualFromARGB(0xffcdcdcd));
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 20:02:02 +03:00
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 07:48:07 +03:00
static const CSSCoord kMinimumColorPickerHeight = 32.0f;
static const CSSCoord kMinimumRangeThumbSize = 20.0f;
static const CSSCoord kMinimumDropdownArrowButtonWidth = 18.0f;
Bug 1674431 - Size the non-native theme number spinner buttons more sensibly. r=spohl Use the same width as the select arrow button makes sense to me and fixes all the reported problems so far. Also tweak the sizing / painting to take less height since these have a background, so stuff like: <input type=number style="height: 100px"> Looks super ugly otherwise. The new polygon coordinates are the result of scaling by 1.5 and centering vertically the arrow, which gives the same visual effect for the regular input without margin / padding, but prevents the issue described above with too-tall inputs or inputs with lots of padding. We might want to shrink them a bit more if needed, but I think this is alright. For reference, Chrome uses 15px, but we remove the inline-end padding by default so we compensate a bit that way. If we don't like how this looks when the author specifies padding on the input (see comment 13 for example), we might want to reconsider the design so that the spinners look good with padding, but that's a different task completely. Differential Revision: https://phabricator.services.mozilla.com/D102754
2021-01-22 19:09:35 +03:00
static const CSSCoord kMinimumSpinnerButtonWidth = 18.0f;
static const CSSCoord kMinimumSpinnerButtonHeight = 9.0f;
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 20:02:02 +03:00
static const CSSCoord kButtonBorderWidth = 1.0f;
static const CSSCoord kMenulistBorderWidth = 1.0f;
static const CSSCoord kTextFieldBorderWidth = 1.0f;
static const CSSCoord kRangeHeight = 6.0f;
static const CSSCoord kProgressbarHeight = 6.0f;
static const CSSCoord kMeterHeight = 12.0f;
Bug 1675389 - Tweak the baseline of checkbox/radio buttons on the non-native theme. r=spohl Differential Revision: https://phabricator.services.mozilla.com/D102478
2021-01-20 23:08:35 +03:00
// nsCheckboxRadioFrame takes the bottom of the content box as the baseline.
// This border-width makes its baseline 2px under the bottom, which is nice.
Bug 1695741 - Choose more round points for windows scroll button arrows. r=mstange This should help with fuzziness in some tests, and also look nicer. Differential Revision: https://phabricator.services.mozilla.com/D106823
2021-03-02 01:55:37 +03:00
static constexpr CSSCoord kCheckboxRadioBorderWidth = 2.0f;
Bug 1675389 - Tweak the baseline of checkbox/radio buttons on the non-native theme. r=spohl Differential Revision: https://phabricator.services.mozilla.com/D102478
2021-01-20 23:08:35 +03:00
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 20:02:02 +03: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 22:26:01 +03:00
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-06 00:15:18 +03:00
class nsNativeBasicTheme : protected nsNativeTheme, public nsITheme {
protected:
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 15:04:29 +03:00
using sRGBColor = mozilla::gfx::sRGBColor;
using CSSCoord = mozilla::CSSCoord;
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 07:48:07 +03:00
using CSSPoint = mozilla::CSSPoint;
Backed out changeset 3e90a3759639 (bug 1679208) for scrollbars-no-margin.html failures CLOSED TREE
2020-12-03 02:11:32 +03:00
using CSSIntCoord = mozilla::CSSIntCoord;
Bug 1670853 - Unified build fix. Differential Revision: https://phabricator.services.mozilla.com/D93628
2020-10-15 07:54:06 +03:00
using ComputedStyle = mozilla::ComputedStyle;
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 15:04:29 +03:00
using EventStates = mozilla::EventStates;
using DrawTarget = mozilla::gfx::DrawTarget;
using Path = mozilla::gfx::Path;
using Rect = mozilla::gfx::Rect;
Bug 1674010 - Draw a shadow under the range thumb in the basic theme. r=spohl What's implemented in this patch doesn't match the spec to 100%, but it comes pretty close. This patch is cutting two corners: We're only using one shadow instead of two, and we're using a smaller blur radius (2 instead of 2 and 4). Both adjustments are done to improve performance; blurring is a computationally expensive operation, so we should minimize its cost. As the shadow color, I'm using a transparent black instead of a transparent gray, because this makes it easier to do the blurring on an A8 surface rather than on a full RGBA surface, given the current Moz2D API. Differential Revision: https://phabricator.services.mozilla.com/D95090
2020-11-02 20:09:05 +03:00
using Point = mozilla::gfx::Point;
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 15:04:29 +03:00
using RectCornerRadii = mozilla::gfx::RectCornerRadii;
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 07:48:07 +03:00
using LayoutDeviceCoord = mozilla::LayoutDeviceCoord;
Bug 1679208 - Use more strongly typed rects in nsNativeBasicTheme. r=heycam As per review comments. Depends on D97937 Differential Revision: https://phabricator.services.mozilla.com/D98099
2020-11-30 01:19:10 +03:00
using LayoutDeviceRect = mozilla::LayoutDeviceRect;
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 15:04:29 +03: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 22:26:01 +03:00
public:
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 03:47:38 +03:00
static void Init();
static void Shutdown();
static void LookAndFeelChanged();
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 07:48:07 +03:00
using DPIRatio = mozilla::CSSToLayoutDeviceScale;
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 22:26:01 +03: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 19:18:33 +03:00
NS_IMETHOD DrawWidgetBackground(gfxContext* aContext, nsIFrame*,
StyleAppearance, const nsRect& aRect,
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 22:26:01 +03:00
const nsRect& aDirtyRect) 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 13:49:37 +03:00
struct WebRenderBackendData {
mozilla::wr::DisplayListBuilder& mBuilder;
mozilla::wr::IpcResourceUpdateQueue& mResources;
const mozilla::layers::StackingContextHelper& mSc;
mozilla::layers::RenderRootStateManager* mManager;
};
bool CreateWebRenderCommandsForWidget(
mozilla::wr::DisplayListBuilder& aBuilder,
mozilla::wr::IpcResourceUpdateQueue& aResources,
const mozilla::layers::StackingContextHelper& aSc,
mozilla::layers::RenderRootStateManager* aManager, nsIFrame*,
StyleAppearance, const nsRect& aRect) override;
// 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,
const nsRect& aRect);
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 19:18:33 +03: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-03 02:11:32 +03: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 19:18:33 +03: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 20:02:02 +03:00
nsRect* aOverflowRect) 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 19:18:33 +03:00
NS_IMETHOD GetMinimumWidgetSize(nsPresContext* aPresContext, nsIFrame*,
StyleAppearance,
Backed out changeset 3e90a3759639 (bug 1679208) for scrollbars-no-margin.html failures CLOSED TREE
2020-12-03 02:11:32 +03:00
mozilla::LayoutDeviceIntSize* aResult,
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 22:26:01 +03:00
bool* aIsOverridable) 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 19:18:33 +03:00
Transparency GetWidgetTransparency(nsIFrame*, StyleAppearance) override;
NS_IMETHOD WidgetStateChanged(nsIFrame*, StyleAppearance, nsAtom* aAttribute,
bool* aShouldRepaint,
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 22:26:01 +03:00
const nsAttrValue* aOldValue) override;
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 19:18:33 +03: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 20:02:02 +03: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 19:18:33 +03: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 03:05:51 +03: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 19:18:33 +03:00
bool WidgetIsContainer(StyleAppearance) override;
bool ThemeDrawsFocusForWidget(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 22:26:01 +03:00
bool ThemeNeedsComboboxDropmarker() override;
Bug 1689615 - Only paint one outline for outline-style:auto with nnt. r=mstange outline-style: auto might show up in non-themed controls and such, and the double-outline there might look ugly. Following border-radius would be an extra improvement for the reddit case, but no platform does it currently (Safari on macOS does it), so let's consider that in a follow-up. Differential Revision: https://phabricator.services.mozilla.com/D104214
2021-02-05 19:25:57 +03:00
ScrollbarSizes GetScrollbarSizes(nsPresContext*, StyleScrollbarWidth,
Bug 1689253 - Add a more sensible scrollbar size API to nsITheme, and use it to replace ScrollbarNonDisappearing. r=spohl There's no reason we should need an scrollbar box to query the size of a scrollbar. I plan to use this in the following patch to make the size of a resizer not vary depending on whether the container has scrollbars or not, which is what ultimately causes the reftest failure. Differential Revision: https://phabricator.services.mozilla.com/D103302
2021-01-29 01:11:54 +03:00
Overlay) override;
Bug 1690700 - Improve scrollbars for non-native GTK theme. r=mstange This is based on the windows implementation and has two nice things: * Makes scrollbar-color react to active / hover state, like on Windows. * Implements dark scrollbar support. Differential Revision: https://phabricator.services.mozilla.com/D103969
2021-02-04 19:15:27 +03:00
static nscolor AdjustUnthemedScrollbarThumbColor(nscolor, EventStates);
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 17:44:13 +03:00
static nscolor GetScrollbarButtonColor(nscolor aTrackColor, EventStates);
static nscolor GetScrollbarArrowColor(nscolor aButtonColor);
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 22:26:01 +03:00
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 03:13:10 +03:00
nscoord GetCheckboxRadioPrefSize() 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 22:26:01 +03:00
protected:
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 20:02:02 +03:00
nsNativeBasicTheme() = default;
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 22:26:01 +03:00
virtual ~nsNativeBasicTheme() = 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 20:02:02 +03:00
Bug 1689253 - Add a more sensible scrollbar size API to nsITheme, and use it to replace ScrollbarNonDisappearing. r=spohl There's no reason we should need an scrollbar box to query the size of a scrollbar. I plan to use this in the following patch to make the size of a resizer not vary depending on whether the container has scrollbars or not, which is what ultimately causes the reftest failure. Differential Revision: https://phabricator.services.mozilla.com/D103302
2021-01-29 01:11:54 +03:00
static DPIRatio GetDPIRatioForScrollbarPart(nsPresContext*);
static DPIRatio GetDPIRatio(nsPresContext*, StyleAppearance);
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 19:18:33 +03:00
static DPIRatio GetDPIRatio(nsIFrame*, StyleAppearance);
static bool IsDateTimeResetButton(nsIFrame*);
static bool IsColorPickerButton(nsIFrame*);
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 20:02:02 +03:00
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 17:44:13 +03:00
// Whether we should use system colors (for high contrast mode).
enum class UseSystemColors : bool { No, Yes };
static UseSystemColors ShouldUseSystemColors(const mozilla::dom::Document&);
std::pair<sRGBColor, sRGBColor> ComputeCheckboxColors(const EventStates&,
StyleAppearance,
UseSystemColors);
sRGBColor ComputeCheckmarkColor(const EventStates&, UseSystemColors);
sRGBColor ComputeBorderColor(const EventStates&, UseSystemColors);
std::pair<sRGBColor, sRGBColor> ComputeButtonColors(const EventStates&,
UseSystemColors,
nsIFrame* = nullptr);
std::pair<sRGBColor, sRGBColor> ComputeTextfieldColors(const EventStates&,
UseSystemColors);
std::pair<sRGBColor, sRGBColor> ComputeRangeProgressColors(const EventStates&,
UseSystemColors);
std::pair<sRGBColor, sRGBColor> ComputeRangeTrackColors(const EventStates&,
UseSystemColors);
std::pair<sRGBColor, sRGBColor> ComputeRangeThumbColors(const EventStates&,
UseSystemColors);
std::pair<sRGBColor, sRGBColor> ComputeProgressColors(UseSystemColors);
std::pair<sRGBColor, sRGBColor> ComputeProgressTrackColors(UseSystemColors);
std::pair<sRGBColor, sRGBColor> ComputeMeterchunkColors(
const EventStates& aMeterState, UseSystemColors);
sRGBColor ComputeMenulistArrowButtonColor(const EventStates&,
UseSystemColors);
std::array<sRGBColor, 3> ComputeFocusRectColors(UseSystemColors);
static bool ShouldUseDarkScrollbar(nsIFrame*, const ComputedStyle&);
virtual sRGBColor ComputeScrollbarColor(nsIFrame*, const ComputedStyle&,
const EventStates& aDocumentState,
UseSystemColors);
Bug 1615038: Fine-tune scrollbars in the non-native theme on Windows. r=emilio Differential Revision: https://phabricator.services.mozilla.com/D102094
2021-01-21 00:33:34 +03:00
virtual sRGBColor ComputeScrollbarThumbColor(
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 19:18:33 +03:00
nsIFrame*, const ComputedStyle&, const EventStates& aElementState,
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 17:44:13 +03:00
const EventStates& aDocumentState, UseSystemColors);
// Returned colors are button, arrow.
std::pair<sRGBColor, sRGBColor> ComputeScrollbarButtonColors(
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 19:18:33 +03:00
nsIFrame*, StyleAppearance, const ComputedStyle&,
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 17:44:13 +03:00
const EventStates& aElementState, const EventStates& aDocumentState,
UseSystemColors);
Bug 1675015: Add Windows high contrast support to non-native theme. r=heycam Differential Revision: https://phabricator.services.mozilla.com/D96803
2020-11-17 23:53:01 +03: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 13:49:37 +03:00
template <typename PaintBackendData>
void PaintRoundedFocusRect(PaintBackendData&, const LayoutDeviceRect&,
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 17:44:13 +03:00
UseSystemColors, 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 13:49:37 +03:00
template <typename PaintBackendData>
void PaintAutoStyleOutline(nsIFrame*, PaintBackendData&,
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 17:44:13 +03:00
const LayoutDeviceRect&, UseSystemColors,
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 13:49:37 +03:00
static void PaintRoundedRectWithRadius(DrawTarget&,
const LayoutDeviceRect& aRect,
const LayoutDeviceRect& aClipRect,
const sRGBColor& aBackgroundColor,
const sRGBColor& aBorderColor,
CSSCoord aBorderWidth,
CSSCoord aRadius, DPIRatio);
static void PaintRoundedRectWithRadius(WebRenderBackendData&,
const LayoutDeviceRect& aRect,
const LayoutDeviceRect& aClipRect,
const sRGBColor& aBackgroundColor,
const sRGBColor& aBorderColor,
CSSCoord aBorderWidth,
CSSCoord aRadius, DPIRatio);
template <typename PaintBackendData>
static void PaintRoundedRectWithRadius(PaintBackendData& aData,
const LayoutDeviceRect& aRect,
const sRGBColor& aBackgroundColor,
const sRGBColor& aBorderColor,
CSSCoord aBorderWidth,
CSSCoord aRadius, DPIRatio aDpiRatio) {
PaintRoundedRectWithRadius(aData, aRect, aRect, aBackgroundColor,
aBorderColor, aBorderWidth, aRadius, aDpiRatio);
}
static void FillRect(DrawTarget&, const LayoutDeviceRect&, const sRGBColor&);
static void FillRect(WebRenderBackendData&, 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 19:18:33 +03:00
void PaintCheckboxControl(DrawTarget& aDrawTarget, const LayoutDeviceRect&,
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 17:44:13 +03:00
const EventStates&, UseSystemColors, DPIRatio);
void PaintCheckMark(DrawTarget&, const LayoutDeviceRect&, const EventStates&,
UseSystemColors);
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 19:18:33 +03:00
void PaintIndeterminateMark(DrawTarget&, const LayoutDeviceRect&,
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 17:44:13 +03:00
const EventStates&, UseSystemColors);
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-24 02:22:19 +03: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 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 17:44:13 +03:00
const EventStates&, UseSystemColors, 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-24 02:22:19 +03:00
template <typename PaintBackendData>
void PaintRadioCheckmark(PaintBackendData&, 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 19:18:33 +03:00
const EventStates&, 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 13:49:37 +03:00
template <typename PaintBackendData>
void PaintTextField(PaintBackendData&, const LayoutDeviceRect&,
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 17:44:13 +03:00
const EventStates&, UseSystemColors, 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 13:49:37 +03:00
template <typename PaintBackendData>
void PaintListbox(PaintBackendData&, const LayoutDeviceRect&,
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 17:44:13 +03:00
const EventStates&, UseSystemColors, 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 13:49:37 +03:00
template <typename PaintBackendData>
void PaintMenulist(PaintBackendData&, const LayoutDeviceRect&,
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 17:44:13 +03:00
const EventStates&, UseSystemColors, DPIRatio);
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 19:18:33 +03:00
void PaintArrow(DrawTarget&, const LayoutDeviceRect&,
Bug 1615038: Fine-tune scrollbar arrow buttons in the non-native theme. r=emilio Differential Revision: https://phabricator.services.mozilla.com/D102352
2021-01-21 00:54:58 +03:00
const float aArrowPolygonX[], const float aArrowPolygonY[],
Bug 1695741 - Choose more round points for windows scroll button arrows. r=mstange This should help with fuzziness in some tests, and also look nicer. Differential Revision: https://phabricator.services.mozilla.com/D106823
2021-03-02 01:55:37 +03:00
const float aArrowPolygonSize, const int32_t aArrowNumPoints,
const sRGBColor aFillColor);
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 19:18:33 +03:00
void PaintMenulistArrowButton(nsIFrame*, DrawTarget&, const LayoutDeviceRect&,
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 17:44:13 +03:00
const EventStates&, UseSystemColors);
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 19:18:33 +03:00
void PaintSpinnerButton(nsIFrame*, DrawTarget&, const LayoutDeviceRect&,
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 17:44:13 +03:00
const EventStates&, StyleAppearance, UseSystemColors,
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-24 02:22:19 +03:00
template <typename PaintBackendData>
void PaintRange(nsIFrame*, PaintBackendData&, const LayoutDeviceRect&,
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 17:44:13 +03:00
const EventStates&, UseSystemColors, DPIRatio,
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 13:49:37 +03:00
template <typename PaintBackendData>
void PaintProgress(nsIFrame*, PaintBackendData&, const LayoutDeviceRect&,
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 17:44:13 +03:00
const EventStates&, UseSystemColors, DPIRatio,
Bug 1698302 - Paint progress/meter chunks along with the track. r=mstange The progress chunk already has the right size, but it's easier to get the right clipping if we just paint it as part of the progress bar. This is much like we paint the range track and thumb. We apply the native appearance atomically so this should be fine. Differential Revision: https://phabricator.services.mozilla.com/D108335
2021-03-16 00:01:08 +03: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 13:49:37 +03:00
template <typename PaintBackendData>
void PaintButton(nsIFrame*, PaintBackendData&, const LayoutDeviceRect&,
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 17:44:13 +03:00
const EventStates&, UseSystemColors, 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 20:02:02 +03: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 13:49:37 +03:00
void PaintScrollbarButton(DrawTarget&, StyleAppearance,
const LayoutDeviceRect&, nsIFrame*,
const ComputedStyle&,
const EventStates& aElementState,
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 17:44:13 +03:00
const EventStates& aDocumentState, UseSystemColors,
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 13:49:37 +03:00
virtual bool PaintScrollbarThumb(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 19:18:33 +03:00
bool aHorizontal, nsIFrame*,
const ComputedStyle&,
Bug 1673121 - Simplify nsNativeBasicTheme scrollbar painting methods. r=spohl This removes some duplication and replaces it with a bool aHorizontal parameter. It also splits out scroll corner drawing into its own method. And it consistently passes down the DPI ratio into all methods. Drive-by fixes: - The border of horizontal scrollbars in the default theme now scales with the DPI ratio. - The border is device-pixel aligned by insetting the stroked rectangle by half the stroke width. This patch also changes the scroll corner drawing in the default theme to no longer draw a border on the left. We can revert that if needed Differential Revision: https://phabricator.services.mozilla.com/D94662
2020-10-27 18:27:31 +03:00
const EventStates& aElementState,
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 17:44:13 +03:00
const EventStates& aDocumentState,
UseSystemColors, 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 13:49:37 +03:00
virtual bool PaintScrollbarThumb(WebRenderBackendData&,
const LayoutDeviceRect&, bool aHorizontal,
nsIFrame*, const ComputedStyle&,
const EventStates& aElementState,
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 17:44:13 +03:00
const EventStates& aDocumentState,
UseSystemColors, 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 13:49:37 +03:00
template <typename PaintBackendData>
bool DoPaintDefaultScrollbarThumb(PaintBackendData&, const LayoutDeviceRect&,
bool aHorizontal, nsIFrame*,
const ComputedStyle&,
const EventStates& aElementState,
const EventStates& aDocumentState,
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 17:44:13 +03:00
UseSystemColors aUseSystemColors, 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 13:49:37 +03:00
virtual bool PaintScrollbar(DrawTarget&, const LayoutDeviceRect&,
bool aHorizontal, nsIFrame*, const ComputedStyle&,
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 17:44:13 +03:00
const EventStates& aDocumentState,
UseSystemColors, 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 13:49:37 +03:00
virtual bool PaintScrollbar(WebRenderBackendData&, 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 19:18:33 +03:00
bool aHorizontal, nsIFrame*, const ComputedStyle&,
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 17:44:13 +03:00
const EventStates& aDocumentState,
UseSystemColors, 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 13:49:37 +03:00
template <typename PaintBackendData>
bool DoPaintDefaultScrollbar(PaintBackendData&, const LayoutDeviceRect&,
bool aHorizontal, nsIFrame*,
const ComputedStyle&,
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 17:44:13 +03:00
const EventStates& aDocumentState,
UseSystemColors aUseSystemColors, 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 13:49:37 +03:00
virtual bool PaintScrollbarTrack(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 19:18:33 +03:00
bool aHorizontal, nsIFrame*,
const ComputedStyle&,
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 13:49:37 +03:00
const EventStates& aDocumentState,
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 17:44:13 +03:00
UseSystemColors, 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 13:49:37 +03:00
// Draw nothing by default. Subclasses can override this.
return true;
}
virtual bool PaintScrollbarTrack(WebRenderBackendData&,
const LayoutDeviceRect&, bool aHorizontal,
nsIFrame*, const ComputedStyle&,
const EventStates& aDocumentState,
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 17:44:13 +03:00
UseSystemColors, 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 13:49:37 +03:00
// Draw nothing by default. Subclasses can override this.
return true;
}
virtual bool PaintScrollCorner(DrawTarget&, const LayoutDeviceRect&,
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 05:58:47 +03:00
nsIFrame*, const ComputedStyle&,
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 17:44:13 +03:00
const EventStates& aDocumentState,
UseSystemColors, 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 13:49:37 +03:00
virtual bool PaintScrollCorner(WebRenderBackendData&, const LayoutDeviceRect&,
nsIFrame*, const ComputedStyle&,
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 17:44:13 +03:00
const EventStates& aDocumentState,
UseSystemColors, 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 13:49:37 +03:00
template <typename PaintBackendData>
bool DoPaintDefaultScrollCorner(PaintBackendData&, const LayoutDeviceRect&,
nsIFrame*, const ComputedStyle&,
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 17:44:13 +03:00
const EventStates& aDocumentState,
UseSystemColors, DPIRatio);
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 03:47:38 +03:00
static sRGBColor sAccentColor;
static sRGBColor sAccentColorForeground;
// Note that depending on the exact accent color, lighter/darker might really
// be inverted.
static sRGBColor sAccentColorLight;
static sRGBColor sAccentColorDark;
static sRGBColor sAccentColorDarker;
Bug 1698783 - Respect Windows' system scrollbar sizes. r=mstange Depends on D108960 Differential Revision: https://phabricator.services.mozilla.com/D108973
2021-03-18 22:12:49 +03:00
static CSSIntCoord sHorizontalScrollbarHeight;
static CSSIntCoord sVerticalScrollbarWidth;
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 03:47:38 +03:00
Bug 1698783 - Respect Windows' system scrollbar sizes. r=mstange Depends on D108960 Differential Revision: https://phabricator.services.mozilla.com/D108973
2021-03-18 22:12:49 +03:00
static void PrefChangedCallback(const char*, void*) { LookAndFeelChanged(); }
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 03:47:38 +03:00
static void RecomputeAccentColors();
Bug 1698783 - Respect Windows' system scrollbar sizes. r=mstange Depends on D108960 Differential Revision: https://phabricator.services.mozilla.com/D108973
2021-03-18 22:12:49 +03:00
static void RecomputeScrollbarSizes();
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 22:26:01 +03:00
};
#endif