GNOME Bugzilla – Bug 735994
Window size too big for tablets in portrait mode
Last modified: 2018-01-24 16:53:47 UTC
The application window currently has a minimal window size which makes it unusable on current Intel baytrail tablet with a resolution 800x1280. Therefore the application cannot be used in portrait mode. Those values should be dynamic to perfectly adjust to the screen regardless of the screen rotation.
It does not have to be a tablet and does not have to be in portrait orientation. The default size of the main window is 1200x800. While this is fine for big displays it looks bad on anything smaller. There should be a solution for smaller screens.
Created attachment 285308 [details] Screenshot of the issue at 1024x768 The image says all.
Created attachment 286626 [details] [review] popular tile: Reduce padding to fit better on 1024x768 screens Cut 3px on either side so that the minimum width of the gnome-software window can fit in 1024 pixels.
before: https://kalev.fedorapeople.org/gnome-software-1024x768-1.png after: https://kalev.fedorapeople.org/gnome-software-1024x768-2.png
aday asked on irc if and how it affects the standard layout on a regular, higher resulution display, this is how: before: https://kalev.fedorapeople.org/gnome-software-standard-width-1.png after: https://kalev.fedorapeople.org/gnome-software-standard-width-2.png
Thanks, that's a step in the right direction,. But there's more to do in order to support 800px widths.
Comment on attachment 286626 [details] [review] popular tile: Reduce padding to fit better on 1024x768 screens Freeze break approval: https://mail.gnome.org/archives/release-team/2014-September/msg00108.html Attachment 286626 [details] pushed as 4b4bd04 - popular tile: Reduce padding to fit better on 1024x768 screens
(In reply to comment #6) > Thanks, that's a step in the right direction,. But there's more to do in order > to support 800px widths. I'll leave the ticket open to track the 800px width work. I'd need some designer guidance how to best solve this.
*** Bug 737147 has been marked as a duplicate of this bug. ***
Even 800 px is too big. My tablet is 1536x2048 tablet (with hi-dpi, so effectively 768x1024), and gnome-software doesn't fit. See attachment 286847 [details]
Created attachment 286954 [details] Proposed how to make the window smaller Please take these screenshots as an evidence that it is possible to go far below 800px. However, this would take some changes in the design so not everybody may like it. I think it is possible to retain the current design at large screens and at the same time have it slightly modified on smaller devices. But without some changes the design will not fit on small screens. I would not call my work even a work-in-progress so I don't post a patch. Just take a look, say what you like or what you don't like, inspire yourselves for better solutions.
Another option could be to dynamically change the number of tiles displayed in one row, depending on the window size. On a regular monitor, we'd show the same 6 + 6 tiles as right now, but on a 768px tablet we'd show 5 + 5 or 4 + 4 tiles instead.
We can also display the popular tiles in 2 rows each group, I mean 2*3 + 2*3, this way we don't lose information. But won't these tiles be too large for the small screens? These are the questions to the designers. I would also recommend placing the software categories in a GtkFlowBox rather than GtkGrid. GtkFlowBox will arrange them automagically. Now when the popular tiles are large (and the details page even larger) they determine the minimum size of the window. But if you make them smaller it will turn out that the software category tiles will determine the minimum, which will be the width of the longest category name multiplied by 4 plus padding and margins. Bad news is that the length and width of the category name depends on the user's language. That's all I would recommend for the overview page but the details page is more complex and I can't yet tell what solutions are the best.
Created attachment 287930 [details] [review] overview: Use GtkFlowBox for software categories Even with the previous patch you will not fit the main window on 1024x768 screen if the locales are set to Portuguese or Galician because the names of software categories are too long. The number of the languages with too long names would grow if we made the window smaller (which is what we want). With GtkFlowBox the categories will be arranged automagically. There should be no visible difference on large screens. I had to change the row and column spacing from 14 to 8 because every child of GtkFlowBox already contains 3px padding on every side. Reviewers: Please note the new behaviour of the Tab key on the GtkFlowBox: it stops twice on every tile. I don't like it but I don't know how to fix it. Any help will be appreciated.
Thanks Rafal! Do you have screenshots how it looks now?
Created attachment 288015 [details] Screenshot of the overview window with the category tiles in GtkFlowBox, LANG=C and pt_BR.utf8 No problem, here it is.
What is the current status of this ticket? I cannot see the flowbox patch in the git yet. What's missing? Do you need additional support?
If it's me who you ask then: 1. I doubt if this patch is 100% correct because the GtkFlowBox cells accept the focus when pressing the Tab key and I don't know how to avoid it. 2. I don't have the commit rights. 3. Even if I had I would not commit without a review. And "thanks" is not a review. :-) If it's not me then I wonder, too.
I would be very much in favour of adopting a responsive approach to the Software "home page". Not only do we need to ensure that it fits on to narrow displays, but Software also looks rather poor on a larger display. An associated issue is that we only show rows of 6 app tiles. This isn't very dense, and it leaves a rather underwhelming impression, like there aren't many apps. It also doesn't look much like a store. Here are some wireframes which hopefully illustrate how a responsive approach could work: https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/software/version2/wire-responsive-scaling.png
Thank you for your new design, Alan. It is very valuable. What is your suggested width of a featured application tile? I'm afraid it will be difficult to fit any valuable content into it when it's smaller than now. Do you want the tiles to appear and grow dynamically when the window size grows? Please note that since the bug 742211 has been fixed we already have such feature and probably you can experience it on your desktop. It's sufficient if you unmaximize the g-s window and squeeze it. What if we actually don't have 8 featured applications? Sometimes we don't even have 6. The current implementation hides all featured/recommended apps if they are less than 6. Please note there is already a bug 734782 reported which requests a way to see all recommended or featured apps if they are more than displayed.
Created attachment 312803 [details] [review] overview: Use GtkFlowBox for categories (rebased, updated, minor improvements) Now since bug 753371 has been fixed it can be committed, IMHO. Also rebased, removed unused variable, explicitly added "can-focus"=FALSE which is required now.
Review of attachment 312803 [details] [review]: Thanks for the patch! Does this work with gtk+ 3.18? I would like to avoid raising the gtk+ dep to anything newer than 3.18 for now. We have a plan to make F23->F24 distro upgrades work through gnome-software and that would mean backporting gnome-software 3.20 to F23, which is only going to have gtk+ 3.18.
(In reply to Kalev Lember from comment #22) > Review of attachment 312803 [details] [review] [review]: > [...] > Does this work with gtk+ 3.18? No, due to a bug 753371. If you try to use it with 3.18 then the users will be unable to access the category tiles with a keyboard. OTOH, one can argue that this is a minor issue since most people use mouse. > We have a plan to make F23->F24 distro upgrades work through gnome-software > and that would mean backporting gnome-software 3.20 to F23, which is only > going to have gtk+ 3.18. Unfortunately, there is no good workaround but I am sure we'll find a solution. Can the fix for the bug 753371 be backported to 3.18? And by the way, please don't close this bug, we need much more patches to reach the required window size.
Please ask Matthias if he would backport it; if so, you can just raise the dependency to 3.18.2.
Matthias said it is probably OK to backport the flowbox patch to 3.18. He may have some questions about the idea of how the distro upgrades would be supported, though.
Great, thanks for checking! If it turns out the gtk+ patch can't be backported, it should be fine to just not use flowbox this cycle. I don't think it's particularly pressing to start using it right now.
(In reply to Kalev Lember from comment #26) > Great, thanks for checking! > > If it turns out the gtk+ patch can't be backported, Good news, it's just been backported: https://git.gnome.org/browse/gtk+/commit/?h=gtk-3-18&id=ca9440c21e2c24a608a0b2bb8bc2884022779664 > it should be fine to > just not use flowbox this cycle. I don't think it's particularly pressing to > start using it right now. As I said in comment 14, it's necessary for the Portuguese (both Brazilian and European) and Galician (https://en.wikipedia.org/wiki/Galician_language) users to reach 1024 pixels width and probably will be necessary for more languages when we are going below 1024 pixels.
Created attachment 313230 [details] [review] details: Info boxes reworked While thinking about the flowbox patch please enjoy this new one. It reworks the info boxes which sometimes show additional information like "This application includes a software source" or "This application requires the internet connection." The main change is making the labels wrapping because nonwrapping labels caused the text to be displayed in one line which in some languages was too wide for some screens. The extreme cases were (as far as I could test) Russian and Greek. Those boxes are almost always hidden but you may observe some of their fallout on your current systems. Here is how to test: kill the running gnome-software and start it with LANG=ru_RU.utf8. Don't click anything. Note that the initial width of the window is large and it cannot be squeezed. This is because all the info boxes are visible by default and the space is reserved for them. Only after displaying the details page for any application they are adjusted (which almost always means hidden) and the window can be squeezed horizontally. At the same time I have removed the grid containers which were intermediate between each info box content area and the labels because their purpose was unclear for me and I guess they were unnecessary. Do you need screenshots for this? Allan and other designers, do you accept this idea? By the way, I think this patch can be safely backported to old branches.
Allan, please answer these questions: 1. Current width of the popular tile is 152 pixels (this may depend on the current font and language, see bug 742211 comment 7.) The spacing between the tiles is 14 pixels. The minimum width of 6 tiles is 982 pixels and this does not count the margins - this will not fit on 768 pixels wide screen. 8 tiles would need 1314 pixels - would not fit on 1020 pixels. Your design shows something like 114 pixels wide tiles and 10 pixels spacing. Do you plan to redesign the tiles? See also my proposal from comment 11 which I wouldn't call a complete design. 2. Our current algorithm tries to display 6 popular and 6 featured applications. If we have less than 6 popular or featured applications we hide whole respective box totally. Additionally, since the bug 742211 has been fixed, if we don't have enough horizontal space we hide one or more tiles but we still require at least 6 popular/featured tiles even if we would not display all of them. How should we handle the transition to 8 tiles? The simplest approach would be to replace "6" with "8" in the algorithm but can we be sure that we'll always have at least 8 featured and 8 popular applications? Wouldn't it be harmful for the medium size screens which would be fine with 6 tiles if we hid the popular or featured box because we don't have 8 apps to display? Wouldn't it be better to try to display 8 apps but hide the box only if we have less than 6 apps? If we had 8 apps in one row but only 6 or 7 in another row wouldn't it be good to display also only 6 or 7 apps in the former row to make both of them look the same? 3. What should happen between 768 pixels and 1340 pixels, e.g., when the user resizes the window? Do you accept a solution for the bug 742211 which would make the tiles appear/disappear as the user expands/shrinks the window? You can experience it already with GNOME 3.18/Fedora 23 playing with the window size.
(In reply to Rafal Luzynski from comment #29) > Allan, please answer these questions: > > 1. Current width of the popular tile is 152 pixels ... Your design > shows something like 114 pixels wide tiles and 10 pixels spacing. Do you > plan to redesign the tiles? See also my proposal from comment 11 which I > wouldn't call a complete design. The mockup I provided in comment 19 is based on the existing tile layout. Some minor adjustments might be required, but I think we'd have to see it in action to know. > 2. Our current algorithm tries to display 6 popular and 6 featured > applications. If we have less than 6 popular or featured applications we > hide whole respective box totally. ... > can we be sure that we'll always have at least 8 featured and > 8 popular applications? Why wouldn't there be 8 recommended/featured applications? If you are referring to the exclusion of installed apps, I thought that was reverted (see bug 746036). > ... ? Wouldn't it be better to try to > display 8 apps but hide the box only if we have less than 6 apps? If we had > 8 apps in one row but only 6 or 7 in another row wouldn't it be good to > display also only 6 or 7 apps in the former row to make both of them look > the same? There should always be the same number of tiles in each of the recommended/featured rows - otherwise the layout will look a mess. > 3. What should happen between 768 pixels and 1340 pixels, e.g., when the > user resizes the window? The scaling logic I had in mind: * Each tile should have a maximum and a minimum width. * The width of the tiles should shrink/expand to fill the available space. * Never show more than 8 tiles in a row. * If there isn't enough room, reduce the number of tiles. * Never show less than 6 tiles in a row - this defines the minimum window width. > Do you accept a solution for the bug 742211 which > would make the tiles appear/disappear as the user expands/shrinks the > window? You can experience it already with GNOME 3.18/Fedora 23 playing with > the window size. Yes, that's good!
(In reply to Allan Day from comment #30) > The mockup I provided in comment 19 is based on the existing tile layout. > Some minor adjustments might be required, but I think we'd have to see it in > action to know. If by "minor adjustments" you mean a redesign of the application tiles so they can fit in 114 pixels width then I like this idea but I can't implement it without a detailed design. > Why wouldn't there be 8 recommended/featured applications? If you are > referring to the exclusion of installed apps, I thought that was reverted > (see bug 746036). As you probably know there are 4 Categories of the Day: Audio, Games, Graphics, and Office. In Audio we have only 7 featured (a.k.a. Recommended) Audio Applications. If we require 8 recommended application we get this warning on the text console: Gs-WARNING **: hiding recommended applications: found only 7 to show, need at least 8 and the Recommended box is hidden. Other categories are fine, though. You can browse the categories in g-s in your computer and review the Featured subcategory for each category, these are the recommended applications. As you can see, there is already a piece of code which ensures that either there are 6 recommended applications or none are displayed. > The scaling logic I had in mind: > > * Each tile should have a maximum and a minimum width. > * The width of the tiles should shrink/expand to fill the available space. > * Never show more than 8 tiles in a row. > * If there isn't enough room, reduce the number of tiles. This is fine. Either we already have it implemented or we need a detailed design. > * Never show less than 6 tiles in a row - this defines the minimum window > width. Even now it is difficult to achieve. For most European languages the minimum window width would be just below 1024 pixels, for some other (bug 742211) it would be even more. That's why we have agreed to display less than 6 tiles if we have not enough space. Although any alternative design idea will be welcome.
Thanks Rafal! I edited the flowbox patch to bump the gtk+ dep to 3.18.2 and pushed them to master: Attachment 312803 [details] pushed as 472cc67 - overview: Use GtkFlowBox for software categories Attachment 313230 [details] pushed as c30c620 - details: Info boxes reworked to fit on small screens
Created attachment 316151 [details] [review] All labels reworked to make sure they don't grow too much horizontally A user has spotted a problem directly related with this bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1282610 I have reviewed (hopefully) all labels and reworked those which potentially could grow too wide horizontally and consequently make whole window grow. I hope it is correct, please test and review.
Created attachment 316153 [details] [review] details: Properties labels reworked again While at this, I have also reworked the properties labels in the bottom of the details page. IMHO they looked bad when the categories path was ellipsized (probably this does not happen in English but does happen in other languages), when the licenses caused the page to be larger, and when the property name appeared near the middle of the long and wrapped property value. Now they are all aligned to the top. This patch is not directly related with the window being too wide but I hope you will like it.
Review of attachment 316151 [details] [review]: Thanks!
Review of attachment 316153 [details] [review]: Thanks!
Rafal, is your screenshots-in-flowbox-in-flowbox stuff ready?
(In reply to Richard Hughes from comment #37) > Rafal, is your screenshots-in-flowbox-in-flowbox stuff ready? Again with asking developers questions in NEEDINFO :( Spending too much time on the RH bugzilla?
(In reply to Richard Hughes from comment #37) > Rafal, is your screenshots-in-flowbox-in-flowbox stuff ready? I'm really sorry to say this but it's not and I can't even prepare a work-in-progress patch at the moment.
I returned back to working on this bug. The final thing to do will be placing the screenshots inside a combo of flowboxes which will display the thumbnails in a vertical column to the right of the main screenshot on large screens (as it is now) but will flip to displaying them in a horizontal row below the main screenshot on small screens. Unfortunately, this must be placed inside a GsFixedSizeBin (directly or indirectly). The current approach with box_details having width_request=752 will not work. Here are the reasons: * width_request actually means the minimum width. The box will never be smaller than this so we must get rid of this anyway if we want to support smaller screens. Note that this width 752px does not include margins. * If we change this value to something smaller or remove it at all the actual width of the box will be the largest of minimum widths of all its children. In the case of the flow box it means that it will place the thumbnails under the main screenshot and will report the width of the main screenshot as its required minimum width. It will have no desire to place the thumbnails vertically to the right of the main screenshot even if there is a place for that. * Alternatively, we can apply halign=fill for the box_details (currently it has halign=center) but that means it would fill entire window on large screens. Again this is not what we want (see bug 761240). * Even worse, the flow box will try to place the thumbnails to the right of the main screenshot but horizontally (sic!) or in something mixed in a flowbox style. * So summarizing all requirements again: the flowbox must require the minimum width sufficient to fit the main screenshot with the thumbnails below it, must use the additional horizontal space to place the thumbnails horizontally to the right of the main screenshot, must not be able to accept more horizontal space to place the thumbnails in more than one column to the right of the main screenshot. * Probably it will be better to have two GsFixedSizeBins: one to limit the width of whole page (this is what bug 761240 is about), and another to limit the width of the screenshot box and make sure it will not try to place the thumbnails into anything different than a single vertical column on a large screen.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-software/issues/15.