Closed Bug 1010352 Opened 6 years ago Closed 6 years ago

(vertical-homescreen) Add Pinch to Zoom to Settings

Categories

(Firefox OS Graveyard :: Gaia::Settings, defect, P1)

x86
Gonk (Firefox OS)
defect

Tracking

(feature-b2g:2.0, tracking-b2g:backlog, b2g-v2.0 fixed)

RESOLVED FIXED
2.0 S3 (6june)
feature-b2g 2.0
tracking-b2g backlog
Tracking Status
b2g-v2.0 --- fixed

People

(Reporter: jsavory, Assigned: crdlc)

References

Details

(Whiteboard: [ft:systemsfe][priority][systemsfe])

Attachments

(3 files, 1 obsolete file)

In addition to the pinch to zoom functionality on homescreen, add a settings option to change between three and four column grids. 

Interaction according to UX spec.
Blocks: 989484
blocking-b2g: --- → backlog
Component: Gaia::Homescreen → Gaia::Settings
Whiteboard: [ft:systemsfe][priority]
Blocks: vertical-homescreen
No longer blocks: 989484
Assignee: nobody → crdlc
Status: NEW → ASSIGNED
OS: Mac OS X → Gonk (Firefox OS)
I think this needs to go under the homescreen panel in settings. Due to replaceable homescreens, this may need to either be done using the same style we do with keyboards (mozActivity), or we may investigate using an embedded widget style. I would also recommend using asyncStorage, or a custom store with our existing indexedDB. What are your thoughts on the approach Cristian?
Attached patch I started with this approach (obsolete) — Splinter Review
Just to see the idea
Attachment #8423126 - Flags: feedback?(kgrandon)
Comment on attachment 8423126 [details] [diff] [review]
I started with this approach

Review of attachment 8423126 [details] [diff] [review]:
-----------------------------------------------------------------

I like the approach, but I am not sure about using entry_points as I thought we were going to deprecate that. I suppose this seems like a better use of it instead of the current main communications use-case. I believe we explored using mozActivity in the past for keyboard settings, but I'm not really sure why we stopped. I'm going to feedback? on a few other people here to see if they might know - and if they have a preference on entry_points vs mozActivity. 

I guess keyboard has a launch_path of settings.html, I'm guessing it manually constructs the entry_point for the main keyboard view somewhere?
Attachment #8423126 - Flags: feedback?(timdream)
Attachment #8423126 - Flags: feedback?(rlu)
Attachment #8423126 - Flags: feedback?(kgrandon)
Attachment #8423126 - Flags: feedback?(dflanagan)
Attachment #8423126 - Flags: feedback+
Please don't use entry_points anymore. They are going away as soon as the comms app is split up.
feature-b2g: --- → 2.0
Comment on attachment 8423126 [details] [diff] [review]
I started with this approach

Looping Arthur for settings.

Yes, keyboard apps have their launch_path pointing to it's settings page, instead of activity. The actual keyboard frames are registered under 'inputs' dict, with their additional information (type, name etc.)

I agree we shouldn't be using entry_points anymore.

What we are really looking for is ability similar to iOS Settings Bundle, which accepts any installed app insert a panel into Settings app. We cannot make that for 2.0, so that leaves us the following options, for 2.0 (I presume we are making the two preloaded/certified homescreen apps interchangable but we are not accepting 3rd-party installations for 2.0):

A) Introduce a "settings_path" entry in the manifest, and load that in a inproc mozbrowser iframe in Settings app. Once bug 879475 is done we can load that frame oop.

B) Squeeze these settings, once again, into mozSettings, and create yet another panel inside Settings panel.

I personally prefer (A) because it's cleaner and less code in Settings app, but I think we need :jonas to greenlight this addition to the manifest, and running the frame in Settings process.

If (A) works and works well we should make keyboard settings do the same thing once we have bug 879475 (since we shouldn't load a privileged keyboard app settings page into Settings process).

I would like to see the frame handling part of Settings app modularized and re-useable, for the intention said above. I will ask Arthur to enforce that during review.
Attachment #8423126 - Flags: feedback?(timdream)
Attachment #8423126 - Flags: feedback?(rlu)
Attachment #8423126 - Flags: feedback?(dflanagan)
Attachment #8423126 - Flags: feedback-
Flags: needinfo?(jopsen)
Flags: needinfo?(arthur.chen)
Maybe "setting_path" instead of "settings_path"? Please verify the grammar for me.
Sorry, I'm the fake Jonas :)
You're probably looking for :sicking ?
Flags: needinfo?(jopsen) → needinfo?(jonas)
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #5)
> Comment on attachment 8423126 [details] [diff] [review]

(A) is a reasonable way to go. However, two things must be addressed when taking the approach. The first one is, if the panel runs OOP, how does it communicate with settings app when users want to navigate back?  And the other one is that it's getting difficult to make the style consistent across the settings of each app. We may need to implement a settings bundle framework as you suggested.
Flags: needinfo?(arthur.chen)
Whiteboard: [ft:systemsfe][priority] → [ft:systemsfe][priority][systemsfe]
Target Milestone: --- → 2.0 S2 (23may)
I don't really think we have an option of going with A) right now. MozSettings doesn't seem like a good option either as we would like to use asyncStorage/IndexedDB I believe.

We need to move forward without being blocked by standardization process, I'm going to recommend that we use entry_points, and we can refactor them when we have some settings_path in the manifest. I think that it will be no problem to remove this before the communications app is split.
(In reply to Kevin Grandon :kgrandon from comment #3)
> Comment on attachment 8423126 [details] [diff] [review]
> I started with this approach
> 
> Review of attachment 8423126 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> I like the approach, but I am not sure about using entry_points as I thought
> we were going to deprecate that. I suppose this seems like a better use of
> it instead of the current main communications use-case. I believe we
> explored using mozActivity in the past for keyboard settings, but I'm not
> really sure why we stopped. I'm going to feedback? on a few other people
> here to see if they might know - and if they have a preference on
> entry_points vs mozActivity. 

FWIW, we did not use mozActivity for "launching keyboard settings" because mozActivity did not support "launch a specific app's activity handler". So the system would show an activity menu for "keyboard-settings" activity name when you install more than one keyboard apps, which does not make any sense.
Attached file Github pull request
As you suggested on bug 1010352 comment 9 I continued working on it in that way and all the code is ready to review although I have to work on test suites on Monday. Maybe you would like to take a look to this code and play with the implementation. Thanks a lot Kevin
Attachment #8423126 - Attachment is obsolete: true
Attachment #8423802 - Flags: feedback?(kgrandon)
(In reply to Jonas Finnemann Jensen (:jonasfj) from comment #7)
> Sorry, I'm the fake Jonas :)
> You're probably looking for :sicking ?

Sorry about that!

(In reply to Arthur Chen [:arthurcc] PTO: 5/19~5/21 from comment #8)
> (In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from
> comment #5)
> > Comment on attachment 8423126 [details] [diff] [review]
> 
> (A) is a reasonable way to go. However, two things must be addressed when
> taking the approach. The first one is, if the panel runs OOP, how does it
> communicate with settings app when users want to navigate back? 

window.close() and mozbrowserclose?  

> And the
> other one is that it's getting difficult to make the style consistent across
> the settings of each app. 

This is a valid issue, however arguably homescreen app are exclusively designed for FxOS only (even the 3rd-party ones), they will probably ship with building block style.

> We may need to implement a settings bundle
> framework as you suggested.

I think for the purpose of this bug let's just implement a minimal one to unblock the 2.0 feature. In the long run we would need a more solid scope of things (e.g. what DOM feature we will support in these frames).

For example, I am definitely not looking into supporting window.open() and navigation chrome for these frames.

(In reply to Kevin Grandon :kgrandon from comment #9)
> I don't really think we have an option of going with A) right now.
> MozSettings doesn't seem like a good option either as we would like to use
> asyncStorage/IndexedDB I believe.
>
> We need to move forward without being blocked by standardization process,
> I'm going to recommend that we use entry_points, and we can refactor them
> when we have some settings_path in the manifest. I think that it will be no
> problem to remove this before the communications app is split.

Looking into attachment 8423802 [details] I realized the different between (A) and that is that you get to use app.launch('setting'), which is indeed simpler, however, :crdlc, you might want to adopt the code Back key in keyboard settings page -- window.close() will take the user back to homescreen instead of Settings app, which will be a blocking bug.
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #12)
> Looking into attachment 8423802 [details] I realized the different between
> (A) and that is that you get to use app.launch('setting'), which is indeed
> simpler, however, :crdlc, you might want to adopt the code Back key in
> keyboard settings page -- window.close() will take the user back to
> homescreen instead of Settings app, which will be a blocking bug.

If this is a problem, we can always use a specific activity for now with an activity.postResult() to go back to the settings app.

(In reply to Rudy Lu [:rudyl] from comment #10)
> (In reply to Kevin Grandon :kgrandon from comment #3)
> FWIW, we did not use mozActivity for "launching keyboard settings" because
> mozActivity did not support "launch a specific app's activity handler". So
> the system would show an activity menu for "keyboard-settings" activity name
> when you install more than one keyboard apps, which does not make any sense.

It seems like we can resolve this by adding a filter for the homescreen manifest URL.
Comment on attachment 8423802 [details]
Github pull request

Nice work. I think it would be worth a shot of using mozActivity so we can leverage asyncStorage. We would need to filter on manifestURL most likely so that the user is not presented with an option menu. Sorry to request such a big change after this work! Let me know what you think.
Attachment #8423802 - Flags: feedback?(kgrandon)
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #5)
> I agree we shouldn't be using entry_points anymore.

Me too.

> What we are really looking for is ability similar to iOS Settings Bundle,
> which accepts any installed app insert a panel into Settings app. We cannot
> make that for 2.0, so that leaves us the following options, for 2.0 (I
> presume we are making the two preloaded/certified homescreen apps
> interchangable but we are not accepting 3rd-party installations for 2.0):

Agreed.

> A) Introduce a "settings_path" entry in the manifest, and load that in a
> inproc mozbrowser iframe in Settings app. Once bug 879475 is done we can
> load that frame oop.

Bug 879475 looks unlikely to make 2.0, though I'd love it if it did. I'm worried that we'll end up in a situation where we cram it in last minute, which would be bad.

And we can't run in-process. Both because it's dangerous to run 3rd party code in the settings process (that process has *a lot* of permissions), and because the settings process doesn't have access to IDB-data from other apps.

> B) Squeeze these settings, once again, into mozSettings, and create yet
> another panel inside Settings panel.

I think we'll have to go this way for 2.0 sadly.

But I agree A) is the way to go long term. Once we have bug 879475 it shouldn't be too crazy hard.
Flags: needinfo?(jonas)
> What we are really looking for is ability similar to iOS Settings Bundle,
> which accepts any installed app insert a panel into Settings app. We cannot
> make that for 2.0, so that leaves us the following options, for 2.0 (I
> presume we are making the two preloaded/certified homescreen apps
> interchangable but we are not accepting 3rd-party installations for 2.0):

FWIW, the way we should do this, IMO, is exactly how you describe in option A). That leaves a lot of flexibility for apps to implement their own settings UI, and allows them to store data in a way that they can retrieve it, i.e. in IDB.

But I think this is more work than we can take on in 2.0.
Comment on attachment 8423802 [details]
Github pull request

Thanks a lot for review
Attachment #8423802 - Flags: review?(kgrandon)
Attachment #8423802 - Flags: review?(ehung)
Comment on attachment 8423802 [details]
Github pull request

Awesome! Really nice to see this, and thanks for the first step at adding some tests :) Let's wait for a settings R+ before landing. Thanks!
Attachment #8423802 - Flags: review?(kgrandon) → review+
(In reply to Jonas Sicking (:sicking) from comment #15)
> (In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from
> comment #5)
> > I agree we shouldn't be using entry_points anymore.
> 
> Me too.
> 
> > What we are really looking for is ability similar to iOS Settings Bundle,
> > which accepts any installed app insert a panel into Settings app. We cannot
> > make that for 2.0, so that leaves us the following options, for 2.0 (I
> > presume we are making the two preloaded/certified homescreen apps
> > interchangable but we are not accepting 3rd-party installations for 2.0):
> 
> Agreed.
> 
> > A) Introduce a "settings_path" entry in the manifest, and load that in a
> > inproc mozbrowser iframe in Settings app. Once bug 879475 is done we can
> > load that frame oop.
> 
> Bug 879475 looks unlikely to make 2.0, though I'd love it if it did. I'm
> worried that we'll end up in a situation where we cram it in last minute,
> which would be bad.
> 
> And we can't run in-process. Both because it's dangerous to run 3rd party
> code in the settings process (that process has *a lot* of permissions), and
> because the settings process doesn't have access to IDB-data from other apps.
> 

I don't think we'll need to host 3rd-party app in Settings process for 2.0. We are only talking about home2 here if I am not mistaken. We could have (A) properly written in Settings and check for certified only for 2.0. Jonas, do you think it's feasible?

> > B) Squeeze these settings, once again, into mozSettings, and create yet
> > another panel inside Settings panel.
> 
> I think we'll have to go this way for 2.0 sadly.
> 
> But I agree A) is the way to go long term. Once we have bug 879475 it
> shouldn't be too crazy hard.

It looks like attachment 8423802 [details] uses neither (A) nor (B) and hacks activity instead (for both to and back transition). It also stores it's own pref in a datastore which I have really no idea who would need these pref outside of home2 itself. Kevin, why is this app written this way?
Flags: needinfo?(kgrandon)
Flags: needinfo?(jonas)
By "hack" the activity, I am referring to the fact this code attempt to use activity filter to target a single app. We already know other apps can interfere with that.
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #19)
> It looks like attachment 8423802 [details] uses neither (A) nor (B) and
> hacks activity instead (for both to and back transition). It also stores
> it's own pref in a datastore which I have really no idea who would need
> these pref outside of home2 itself. Kevin, why is this app written this way?

A) doesn't seem like it's going to make 2.0. If it does, let's definitely use that.
B) mozSettings seems wrong as well, why would you store this as a system setting if only one app needs to use it? I'm not really convinced this is any better than using our own datastore.

