Support various screen resolutions/DPI in sugar themes

[mungewell]

On a 1024x600 screen the bottom of the information pane is cut off.

[tomeu]

Eben, can you take care of this, please? Thanks!

[gregdek]

Please check to see if this is happening in the latest version, and if so, please provide a screenshot. Thanks!

[erikos]

in detail view cut off

[homunq]

I think that the right solution for such a tiny display is to globally scale the display, using the bin/sugar to set SUGAR_SCALING to 72. The question is, how to detect display resolution from this shell script? The only solution I can think of is an evil hack involving xrandr and sed, and there has to be a better way.

[homunq]

patch to sugar - scale down to 72 if w<900 or h<700

[homunq]

Can someone test this patch and see if it fixes things?

[erikos]

I *think* a detection should take the dimensions and the resolution into account.

[erikos]

The patch and the discussion is still valid.

[walter]

More discussion re scaling strategies from IRC

• silbe declares "gracefully" the word of the day <g> <silbe> tomeu: is the "[lowest] resolution [...] we support" documented anywhere? <tomeu> silbe: indirectly, yes <tomeu> I guess it depends on what you say documented means <walterbender> silbe: Sugar will "gracefully degrade" down to 1x1 pixels :) <silbe> walterbender: not according to #308 :) <tomeu> silbe: in the HIG is specified the number of grid cells sugar is expected to have available <walterbender> silbe: I haven't tried at less than 800x600 in a long time... <tomeu> silbe: and we support two modes: 72 and 100 <silbe> tomeu: if we say "800x600 isn't supported because it doesn't fit what the HIG specifies", we should add that at least to some README, or even better show a warning. <silbe> tomeu: IMO we should at least support any (native) resolution on "netbook" style hardware, though, including 800x600. <tomeu> silbe: the HIG only mentions the number of grid cells <walterbender> silbe: I am running at 640x480 right now... Sugar basically works... <tomeu> it's more a limitation of the implementation <walterbender> I think some activities will start to degrade (ungracefully :) <walterbender> browse is not bad at 640x480 :) <silbe> walterbender: basically, yes, except for some issues like the control panel clipping some text ;) <walterbender> silbe: yeah. well that can be a problem even at 1200x900 <silbe> walterbender: ok, then it's a plain bug. i was worried because tomeu mentioned he suspected "people were running Sugar on a lower resolution than we support". i would hate seeing Sugar not support common Netbook-style hardware... <walterbender> silbe: we can recommend a minimum size, probably 800x600 that we should try to guarantee that all of sucrose adheres to <walterbender> silbe and maybe just document recommendations beyond that <tomeu> silbe: should be quite easy to add more cell sizes <tomeu> silbe: we jut started supporting the XO and what we were running jhbuild on <walterbender> silbe: e.g., circle view in not very useful at 640x480, but random view is quite easy to read <silbe> walterbender: the problem is the users doesn't have a choice since the hardware defines the size <walterbender> rgs_: I had not heard. great news <walterbender> silbe: true enough, but we cannot solve every problem for everyone... <silbe> tomeu: ok, so it's more a "lower than currently works properly because of fixed scaling settings", not "we don't want to support these sizes"? <walterbender> silbe: Even the smallest netbooks have 768x480 dsiplays, I would guess <walterbender> what is the resolution of an iPhone? <cjb> walterbender: 480x320, looks like <tomeu> silbe: yup <tomeu> for wanting, I would want to support scaling down to 1x1 sizes ;) <walterbender> cjb: let me take a snapshot of Sugar at that res :) <silbe> tomeu: hehe, we can do that easily. it's the sizes in between that are troublesome ;) <tomeu> silbe: btw, there's also the issue of correctly setting SUGAR_SCALING <tomeu> silbe:  http://dev.sugarlabs.org/ticket/39 <walterbender> there is a toolbar problem with scaling as well... see  http://wiki.sugarlabs.org/go/File:Pre-86-toolbars.png and  http://wiki.sugarlabs.org/go/File:Post-86-toolbars.png <silbe> walterbender: i think there are two dimensions to it: a) not breaking (by e.g. clipping text), b) "optimal" layout <walterbender> if you have a input field that doesn't fit, then you have no way of using it... <walterbender> buttons work on the pull-down menu but not input fields <silbe> walterbender: i agree we shouldn't spend too much on b) without a good reason, but a) should work in general (by adding scroll bars) <walterbender> so, for example, Browse at 480x320 works, but you cannot type in a URL :( <walterbender> silbe: that is how I dealt with it on TA <walterbender> silbe: TA portfolio presentations look great at 480x320 :) <silbe> tomeu: #39 (including the solution) sounds good to me in general. what's blocking it? <walterbender> silbe I think the toolbar issue is a blocker for small sceens <silbe> tomeu: that reminds me i'd like to talk to you about the "sugar" script... <tomeu> silbe: someone to check that the proposed patch addresses all screens instead of fixing ones and breaking others <walterbender> for laughs, check out  http://wiki.sugarlabs.org/go/File:Sugar-480x320.png <silbe> tomeu: do you mean that it works for all small screens or that it doesn't somehow set scaling correctly for larger screens? <silbe> walterbender: lol <tomeu> silbe: that I would expect that we need to take into account both dimension in pixels and dpi <tomeu> silbe: I may be wrong, but nobody has explained why <silbe> tomeu: IIRC albert cahalan has done a pretty good explanation on the mailing list <silbe> tomeu: but that's how it should work long-term, with proper dynamical scaling <tomeu> silbe: so what do you think about the patch in #39? <silbe> tomeu: for the current code, i think low resolution = lower distance to screen => reduce pixel size of screen items is a good guesstimate. <walterbender> tomeu + silbe: I actually think that stylesheets were invented to deal with the problem #39 is trying to address <tomeu> silbe: but we cannot take into account the distance to the screen, right? <walterbender> global scaling is a crude solution that will not really work in practice <silbe> tomeu: the exact values for the switchover are debatable (= could do some testing), but in general it looks good to me <tomeu> walterbender: how would help stylesheets? <silbe> tomeu: for a proper solution, the distance to the screen is exactly what we need, but don't know. that's why it should be a setting, with some heuristic (like the one proposed in #39) as a default. <walterbender> tomeu: a simple example: by switching to random home view, suddenly my icons are bigger <walterbender> scaling the circle doesn't work--it gets too small <tomeu> walterbender: oh, that's a known bug in icon sizing there <walterbender> you need different heuristics at different sizes... why stylesheets were invented in the first place <walterbender> tomeu: it is not a icon-sizing bug... it is that the layout itself is unsuitable for small displays <walterbender> on a big display, you can afford to waste space to make other tradeoffs. on a small display, you cannot <tomeu> oh, so the problem is the circle <tomeu> I see now <silbe> walterbender: i don't think the circle doesn't scale (no pun intended) in the long term (i.e. with increasing number of activities on a learners system) anyway. but i admit i don't have any real-world experience with that... <walterbender> so we would ultimatelty want styles that adapt to available resources <walterbender> this would also solve silbe's problem re the circle not scaling as it fills <walterbender> and activities could have preferences re what buttons are shown on what menus depending on scale <tomeu> erikos, alsroot, benzea, *: what do you think of this list of blockers:  http://tinyurl.com/lgr74k ? do you think the tickets there should really block the release? <silbe> walterbender: i agree in general, though i think we still need scaling (unless you expect the user to edit the style sheet). <walterbender> silbe: we need both. but no need for the user to edit... we can have reasonable defaults triggered by screensize <silbe> walterbender: i meant that the activities won't fit in the circle, no matter how big your screen is. the icons should always be the same size. <silbe> walterbender: no, we need to let the user tweak the sizes. we can't possibly know what's best. think users with bad eyesight... <walterbender> silbe: when that happens, a new layout should be triggered. We have some nice ones. See  http://en.flossmanuals.net/Sugar/ModifyingSugar <walterbender> silbe: that too. <walterbender> silbe: we need that for accessibility, if nothing else... <tomeu> I guess we'll need to let users change the scaling and font size, just like web browsers do now <walterbender> silbe: but my point is that different sized icons (or smaller screens) requires differenet layout strategies, hence the need for stylesheets <silbe> tomeu, walterbender: exactly :) <silbe> walterbender: no disagreement on that. style sheets for bigger changes, scaling for tweaking. <tomeu> gtk will get there, not sure about qt <benzea> stylesheets? widgets are not html elements :-) <silbe> benzea: what's the difference? :-P <benzea> well, I have had loads of discussions about css vs. eg. gtkrc in the past ...

[erikos]

Can we get a summary of a doable plan? /me heard about: "as a short term measure, add 5 or so steps to the gtkrc".

Not sure this is a blocker for 0.86 - could be 0.86.x to me as well.

[alsroot]

Lets change title to not confuse readers since this ticket is not only about issue in details view(and moreover, it can can be reproduced only with scale 100 which is useless for such resolution) and 72 scaling is default for now due to #565.

And switch milestone to Unspecified until we encounter need of new scaling for particular deployment.