Re: F11 for XO1 - Fonts
Art Hunkins <abhunkin <at> uncg.edu>
2009-09-01 02:25:53 GMT
I've developed a way to handle fonts both on the XO-1 and on SoaS that fits
text nicely, on fixed pages, to all-sized screens.
I've written up this material immediately below, and invite everyone's
critique. I'd particularly be interested in any example cases in which it
would not work. I'm assuming that all monitor ratios will fall in the range
of from slightly less than 4:3 up to 16:9 (wide-screen format).
If the consensus is that the material would be worth posting on the Sugar
wiki, I will do that - and I'd appreciate suggestions as to where would be
the most appropriate place.
Also, if it would help for me to forward (to the sugarlabs list) one of the
text-based .xo's I've developed, in order to facilitate testing, I'd be
happy to do so.
Art Hunkins
Fixed-Screen Text Formatting for Sugar (XO-1 and SoaS)
Formatting text for the various-sized screens that are used with
Sugar-on-a-Stick, is a tricky proposition. The activities I am developing
are text-based, requiring only buttons, spinners, frames and boxes
otherwise. They are intended to fit on a single screen, with no scrollbars.
The challenge is to create a text layout that looks pretty much the same on
all screens. (Typical screen ratios vary from slightly less that 4:3 up to
16:9 [wide-screen].)
There are two problems: 1) choosing the right font size to fill screens
similarly as width varies; 2) adjustment for different width-to-height
ratios (4:3, 16-9 and everything in between). This latter boils down to a
variable number of text rows.
The issue is complicated by the fact that while the XO-1 is a normal 4:3
ratio, it doesn't count pixels the way SoaS does. As far as font size is
concerned, the XO-1 must be treated as its own special case.
I have pretty much solved these knotty problems by incorporating the code
below, as well as by following this plan:
1) Compose my basic screen (4:3) on the native XO-1.
2) Copy it to SoaS and make sure it looks good on a 4:3 non-XO system. (My
desktop monitor is a bit less than 4:3, which is, I think, the lowest ratio
you'll find.)
3) Add to the script a "16:9 alternative," reducing the number of text lines
so that everything fits on this size screen. (I used an asus eeePC900
netbook here.)
4) Test my SoaS script on other screen formats.
The code:
import os
width = gtk.gdk.screen_width() # determine screen dimensions
height = gtk.gdk.screen_height()
if not os.path.exists("/sys/power/olpc-pm"): # test for XO-1; leave XO-1
alone
settings = gtk.settings_get_default() # non-XO code begins
size = width * .0125 # font size is a function of screen width
settings.set_property("gtk-font-name", " %s " % size) # set font size
if (height * 1.35) > width: # examine width-to-height ratio
# code for 4:3 (or less) ratio screen; same as native XO-1 (4:3)
else:
# code for > 4:3 up to 16:9 ratio screens (reduced number of lines)
----- Original Message -----
From: "Daniel Drake" <dsd <at> laptop.org>
To: "Art Hunkins" <abhunkin <at> uncg.edu>
Cc: "Martin Langhoff" <martin.langhoff <at> gmail.com>;
<sugar-devel <at> lists.sugarlabs.org>; <fedora-olpc-list <at> redhat.com>
Sent: Tuesday, August 18, 2009 1:19 PM
Subject: Re: [Sugar-devel] F11 for XO1 - Fonts
> 2009/8/18 Art Hunkins <abhunkin <at> uncg.edu>:
>> I'm thoroughly confused and frustrated.
>>
>> My POV: I'm authoring an Activity *today*. I'd like it to look good on
>> all
>> XO and (other) Sugar on a Stick screens (monitors) *today*.
>
> I think you're out of luck then. You could detect the XO somehow and
> choose a good setting that works there, but as for all of the SoaS
> machines in the world, they all have different displays and there
> isn't going to be one default setting that looks good on them all
> (hence our discussion of making this customizable by deployers and
> users). Unless you want to place a personal guarantee that you'll
> purchase any display that any SoaS user is ever possibly going to use,
> before they use it. and even then you aren't considering the quality
> of the users eyesight or the distance they will sit from the monitor.
>
>> I am lukewarm at best to having a user option in Control Panel to make
>> font
>> size smaller or larger. (Please count me as a -1 for this suggestion.)
>> For
>> *my* activity, this would only allow kids to make text too small to read,
>> or
>> possibly overflow the screen
>
> If the user clicks "make text smaller" to the point where the font is
> too small to read then that's their problem, not yours, and they'll
> hopefully realise that they can fix the situation by clicking the
> "make text bigger" button.
>
> If they make it so big that you run out of space in your activity, you
> could dynamically add scroll bars.
>
> If it really is important that you fill the screen with text without
> scroll bars, then your activity would be an exceptional case that
> ignores the Sugar font size setting, and instead dynamically
> calculates the font point size needed to make the text fill the screen
> nicely.
>
>> Basically, I strongly feel that *authors* - not users, not the system
>> (including upstream), nor even deployments - should determine their basic
>> screen layouts. "One size" certainly does *not* fit all; and any/all
>> defaults should be overridable by authors in their scripts. It should be
>> the
>> *author's* responsibility to make their activities look right on various
>> monitors.
>
> I disagree. This is an impractical responsibility to pass on. However,
> activity authors can of course render any graphics that they like, at
> any size, including fonts. They do not have to obey the font sizes
> suggested by Sugar, as is the situation now (sugar provides one font
> size in the GTK+ RC and another in profile.py but you can actually use
> any font size that you want).
>
> Daniel
From Mike C. Fletcher's email it seems we may be better of without it. I'm not quite sure what real advantage does it give us. > It's likely going to be the end of the week before I can spend much time on > Physics. Ok, don't worry. >I can see the need for a "World" tab, > and "Material" tab, so that we don't overload on too many features all at > once (i.e a young kid could ignore World and Material tabs, and just get on > with building things as they do now). We could also think of a "Tools" tab were we can put all the data acquisition tools such as the trail tool and maybe the save/clear background options, also we could have the background "paper" move in some direction so some sort of plots can be made. (This is just a soup of ideas) > >> I was also thinking on another new feature. What about joint's >> displaying the tension they're in by changing their color? > > Ooh, yes I like that one, colour would be good, black --> red? Have you had > a look at the old Bridge Activity? It did this for the "rivet" colour. I may have seen It. I also saw it in another Bridge Building Game. http://www.crypticsea.com/images/bbg1.jpg > >> We could even break the joints if tension is too high.
RSS Feed