Opened 12 years ago

Closed 8 years ago

#39 closed defect (obsolete)

Support various screen resolutions/DPI in sugar themes

Reported by: mungewell Owned by: eben
Priority: major Milestone: Unspecified
Component: journal Version: 0.84.x
Severity: Unspecified Keywords:
Cc: tomeu, sascha_silbe Distribution/OS: Unspecified
Bug Status: Assigned

Description

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

Attachments (2)

journal_resolution_issue.png (32.9 KB) - added by erikos 12 years ago.
in detail view cut off
0001-bug-39-scale-down-for-small-displays.patch (839 bytes) - added by homunq 12 years ago.
patch to sugar - scale down to 72 if w<900 or h<700

Download all attachments as: .zip

Change History (18)

comment:1 Changed 12 years ago by tomeu

  • Component changed from sugar to journal
  • Owner changed from marcopg to tomeu

comment:2 Changed 12 years ago by tomeu

  • Cc tomeu added
  • Owner changed from tomeu to eben
  • Status changed from new to assigned

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

comment:3 Changed 12 years ago by gregdek

  • Bug Status set to Needinfo
  • Distribution/OS set to Unspecified
  • Severity set to Major

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

comment:4 Changed 12 years ago by erikos

  • Bug Status changed from Needinfo to Assigned
  • Milestone set to 0.84
  • Summary changed from Journal: Information tags/participants cut off 1024x600 to Journal detail-view: Information tags/participants cut off 1024x600
  • Version set to 0.84.x

Changed 12 years ago by erikos

in detail view cut off

comment:5 Changed 12 years ago by 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.

Changed 12 years ago by homunq

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

comment:6 Changed 12 years ago by homunq

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

comment:7 Changed 12 years ago by homunq

  • Keywords r? added

comment:8 Changed 12 years ago by erikos

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

comment:9 Changed 12 years ago by sascha_silbe

  • Cc sascha_silbe added

comment:10 Changed 12 years ago by tomeu

  • Severity changed from Major to Blocker

comment:11 Changed 12 years ago by erikos

  • Milestone changed from 0.84 to 0.86

The patch and the discussion is still valid.

comment:12 Changed 11 years ago by 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 ...

comment:13 Changed 11 years ago by 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.

comment:14 Changed 11 years ago by alsroot

  • Keywords r? removed
  • Milestone changed from 0.86 to Unspecified by Release Team
  • Summary changed from Journal detail-view: Information tags/participants cut off 1024x600 to Support various screen resolutions/DPI in sugar themes

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.

comment:15 Changed 11 years ago by alsroot

  • Severity changed from Blocker to Unspecified

comment:16 Changed 8 years ago by godiard

  • Resolution set to obsolete
  • Status changed from assigned to closed

Obsolete. Open a new one if needed.

Note: See TracTickets for help on using tickets.