GNOME Bugzilla – Bug 742211
GNOME Software doesn't fit into a 1024x768 screen
Last modified: 2015-04-16 21:14:25 UTC
I can reduce the width of GNOME Software to 1024, so it doesn't fit my screen. I really don't see why it can't be smaller (maybe because of some images?). Surprisingly, it's height can be very small. Even if it is preferred to have a bigger minimum width, I'd suggest to make sure that the minimum width is at most as wide as the width of the screen. The current experience in such screens is really annoying, so don't fear about loss of quality. Thanks
What version of GNOME Software is it? We worked on the minimum width issue during this cycle to make sure it works fine on smaller screens and 3.14.x is supposed to fit nicely on 1024x768 screens. Can you post a screenshot how it doesn't fit the screen? Thanks!
Created attachment 293598 [details] Minimum Size Screenshot
It's 3.14.2. A slightly scaled down screen shot is attached. You can see that the scroll bar at the right side is not visible. While the screenshot shows the main screen, other screens also have the same minimal width. The screenshot shows the minimal width/height in my system.
From my research it seems that this specific bug: - occurs only with LANG=fa_IR.utf8 (Hedayat, do I guess right that this is your native locale?), also may occur with some other locales I have not tested; - is not caused by gnome-software; - is caused by some other library: my suspects are gtk and/or pango; - does not occur with the latest version from git of these libraries. Here are the steps to reproduce my test: 0. # Work on a real or virtual machine with 1024x768 screen. 1. # Get the latest sources of gnome-software and required libraries (gtk, pango, ...) from git and build them. Actually, the libraries will be sufficient. 2. killall gnome-software # or otherwise any your 'gnome-software' command will just bring the already running process to the foreground 3. LANG=en_US.utf8 /usr/bin/gnome-software # no bug because LANG is not fa_IR 4. LANG=fa_IR.utf8 /usr/bin/gnome-software # BUG! gnome-software window does not fit! 5. LANG=fa_IR.utf8 LD_PRELOAD=~/jhbuild/install/lib/libgtk-3.so.0:~/jhbuild/install/lib/libgdk-3.so.0:~/jhbuild/install/lib/libpango-1.0.so.0 /usr/bin/gnome-software # no bug! And use your correct location of the newly built libraries In the last step there is no bug although we use the same gnome-software with LANG=fa_IR.utf8 which initially exposed the problem. I don't know which library (gtk, gdk, pango) caused the problem but gnome-software will not run correctly if I preload only one or two of them. Please anybody repeat my test and confirm. My suggestion is either to find a specific bug report in gtk or pango which caused this problem and mark this bug as a duplicate or just mark this one as "works for me" because the problem is already solved in the git repository and the solution will eventually reach the end users' machines. I have tested with the installed gtk3 3.14.6-1 and built from git gtk3 3.15.3.
Yes, I was using fa_IR.utf8 locale and I confirm that the bug doesn't happen when run in en_US.utf8 locale.
Can you get a newer version of gtk3 and maybe pango, from git.gnome.org or from koji.fedoraproject.org or whatever fits your Linux distro, and confirm that it fixes your problem?
Created attachment 298585 [details] [review] Patch that should fix the problem This is more complex than I thought. First of all, it does not depend on the gtk or pango version because I tried to checkout the older sources from git and with jhbuild and fa_IR.utf8 locale gnome-software always fits into 1024x768. This must be caused by another library, fonts/themes available, etc. But after the investigation I think that we should not rely on a specific library version which makes gnome-software fit or not fit into 1024x768. Here is why sometimes it fits and sometimes does not fit. The minimum and natural width of the label (widget id="label") is set to 12 chars. In order to calculate pixels from chars pango multiplies it by a factor which depends on the current font and the current user's language, and it does not matter if the text to be displayed is actually localized or English. With the current default font Cantarell 11 and most of languages I have examined the quotient is 9, multiplied by 12 makes 108 pixels. Let's calculate: * Plus 6 pixels margin on each side the label occupies 120 pixels. * Plus 15 pixels margin on each side the box (id="box") and eboxbox has 150 pixels. * Plus 1 pixel border the popular tile has 152 pixels. * Multiplied by 6 and plus 5 spacing between the tiles 14 pixels each the box_popular has 982 pixels. * With 12 pixels margins on each side the box_popular actually occupies 1006 pixels. * Without the overlay-scrolling mode the scrolledwindow_overview needs 15 pixels for the vertical scrollbar. This makes total 1021 pixels which fits into the 1024 pixels wide screen. Now if the pixels/char ratio is 10 instead of 9 the 1 pixel difference must be multiplied by 12 chars and 6 tiles, the total difference is 72 pixels and the total window width is 1093 pixels which does not fit into 1024x768 screen. I have noticed this difference with fa_IR.utf8 but also with Greek and Cyrillic scripts. Even if in some setup the bug does not occur it may occur in future in any language if we or our user changes the default system font or if the rendering library is changed. So we cannot always rely on the label width in chars. With this patch I propose to use width-request set to 108 pixels instead of 12 chars. For most languages it does not introduce any visual change, for some languages which suffer from this bug it sets the correct width of the label. In future the width of the label in chars may be restored if we find a better way to fit the tiles into the screen even when their actual width may be unpredictable.
Review of attachment 298585 [details] [review]: No, thats not the right way to fix this. If the layout is not flexible enough to adapt to a small screen size, it is not the right answer to make it even more rigid...
I would suggest that we should do something similar to what we do for gnome-initial-setup: If we detect a 'small screen', maximize the window, and change the scrolled window to allow horizontal scrolling if needed.
Created attachment 298695 [details] [review] Copy with small screens When we find a screen that is 1024 or fewer pixels wide, maximize the window and allow horizontal scrolling in the overview.
Very quick patch to show how this could look.
We had quite a few discussions about this bug on IRC so I will put down here some conclusions we have had before we forget them. They obsolete most of the comments above. We are going to hide some of the popular tiles when we have not enough space to display them all. This includes the cases when the screen is small but also when the user shrinks the window, we will not disable this feature on big screens. Currently the tiles are placed inside GtkBox. [1] Neither GtkBox nor any other container in GTK provides these features so we will have to implement our own custom one. It should be similar to GtkBox but we don't need all its features: we need only horizontal orientation, we don't need all expand and packing options. Optionally we could think about the possibility to mark individual children as "hideable". The new custom container will be derived directly from GtkContainer. There was a question: when the window shrinks we hide one tile and this gives us some additional space, probably more than we need. What shall we do with this extra space? The default answer is: the extra space is allocated to the remaining tiles because they are placed in the GtkBox with expand=TRUE and fill=TRUE. This should be changed, the extra space should make the additional spacing between the tiles, they should not grow, should behave like having fill=FALSE. The original author of probably all of these ideas is Matthias Clasen. [1] https://developer.gnome.org/gtk3/stable/GtkBox.html
Created attachment 299375 [details] Screencast with the new hiding box Please take this as a preview of how it would look like when finished. You can look and tell if you like it or not. The screencast has been made with LANG=fa_IR.utf8 and GTK 3.14.6 (10 pixels width per character). The display is 1280x960 but the window can be shrunk and will fit into smaller screens. The patch is not yet ready, needs some more testing and polishing.
My guess is that the designers might prefer not to have moving pieces, and just keep things left-aligned with fixed spacing.
In any case: good work!
The Mac App Store has a similar look and has exactly the same moving pieces. Anyway, this is the aim of this screencast: to let the designers and other interested people express their opinion already.
Thanks! :) I like it.
Created attachment 299560 [details] [review] Introducing GsHidingBox Here is the promised patch. Sorry for the delay. This time I have decided to obsolete two previous patches, I hope it is OK. Feel free to review, test, comment, etc. We still have not heard an opinion from the UI designers whether we should spread the remaining popular tiles when we hide one of them or align them to the left/start of the box. Please commit only if the time is right for committing. We are in the hard code freeze period, aren't we?
That file should be Copyright (C) 2015 Rafal Luzynski! (In reply to Rafal Luzynski from comment #18) > Please commit only if the time is right for committing. We are in the hard > code freeze period, aren't we? Yup
Review of attachment 299560 [details] [review]: Looks good to me, aside from the copyright notices that were already pointed out.
OK, that's a really minor issue. :-) So let's wait until the end of the hard code freeze which should be next week and then I'll provide the corrected patch. Also this is a chance for more people (UI designers!) to provide their feedback.
Created attachment 300164 [details] [review] Introducing GsHidingBox Here is the new version of my patch. It does not introduce other changes to the previous one except the copyright message that you mentioned above.
I think this looks great. Thanks for working on this, Rafal! We've branched for 3.16 now and master is open for new development, so let's try and get this merged. One thing I noticed when testing it is that the shadows around the tiles are now all clipped. Can you fix that please? https://kalev.fedorapeople.org/gnome-software-before-hiding-box.png https://kalev.fedorapeople.org/gnome-software-after-hiding-box.png
Created attachment 300411 [details] [review] Introducing GsHidingBox Here is the new version with the box-shadows NOT cut off. Kalev, thank you for pointing this out. The issue was that my box missed the correct call of _gtk_widget_set_simple_clip() which is called by most containers at the end of their size_allocate function. However, since _gtk_widget_set_simple_clip() is private I cannot call it so I had to provide my own piece of code which is partially a copy of _gtk_widget_set_simple_clip(). Some people on IRC told me that this could involve some license issues between GTK+ and gnome-software so I'd like to notify you and ask about your opinion about it. By the way, the GsHidingBox is heavily inspired by GtkBox.
Created attachment 300505 [details] EknSpaceContainer example I mentioned at one point on IRC while this bug was being discussed that we have something similar internally and I would try to get permission to post it here. I finally did - see attachment; EknSpaceContainer (in GJS). Unfortunately it won't work by itself because of a bug in GJS that prevents you from implementing GtkContainer vfunc_forall - inheriting from Endless.CustomContainer is a workaround for that. I could post that too but it's pretty straightforward and wouldn't be necessary in C. Probably this is too late to fix the gnome-software problem, but if people found this useful, I would be interested in combining EknSpaceContainer with GsHidingBox into a GTK widget. jrb suggested GtkOverflowBox as a good name.
So we have two solutions, let's see what the project leaders say. Now I'm also thinking about possible third solution: we could derive a custom container from GtkBox if it only did not ignore the "child-visible" property of its children. Maybe it's a bug in GtkBox and we should file and fix it? I remember this IRC discussion you mention and just to remind we have also discussed an idea of a new container which is already filed as bug 745317.
Is GtkBox supposed to be supplanted by GtkGrid in the future, though? Let me clarify that I wasn't suggesting EknSpaceContainer as a second solution for this problem - you already have GsHidingBox which will do the job, and this one arrives quite late and still needs porting into C. But we could combine the best of both solutions and fill a need that is obviously there in GTK.
(In reply to Philip Chimento from comment #27) > Is GtkBox supposed to be supplanted by GtkGrid in the future, though? I may be wrong but I have never heard about this idea. By the way, if you would like to propose a new widget for GTK then I suggest you to file a new ticket against GTK. Let's focus on the tiles being too large for 1024x768 screen here.
Created attachment 300894 [details] [review] Introducing GsHidingBox This is the new corrected version of my patch. This new version: * adds the new gs-hiding-box.c file to POTFILES.in to let the description of the "spacing" property be translated, * adds a comment for the translators about the "spacing" property.
I like this. However it would be even better if the size of the boxes itself expanded/shrunk rather than the whitespace between them. ie box padding rather than margin expanding. Also big thanks for the screencast!
Created attachment 301580 [details] Screencast with the new hiding box + expanding tiles Jakub, here is the new screencast with the popular tiles expanding/shrinking instead of getting extra spacing between them. Now you can choose.
Created attachment 301583 [details] [review] Introducing GsHidingBox + expanding tiles This new version of the patch causes the popular tiles to expand when one or more of them are hidden, as suggested by Jakub. Please note that I do not mark the previous patch as obsoleted, you will have to choose which one you prefer and commit at most one of them.
Thanks for working so long on this Rafal. :)
(In reply to Rafal Luzynski from comment #31) > Created attachment 301580 [details] > Screencast with the new hiding box + expanding tiles This is much better (obviously items jumping into view isn't, but transitioning that is outside of the scope of this bug). Great work, Rafal.
Review of attachment 301583 [details] [review]: Looks good to me