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*. My activity is entirely text-based, is a single fixed screen, and fills that screen. It is also in English, and I think it unlikely to translate to other languages. Please excuse me: I'm not a Suger developer, nor a Linux guru; I'm just struggling with a couple of python scripts.
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 - ruining my considerable effort to achieve maximum readability. OTOH, hardly any child will try this; certainly no author should *expect* a 6-year-old to have to change font size to make their activity "readable." So, this issue matters rather little to me. I write my activities on the XO-1, *for* the XO. I hope there is no change of default font or font size for the XO series. If there *is* a change, my activity won't look right, nor, I suspect, would other activities with substantial text (especially fixed screen - no scrolling). I plan to make sure my screens stay the way I want, by specifying font size (thus hopefully overriding any change in system default). 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. As I see it, as far as text is concerned, the only real tool the author has is font size. And the same font size does not fill up the screen for both XO-1 and a larger SoaS monitor. (And I *want* it to fill both screens.) So I need to (and can) determine which kind of screen I'm dealing with (either XO, non-XO 4:3 or non-XO 16:9) and specify font size per screen type. Again I ask: given that *I* want to control display characteristics, should the above strategy work, and be compatible with the changes in F11 fonts being considered? Or is there a better way (*now*)? I've put in over a year of my life already on this project, and would like to get it out the door sometime soon. (Can you tell I'm frustrated?!) Art Hunkins ----- Original Message ----- From: "Daniel Drake" <d...@laptop.org> To: "Martin Langhoff" <martin.langh...@gmail.com> Cc: "Art Hunkins" <abhun...@uncg.edu>; <sugar-devel@lists.sugarlabs.org>; <fedora-olpc-l...@redhat.com> Sent: Tuesday, August 18, 2009 6:48 AM Subject: Re: [Sugar-devel] F11 for XO1 - Fonts 2009/8/18 Martin Langhoff <martin.langh...@gmail.com>: > IOWs, I pine for this gtk+ v3 patch > > http://bugzilla.gnome.org/show_bug.cgi?id=546711 > > which was introduced with a very insightful discussion thread > > http://mail.gnome.org/archives/gtk-devel-list/2008-August/msg00044.html This was brought up earlier in the discussion. Yes, it's hopefully the light at the end of the tunnel. > see specially > > http://mail.gnome.org/archives/gtk-devel-list/2008-August/msg00068.html > > Hmmm. You guys are papering over this gtk shortcoming -- which is > bound to be confusing. Here's a candle for GTK+v3 Feel free to suggest another option that can be implemented today. I feel that my proposal is technically sound given what we have right now, given its simplicity. Don't mess with DPI, just let deployers select font sizes that look good on their target systems, and give the users 2 nice simple buttons: get bigger, get smaller. It's simple and won't eat much developer time. It will allow things to look ok on XO and other platforms as long as there is someone who can select a good default base font size. It also fits nicely into what would come with GTK+3 since you'd just swap the backend control from "font size" to "scale factor" (or whatever equivalent knob comes out of all those discussions). The idea of deployers being able (and often required) to select a good default will remain, along with a dead-simple UI for changing it. It will be also interesting to see what the css/html world comes up with. I've seen a few discussions recently, they too are challenged by being a platform that's spreading to vastly different displays. Daniel _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
