-
Notifications
You must be signed in to change notification settings - Fork 3.1k
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
Multi select navigation state bug - to be discussed (#899) #1412
Comments
Yeah, I think we can just wait for #1275. |
Yeah, probably just a non-issue as soon as the details screen is gone. The blue line I mentioned in #1434 would still be cool to fix. |
The blue lien isn't there ;) - The multiselection is basically a grey (kind of second action bar) hovering above the first one. So we will have to check if and how the bar can be themed/customized. If that is possible it shouldn't be to to big of a deal. But I never worked with the multiselect bar before. |
Mmmm, I think the real problem is that the selection should not be there once the details view appears. I mean, when the user selects one or multiple files and clicks "Remove", once the removal is finished the selection goes aways. With the same pattern, if the user clicks "Details", once the details view is shown, the selection should go away too. The action requested for the selection was already done. |
Oh, I see. This happens with more commands, the action mode remains enabled after they are finished; for instance, select multiple files and download. Don't you think would be better if the selection is cleared? |
Hmm, tricky. Just checked GMail and the selection persists on actions that move away from the list and come back to it but removes the selection for the delete action since this also means all selected items are gone. Looking at our action I would start start with clear the selection when calling the action. Clearing would also be what I expect since GMail's way of not clearing it usually confuses me 0_o |
And this is the proper way to do it. Actions which move away from the list have nothing to do with the selection. They might just be to check (details for example) or a simple misclick. Actions like deletion obviously clear the selection though, since it doesn’t exist anymore. |
That's fine. Gmail keeps the selection when the user comes back, but the selection mode is not visible in any way while the user is "away" in the other view. In this issue the problem is that the selection mode is still visible while the user is not in the list - see the picture. IMHO should be:
|
Ah ok. Yep, of course, should be like you described @davivel |
After deep review: the only transition to a different view that is problematic is details view. In every other case, the selection is remembered when going back. The bad new is that to implement the current behaviour of rotation in tablets when details view is visible we did some tricks that make harder remembering the selection when going back. Rewriting the tricks to have a code easier to update would be awesome, but I'm sure it will need a considerable amount of time. There are plenty of things that discourage putting more effort in that detail for the moment:
Given this, I will grant that selection mode is disabled when the transition to details is done, and let's see if we can live with this for now. |
This is now ready to test in #1176. Any opinion is welcome :) |
Fixed |
Great, thx :) |
This is related to #899
Scenario:
In case you hit the back button (or click on the arrow in the action bar), the selection mode gets disabled and you are still in the details screen. Imho this is only a not very nice detail and should be resolved automatically when #1275 gets approved and merged (since it removed the details menu item). So looping in @jancborchardt and @tobiasKaminsky
The text was updated successfully, but these errors were encountered: