Closed Bug 1002469 Opened 10 years ago Closed 6 years ago

Themes framework

Categories

(Firefox OS Graveyard :: Gaia, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: zoran.jovanovic, Unassigned)

References

Details

Attachments

(3 files)

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.116 Safari/537.36

Steps to reproduce:

Adds a framework for customizing visual style of Gaia apps.

The theme feature can change application appearance, home screen background, software home button and adds a theme section in Settings application for end user to switch theme. Changes are processed immediately, allowing the user to instantly experience the new look and feel.

Initial drop:

* Theme files (stylesheets, images, etc.) should be placed in GAIA_OUTOFTREE_THEME_SRCDIRS, these will be sym-linked to gaia/shared/style/theme during build. The theme path is preferably added to local.mk, just like with out of tree apps. Example:
GAIA_OUTOFTREE_THEME_SRCDIRS := $(realpath ../firefox/theme)
Make will then symlink every folder in this dir into the correct place in Gaia.

* In order to style an app, the app's index.html file needs to be modified. This is done by adding the following code:
<script defer src="/shared/js/theme.js"></script>
<!--
<link rel="stylesheet" type="text/css" href="/shared/style/theme/"/>
-->

This lets theme.js lazy load the app specific theme stylesheets, which then overrides the needed stylesheet rules. The actual style changes are done by adding css-rules for the new theme, which override the default rules.

* Adds theme category to settings
* Contains "firefox default"-theme
* Symlinks specified theme location to shared/style/theme
* Adds the theme folder created during build to gitignore

Current Shortcomings:
* Themes can't be installed during runtime; they have to be built together with Gaia.
* Only certified apps can be styled (this should probably stay like this)
* Card View screenshots of open apps are currently not being refreshed when switching themes.
* Some apps lack themed images in the example theme.
* The themes area in settings should be implemented like other areas instead of being injected by themes.js

Image info:
    Background from /gaia/shared/resources/branding/official
Blocks: 1002462
Severity: normal → enhancement
Attached file theme-demo.tar.gz
Flags: needinfo?(21)
Flags: needinfo?(21) → needinfo?(jachen)
Flags: needinfo?(21)
Note: the mechanism from bug 923897 let you do themes with installable app packages instead. Security restrictions ensure that you don't re-skin apps that have higher privilege than the theme itself, but that should not be an issue with pre-installed themes for certified apps.
This is also dependent on bug 877993 for refreshing the card view screenshots when switching themes.
(In reply to Fabrice Desré [:fabrice] from comment #4)
> Note: the mechanism from bug 923897 let you do themes with installable app
> packages instead. Security restrictions ensure that you don't re-skin apps
> that have higher privilege than the theme itself, but that should not be an
> issue with pre-installed themes for certified apps.

The mechanism from bug 923897 sounds a nice patch. That said in its current form it does not address all of this bug.

My understanding is that bug 923897 let you access resources from a separate app, in a statically declared list. All those resources are then injected into the app scope.

It's great as we can offer theming for installable package in a much easier way than buildtime customization. (On a completely different note it may also makes our life easier for shared/ scripts.)

I proposed a change to your code in bug 923897 that change a bit the meaning of your patch. Instead of injecting the declared list at startup it insert rules into the CSP policy to let the content load the files declared in the manifest.

That said it would not let you choose exactly which theme you want.

Instead of relying on reading mozSettings from the app, and using CSS to inject the necessary CSS files (all this seems slow.), I wonder if we can't rely on a media query that check a pref in the background that is mapped to a mozSettings ?

The media query will be something like https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Media_queries#Mozilla-specific_media_features

Then based on this media query, the app will be able to select the right files to load. Those files can comes from other certified apps with bug 923897 or build time themes.

This should get rid of JS and the needs to access the mozSettings API for those apps. It will also let a way for third party apps to use the media query in order to customize a bit their look and feel for those themes if they want too, while keep letting them fallback on a default style on other platforms.


needinfo'ing Ehsan, Jonas and dbaron, to make sure they are aware of what's going on here and that we don't rush into something that's not desirable.
Flags: needinfo?(jonas)
Flags: needinfo?(ehsan)
Flags: needinfo?(dbaron)
Flags: needinfo?(21)
Thanks for reaching out, Vivien!  So I had a quick look at bug 923897 and I hope that I understand enough about what's going on here.  But here's a question about what we're trying to achieve here.  Are we trying to make it easier to theme third-party apps here?  Or is it just about theming our built-in certified apps?
Flags: needinfo?(ehsan) → needinfo?(21)
(In reply to :Ehsan Akhgari (lagging on bugmail, needinfo? me!) from comment #7)
> Thanks for reaching out, Vivien!  So I had a quick look at bug 923897 and I
> hope that I understand enough about what's going on here.  But here's a
> question about what we're trying to achieve here.  Are we trying to make it
> easier to theme third-party apps here?  Or is it just about theming our
> built-in certified apps?

Primary goal is to skin built-in apps.

As a secondary goal, I would like to offer a way for third party apps to opt-in.
Flags: needinfo?(21)
(In reply to Vivien Nicolas (:vingtetun) (:21) (NOT reading bugmails, needinfo? please) from comment #6)
> Instead of relying on reading mozSettings from the app, and using CSS to
> inject the necessary CSS files (all this seems slow.), I wonder if we can't
> rely on a media query that check a pref in the background that is mapped to
> a mozSettings ?
> 
> The media query will be something like
> https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Media_queries#Mozilla-
> specific_media_features
> 
> Then based on this media query, the app will be able to select the right
> files to load. Those files can comes from other certified apps with bug
> 923897 or build time themes.

This sounds somewhat similar to bug 677302, which wants to do similar for preferences.

I'm having trouble imagining standardizing something like this, though.  Or does mozSettings have some sort of path towards standardization?  (Is mozSettings only for certified apps?  Is this?  Maybe that makes it less of an issue.)
Flags: needinfo?(dbaron)
We'll soon expose mozSettings to privileged apps. However I don't see any chance of it getting standardized anytime soon. So yeah, I don't expect that we'd be able to standardize something like this either.

But we could still expose it to privileged apps though.
Flags: needinfo?(jonas)
Depends on: 1011738
Depends on: 1015853
Depends on: 1064735
Depends on: 1066830
Flags: needinfo?(jachen)
Depends on: 1067992
Blocks: 1068006
Depends on: 1069791
Depends on: 1069840
Depends on: 1069850
Depends on: 1081684
No longer blocks: 1068006
Firefox OS is not being worked on
Status: UNCONFIRMED → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: