Closed Bug 974983 Opened 10 years ago Closed 3 years ago

Reorder Home panels in Settings via dragging

Categories

(Firefox for Android Graveyard :: General, defect, P5)

ARM
Android
defect

Tracking

(fennec+)

RESOLVED INCOMPLETE
Tracking Status
fennec + ---

People

(Reporter: liuche, Unassigned)

References

Details

Splitting off the drag and drop capability from the main reordering bug (bug 959917) since it will involve a big refactor.
Depends on: 959917
Blocks: lists
Is this something important we should put on the roadmap? It will be a non-trivial amount of engineering effort, but the current context menu system for moving panels around is pretty clunky.
Flags: needinfo?(ibarlow)
Flags: needinfo?(deb)
This should be a project. AIUI, this will depend on the Setting (PreferenceActivity) refactor.
(In reply to :Margaret Leibovic from comment #1)
> Is this something important we should put on the roadmap? It will be a
> non-trivial amount of engineering effort, but the current context menu
> system for moving panels around is pretty clunky.

Yes, definitely should be prioritized if possible.
Flags: needinfo?(ibarlow)
(In reply to Mark Finkle (:mfinkle) from comment #2)
> This should be a project. AIUI, this will depend on the Setting
> (PreferenceActivity) refactor.

Is there a separate bug/project for that?
tracking-fennec: --- → ?
I've started a local project to see if we can port the existing Preference Fragments over without too much pain (Eclipse has been super useful!). I'm trying to get the tablet UI right, which shouldn't be too hard.
Assignee: nobody → liuche
tracking-fennec: ? → 33+
It looks like the Android settings app uses the Preferences* code actually, with many little Fragments for the more complicated things (data usage, etc) - trying to rewrite everything, especially for tablet, isn't going to be the right approach.

The right approach seems to be to keep our Settings code using Preference*, but add Fragments for the more complex stuff (draggable lists) the way the Android Settings does. I'm going to dig into the Android Setting code some more, see how these Fragments work.
we've slated this for Fx33, clearing needinfo :)
Flags: needinfo?(deb)
I played a bit with putting a sub "List" inside settings at one point via a custom setting. Thats doable! The idea was if we could insert a List we could use someone else's drag and drop list code. For instance, Google has code for draggable listview's linked to from this video:

https://www.youtube.com/watch?v=_BZIvjMgH-Q

Since this is a sublist inside settings, it should probably not be a ListView though. I had a couple ideas for how to move forward:

1.) We could do what we used to do on about:home and use a ListView but force it to be exactly as tall as its contents i.e. it wouldn't scroll. I think that had issues, but I don't know what they were. Maybe we just felt like it was hacky?

2.) We could use a LinearLayout for the list instead of a ListView. We'd have to update the Google drag & drop code significantly to work with it. That made me sad because I'd like to be able to easily reuse this for things like the tabs tray. But I can be sad.

3.) We could use a custom LinearLayout->AdapterView hybrid and alter the Google code to only deal with AdapterView's instead of ListViews. Still a lot of work I think.

I haven't seriously tried to implement any of those ever. #2 is probably the quickest way forward.
Can you post comment 8 (basically) to mobile-firefox-dev? I think it would get more people to give feedback.
QA Contact: ioana.chiorean
What's the status here? I'm pretty sure this isn't going to happen for Firefox 33 at this point.
Flags: needinfo?(liuche)
I think I'm just assigned, but I'm definitely not actively working on this at all. I think Wes started taking a look at using listviews, but I'm not sure where he got with that. Definitely not making 33 though.
tracking-fennec: 33+ → ---
Flags: needinfo?(liuche)
tracking-fennec: --- → ?
tracking-fennec: ? → +
Maybe we can get around to this one day as part of an "improve customizability" effort.
filter on [mass-p5]
Priority: -- → P5
Thinking about this a bit more, I feel like even though this wouldn't drive huge adoption numbers for Panels, it would really help make these Panels feel more polished. If there's is an opportunity for a quick win here, we should definitely pick it up again.

Going to NI Chenxia here again so we could possibly get this moving when she gets back :P
Flags: needinfo?(liuche)
Wes had a suggestion that we could do panel reordering in-content, which I actually really like. As a note, doing drag-and-drop within Settings is pretty difficult because we're using the Android Preferences classes, and they provide only a very straightforward preferences UI.
Flags: needinfo?(liuche)
(In reply to Chenxia Liu [:liuche] from comment #15)
> Wes had a suggestion that we could do panel reordering in-content, which I
> actually really like. 

+1
Unassigning for now, because it's been a while since we've revisited this. We should consider handling panel reordering in-content.
Assignee: liuche → nobody
I think we should look into this again since we're doing a lot of work to make our Awesome screen/ Panels more awesome. If we're going to point users at customize-ability and this as one of the main ways you can personalize about:home, we should really fix this up :)
We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → INCOMPLETE
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.