Datastore was chosen mainly due to change notifications after settings have been updated. We would prefer to use plain asyncStorage, but then we need a way to get notifications in the homescreen.

I only really care about having a working solution for 2.0 - whenever we get settings_path in the manifest it should be trivial to migrate to it. As it stands today activities seem like our only choice to get this done by 2.0.
Flags: needinfo?(kgrandon)
We don't follow the option A because the bug 879475 is not already done. So we prefer to continue activity approach in order to test the interaction and after landing that bug we can open a follow-up to re-write the mechanism. This is the reason why we did that. Our idea is to address your suggestions not to go by them :)
As I already said in comment 19, I don't think bug 879475 blocks proposal (A), since home2 is a certified app. 

Unless you told me it's not I would rather prefer we are on the right track from the start. We cannot afford making any more throw away hacks even though we know it unblock us from shipping features. Will you be responsible for "rewriting" the handling in Settings later? Do you think it make sense to add integration tests on this hack to protect the interaction? If either answer to the both questions is "no", then I don't think this is something I am comfortable shipping.
So Evelyn just told me offline that without bug 879475 it's not possible for oop'd Settings app to get a hold of "embed-apps" permission and include a inproc <iframe mozbrowser mozapps> frame. IPC permission check will spot that violation and crash the Settings app. That indeed blocks (A) from being done.

