1229040 - Rename all gaia-* components to fxos-* and update the gaia dependencies

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia, defect)

Description

[Maria Angeles Oteo (:oteo)]

As part of the meta bug 1229029 - [Meta] Rename each individual component from gaia-* to fxos-* and update the gaia dependencies, we will handle in this bug the header component.

Comment 1

[Wilson Page [:wilsonpage]]

Myself and gmarty are tackling this together on this branch [1]. We will have to rename all components in all apps the same time, this is because new components all depend on fxos-theme.

One issue that's come up is related to the change breaking custom themes created by the studio app. I believe the studio app is being removed. When it does we'll have to have a way to switch users back to the default theme (fxos-theme.css) are the variables being used in the custom theme will not longer apply.

I'm not sure who will be tasked with the removal of 'Studio' and the other Spark apps. Maria, any idea?

[1] https://github.com/wilsonpage/gaia/tree/1229040

Comment 2

[Maria Angeles Oteo (:oteo)]

(In reply to Wilson Page [:wilsonpage] from comment #1)
> Myself and gmarty are tackling this together on this branch [1]. We will
> have to rename all components in all apps the same time, this is because new
> components all depend on fxos-theme.

 :( 

> One issue that's come up is related to the change breaking custom themes
> created by the studio app. I believe the studio app is being removed. When
> it does we'll have to have a way to switch users back to the default theme
> (fxos-theme.css) are the variables being used in the custom theme will not
> longer apply.

What is exactly the issue? Does it mean that if we migrate all the apps to use fxos-* any theme created by the studio will stop working?

> 
> I'm not sure who will be tasked with the removal of 'Studio' and the other
> Spark apps. Maria, any idea?

It seems that it was agreed that they should be removed (Bug 1213113) because they were not working fine (bug 1207371) but nobody is right now assigned to those tasks although there are patches for bug 1213113 done by Dough if you want to have a look.

Comment 3

[Wilson Page [:wilsonpage]]

(In reply to Maria Angeles Oteo (:oteo) from comment #2)
> What is exactly the issue? Does it mean that if we migrate all the apps to
> use fxos-* any theme created by the studio will stop working?

Correct

Comment 4

[Maria Angeles Oteo (:oteo)]

Ok, just talked to Wilson offline. 

The problem we are facing is that if we rename the Web Components, and send an OTA to dogfooders who have customized their themes via studio, the users will have visual issues, as the themes would stop working.

The safest approach would be waiting for an OTA that removes the Studio app (as planned already in Bug 1213113) and move all the users to the default theme. However, it seems that the current patch in Bug 1213113 just removes the app but does not move users back to the default theme, which means it wouldn't solve the issue. 

Julien, Wilson mentioned you were the author of the Studio App, is the analysis above correct? What is the best way forward?

Comment 5

[Julien Wajsberg [:julienw]]

I'm not _really_ the author of the Studio app, but I slightly contributed at one moment.

The analysis is perfectly correct. Something is missing though: we also need to uninstall installed themes, and remove the functionality from the Settings app.

Note that the "Themes" entry in Settings does not show up if we have only the default theme.

Comment 6

[Maria Angeles Oteo (:oteo)]

So, to be on the safe side, the patch to remove "Studio" App should not only remove the app but also:

1 - Remove the non-default themes (installed or customised) 
2 - Revert the system to use the default theme
3 - Remove the themes functionality from settings app

julienw, am I missing anything else? Who do you think is in the best position to create such a patch?

Comment 7

[Julien Wajsberg [:julienw]]

Actually this could be several patches/bugs, not necessarily one :)

Patch 1:
0- remove the "Studio" app
=> I guess we can carry on with the existing patch. Not sure who's the best to do this, likely I could have a look, depending on the priority for this work.

Patch 2:
1- Remove the non-default themes
2- Revert to use the default theme
=> not sure how we can do this, the System peers should know better.
Also I think this should be communicated to the foxfooders.

Patch 3:
3 - Remove the themes functionality from settings app
=> not urgent, as this shouldn't show up once patch 2 is done. Moreover we may want to resurrect this later. So the Settings people should decide whether they want to remove the feature for real.

So I think you should file 2 new bugs for this.

Comment 8

[Maria Angeles Oteo (:oteo)]

Changing the title to reflect that we need to do this at one time rather than component per component based on comment 1

Comment 9

[Wilson Page [:wilsonpage]]

Julien have you had any more thoughts on how we could better apply themes to our components that won't couple base-theme, user-theme and component?

Comment 10

[Julien Wajsberg [:julienw]]

This is just some food for thought, as a basis for discussion.


As UX, I think we should provide to the user different ways to define a theme:

1 - let the user provide a base color (or maybe just a hue ?), and decide if he wants a dark or light theme. From there we can generate a palette using JavaScript, or directly in CSS once we have CSS4 colors [1].
Note: my favorite tool to create palettes is [2]. The "Shades" behavior could be what we want here.

2 - let the user decide if he wants different colors for different app groups. This could be automatic using the "Triad" algorithm of [2] or something similar, or the user could choose himself the 3 colors (or hues), and decide if he wants a dark/light theme for each of these colors.
Ideally (but won't happen :D) the user could decide which apps are in which groups and we could inject the right CSS class in the body.

3 - From a picture we could hook into 1 or 2.

[1] https://drafts.csswg.org/css-color-4/#modifying-colors
[2] https://color.adobe.com


Now, what could happen from a technical point of view ? We'd need some trial and error, I guess.


My first idea is this should be abstract variables, but not as abstract as you already have with alpha/beta/etc. They need to correspond to "something" that more concrete variables (header-menu, etc) can link to.
So my first idea is that concrete variables can change, but not the palette colors.

A second idea, maybe easier and more practical, is that we can regenerate the palette colors from the initial user choice (hue + dark/light) whenever we want. Then we can put less thoughts about how we name the variables. Just keep in mind that the user choice is authoritative.

Comment 11

[BMO Automation]

Firefox OS is not being worked on