-
Notifications
You must be signed in to change notification settings - Fork 891
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Brave theme #351
Brave theme #351
Conversation
|
||
SkColor ThemeService::BrowserThemeProvider::GetColor(int id) const { | ||
+#if defined(BRAVE_CHROMIUM_BUILD) | ||
+ MAYBE_OVERRIDE_DEFAULT_COLOR_FOR_BRAVE(id, incognito_, theme_service_.profile()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why aren't we just using a theme service with the color we want?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Clients can get color value from ui::ThemeProvider
interface and BrowserThemeProvider
is the implementation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't understand. The ThemeService comes from ThemeServiceFactory and we can change that by creating our own and doing a preprocessor replace in ThemeServiceFactory
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
#define ThemeService BraveThemeService
, #define ThemeServiceWin BraveThemeServiceWin
, etc... no patch or additional prefs, etc... required
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
prefs is needed to store current theme type(dark or light).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think CustomThemeSupplier
is not an option for us if we will allow user theme extension install. Only one theme supplier is used at once.
When user installs theme, we don't have any chance to overriding any color values.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we want to override default colors,
calling MAYBE_OVERRIDE_DEFAULT_COLOR_FOR_BRAVE(id, incognito, profile())
before GetDefaultColor(id, incognito)
like below is not bad.
SkColor ThemeService::GetColor(int id,
bool incognito,
bool* has_custom_color) const {
DCHECK_CALLED_ON_VALID_SEQUENCE(sequence_checker_);
if (has_custom_color)
*has_custom_color = false;
// The incognito NTP always uses the default background color, unless there is
// a custom NTP background image. See also https://crbug.com/21798#c114.
if (id == ThemeProperties::COLOR_NTP_BACKGROUND && incognito &&
!HasCustomImage(IDR_THEME_NTP_BACKGROUND)) {
return ThemeProperties::GetDefaultColor(id, incognito);
}
SkColor color;
const int theme_supplier_id = incognito ? GetIncognitoId(id) : id;
if (theme_supplier_ && theme_supplier_->GetColor(theme_supplier_id, &color)) {
if (has_custom_color)
*has_custom_color = true;
return color;
}
#if defined(BRAVE_CHROMIUM_BUILD)
MAYBE_OVERRIDE_DEFAULT_COLOR_FOR_BRAVE(id, incognito, profile())
#endif
return GetDefaultColor(id, incognito);
}
With this, user installed theme is applied(if exist) and we can override NotOverwritableByUserThemeProperty
properties.
Also, we can do this by overriding GetDefaultColor().
This method will introduce new three classes BraveThemeServiceWin
,
BraveThemeServiceAuraX11
and BraveThemeService
.
We can use overriding technique for BraveThemeServiceWin
and BraveThemeServiceAuraX11
w/o patching. However, BraveThemeService
needs patching because there are many ThemeService
in theme_service_factory.cc
.
So, overriding GetDefaultColor() causes three new classes and patch file.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
BraveThemeService does not need patching
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
and we don't even necessarily need our own CustomThemeSupplier if we're overriding ThemeService
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this just isn't a scalable method of making changes, we can't keep patching in hacks like this now that we have better ways to handle it
browser/themes/BUILD.gn
Outdated
@@ -2,8 +2,11 @@ source_set("themes") { | |||
sources = [ | |||
"theme_properties.cc", | |||
"theme_properties.h", | |||
"theme_util.cc", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
these should be in a test only target
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
those apis will be used by settings handler to change theme preference.
71c89a9
to
daf9f68
Compare
* You can obtain one at http://mozilla.org/MPL/2.0/. */ | ||
|
||
#include "build/build_config.h" // For OS_LINUX | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we need to include theme_service.h before we do anything else so we don't accidentally modify it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done.
browser/themes/theme_properties.h
Outdated
|
||
#define MAYBE_OVERRIDE_DEFAULT_COLOR_FOR_BRAVE(id, incognito) \ | ||
const base::Optional<SkColor> braveColor = MaybeGetDefaultColorForBraveUi(id, incognito); \ | ||
#define MAYBE_OVERRIDE_DEFAULT_COLOR_FOR_BRAVE(id, incognito, profile) \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we need this anymore, we can just call BraveThemeService::GetColor
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, I can't catch what you mean.
ThemeService::GetColor()
is private method.
Also, BraveThemeService::GetDefaultColor()
gets color value using MAYBE_OVERRIDE...
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm saying that BraveThemeService::GetColor shouldn't use MAYBE_OVERRIDE_DEFAULT_COLOR_FOR_BRAVE
and everything else should call BraveThemeService::GetColor
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
there's no reason to use a define
for this anymore. It was a hack to allow us to return in the calling method
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
at the very least you could call MaybeGetDefaultColorForBraveUi
directly, but we can move the logic from MaybeGetDefaultColorForBraveUi
into BraveThemeService and get rid of both
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the problem with the macro is that it hides the fact that it will sometimes return early in the method. That should be explicit inside the method.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This macro is deleted.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, ThemeServiceWin
and ThemeServiceAuraX11
became a subclass of BraveThemeService
.
I think it's more clear class hierarchy.
browser/brave_profile_prefs.cc
Outdated
@@ -24,6 +25,8 @@ void RegisterProfilePrefs(user_prefs::PrefRegistrySyncable* registry) { | |||
|
|||
RegisterAlternatePrivateSearchEngineProfilePrefs(registry); | |||
|
|||
RegisterProfilePrefsForBraveThemeType(registry); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
RegisterProfilePrefsForBraveThemeType
-> BraveThemeService::RegisterProfilePrefs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done, all apis in theme_util is moved to static method of BraveThemeService
.
995074b
to
b6bc7f1
Compare
#include "chrome/browser/themes/theme_properties.h" | ||
#include "testing/gtest/include/gtest/gtest.h" | ||
|
||
TEST(BraveThemeTest, ObtainsBraveOverrideColors) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bbondy This test isn't valid anymore because overriding isn't done in ThemeProperties::GetDefaultColor
.
Instead, newly added BraveThemeServiceTest
covers it.
browser/themes/BUILD.gn
Outdated
deps = [ | ||
"//base", | ||
"//components/version_info", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks like we also need //brave/common
, //components/prefs
, //components/pref_registry
and possibly //chrome/browser
unless that causes a circular dependency issue
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
also //chrome/common
from theme_properties
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done except //chrome/browser
(circular)
browser/themes/BUILD.gn
Outdated
deps = [ | ||
"//base", | ||
"//components/version_info", | ||
"//net", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why net
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Deleted. gn complained about net headers but I think it is fixed by above addition.
#define DISALLOW_COPY_AND_ASSIGN(TypeName) \ | ||
DISALLOW_COPY(TypeName); \ | ||
DISALLOW_ASSIGN(TypeName); \ | ||
friend class BraveThemeServiceWin |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we need to check TypeName
here to prevent accidentally inserting the friend
into other headers
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
DISALLOW_COPY(TypeName); \ | ||
DISALLOW_ASSIGN(TypeName) | ||
|
||
#undef ThemeService |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we need to restore the original ThemeService here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added #define ThemeService ThemeService
.
However, there is no problem whether it added or not.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, but it's safer this way in case something else includes this
} | ||
|
||
// static | ||
int BraveThemeService::GetBraveThemeType(Profile* profile) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think GetBraveThemeType and SetBraveThemeType should go into brave_theme_service_browsertest.cc or into another file target that is testonly. We don't want people to accidentally use these outside of tests
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We will have a setting option to switch dark or light. These apis can be used from settings hander.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we would handle that with a pref observer. In either case I don't think we should call NotifyThemeChanged
like that outside of tests. It isn't correct usage because the theme hasn't actually changed at that point
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't mind GetBraveThemeType, but it should return a BraveThemeType
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In fact I think we need a pref observer now for this to work correctly. We're basically counting on something else updating the UI and triggering a refresh of the theme values
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess technically the theme has changed when you change the pref value, but the pref observer should call NotifyThemeChanged
because that isn't even happening outside of tests right now
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
also the prefs UI isn't set up to deal with something like SetBraveThemeType
. It just changes the pref value and pref observers are supposed to take care of the rest
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about making SetBraveThemeType
just change prefs and BraveThemeService
act as our prefs observer?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess that's fine, I just don't see the point of having SetBraveThemeType
if it's just setting the pref. We'll never use it in the browser because the UI will set the pref directly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Setter is moved to test file and BraveThemeService observers prefs and will trigger theme change notification.
Getter is used by MaybeGetDefaultColorForBraveUi()
.
48ee6f3
to
d98787e
Compare
#define DISALLOW_COPY_AND_ASSIGN(TypeName) \ | ||
DISALLOW_COPY(TypeName); \ | ||
DISALLOW_ASSIGN(TypeName); \ | ||
static_assert(strings_equal(#TypeName, "ThemeServiceWin"), "Use only for ThemeServiceWin"); \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just leaving a comment here from our DM discussion to make sure we don't forget to change this to selectively apply friend
instead of asserting
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will be reverted to patching friend class
. I can't find how conditionally add in macro.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I concur. Not worth the time right now
With kBraveThemeType, we can switch dark/light theme.
With this, theme extension have a chance to override theme color.
BraveThemeService became subclass of ThemeServiceAuraX11 and ThemeServiceWin. Also apis in theme_util.h are moved to static methods of BraveThemeService.
This unittest can't be used because override is done in ThemeService. BraveThemeServiceTest can cover this test. Also static check is added to prevent other class should not use newly defined DISALLOW_COPY_AND_ASSIGN.
I tried to conditionally add friend statement in DISALLOW_COPY_AND_ASSIGN. However, I can't find how to do it in macro.
d7fffa3
to
3a72c6c
Compare
~ThemeServiceWin() override; | ||
|
||
private: | ||
+#if defined(BRAVE_CHROMIUM_BUILD) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just fyi - we don't need #if defined(BRAVE_CHROMIUM_BUILD)
for these because they don't change behavior for the original class
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done. Thanks!
Add support for translating brave_generated_resources.grd
Close brave/brave-browser#808
Issue brave/brave-browser#789
Captured image on Win10.
Submitter Checklist:
git rebase -i
to squash commits (if needed).Test Plan:
yarn test brave_browser_tests --filter=BraveThemeServiceTest.BraveThemeChangeTest
Reviewer Checklist: