In portrait orientation, toolbar does overflow and does leave some widgets in non usable ways

[garycmartin]

Browse case:

In portrait orientation toolbar URL widget is almost unusable due to small size, it is only large enough to show about 7 or 8 characters of text, and the search history is close to useless with items like "Re... htt..." and "OL... file:..."

13.1.0 build 11: XO-1.75

[erikos]

Hmm, this one is difficult. Should we make the entry a minimum size so that more icons overflow in the portrait mode? The < > buttons I would not like to see overflowing. The favourite icon would maybe be ok or the home button, but that is already positioned at the left to the url entry.

Gary, suggestions please :)

[manuq]

This is worth fixing. But being realistic, not in this cycle. Moving out.

[garycmartin]

Replying to erikos:

Hmm, this one is difficult. Should we make the entry a minimum size so that more icons overflow in the portrait mode? The < > buttons I would not like to see overflowing. The favourite icon would maybe be ok or the home button, but that is already positioned at the left to the url entry.

Nice though, it would help a little, but not enough to really make a difference.

Gary, suggestions please :)

We should try and find a solution that helps the other activity cases as well. Suggestions so far range from having some Activities with custom portrait orientation toolbar layouts (trying to prioritise key features); or to changing the toolbar overflow behaviour so that the tools overflow in to a new secondary toolbar. This requires some design cycles, not something we have an obvious, quick, solution for right now.

[erikos]

Replying to garycmartin:

Replying to erikos:

Hmm, this one is difficult. Should we make the entry a minimum size so that more icons overflow in the portrait mode? The < > buttons I would not like to see overflowing. The favourite icon would maybe be ok or the home button, but that is already positioned at the left to the url entry.

Nice though, it would help a little, but not enough to really make a difference.

Gary, suggestions please :)

We should try and find a solution that helps the other activity cases as well. Suggestions so far range from having some Activities with custom portrait orientation toolbar layouts (trying to prioritise key features); or to changing the toolbar overflow behaviour so that the tools overflow in to a new secondary toolbar. This requires some design cycles, not something we have an obvious, quick, solution for right now.

Ahhh, the secondary toolbar was as well something that came to my mind directly. The 'other toolbar in portrait mode' sounds scary from an implementation point of view. If we would go down that road, the secondary toolbar could be a fallback for the activities not handling that themselves.

[walter]

I made a version for AU that works well. We should consider upstreaming it. We also should make some recommendations in the HIG for how to best handle these situations. Not difficult, but it takes some planning by the activity developer.

[manuq]

I looked at the patch you sent me Walter, and today I did a slightly different approach.

​http://dev.laptop.org/~manuq/browse-url-entry.png

I will make it work only in portrait mode, and will make the icons left align in that case, except for the Stop.

[walter]

Making it work only in Portrait mode (or when the screen is too narrow for all the buttons) works for me :)

In my version, I put the nav forward/back buttons on the same palette as the entry. I think they are better there, but I won't press the point.

Thanks for fixing this.

[manuq]

Fixed in master branch, commit b5fff700 . And sugar-98 branch, commit bc272c54 .