Re: [Sugar-devel] [DESIGN] Control Panel Font configuration
On Mon, Feb 1, 2010 at 4:19 PM, C. Scott Ananian wrote: > On Mon, Feb 1, 2010 at 3:31 PM, Albert Cahalan wrote: >> On Sat, Jan 30, 2010 at 2:50 PM, C. Scott Ananian wrote: >> >>> Really, the problems described here can all be solved by careful font >>> selection and configuration. Fontconfig allows 'virtual fonts' which >>> can combine the best parts of a number of font files. >> >> Please explain how this solves the problem of having >> multiple fonts in the GUI that all look the same to a >> single-language user. >> >> (for example, 100 fonts with foreign-sounding names >> that all look **exactly** like DejaVu Sans) > > You should configure fontconfig to only show *one* "Sans" font which > includes the relevant parts of all these other script-specific fonts > for the appropriate unicode ranges. I don't think "Sans" should pretend to be a font. The GUI should have the correct font name. > Fonts which map script-specific > differences which do not have a roman-script equivalent should either > be given names which make this clear (made up example: "Sans (North > Korea)", "Sans (South Korea)") and/or omitted from deployments This is unsatisfying and/or troublesome. Last I looked (which was some time ago) there were about 20 Arabic fonts in the standard OS builds. They all looked **exactly** like DejaVu Sans. What if I do want multi-script text? If I can't pick a distinct font for each script, then I have to change fonts all over the document. (assuming I'm not happy with the default pairing) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Control Panel Font configuration
On Sat, Jan 30, 2010 at 2:50 PM, C. Scott Ananian wrote: > Really, the problems described here can all be solved by careful font > selection and configuration. Fontconfig allows 'virtual fonts' which > can combine the best parts of a number of font files. Please explain how this solves the problem of having multiple fonts in the GUI that all look the same to a single-language user. (for example, 100 fonts with foreign-sounding names that all look **exactly** like DejaVu Sans) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Control Panel Font configuration
Sayamindu Dasgupta writes:
> It may make sense to allow setting of the font as well. While the
> default "Sans" may be good enough for most European scripts, it may
> cause problems for Arabic, Asian, South Asian scripts, etc. "Sans"
> usually resolves to DejaVu Sans, etc, which often carry suboptimal
> glyphs from non Latin scripts
I think it's only fair that you get suboptimal glyphs too. :-)
DejaVu Sans looks bad even for English with plain ASCII. Among other
things, somebody invented a screwy non-standard way to distinguish the
lowercase L ("l") character. That sort of "innovation" just isn't what
you do in a system-wide default font. The rest is messed up too.
BTW, consider a document containing several languages. You'd normally
want all the Latin-based ones to use one font, all the Cyrillic ones to
use one font, and so on. In other words, per-script (not per-language)
selection of the font. If I remember right, there are about 14 scripts
in active use around the world.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Scrollbar width
On Fri, Dec 11, 2009 at 12:19 PM, Eben Eliason wrote: > On Fri, Dec 11, 2009 at 3:02 AM, Albert Cahalan wrote: >> That said, at least for the common case of the scrollbar being at >> the edge of the screen and possibly elsewhere, there is a solution. >> Scrollbars could widen up as the mouse goes over them, overlapping >> into/above the area that is to be scrolled. >> >> It's a nice solution, allowing for scrollbars 100 pixels wide. > > This is an interesting thought, but it seems to me that it's actually > a solution proposed for the wrong circumstance. The scrollbars that > lie at the edge of the screen are the ones that needn't be large, > since grabbing them (assuming they are properly edge-aligned) is easy > regardless of their width. I suspect the "infinite width" concept fails on real-world hardware, particularly with a kid and a filthy touchpad. I expect that the mouse pointer won't reliably remain at the edge of the screen. Think of the mouse pointer as bouncing off of the screen edge. (because it may move a bit in some random direction) > It's those that float within the UI, such as a scrolling left column > (eg. Pippy examples) that are hardest to target, and which need > adequate affordances to make them usable. Increasing the target area > dynamically on hover is definitely a solution worth experimenting > with. > >> Speed is critical of course. Being slow like the Frame would be >> some kind of torture. My best guess for appropriate timing: > > I'm not even sure an animation would be critical to understanding this > model. One possibility might be to only increase the size of the > scroll handle (leaving the "bar" itself thin), when the cursor is > within range of it. It could grow from its center, so that it hovers > above yet centered on the bar it belongs to, perhaps settling on a > width 3x that of the bar. Leaving the bar thin should help performance, so I like that. Animation isn't for understanding. It's for eye tracking. BTW, rounded corners and 3D shading are important for the same reason. Does 3x get to about 100x100 ? That's the size needed. Expressing that in less device-specific units, 10% of screen height or 7.5% of screen width (whichever is greater) would be appropriate for a normal mouse. Give it a bit more for touchpads, and stick to 2-pixel alignment in case that renders faster. An XO with a nice mouse would thus get 90x90. Maybe the new touchpad should get 112x112, and the original touchpad should get 160x160. (yes that's 0.8 inches per edge) A thought occurs to me regarding the grab keys. By default, they could be made sticky (like CapsLock) and cause an on-screen indicator to appear. Probably this would be a large 2-direction or 4-direction arrow (a shaped undecorated window) about 1/2 the height of the screen in the long dimension. Use the touchpad, arrow keys, or game keys to scroll. Hit a grab key or any non-scrolling button to leave this mode. Optionally, but off by default, go into this mode when the user clicks (especially a fast click w/o drag) on the scrollbar slider. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Scrollbar width
It's perfectly reasonable to have a scroll bar that isn't anywhere near the edge of the screen. (scrolling a list, etc.) We must not forget this when discussing things like "infinite target width". That said, at least for the common case of the scrollbar being at the edge of the screen and possibly elsewhere, there is a solution. Scrollbars could widen up as the mouse goes over them, overlapping into/above the area that is to be scrolled. It's a nice solution, allowing for scrollbars 100 pixels wide. Speed is critical of course. Being slow like the Frame would be some kind of torture. My best guess for appropriate timing: a. movement begins in less than 30 ms b. movement is done in less than 200 ms (no exceptions ever) In that time there ought to be 6 to 12 frames drawn. Drop frames as required to meet the required performance. I'm thinking the speed ought to vary, like this: 0 ms, 8 pixels (begin state) 20 ms, 12 pixels 40 ms, 16 pixels 60 ms, 24 pixels 80 ms, 40 pixels 100 ms, 72 pixels 120 ms, 88 pixels 140 ms, 96 pixels 160 ms, 100 pixels (end state) Motion blur would help. (precomputed I suppose) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] ribbon, right-click, button bars (was: RFC: Kill the delayed menus for good)
On Tue, Oct 20, 2009 at 4:19 PM, Eben Eliason wrote: > On Tue, Oct 20, 2009 at 4:08 PM, Albert Cahalan wrote: >> Eben Eliason writes: >>> Another possibility would be to educate children about right click >>> somehow. >> >> On the one hand, I think it's really important to do this. Besides >> the human-compatibility issue and the extra expressive power, I think >> using a second button will help to develop the mind a bit. (you're not >> just grabbing or poking when you click; you're performing an action >> that could be determined by which button you click) >> >> On the other hand, I think both buttons should be the left button >> by default. Kids have trouble hitting the correct button. Button >> mistakes should not be something kids face from the moment go. > > Yup. The hardware design was done before a UI team was organized at > OLPC. One of the first suggestions, though it was already too late, > was to limit the hardware to one button. The hardware needs two buttons so that it can support the kid as he grows older. The only button issue I can see is that there is no space between the buttons; there should be a gap or the buttons should be on opposite sides of the track pad. (not that a track pad is OK with filthy kid fingers) The software should map the buttons together by default. Here's a config proposal: By default, the buttons are mapped together and there are hover menus. There is a config switch that enables distinct buttons and changes hover menus to right-click menus. Here is an alternate default: The right button shows an animation of clicking on the left button or similar, correcting the user. (this is currently the default for Tux Paint; an adult is expected to change to both-are-left for 2-year-old kids) > provide a more traditional right-click functionality both because it > did provide a way to offer more contextual actions in a manner > consistent with other interfaces that already exist, and because we > thought it could actually be perplexing to have two buttons that > always appeared to do the same thing. If that's proving problematic > for children in practice, we could make a change there. I hadn't heard > much on that particular issue, so I don't know how common (or > persistent) it is. It's not that they don't understand. Their fingers land in the wrong spot. They may click right in the middle, hitting both buttons at once. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Should we care about non readers and kids with motor skill issues?
Caroline Meeks writes: > True. But all kids matter. Including the nonreaders, the ones going > to schools that are not taught in their native language, the ones > for whom reading is a struggle, the dyslectics. You don't want to keep them non-readers forever, do you? That's what happens when you don't push them to use text. There are 2-year-old kids using Tux Paint. They don't read AFAIK, yet nearly every Tux Paint icon comes with text. There is even an area at the bottom of the screen where Tux constantly spews text. The less a kid is able to read, the more he desperately needs text. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] ribbon, right-click, button bars (was: RFC: Kill the delayed menus for good)
Eben Eliason writes: > palettes, we aimed to reduce accidental invocation > of them without entirely eliminating discovery by increasing the > delay. ... > I'm more worried about immediately revealing of all secondary > actions, which pull attention from the more efficient manner in > which basic actions can be performed - namely, clicking on the > big icons. > > If we can do this in a manner which doesn't distract from the > primary interaction methods and encourage inefficient paths > through the UI, that would be great. I believe this was first solved by Kid Pix, a few decades ago. One button bar swaps out another button bar. Microsoft's ribbon looks like the same thing, though I've never used it so I can't say for sure. Tux Paint certainly uses this model. In that case, it works fine for kids **way** below sugar's target age. (smart 2-year-old or regular 4-year-old for sure, possibly younger) > Another possibility would be to educate children about right click > somehow. On the one hand, I think it's really important to do this. Besides the human-compatibility issue and the extra expressive power, I think using a second button will help to develop the mind a bit. (you're not just grabbing or poking when you click; you're performing an action that could be determined by which button you click) On the other hand, I think both buttons should be the left button by default. Kids have trouble hitting the correct button. Button mistakes should not be something kids face from the moment go. > Perhaps, as suggested by Wade, we could allude to the availability > of more information immediately on hover, and perhaps even try making > the right button the only means of invoking the secondary actions. > This does work today, but the lack of discoverability is a definite > problem. It's no less discoverable than the left button. Right-click menus need to work two ways though: a. Press and hold down right button, move, release b. Click (press and release) right button, move, click either button ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] two kinds of delay (was: RFC: Kill the delayed menus for good)
Michael Stone writes: > Good suggestion for discoverability, inadequate suggestion for > fast access to the actually rather important information hidden > on the secondary palettes (e.g. disk space availability, battery > status, etc.) That trumps all. There are two kinds of delay. Type 1 is stuff like drop-down menus that remain even if the mouse briefly goes out of bounds. This kind of delay normally doesn't waste a nanosecond of the user's time. Type 2 is stuff like start-up animations, sliding menus, and these delayed menus. Type 2 is in the critical path of user interaction. It's normally a source of frustration, permanently preventing users from becoming efficient. Type 2 delays are almost never acceptable. The only case I can think of is when something is about to cause a sudden screen change that may be disorienting to the user. In that case, a very fast transition effect (perhaps 0.1 second) can help the user follow what is happening. I doubt the XO-1 hardware is capable of providing this; certainly the current software situation is far too slow to even attempt it. Since the delayed menus are a type 2 delay with no excuse, they really need to go. Right now, users are forced to be essentially incompetent. You'll never navigate quickly in sugar no matter how proficient you are. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Bug 422302] Re: Soas-2-beta: drop-down menu on XO icon incomplete
Alt-Ctrl-Backspace is supposed to make X stop, not restart. It's the XO that has a bug. (an ill-considered "feature") If you screw up your laptop such that X dies or hangs at start-up, the current XO behavior will cause you pain. You'll find yourself in a restart loop, unable to repair or debug the problem. Without a developer key, the only way out is a full data-losing reinstall. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Design] ColorButton
Aleksey Lim writes: > Another option is that picker should contain only predefined colors > (and maybe one custom) by default and having click-to-close behaviour. > Then if users want to make(change) custom color, they click "add.." > (or so) button and palette opens right panel and click on predefined > color will just change custom color. Here are two ideas that would be interesting to test with users who lack the expectation that a proper selector is defined by Microsoft and/or Adobe. The first is simply a colorful square that you click on. The trouble is that most methods of mapping the 3-D RGB space onto a 2-D square are really awful. Consider a 3-D space-filling curve in a 64*64*64 color cube. Use that to map 0x4 colors onto a 1-D space. Now consider a 2-D space-filling curve in a 512*512 square. Use that to map the 1-D space onto a 2-D image. The result is that you can cover the RGB space nicely, with similar colors mostly together. This should be precomputed. Also note that the 64*64*64 would ideally have the spacing adjusted for gamma; try 1.0 and 1.8 for gamma. The second is an iterative selector with a notion of "current" color. The selector displays color patches that are visually related to the current color. Each time you click on a patch, it becomes current. This lets the user walk his way through the color space, allowing access to all colors without the need to understand color spaces. The user just picks the closest color of those available until he is happy with the current color. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] F11 for XO1 - Fonts
Art Hunkins writes: > 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. ... > 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. Render off-screen, big enough to get well-defined curves, and then scale the resulting bitmaps as required. You can even create these bitmaps during your build process and include them in your program. You might do 32x64 for each character. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Deployment feedback braindump
On Wed, Aug 12, 2009 at 10:16 AM, Lucian Branescu wrote: > 2009/8/12 Bernie Innocenti : >> El Wed, 12-08-2009 a las 13:28 +0100, Lucian Branescu escribió: >>> JavaScript-in-PDF is mostly a joke and a big security risk. It's not >>> something to be relied upon. >> >> It might be useless, but I don't see why it should be more risky than >> Javascript in web browsers, which everybody happily accepted without >> much thought. Is JS in PDF even allowed to make HTTP connections? > > JavaScript in PDF is more risky because the sandboxing isn't as mature > as the one in web browsers. It should theoretically be at least as > safe, but in practice it isn't. This is mostly a problem with adobe's > implementation, which is an absolute train-wreck, but other > implementers without browser sandboxing experience might repeat some > mistakes. Anybody sane would just grab a mature engine from a browser. The recent supposed JavaScript problems in Acrobat are nothing more than heap spraying; there are at least two non-JavaScript ways to do that. The exploit was recently redone w/o any JavaScript. Note that PDF, being essentially postscript, already comes with a full programming language. That's what postscript **is**. >> How do you dubmit the form? By HTTP? Does the PDF reader tell the user >> when it's going to make this connection? > > You would submit the form by sending back the completed PDF file. It's > a bit awkward, but it works. > > Ideally, people should be using HTML forms, those are made to be > easily and seamlessly submitted. ... > In any case, PDF is a good presentation format. Why make it > significantly more complex for small-to-none improvements to its main > purpose? PDF forms often look attractive. HTML forms normally look ugly. This is because PDF is a good presentation format. HTML is not. Printing a PDF form to fill it out the old-fashioned way is reasonable. You can even fill most of it out, print it, and then sign it or stamp it. With HTML this really isn't practical. In the case of math worksheets, the child really needs a way to scribble on the document. This is for handwriting practice and to allow arbitrary free-form drawing and layout. PDF can provide this, either via printing or via wrapping extra postscript code around the document. To do this in HTML you'd have to write a custom app in JavaScript, Java, or flash -- none of which is really HTML at all. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] How to not make a window?
On Wed, Aug 12, 2009 at 10:26 AM, Benjamin M. Schwartz wrote: > Albert Cahalan wrote: >> Benjamin M. Schwartz writes: >> >>> I am trying to create a sugar activity that wraps a >>> simple X application. >> >> Have you tried using the sugarize code? If it fails, >> let me know how. You really shouldn't need Python to >> wrap a simple X application. > > Good point. I'd forgotten about sugarize, and I'll take another look at > it. However, as noted in the original e-mail. I'm trying to wrap a > simple application in a complicated way, using the presence service and > telepathy, so it's not as easy as a direct launch. Let's consider it a bug that this requires any extra effort. Can somebody fix Sugar? Can I add another hack to sugarize? (ideally Sugar would not need anything abnormal) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] New activity: Arithmetic.
First of all, it's wonderful to finally see this activity. Plenty of words in the UI are not easy, starting with "difficulty". :-) There doesn't seem to be any scratch space to work in, but I'm just looking at the screen shot. Can the user lay out a long division in the standard form? Can the user have some place to write out extra numbers for borrow/carry (optionally tiny) and possibly cross out the original numbers? There are at least two styles for this, with tiny numbers probably the norm when doing multi-digit multiplication. The 3 difficulty levels are kind of vague. Just for addition I can think of... 0..9 plus 0..9 resulting in 0..9 0..9 plus 0..9 resulting in 0..18 0..9 plus 0..9 plus optional-one resulting in 0..19 multi-digit w/o carry multi-digit w/ carry, no change in number of digits arbitrary multi-digit That's w/o even considering decimals, negative numbers, fractions, and worse. Subtraction has an extra level, because borrowing is harder when you need to borrow from a zero. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Deployment feedback braindump
S Page writes: > On Sun, Aug 9, 2009 at 10:41 AM, Daniel Drake wrote: >> adding an interactivity component that would be impossible >> to have when working with paper-based exercise books. > > And impossible with PDFs. No way. PDFs can be interactive in many ways. First of all, a PDF is pretty much just well-behaved postscript. You can embed that in more postscript. The user can thus scribble all over the document. Second, the PDF format has long had form support. It's pretty much like HTML forms, but much more attractive. I've used this several times in xpdf and/or evince, and it works very well. You get the choice of filling out the PDF form directly, or doing things the traditional way on paper. Finally, you can put JavaScript in a PDF. I'm not sure if any of the free software viewers can handle this yet. In theory you can have all sorts of animations. It's kind of like flash. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] How to not make a window?
Benjamin M. Schwartz writes: > I am trying to create a sugar activity that wraps a > simple X application. Have you tried using the sugarize code? If it fails, let me know how. You really shouldn't need Python to wrap a simple X application. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Google's wave protocol
I just noticed this: http://arstechnica.com/open-source/news/2009/07/google-releases-wave-protocol-implementation-source-code.ars It seems to be something for collaboration, including simultaneous editing. Compatibility could be useful. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity as regular objects proposal
Daniel Drake writes: > Finally, I personally don't like the idea of having activities > (as in applications) in the journal. The journal is for > recording what the user has done. I think that **uninstalled** activities belong in the journal. An activity can be in the journal like any random data file, or it can be in the launcher. It can be moved back and forth. This should reduce confusion, clutter, accidental damage, etc. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] journal concerns (was Re: Planning for Weds - Tux Paint, Conozco Uruguay, Memorize with Speak)
On Tue, Jul 21, 2009 at 4:32 AM, Tomeu Vizoso wrote: > On Tue, Jul 21, 2009 at 09:07, Albert Cahalan wrote: >> Last I checked, the Journal interface... >> >> a. required piles of custom D-BUS code (very painful to do) > > This hasn't been a problem for other developers. Yes it has been. A few (?) developers succeeded. Everything else is a Python script. I'm only aware of Etoys in fact. Any others? Really, I don't see why there isn't a *.so file supplied in /usr/lib that could be used via dlopen(). >> c. would make the kid-friendly picture browser impossible > > How so? OK, here is what I need: Tux Paint gets a list of all Tux Paint images. For each one, it opens the thumbnail. It displays **all** thumbnails for the user, as large buttons in a scrollable grid. If a thumbnail does not exist, Tux Paint will open the main file and create a new thumbnail. The user may choose to delete an image. Tux Paint does so. The user may load an image. Tux Paint then must deal with the previously loaded image. It may be saved over an old copy, saved as a new copy, or thrown away. After doing so, the requested image gets loaded. (BTW, that choice is also offered elsewhere in the UI. It's given when the user hits the "New" button to get a fresh start. It's given when Tux Paint exits.) There is also a slideshow feature. The kid selects images from the visual selector, then hits the "Play" button. This isn't going to work at all with selection via the journal. Not that this works now, but on the laptops with both Sugar and GNOME there should be exactly one Tux Paint sandbox. Images shouldn't be held hostage in one environment. >> d. would cause performance-sucking data copies > > Doesn't seem to be a problem for Paint, in which way is TuxPaint more > exigent performance-wise? There is a visual file selector, so numerous images may need to be loaded. Giving this up would have a usability impact. Stopping and restarting Tux Paint in order to load a new file would be painful. Despite optimization effort, Tux Paint will never be fast-starting. (OK, it beats many Python things, but we still get bothered by the start-up delay) The built-in file selector can be somewhat fast; it does not need to load up all the fonts and sounds again. > If you are able to name drawings in the TuxPaint's sandbox, > then you are also able to do so in the journal entries. In the normal sandbox, there is little need for names. One of the nice things about a paint program is that large thumbnails do a pretty good job. We use 232x152 for a normal 1200x900; perhaps we'd like to increase that for the XO. Is there some way for the journal to deliver this? 320x240 could be nice. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Planning for Weds - Tux Paint, Conozco Uruguay, Memorize with Speak
Caroline Meeks writes: > the 3rd graders. They are the ones who > would test out these three activites. > > I want to check in on the current status I think it is: > > 1. Tux Paint - Waiting for it to save to the Journal > before we let the kids use it Last I checked, the Journal interface... a. required piles of custom D-BUS code (very painful to do) b. was being changed c. would make the kid-friendly picture browser impossible d. would cause performance-sucking data copies e. wouldn't provide interoperability anyway I'd better elaborate on that last item. Tux Paint maintains some metadata for each image. It's normally kept in extra files. For example, 20081009200559.png uses 20081009200559.dat containing: chicken 0 0 0 c255 255 255 This stuff is really internal to Tux Paint; it shouldn't be showing up in some keyword/label/tag search. There is also a thumbnail. There are some possibly neat and tidy solutions that I hope to investigate, involving private PNG tags. The typical solution is to wrap files in a *.zip archive, which I guess Etoys will claim. Anyway... Even on desktop Linux, Tux Paint uses a private sandbox. IMHO, it's not a bad thing that Tux Paint allows kids to find back their work. I'm really not sure why a kid is expected to be able to navigate 100 files all named "Tux Paint image" and all having the exact same icon, especially when all sorts of other cruft gets mixed in and the scrolling lags **way** behind. Seriously, how exactly would the Journal be an improvement? ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] More information on font scaling problem
Tomeu Vizoso wrote: > In 0.84 Pango knows the resolution of the screen and scales all > fonts accordingly. This means that by using, say 10, the font > will always look good in all hw. I wish this were so. Consider 3 ways to measure font size: 1. number of pixels 2. physical size on the screen 3. angular size (depends on physical size and viewer distance) For readability, both #1 and #3 have lower limits. That "10" you feed into Pango has nothing to do with either; it's #2. On the screen, almost nobody actually cares about #2. Lots of systems lie about it, including Browse. Normally people sit far away from a large screen. If we assume that people tend to fill their eye's viewing area with the screen, then pixels per character should scale according to the number of pixels across the screen. (diagonal perhaps) Most everything tends to break down when using a projector. You may be at 5 DPI, yet the angular size is smaller than normal. A practical way to size things is to make font and icon pixel dimensions scale with the square root of the screen pixel dimensions. Tux Paint does this for stamps. Like this: d = sqrt(x*x+y*y); // diagonal screen size in pixels d0 = sqrt(x0*x0+y0*y0); // same, for a standard reference screen s = sqrt(d)/sqrt(d0); // scale factor So if the reference is 640x480 and you want to display on a 2560x1920 display, the scale factor is 2. (the idea is that people want to use extra resolution both for more object detail and more objects; this splits the usage) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] I'm looking for a tree...
Benjamin M. Schwartz writes: > I am looking for a fast data structure with the following properties: > > Maintains an indexed list of arbitrary, non-ordered objects > (like a python List or C array) > Allows fast: > Insertion at any location > Deletion at any location > Lookup of an object by its index > Reverse lookup, to determine the index of an object It may have been better to describe what you wanted to do. For example: Might the amount of data ever exceed the size of RAM? What data type is an index? (string, int, arbitrary blob...) What data type is an object? (string, int, arbitrary blob...) How can you say "Insertion at any location" yet "non-ordered"? This doesn't seem to make sense. Did you change your mind? > Python's List has O(1) lookup, but O(N) insert, delete, and > reverse-lookup. Heh. A "high level" language is supposed to not have that kind of problem. Try perl. :-) > To make reverse lookup O(1) I could maintain a separate > Dict mapping objects to indices, but this would cost an > additional O(N) on every insertion and deletion. If it did, you're still O(N) because O(N)+O(N)==O(N). It should not take O(N) for insert/delete, even if you decide you want things ordered. Reverse mapping is easy: store a copy of the index in (with) the object. > A linked list has O(1) insertion and deletion, I wouldn't say that. You have to find the object's location to do that, so you need to include the O(N) lookup cost. > A standard self-balancing tree cannot be used because the objects > are not ordered, and self-balancing trees require ordered keys. > I could use the index of an object as the sort key, but then > insertion and deletion are O(N) because all subsequent keys must > be altered. I could fabricate new sort keys to ensure that > insertions occur at the desired location, but then the length of > the keys will grow like O(N), making all operations at least O(N). Standard self-balancing trees don't have these problems. Neither do hash tables, assuming reasonable table size. Here you go: http://en.wikipedia.org/wiki/Judy_array http://en.wikipedia.org/wiki/Red-black_tree http://en.wikipedia.org/wiki/AVL_tree http://en.wikipedia.org/wiki/Splay_tree http://en.wikipedia.org/wiki/B%2B_tree http://en.wikipedia.org/wiki/Radix_tree http://en.wikipedia.org/wiki/Scapegoat_tree http://en.wikipedia.org/wiki/AA_tree http://en.wikipedia.org/wiki/Heap_(data_structure) http://en.wikipedia.org/wiki/Skip_list http://en.wikipedia.org/wiki/Hash_table If you end up swapping or otherwise going to disk, pick a tree with a large branching factor. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] OT: determining memory usage of short-lived processes
Sascha Silbe writes: > I've examined memory usage of long running processes (i.e. daemons > and applications) in the past, no problems. But for my VCS comparison > I need to determine the peak memory usage of all child processes > (combined), which are rather short-lived. What's the best way to do > that? atop, vmstat, sar, pidstat, sa, accton > Performance is an issue as the benchmark already takes 13h to run > on a sample set of 100 Project Gutenberg files (originally I had > a sample size of ~800 files). That probably rules out valgrind > (AFAIK it incurs quite a performance penalty)... Never rule out valgrind. Find a way. Valgrind supports tools that you can use to discover where you suffer from cache line misses. Valgrind finds any use of uninitialized memory. Also consider using oprofile, or at least gprof. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Journal criticism
On Thu, May 28, 2009 at 5:49 AM, Jonas Smedegaard wrote: > On Thu, May 28, 2009 at 04:58:17AM -0400, Albert Cahalan wrote: >>Tomeu Vizoso writes: >>> I think it's very important if we want to keep pushing Sugar that we >>> distinguish between design decisions and bugs and unimplemented >>> features. If we bring down good design ideas not by themselves but >>> because of its implementation status, we risk ending up with nothing >>> that brings new value compared to existing desktops. >> >>You say that like it would be a bad thing. The existing desktops >>are at least time-tested. Learning to deal with the common features >>of modern desktop systems is very valuable for children. > > I flat out disagree that Sugar should be a learning experience towards > using alternative user interfaces. > > In that mindset we should mimic Word, Excel and the Windows desktop, not > for the quality of their interface designs, but simply because they are > expremely popular so getting acquainted to them is "very valuable for > children". To the extent that there are common features that are highly unlikely to change across versions or even OSes, definitely. MacOS System 6, MacOS X, OS/2 Warp, and Windows Vista have certain basic features in common. It's a safe bet to say that most of these features will remain in the computers of 2017. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Journal criticism
2009/5/28 NoiseEHC : > > I think it's very important if we want to keep pushing Sugar that we > distinguish between design decisions and bugs and unimplemented > features. If we bring down good design ideas not by themselves but > because of its implementation status, we risk ending up with nothing > that brings new value compared to existing desktops. > > > You say that like it would be a bad thing. The existing desktops > are at least time-tested. Learning to deal with the common features > of modern desktop systems is very valuable for children. > > > This relies on the assumption that 8 years from now when children grow up we > will still use directories. I do not dare to predict the future so I will > leave it to you... :) In graphical environments alone, directories are over 25 years old. Since 8 is less than a third of that, there is only one safe bet. It'd be way more than 25 years, except that we didn't even have graphical environments much beyond that. Directories go back about 40 years. 8 years is just another 20%. This isn't the "Microsoft Windows XP Service Pack 2" feature set. This is a concept that is pretty fundamental in computing. It crosses platforms, it's in our network protocols, and it's even required for all the programming languages that implement Sugar. > The following things unfortunately cannot be done with a flat filesystem > view: > 1. Revision based view. > 2. Tagging. First, I think you didn't mean "flat". That's the Journal. Second, both flat and tree systems can handle that. > It is a totally different problem that the current Journal barely implements > those things but dropping it in favor of "time-tested" solutions is a > mistake IMHO. (Note that no filesystem solves those problems I have > mentioned.) No filesystem should! It looks like GNOME 3.0 will get you those features on top of a plain old UNIX-style filesystem tree though, without making the filesystem incompatible with both software and humans. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] journal criticism
James Zaki writes:
> Understanding hierarchical file structures use the concepts of containers
> and recursion with no limits (except for total capacity). It is not
> naturally intuitive, like a tree where branches get smaller from the trunk
> with fruit/leaves only at the end nodes.
>
> Empirically I've seen many new people approach computers (non-tech
> elder-relatives included), and hierarchical structures are not initially
> utilised. It was a secondary focus that had to be learnt out of necessity.
Perhaps the concept is easier to learn as a child. If you've gone
many decades without it ("non-tech elder relatives") and gotten set
in your ways, you may be at a disadvantage.
Let's not leave the next generation at a disadvantage too.
> Perhaps an activity/game could be made that teaches the concepts
> of a hierarchical file structure.
That won't get enough use. Learning to deal with the general features
of modern computing is much of the reason why the XO even exists, yet
the children are denied the opportunity to learn about directories.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Journal criticism
Tomeu Vizoso writes: > On Wed, May 27, 2009 at 04:54, wrote: >> I am happy to expand this to the list. I have raised the journal once >> or twice before but mainly kept quiet not wanting to be trollish. ... >> The journal and sharing are probably the two central things that >> distinguish sugar as as a purpose built learning platform. The team have >> a huge investment of time and energy and are rightly proud of their >> achievement. That presents a problem for constructive discussion around >> the journal, the last thing I want to do is be trollish and destructive. You probably would look trollish and upset a few people, but this can be good for sugar and/or education. If few people ever dare to point out problems, we have useless groupthink. I certainly point out problems, but you can't rely on me alone. It's easy to dismiss one person as a grumpy old troll, but not so easy to dismiss a variety of unrelated people pointing out that something isn't right. The more fundamental/core/central the issue, the more this applies. >> For me, the workings behind the journal are hidden and there is a lack of >> tools to make it do different things when the default operation is not >> what you want. Also temporal and tagging is fine as a primary method of >> storage but hierarchical storage is not offered as an alternate method. Instead of trying to add hierarchical storage to the journal, consider inverting the issue. Modern desktop systems often have special ways to view particular directories. For example, Windows does something special with the directory you use for MP3 files. It also does something special for the font directory. Suppose that one directory got a special view called "journal view". This could be a "My Documents" or "Desktop" directory. Activities throw stuff in there using the journal API. AFAIK, GNOME's Nautilus just needs a plug-in to enable a journal view to work there. The hiding of the file system was well intended, files and directories are probably just a passing phase in computing and they cause some confusion to beginners, but they are the system which underlies the Journal and the way we interface with the www > > I agree that it would be helpful to have hierarchical views of the > file system in Sugar, though I don't think they should be the default Given that they are everywhere, it's an educational issue. This isn't like the particulars of Microsoft Office 2007. This is something pervasive throughout the world of computing. > one because IMO a flat view like gmail with good filtering and search > capabilities is more efficient for users that don't want to spend > their energy in keeping their data in directories. I understand this > opinion is very debatable, but it comes from my observation of how > people around me use their computers and also from the feedback about > Sugar from the field. The most interesting feedback from the field was about the kids teaching each other to wipe the journal with "rm". ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Journal criticism
Tomeu Vizoso writes: > On Wed, May 27, 2009 at 20:20, Lucian Branescu > wrote: >> I'm new to Sugar, so I may be horribly wrong. >> >> But to me, the Journal seems more of an annoyance than anything else. >> A lot of the work I see done is towards bringing back some of the >> properties that regular filesystems have >> >> What advantage does it have as opposed to a regular filesystem with >> support for versioning and metadata? A filesystem would be more >> compatible with existing software (which could just ignore the >> metadata), at least. > > I can very easily understand that for someone who is used to a regular > filesystem, the journal may seem as an annoyance when an attempt to > use it in the same way is done. The same can be said of any other > diversion in Sugar from how Windows/OSX behave. > > Though, interestingly, many people have successfully switched from > files-in-folders-in-folders email clients to GMail. Maybe it is > because the journal is not as mature as gmail? There are big differences in the problem space. GMail is dealing with text. Text search is somewhat reliable. Sugar is dealing with all sorts of random data, like video. GMail can briefly throw **lots** of beefy hardware at the problem, allowing searches to be fast. Sugar can operate a single wimpy processor. Also, lack of folders in GMail is a common complaint. People put up with it because they like other things about GMail. I switched partly because Evolution was eating my inbox. > If I think that something like the journal is worth having, it is: > > - because I can easily observe how non-technical users are unable to > find the files that they stored in folders some time ago, or forget to > save an important document, or modify a file that Firefox saved to > /tmp and it got deleted after a reboot, etc, Now we have equality. The technical users are now also unable to find their files. :-( > I think it's very important if we want to keep pushing Sugar that we > distinguish between design decisions and bugs and unimplemented > features. If we bring down good design ideas not by themselves but > because of its implementation status, we risk ending up with nothing > that brings new value compared to existing desktops. You say that like it would be a bad thing. The existing desktops are at least time-tested. Learning to deal with the common features of modern desktop systems is very valuable for children. > And btw, the Sugar people aren't alone in this, as GNOME will ship > with a very similar journal concept in their 3.0 version. You can > find info in the net and read their own justifications for it. > > Would be awesome if the Sugar Journal and the GNOME one could share > its backend. Could someone check out the current state of the GNOME > one and compare with our needs? It looks like a heavy-duty version of "Recent Documents". It's far from being a Journal clone as far as I can tell, but it certainly deals with the concerns that led to the creation of the Journal. Converting the Journal database is possible I think, allowing for an excellent migration path. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] possible foundation for an email activity
On Sun, May 24, 2009 at 3:14 PM, Carol Farlow Lerche wrote: > Albert -- The page you mention (http://www.jwz.org/doc/threading.html) says > "I'm told this algorithm is also used in the Evolution and Balsa mail > readers. " Right. That's why I used to use Evolution. The threading was wonderful. In many ways, I miss Evolution. After years of watching bug duplicates pile up for the mailbox corruption, I had to face the fact that Evolution just wasn't something I could trust with my email. Go ahead and clone the UI, mostly. Run from the code. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] possible foundation for an email activity
Lucian Branescu writes: > 2009/5/22 Tomeu Vizoso : >> Anjal uses Webkit and the evolution backend and has a cool UI, >> may be interesting to see how to use that code in an activity. Evolution has a long history of eating mailboxes. When a serious bug commonly affects users and goes unfixed for years, one should have quite a bit of doubt about the code. Evolution also happens to mangle mail in ways that hinder full participation in many Open Source mailing lists. Really, this code is not a candidate for reuse. > It looks lovely, even has conversations (the one absolutely > necessary feature of GMail). GMail conversations are a poor substitute for real threading. See jwz's site for the proper algorithm. (Google: jwz threading) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Browse.xo performance & resolution - Hulahop 200dpi vs Browse 134dpi
Martin Langhoff writes: > The short version of it is that canvas (and image rendering in > general) is hurting lots due to the dpi being hardcoded to 134 > which forces Gecko into image scaling games. Just setting > layout.css.dpi to 96 makes Browse much snappier in general, > and incredibly faster in canvas painting. This was discovered when scaling was first enabled. One could write a special-case scaler for that DPI, avoiding the more generic scaling code. The XO also suffers from 5:6:5 pixel layout, which requires lots of bit shifting. > It also makes pages unreadably small though. It's not just the size. The XO screen purposely smears the pixels to reduce color fringing. > Questions: > > - I am intrigued, hulahop sources say it's hardcoded to 200dpi > (and that jives with our screen) - why does it end up being 134? > Should it be 200dpi? 134 puts 860x645 web pixels on the screen. We do this partly because it is enough pixels for most modern web pages, and partly because of a persistant myth that the XO screen resolution is equal to 800x600. In other words, it's an arbitrary number with feeble justification. There are at least two reasonable ways to deal with this problem. The first way is to use the hardware scaling. This involves telling the X server to change screen resolution. Sugar would need to manage this on a per-activity basis, with adjustments to the frame as needed. Besides elimination of scaling, the browser would move fewer pixels and need less memory. It'd be amazing for performance. A downside is that text would be less sharp, both from the scaler operation and more directly from having fewer pixels. The second way is to choose a scaling factor that is easy to optimize, and then do so. Easy would be 128 (3:4 ratio, 900x645 web pixels) or 144 (2:3 ratio, 800x600 web pixels). You could optimize both, along with 192 (1:2 ratio, 600x450 web pixels), and let users get a choice. Unscaled can be an option too. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] The User experience/interface for Printing
On Mon, May 4, 2009 at 12:48 PM, Sascha Silbe wrote: > On Mon, May 04, 2009 at 04:44:33AM -0400, Albert Cahalan wrote: > >> Sending the docs to cups-pdf for conversion and then talking to Moodle >> for teacher review can be done via /usr/bin/lpr, > > But that would sidestep the Journal and prevent review of the actual output > (i.e. what it looks like on paper, not on screen - that can be vastly > different!) before printing. It wouldn't have to. That could be how all activities put print jobs into the Journal. You are essentially using the Journal as client-side print queue, and Moodle as server-side print queue. You might as well use the normal (highly compatible) way to submit to a print queue. FYI, preview isn't going to be perfect anyway. PDF code can ask the printer for exact dimensions; this info is unavailable to the Read activity. It can be used for landscape/portrait rotation, scaling, or whatever. Some enterprising kid may even concoct a PDF that looks nice in Read, but offensive on paper. Getting your teacher to approve printing goatse is priceless. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] The User experience/interface for Printing
On Mon, May 4, 2009 at 1:47 AM, Andrés Ambrois wrote: > On Sunday 03 May 2009 06:29:26 pm Albert Cahalan wrote: >> Vamsi Krishna Davuluri writes: > The priority is on sending the docs to cups-pdf for conversion and then > talking to Moodle for teacher review. It is a good idea to have the code > that sends docs for printing (to Moodle, a local printer, or one discovered > by avahi) in a reusable module that a /usr/bin/lpr script can use. Sending the docs to cups-pdf for conversion and then talking to Moodle for teacher review can be done via /usr/bin/lpr, eliminating the trouble of having multiple data paths. > Adding a print dialog to every activity (e.g. Adding some gtkprint support > in sugar-toolkit) should be optional for GSoC. First we should concentrate > on getting entries printed, and getting teacher review right. Then we can > move code around for legacy support and nice "print me" buttons. If you start with what you disdain as "legacy support", then you can trivially test "getting entries printed" from the command line. The same goes for "getting teacher review right". You could even test with the TuxPaint activity, using real kids. >> > the teacher checks his print page in moodle, views the file (either >> > through fancy javascript or a download) and approves/disapproves >> > for printing. Kennedy then logs into his moodle print page and >> > checks if the job was success or not, and if he has a comment from >> > his teacher. >> >> I can barely imagine that happening in a real classroom. Try this: >> >> The student brings his XO to the teacher's desk, with his work shown >> on the screen. The teacher looks at the work, then lets the student >> plug his XO into a printer which sits on the teacher's desk. >> >> > Printing resources can be very expensive for most schools, so >> > the system should include a way for students to submit jobs to a >> > queue and for an administrator to preview and approve or denie them. >> >> Tux Paint can rate limit a student's printing. For example, a setting >> of 60 will be once per minute. >> >> Do not forget that this issue is more social than technical. In addition >> to any discipline, the teacher can simply turn off the printer. This is >> advisable in any case; many printers use excessive power in standby. > > I dont see a teacher having a printer on her desk. Most schools here in > Uruguay (and I dare say in Perú) don't even have printers. If there is one, > it will be where the server/administration is. And possibly locked in a cage > (like we have the servers now). So that scenario is going to be priority > one. That sounds like a printer that students aren't allowed to use. Such a school might not need printing support at all. Teachers are unlikely to learn a complicated (probably slow too) interface for approving printer use. I just don't see it happening with regular normal everyday human teachers. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] The User experience/interface for Printing
Vamsi Krishna Davuluri writes: > So, talking to Tomeu, we agreed that for Write and Read using > the gtkprint would be best as both support it as a printing API. The focus on "Write and Read" is short sighted and may lead to inflexible solutions. > Now, the current plan is: > 1) We do journal printing only, albeit, the respective > activity opens the file. Eh, OK. Provide a script called /usr/bin/lpr which runs ps2pdf or directly runs gs. This lets normal software, which is already designed to output standard Postscript to lpr, work just fine. After conversion, put the PDF into the journal. Better yet, just toss the file into the journal without conversion. BTW, this can also be implemented as a filter script that the normal lpr program invokes for the default printer. > Now here a cross road is presented: > > 1) Do we use a print dialog inside each activity that can save it as pdf, > print or export a pdf to moodle > > 2) Do we use separate buttons for each of these operations? > > What of the user experience? Separate buttons provides a distinction that will be important in some environments. Some places will want immediate printing. For now, the "print" button can be almost the same as the other, but with the output PDF marked for near-term deletion. "Make PDF" and "Print now" seem like fine names. > The initial plan was to make Read the global printing station, > how do you find this idea? Starting up Read just to print something is not nice. Read may even cause an out-of-memory condition. For sure, there is no need to very slowly render a big document that doesn't even need to be seen on the screen. > the teacher checks his print page in moodle, views the file (either > through fancy javascript or a download) and approves/disapproves > for printing. Kennedy then logs into his moodle print page and > checks if the job was success or not, and if he has a comment from > his teacher. I can barely imagine that happening in a real classroom. Try this: The student brings his XO to the teacher's desk, with his work shown on the screen. The teacher looks at the work, then lets the student plug his XO into a printer which sits on the teacher's desk. > Printing resources can be very expensive for most schools, so > the system should include a way for students to submit jobs to a > queue and for an administrator to preview and approve or denie them. Tux Paint can rate limit a student's printing. For example, a setting of 60 will be once per minute. Do not forget that this issue is more social than technical. In addition to any discipline, the teacher can simply turn off the printer. This is advisable in any case; many printers use excessive power in standby. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Print support, a few issues
Look, I'm running "lpr" and feeding it Postscript. I'm not in a position to use some Python XML RPC nonsense. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] 3D engine uses in a no-nonsense GUI (was: XO Gen 1.5)
Christoph Derndorfer writes: > I honestly can't think of a use-case for including any sort > of 3D acceleration into the basic Sugar and activities. There's > about a million significantly more important things that people > should be working on before even thinking about 3D (IMHO). One can use a 3D accelerator to greatly improve human factors in the GUI. Smooth transitions in the GUI are vital to reducing the user's sense of disorientation and confusion. This isn't just an issue for less-clueful users; you might not realize it but poor transitions are forcing needless mental effort that eats up a tiny bit of time here, a tiny bit of time there... and it all adds up. You may feel it in frustration even if you don't spot the cause. Without the 3D engine, animations are a painful compromise. They are slow, jerky, and CPU consuming. Imagine if the frame could slide into view with fast perfectly smooth motion and almost no CPU use. Think how much more usable Sugar would be. Imagine if view switching and activity switching looked like a rapid zoom out to showing a grid of all views and activities, then a rapid pan to the right grid spot, and finally a rapid zoom in to the newly selected view or activity. Better yet, make it all in one smooth motion so that the user feels as though they are jumping with a ballistic trajectory. The confusion goes away and the transition might even be attractive. You can't make this be acceptably fast or smooth without a 3D engine, even if you cheat by using static screenshot images for the activities. Imagine having every activity smoothly scaled to fit the screen. An activity opens a 320x720 window. It becomes a 400x900 window on the LCD, but the activity doesn't have to deal with that at all. Getting stuff to work well on the XO is suddenly much much easier. Users can spot objects on the screen faster if they have slightly organic shapes. Rather than having **perfectly** sharp corners on things, give them tiny anti-aliased curves. Use bump mapping and other shader features in **subtle** ways to enhance object edges. Make the edges look like they have been polished or sanded a tad, instead of being infinitely sharp and thus ill-defined to the eye. Today, pressing a GUI button normally causes the button face image to shift a bit. That's the best we could do before 3D engines. Imagine if the button face could pop from convex to concave, with perfect realism. The highlights, the density of the shadow, etc. The button metaphor would be more effectively represented to the user. BTW, stay away from the pointless stuff. It's now common to use 3D for random nonsense that hurts usability. Don't do that. Stick to the stuff that helps the eye follow things: smooth motion, softened shapes, realistic shading, quality scaling, etc. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Microsofts future UI inspired by Sugar?
On Thu, Mar 19, 2009 at 9:19 AM, Tomeu Vizoso wrote: > 2009/3/19 Walter Bender : >> Wow. Looks like they cut and pasted the frame directly from Sugar :) > > That means we don't need to dump it any more? :p Visually, of course not. The frame looks OK. Add corner activation, hover menus, really slow show/hide, and a demon-possesed touchpad though... ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Print Support proposal (need input) Beta
2009/3/19 Benjamin M. Schwartz :
> Specifically, there are at least 3 different use cases you may choose to
> support:
>
> 1. USB printer connected directly to the Sugar machine.
This is likely, even in a classroom environment. The printer
may sit next to the teacher, who gives approval to connect.
Students show their work to the teacher, get approval, plug
in the cable, and print. Plugging in the cable might prompt
the user for printing, either to select things or to confirm jobs
that are already queued.
> 2. Networked printer, no server. Sugar prints directly over the network.
This is somewhat likely. It's very simple. You can get a tiny
box that will convert any printer into a network printer.
Networked printers tend to be reliable and cheap when you
don't ignore server costs.
> 3. All printing passes through a server.
> a. networked printer with restricted access
> b. USB printer connected directly the server
> and also
> 1. the server may print every submission immediately
> 2. apply automatic quotas, or
> 3. require manual approval
This is getting complicated. Real IT support will be needed.
The server, including all the extra cabling, is a failure point.
Usability drops; now one must boot the server and muck with
the permissions.
> I think you should focus on #3 and ignore #1 and #2. I say this because
> #3 does not require CUPS, or _any_ printing stuff, in Sugar. You don't
> even need to include the "print to PDF" functionality in Sugar. All you
> need to do is send the file you want to print to the server, over the
> network. The server (running CUPS) can take the file (png for Paint, jpg
> for Record, odt for Write) and convert it to postscript for printing.
Lots of useful software prints roughly like so:
fp=fopen("/tmp/4wiP9r.ps","w");
fwrite(printout,1,nbytes,fp);
fclose(fp);
system("lpr /tmp/4wiP9r.ps");
Sometimes PDF is used instead of PS. Sometimes popen() is used
instead of a tmp file. Sometimes lp is run instead of lpr.
Sometimes bare system calls (open,write,close,pipe,execve) are
used instead of stdio.
For example, Tux Paint normally sends PS into popen("lpr").
CUPS is among the many ways to support this. It's certainly
not the only game in town.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Education on the XO
David Van Assche writes: > Actually there are a whole bunch of examples I uploaded > to schools.sugarlabs.org, the problem we have is of how > to categorise them. ie... do we put them via subject, > via class, via country, via language? I can't see anything there. It keeps demanding an account. I have absolutely no desire for yet another web site account, especially when Moodle will supposedly shove constructivist bullshit down my throat. Why can't I just browse? > If there are any course content creators out there, I'd love > to hear their ideas, and if they need help with creating courses > on the schools.sugarlabs.org site, I believe I can help. Perhaps we can find some way to work together. In about 10 months I taught a kid about 10 years of normal honors math. Along the way I saved all the worksheets that I made for him. He's now beyond that, being well into my old college calculus textbook. At the start he was only doing single-digit addition and subtraction. Nope, it's not constructivist. It actually works. I was careful to mark the worksheets that were not my own work. I think that far less than 10% of the worksheets are thus not free to be used in some other project. The free worksheets could be used as the majority of practice problems for a set of free math books. It's currently on graph paper, 10 lines to the inch. I don't have a scanner for it, though maybe my 3016x2008 camera (should do 200 dpi) would be workable. (really slow though -- I have hundreds of pages) Conversion would involve dealing with plenty of line art. I'm not likely to have much time for any of this, but it sure seems wasteful to let the problems just gather dust. Perhaps success is more about the teaching method and continuous effort though, in which case the worksheets are less useful. BTW, when faced with teachers that are missing or useless, something closer to the Robinson Curriculum would be appropriate. Be sure to note how the subject ordering avoids premature and ineffective study. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
