GNOME Bugzilla – Bug 719760
Annoying default window size with numerous cities
Last modified: 2020-11-24 15:16:38 UTC
Created attachment 263386 [details] Clocks window after launch When adding a non-trivial number of cities (I have 9), the default window size for clocks leaves a lot of whitespace and only shows two per row. Screenshot attached. The problem may be caused by the scrollbar appearing when not all cities can fit in the window by default. It would be nice if it sized itself a bit better by default.
I do not understand this to be honest, why don't you just change the window's width?
(In reply to comment #1) > I do not understand this to be honest, why don't you just change the window's > width? Because you might want to keep the clocks window small, so you can see other windows? I would really like to try using a responsive layout for the world clocks grid. :)
(In reply to comment #1) > I do not understand this to be honest, why don't you just change the window's > width? Because the whole point of computers is getting them to do the work you don't want to do yourself? :)
A couple of experiments for doing a more responsive layout here: https://raw.github.com/gnome-design-team/gnome-mockups/master/clocks/responsive-grid-wires.png The idea is that the layout would dynamically adjust according to the number of items and the size of the window. This could be an interesting test case for the new flow box widget.
(In reply to comment #4) > A couple of experiments for doing a more responsive layout here: > > https://raw.github.com/gnome-design-team/gnome-mockups/master/clocks/responsive-grid-wires.png > > The idea is that the layout would dynamically adjust according to the number of > items and the size of the window. This could be an interesting test case for > the new flow box widget. There is a bug report (Bug 712695), in which a user requests a possibility to make a clock window smaller. This is restricted at the moment by the stopwatch/timer design with a circle around widgets. So we need an improvement here. However, I am a bit confused by your new design proposal for the clock view:-) I have labeled images like: 1 2 3 4 So, a lot of questions arises :-) In a case of a single added clock the single view and grid view modes seem to be conflicting with each other. I have assumed, that by adding clocks the grid layout should change from 1 to 4. In the same time the square size of each clock gets smaller in size. Will it be possible to have clocks aligned in the linear layout like it's shown in the fig. 3? With the current design it is possible just by playing with the window size. When should a scrollbar appear? Is it possible to switch between layouts shown in fig. 3 and 4, back and forth?
There are plenty of details to work out if we want to go down this road, and it will take some experimentation to get it right. The rough shape of what I'm proposing is: * Always keep the padding around each clock fixed. * Have a minimum size for each clock. * Try and keep the size of each clock as large as possible. * Only scroll if the clocks won't fit on the visible view (with their minimum size). * Once the view is scrolled, try and keep the height of the scrolled area as low as possible. That could be a bit tricky of course, and we should try and simplify it if we can.
I was coming to Bugzilla to report the same issue. Your app should pick a *default* window size that looks good. Currently the bottom row of clocks gets cut off slightly (not a big deal) and there is a huge amount of whitespace on the right edge. This gives a negative first impression of the app. I like Allan's responsive design suggestion a lot. However, the obvious one-line solution that we apply in other apps with similar issues is to just pick a better default size. Current that is 870x690. 925x725 looks good to me.
The current design uses libhandy and is responsive. The issue described here seems gone.