In this case, I am withdrawing my objection to attachment 8423802 [details]. It looks like this is the least worse hack we can think of.

A new manifest entry won't work either that involves modification to mozApps API.
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #20)
> By "hack" the activity, I am referring to the fact this code attempt to use
> activity filter to target a single app. We already know other apps can
> interfere with that.

Yes, this is really my concern. I'm not sure if this hack will pass security review and UX review. A 3rd-party app will be able to interfere the process if it registered the same activity entry in its manifest. ni Paul to answer my question on security part, and Jacqueline to answer UX part.
Flags: needinfo?(ptheriault)
Flags: needinfo?(jsavory)
And what about moving the vertical homescreen's settings to vertical homescreen view in settings app? and the communications by means of datastore? Thanks
Indeed, option A is out for now.

I don't want to do a activity solution since 3rd party apps, including ones that are not installed through the mozilla marketplace, can intercept it.

I don't see much difference between using a DataStore and using mozSettings. Both are essentially a system-wise database which we'd stick application specific data in. However given that we can't do A, we have to do one of them.

Both DataStore and mozSettings have change events that allow any app to react to data being changed by other apps.

Using mozSettings seems easier to me, but I don't care strongly either way.

Note that we will be making mozSettings available to privileged apps (see bug 846200), so that's not a problem.
Flags: needinfo?(jonas)
Comment on attachment 8423802 [details]
Github pull request

