Applications to adopt: Difference between revisions
| Line 32: | Line 32: | ||
:I agree that it should have separate "modes" which group related functions for a streamlined UI - however, these should not be separate programs. Children should be able to build up to expert level and, while they may need more switching between "modes", still do everything that experts do. |
:I agree that it should have separate "modes" which group related functions for a streamlined UI - however, these should not be separate programs. Children should be able to build up to expert level and, while they may need more switching between "modes", still do everything that experts do. |
||
:That said, the steps it takes to join the ends of two paths (first "join" the paths into "one" disjoint object, then join the ends) are very nonintuitive in Inkscape, and need work for a beginner. Most everything else - even the sum, difference, intersection operators - are pretty intuitive and could be exposed almost as is. Generally, it would be good to move away from two-step processes (select then do) to one-step (a tool that does both in one) when possible, but that's pretty simple. For instance, a lasso which selects and groups in one step. And make results obvious when possible - for instance, when converting from a smooth corner to an abstractly "cornered" one, remove all the smoothing instead of having that be a separate step. Also, the game keys are our friends. |
:That said, the steps it takes to join the ends of two paths (first "join" the paths into "one" disjoint object, then join the ends) are very nonintuitive in Inkscape, and need work for a beginner. Most everything else - even the sum, difference, intersection operators - are pretty intuitive and could be exposed almost as is. Generally, it would be good to move away from two-step processes (select then do) to one-step (a tool that does both in one) when possible, but that's pretty simple. For instance, a lasso which selects and groups in one step. And make results obvious when possible - for instance, when converting from a smooth corner to an abstractly "cornered" one, remove all the smoothing instead of having that be a separate step. Also, the game keys are our friends. [[User:Homunq|Homunq]] 16:35, 28 August 2007 (EDT) |
||
===Encryption Tools=== |
===Encryption Tools=== |
||
Revision as of 20:35, 28 August 2007
This page should be some kind of list of applications that we should adopt or adapt. It really should have two sections and then lists within those sections sorted by application type.
Adopt
Ebook Readers
Evince is the obvious one to start with since it is already part of the project.
How about a Blind Reader
That would be an application in which the cámera can read text in paper, and apply OCR to it to read it aloud for blind children/adults. also reads aloud the Ebooks. MEXICO, AGS, --Dagoflores 16:25, 14 March 2007 (EDT)
Python shell
Provides a simple way for children to experiment with programming. See Programming for Kids.
Formal word processor
AbiWord is being adapted for the OLPC.
OpenDocument Viewer
See OpenDocument Viewer for more information about OpenDocument readers.
Adapt
E-mail clients
Some work is being done to try to develop a prototype email client. Tinymail is a project that aims to create a E-mail client development infrastructure for creating E-mail clients for small devices. At this moment it can show large IMAP and POP folders using less than 5 megabytes of memory. Tinymail is licensed as LGPL. https://svn.cronos.be/svn/tinymail/trunk
Inkscape
This is an SVG drawing program but it is far more feature rich than it needs to be for OLPC. To start with, import and export formats could be removed leaving only SVG and PNG. But more than that, it needs to be simplified for beginners even if that means reducing its functionality.
In fact, by applying the principles of UNIX as a collection of straightforward utilities that do one job well, Inkscape could be broken up into several separate programs. One for sketching, one for adding color, one for texturing, one for animating. In particular, since the device will often be used in monochrome mode, separating coloring from drawing makes a lot of sense.
- I agree that it should have separate "modes" which group related functions for a streamlined UI - however, these should not be separate programs. Children should be able to build up to expert level and, while they may need more switching between "modes", still do everything that experts do.
- That said, the steps it takes to join the ends of two paths (first "join" the paths into "one" disjoint object, then join the ends) are very nonintuitive in Inkscape, and need work for a beginner. Most everything else - even the sum, difference, intersection operators - are pretty intuitive and could be exposed almost as is. Generally, it would be good to move away from two-step processes (select then do) to one-step (a tool that does both in one) when possible, but that's pretty simple. For instance, a lasso which selects and groups in one step. And make results obvious when possible - for instance, when converting from a smooth corner to an abstractly "cornered" one, remove all the smoothing instead of having that be a separate step. Also, the game keys are our friends. Homunq 16:35, 28 August 2007 (EDT)
Encryption Tools
Use also LUKS - Linux Unified Key Setup
- http://luks.endorphin.org/ (main page)
- http://blog.fubar.dk/?p=64 (blog)
- http://people.freedesktop.org/~david/crypto/ (flash demo)