Skip to content
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

Merged
merged 7 commits into from
Aug 24, 2018
Merged

Brave theme #351

merged 7 commits into from
Aug 24, 2018

Conversation

simonhong
Copy link
Member

@simonhong simonhong commented Aug 22, 2018

  • Make our theme color chosen at first
  • Introduce kBraveThemeType preference to switch light and dark theme

Close brave/brave-browser#808
Issue brave/brave-browser#789

Captured image on Win10.
image

Submitter Checklist:

  • Submitted a ticket for my issue if one did not already exist.
  • Used Github auto-closing keywords in the commit message.
  • Added/updated tests for this change (for new code or code which already has tests).
  • Ran git rebase -i to squash commits (if needed).
  • Tagged reviewers and labelled the pull request as needed.
  • Request a security/privacy review as needed.
  • Add appropriate QA labels (QA/Needed or QA/No-QA-Needed) to include the closed issue in milestone

Test Plan:

yarn test brave_browser_tests --filter=BraveThemeServiceTest.BraveThemeChangeTest

Reviewer Checklist:

  • New files have MPL-2.0 license header.
  • Request a security/privacy review as needed.
  • Adequate test coverage exists to prevent regressions
  • Verify test plan is specified in PR before merging to source

@simonhong simonhong self-assigned this Aug 22, 2018
@simonhong simonhong requested a review from bbondy August 22, 2018 00:37
@simonhong simonhong changed the title Make our theme color chosen at first Brave theme Aug 22, 2018

SkColor ThemeService::BrowserThemeProvider::GetColor(int id) const {
+#if defined(BRAVE_CHROMIUM_BUILD)
+ MAYBE_OVERRIDE_DEFAULT_COLOR_FOR_BRAVE(id, incognito_, theme_service_.profile())
Copy link
Collaborator

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?

Copy link
Member Author

@simonhong simonhong Aug 22, 2018

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.

Copy link
Collaborator

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

Copy link
Collaborator

@bridiver bridiver Aug 22, 2018

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

Copy link
Member Author

@simonhong simonhong Aug 22, 2018

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).

Copy link
Member Author

@simonhong simonhong Aug 22, 2018

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.

Copy link
Member Author

@simonhong simonhong Aug 22, 2018

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.

Copy link
Collaborator

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

Copy link
Collaborator

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

Copy link
Collaborator

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

@@ -2,8 +2,11 @@ source_set("themes") {
sources = [
"theme_properties.cc",
"theme_properties.h",
"theme_util.cc",
Copy link
Collaborator

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

Copy link
Member Author

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.

@simonhong simonhong force-pushed the brave_theme branch 2 times, most recently from 71c89a9 to daf9f68 Compare August 23, 2018 02:47
* You can obtain one at http://mozilla.org/MPL/2.0/. */

#include "build/build_config.h" // For OS_LINUX

Copy link
Collaborator

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done.


#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) \
Copy link
Collaborator

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

Copy link
Member Author

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....

Copy link
Collaborator

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

Copy link
Collaborator

@bridiver bridiver Aug 23, 2018

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

Copy link
Collaborator

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

Copy link
Collaborator

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This macro is deleted.

Copy link
Member Author

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.

@@ -24,6 +25,8 @@ void RegisterProfilePrefs(user_prefs::PrefRegistrySyncable* registry) {

RegisterAlternatePrivateSearchEngineProfilePrefs(registry);

RegisterProfilePrefsForBraveThemeType(registry);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

RegisterProfilePrefsForBraveThemeType -> BraveThemeService::RegisterProfilePrefs

Copy link
Member Author

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.

@simonhong simonhong force-pushed the brave_theme branch 5 times, most recently from 995074b to b6bc7f1 Compare August 23, 2018 11:31
#include "chrome/browser/themes/theme_properties.h"
#include "testing/gtest/include/gtest/gtest.h"

TEST(BraveThemeTest, ObtainsBraveOverrideColors) {
Copy link
Member Author

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.

deps = [
"//base",
"//components/version_info",
Copy link
Collaborator

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

Copy link
Collaborator

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

Copy link
Member Author

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)

deps = [
"//base",
"//components/version_info",
"//net",
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why net?

Copy link
Member Author

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
Copy link
Collaborator

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

Copy link
Member Author

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
Copy link
Collaborator

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

Copy link
Member Author

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.

Copy link
Collaborator

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) {
Copy link
Collaborator

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

Copy link
Member Author

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.

Copy link
Collaborator

@bridiver bridiver Aug 24, 2018

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

Copy link
Collaborator

@bridiver bridiver Aug 24, 2018

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

Copy link
Collaborator

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

Copy link
Collaborator

@bridiver bridiver Aug 24, 2018

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

Copy link
Collaborator

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

Copy link
Member Author

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?

Copy link
Collaborator

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.

Copy link
Member Author

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().

@simonhong simonhong force-pushed the brave_theme branch 2 times, most recently from 48ee6f3 to d98787e Compare August 24, 2018 01:29
#define DISALLOW_COPY_AND_ASSIGN(TypeName) \
DISALLOW_COPY(TypeName); \
DISALLOW_ASSIGN(TypeName); \
static_assert(strings_equal(#TypeName, "ThemeServiceWin"), "Use only for ThemeServiceWin"); \
Copy link
Collaborator

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

Copy link
Member Author

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.

Copy link
Collaborator

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.
~ThemeServiceWin() override;

private:
+#if defined(BRAVE_CHROMIUM_BUILD)
Copy link
Collaborator

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done. Thanks!

bridiver
bridiver previously approved these changes Aug 24, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Our frame color isn't applied on Windows
3 participants