I'd like to r- this patch on settings part because we shouldn't hack activity and it maight be broken by a 3rd-party app. Per the solutions we've discussed above, I think there are two ways to re-consider:

1. use app.launch('setting') (comment 12), introduce a 'setting' entry in manifest, and modify mozApp API to allow us launch an app to its setting page.
2. use mozSettings (comment 5 plan (B))

I prefer (1) if we can make it happen in 2.0. It's closer to (A) in comment 5, so when we have bug 879475 done, we could migrate to approach A easier. (For a long-tern solution, I'd like to see we support Settings Bundle)

So :crdlc, I see a few changes in your patch are about home2, is there anything we can land first separatedly from the issue of launching setting page?
Attachment #8423802 - Flags: review?(ehung) → review-
Flags: needinfo?(ptheriault)
Flags: needinfo?(jsavory)
These patches can be split up, but they need to land together. The app.launch('settings') idea directly conflicts with entry_points, so we'd probably need something like app.launchSettings().

If we don't get an R+ on the current approach, it's likely that this feature will not be done for 2.0. I think next steps would be to check with management if we can get resources for mozApps changes, or check with UX/Product to see if we can backlog this feature until 2.1. Thank you for your hard work on this Cristian.
Priority: -- → P3
Hi all,

   What about for 2.0...?

1) Move the "Grid layout" select UI component to Settings app within "Vertical Homescreen" view
2) Datastore vs mozSettings. I think that datastore is more accurate solution because mozSettings is for hardware thought. If you want to use mozSettings to store some preferences for an specific app, this would be a bit hacky in my honest opinion

******

if (home.origin === 'vertical.home.gaia...') {
   // Paint the Grid layout select
}

******

This would be just for 2.0, what do you think Evelyn
Flags: needinfo?(ehung)
It seems we can only do in this way to meet deadline before having resource to work on other options. :(
Flags: needinfo?(ehung)
Raising the priority of this for 2.0 as we may drop the pinch to zoom gesture and just have settings control for this.
Priority: P3 → P1
Duplicate of this bug: 1015356
Blocks: 1015336
Well, I am a bit lost with this bug :). If we will release the version 2.0 only with the vertical homescreen without any support for others. I guess that we have to wait for having the vertical homescreen by default because the current UI in settings called "Homescreens" will disappear, right? So if we decide to move the vertical's settings to settings app it should be done in another view different than one we have right now thought. Any suggestion?
Flags: needinfo?(kgrandon)
My recommendation would be to do this under the current 'Vertical' homescreen panel still. When we turn this on by default it would make sense to always show the homescreen option (even if there is just a single result).

