Re: [Sugar-devel] [DESIGN] Control Panel Font configuration
On Mon, Feb 1, 2010 at 4:19 PM, C. Scott Ananian csc...@cscott.net wrote: On Mon, Feb 1, 2010 at 3:31 PM, Albert Cahalan acaha...@gmail.com wrote: On Sat, Jan 30, 2010 at 2:50 PM, C. Scott Ananian csc...@cscott.net 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 csc...@cscott.net 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
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
[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
[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
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
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 e...@laptop.org wrote: On Tue, Oct 20, 2009 at 4:08 PM, Albert Cahalan acaha...@gmail.com 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] [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] 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
Re: [Sugar-devel] Deployment feedback braindump
S Page writes: On Sun, Aug 9, 2009 at 10:41 AM, Daniel Drakedsd at laptop.org 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] [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] How to not make a window?
On Wed, Aug 12, 2009 at 10:26 AM, Benjamin M. Schwartzbmsch...@fas.harvard.edu 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] Deployment feedback braindump
On Wed, Aug 12, 2009 at 10:16 AM, Lucian Branesculucian.brane...@gmail.com wrote: 2009/8/12 Bernie Innocenti ber...@codewiz.org: 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] 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
[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] 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] journal concerns (was Re: Planning for Weds - Tux Paint, Conozco Uruguay, Memorize with Speak)
On Tue, Jul 21, 2009 at 4:32 AM, Tomeu Vizosoto...@sugarlabs.org wrote: On Tue, Jul 21, 2009 at 09:07, Albert Cahalanacaha...@gmail.com 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] 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
Tomeu Vizoso writes: On Wed, May 27, 2009 at 20:20, Lucian Branescu lucian.branescu at gmail.com 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] [IAEP] Journal criticism
Tomeu Vizoso writes: On Wed, May 27, 2009 at 04:54, forster at ozonline.com.au 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
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] possible foundation for an email activity
On Sun, May 24, 2009 at 3:14 PM, Carol Farlow Lerche c...@msbit.com 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 tomeu at sugarlabs.org: 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 1:47 AM, Andrés Ambrois andresambr...@gmail.com 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
On Mon, May 4, 2009 at 12:48 PM, Sascha Silbe sascha-ml-ui-sugar-i...@silbe.org 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
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