Re: [Sugar-devel] [DESIGN] Control Panel Font configuration

2010-02-02 Thread Albert Cahalan
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

2010-02-01 Thread Albert Cahalan
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

2010-01-30 Thread Albert Cahalan
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

2009-12-11 Thread Albert Cahalan
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)

2009-10-20 Thread Albert Cahalan
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)

2009-10-20 Thread Albert Cahalan
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?

2009-10-20 Thread Albert Cahalan
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)

2009-10-20 Thread Albert Cahalan
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

2009-10-16 Thread Albert Cahalan
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

2009-09-14 Thread Albert Cahalan
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?

2009-08-12 Thread Albert Cahalan
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

2009-08-12 Thread Albert Cahalan
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.

2009-08-12 Thread Albert Cahalan
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?

2009-08-12 Thread Albert Cahalan
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

2009-08-12 Thread Albert Cahalan
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

2009-07-28 Thread Albert Cahalan
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

2009-07-28 Thread Albert Cahalan
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

2009-07-21 Thread Albert Cahalan
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)

2009-07-21 Thread Albert Cahalan
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

2009-06-08 Thread Albert Cahalan
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

2009-05-28 Thread Albert Cahalan
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

2009-05-28 Thread Albert Cahalan
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

2009-05-28 Thread Albert Cahalan
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

2009-05-24 Thread Albert Cahalan
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

2009-05-23 Thread Albert Cahalan
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

2009-05-16 Thread Albert Cahalan
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

2009-05-04 Thread Albert Cahalan
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

2009-05-04 Thread Albert Cahalan
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

2009-05-03 Thread Albert Cahalan
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

2009-04-26 Thread Albert Cahalan
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)

2009-04-21 Thread Albert Cahalan
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