I am suggesting doing it in the panel and changing the settings app to always show the option.
Flags: needinfo?(kgrandon)
I gonna implement what you explained but in its specific panel as the spec says [1]. The current "homescreens" panel will disappear for 2.0 so IMHO it does not make sense, I mean, to add the vertical settings to a panel which will disappear. Also following this approach we are implementing the spec properly. 

[1] http://i.imgur.com/Fkvfg5k.png

(In reply to Kevin Grandon :kgrandon from comment #35)
> My recommendation would be to do this under the current 'Vertical'
> homescreen panel still. When we turn this on by default it would make sense
> to always show the homescreen option (even if there is just a single result).
> 
> I am suggesting doing it in the panel and changing the settings app to
> always show the option.
I think it should probably still be under the 'Vertical' panel, specific to the vertical homescreen, but I guess this is ok for now. It would just be nice to be ready for replaceable homescreens in 2.1 without too much refactoring. (We can keep the homescreen panel with only the vertical option for 2.0 perhaps?)
From an user/UX point of view I don't see to have a navigation like this: homescreen > vertical > settings when we know that we will have only one homescreen in 2.0. I see homescreen > settings honestly as the spec says too. If the only reason to follow your suggestion is to be ready for replaceable homescreens in 2.1 without too much refactoring. This reason is just good for us as developers but I don't see that regarding to product quality thought
Comment on attachment 8423802 [details]
Github pull request

Second round :)

The patch implements the spec [1] and the result is [2].

[1] http://i.imgur.com/Fkvfg5k.png
[2] http://i.imgur.com/gZJNuMy.png

There are two panels in settings app right now while we have the two homescreens living in Gaia in the device (2.0 will be released with only the vertical homescreen AFAIK):

* "Homescreen" panel which implements the vertical settings according to UX spec
* "Homescreens" panel which allows users to change among homescreens. It will disappear when the horizontal homescreen will be removed from Gaia in the short time (bug 1009111)
Attachment #8423802 - Flags: review?(kgrandon)
Attachment #8423802 - Flags: review?(ehung)
Attachment #8423802 - Flags: review-
Attachment #8423802 - Flags: review+
Thanks for the review
Attachment #8429184 - Flags: ui-review?(pla)
Comment on attachment 8423802 [details]
Github pull request

Homescreen parts look good. Thank you!
Attachment #8423802 - Flags: review?(kgrandon) → review+
Comments addressed Kevin, thanks

(In reply to Kevin Grandon :kgrandon from comment #41)
> Comment on attachment 8423802 [details]
> Github pull request
> 
> Homescreen parts look good. Thank you!
Target Milestone: 2.0 S2 (23may) → 2.0 S3 (6june)
No longer blocks: vertical-homescreen
Rebased and comments addressed
Comment on attachment 8423802 [details]
Github pull request

The patch looks good to me, but here are three follow-up we need to address in 2.0:

1. a icon for the 'Homescreen'(vertical one) item, do we have a bug for this?
2. follow AMD pattern - at least add your scripts under loader's control. I'd like to hear from Arthur to know if he prefers a follow-up bug or fixing in this patch, and his requirement of modulization.
3. add test case for vertical_preferences.js under shared/. :djf would have concerns on this, since he's taking care code healthy under shared/ folder.

Thanks for your patch. Let's wait travis green and check Arthur and David's opinions on point 2&3. :)
Attachment #8423802 - Flags: review?(ehung) → review+
Flags: needinfo?(dflanagan)
Flags: needinfo?(arthur.chen)
thanks, inline

