[Bugs] #39 MAJO: Journal detail-view: Information tags/participants cut off 1024x600

[Sugar Labs Bugs]

#39: Journal detail-view: Information tags/participants cut off 1024x600
----------------------------+-----------------------------------------------
    Reporter:  mungewell    |          Owner:  eben    
        Type:  defect       |         Status:  assigned
    Priority:  major        |      Milestone:  0.86    
   Component:  journal      |        Version:  0.84.x  
    Severity:  Blocker      |       Keywords:  r?      
Distribution:  Unspecified  |   Status_field:  Assigned
----------------------------+-----------------------------------------------

Comment(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 ...

-- 
Ticket URL: <http://bugs.sugarlabs.org/ticket/39#comment:12>
Sugar Labs <http://sugarlabs.org/>
Sugar Labs bug tracking system