(In reply to Evelyn Hung [:evelyn] from comment #44)
> Comment on attachment 8423802 [details]
> Github pull request
> 
> The patch looks good to me, but here are three follow-up we need to address
> in 2.0:
> 
> 1. a icon for the 'Homescreen'(vertical one) item, do we have a bug for this?

When this bug would be landed I though ask for it because I didn't know if it will be part of homescreens section, etc.. Once landed it I will file a new bug for the icon for sure

> 2. follow AMD pattern - at least add your scripts under loader's control.
> I'd like to hear from Arthur to know if he prefers a follow-up bug or fixing
> in this patch, and his requirement of modulization.

I wouldn't like to block here because this bug is Priority 1 and the bug 973432 does not seem P1 although it is just my opinion

> 3. add test case for vertical_preferences.js under shared/. :djf would have
> concerns on this, since he's taking care code healthy under shared/ folder.
> 

I don't have a strong opinion here :)

> Thanks for your patch. Let's wait travis green and check Arthur and David's
> opinions on point 2&3. :)
(In reply to Cristian Rodriguez (:crdlc) from comment #39)
> * "Homescreens" panel which allows users to change among homescreens. It
> will disappear when the horizontal homescreen will be removed from Gaia in
> the short time (bug 1009111)

Do we need a bug to make sure Homescreen"s" will be removed? or it's included in bug 1009111
Product said that the homescreen will disappear for 2.0
(In reply to Cristian Rodriguez (:crdlc) from comment #47)
> Product said that the homescreen will disappear for 2.0

No, I'm saying the "Homescreens" panel in Settings should be removed in bug 1009111 or another bug depend on bug 1009111.
Kevin, do we have any bug for comment 48? or will it be removed in bug 1009111 for free? BTW when gaia has only one home installed, the section won't appear
Flags: needinfo?(kgrandon)
(In reply to Evelyn Hung [:evelyn] from comment #48)
> (In reply to Cristian Rodriguez (:crdlc) from comment #47)
> > Product said that the homescreen will disappear for 2.0
> 
> No, I'm saying the "Homescreens" panel in Settings should be removed in bug
> 1009111 or another bug depend on bug 1009111.

Well, maybe it's okay, since there won't are two homescreens so the item would be displayed. /me just feel it confuses people working in this codebase.
Blocks: 1017492
No longer blocks: 1017492
Depends on: 1017492
New bug 1017492 to track the icon for new panel
Let's do the refactoring in a separate bug as we may need to extract some common logic during the refactoring and which is beyond the scope of this bug.
Flags: needinfo?(arthur.chen)
ok we have green and the Arthur's opinion. Just waiting for David :) Thanks
We can file a bug to remove the old homescreens panel. TBH I would prefer to not remove it so it's still functional for testing if we'd like. I think changing the old homescreen app role from "homescren" -> "system" might do it.
Flags: needinfo?(kgrandon)
I've attached a small update to the settings screen for pinch to zoom. 

The explanatory text underneath the selection box needs to be removed and I've cleaned up a bit of the layout.
Comment on attachment 8429184 [details]
vertical_home_settings_panel.png

Hi Cristian,

As we spoke about today, UX has some minor changes we'd like to make.  Please see Jacqueline's updated spec in comment 55.

Thanks!

(and thanks to Jacqueline for the update!)
Attachment #8429184 - Flags: ui-review?(pla) → ui-review-
Merged in master:

https://github.com/mozilla-b2g/gaia/commit/1e3aaeeb7b5bacd7321889f9ca5471051778eb75
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #5)
> What we are really looking for is ability similar to iOS Settings Bundle,
> which accepts any installed app insert a panel into Settings app. 

FYI, this is now bug 1020063.
Mass modify - set status-b2g-v2.0 fixed for fixed bugs under vertical homescreen dependency tree.
Flags: needinfo?(dflanagan)
blocking-b2g: backlog → ---
You need to log in before you can comment on or make changes to this bug.