[Sugar-devel] On Zeroinstall and Sugar packages

[Benjamin M. Schwartz]

I have long argued that the only way to achieve reasonably bundle behavior
in Sugar is to restrict ourselves exclusively to carefully selected
interpreters.  After speaking with the Zeroinstall developers, especially
Thomas Leonard, I have changed my mind.

Zeroinstall's tools and design are extremely closely aligned to Sugar's
goals for package management.  They have anticipated almost every use case
that we have described.  Their solutions are not perfect, but they make
the best available compromise when compromises are necessary.

A month ago I wrote:
"""
I really do believe we _could_ implement a
highly usable system in which Activities are completely self-contained
portable bundles.  For example, see Android.  I don't believe that we
_have_ implemented such a system.  I do believe that we _should_, because
it maximizes the ability of users to predict how their system will behave,
and predictability is the core of usability and security.
"""

My principal reason for wanting Activities to be highly restricted and
purely interpreted was to enable users to push bundles between machines
and have them "just work" without worrying about whether the dependencies
are installed or what CPU architecture is in use.  Zeroinstall can solve
the dependency problem with 0export [1] and 0compile [2].  0export is a
tool to produce a bundle for a given program that contains all needed
dependencies for all target architectures in a single file.  0compile,
combined with Zeroinstall's support for source bundles, enables us (1) to
approach true platform-independence and (2) to provide users the
opportunity to modify the source code of a package and rebuild it in a
natural way.

My epiphany is: the alternative to a system like Zeroinstall is not an
idealized purely interpreted bundle type.  It's the mess we have now,
where bundles contain all sorts of bizarre binary blobs, and make a
variety of fragile assumptions about the rest of the system.  We have no
way to prevent Activity authors from doing this, and this is likely to
remain true.  Even I am guilty of including binary blobs, in Watch Me [3],
because there was no other way to make the Activity work.  This means that
I've distributed binary code without the source.  This is counter to our
educational goals, and counter to our goals of building a reliable,
predictable system.

We need to bring native-code Activities aboveboard, and Zeroinstall is by
far the most promising avenue I've encountered to make that happen.

--Ben

[1] http://0install.net/0export.html
[2] http://0install.net/0compile.html
[3] http://activities.sugarlabs.org/sugar/addon/4205
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] Sugar Digest 2009-10-19

[Walter Bender]

=== Sugar Digest ===

1. I had been meaning to mention that already several weeks ago we
exceeded one-million downloads from activities.sugarlabs.org. We are
now over 1.1 million.

2. Last week, Sayamindu Dasgupta posted a blog
[http://sayamindu.randomink.org/ramblings/2009/10/14/books-sugar-and-olpc/]
about the various tools for downloading and reading books in Sugar. If
you haven't yet seen it, it is worth a look.

3. In response to the discussions about the need for more amd more
accessible lesson plans, Martin Dengler has created a wikify your
Sugar Lesson Plan template [[Lesson_plan_template]].

4. The minutes from last week's Sugar Labs oversight board meeting are
posted in the wiki  [[Oversight_Board/Meeting_Minutes-2009-10-16]].
Our next meeting will be this Friday (23 Oct) on #sugar-meeting at
14:00 UTC.

=== In the community ===

5. Simon Schampijer has posted an initial schedule for the Sugar Camp
at Bolzano. [[Marketing_Team/Events/Sugarcamp_Bolzano_2009#Schedule]]

6. I'll be speaking at Free Software Day at Universidad de San Martín
de Porres (USMP) in Lima next Saturday.

=== Tech Talk ===

7. Rubén Rodríguez Pérez had a correction to the information I posted
last week re the Trisquel packaging of Sugar. Please refer to
[http://devel.trisquel.info/sugar/trisquel-sugar_3.0-LATEST_i686.iso]
for the latest image. Current snapshots are in found at
[http://devel.trisquel.info/sugar/].

8. I have been trying to wrap my head around how to use Cairo in
Sugar. With the help of Tomeu Vizoso, I finally think I understand how
it all works. Check out [[Activity Team/Sample code/Ruler]]. I
modified Mitchell Charity's Ruler to use the new toolbars and enable
one to set the DPI of the display. (Ruler had previously been set to
display correctly on the OLPC XO; as a consequence, the DPI was wrong
on most other displays.) Next, I'll try to refactor Turtle Art to use
Cairo.

===Sugar Labs===

9. Gary Martin has generated a SOM from the past week of discussion on
the IAEP mailing list (Please see
[[File:2009-October-10-16-som.jpg]]).

-walter

-- 
Walter Bender
Sugar Labs
http://www.sugarlabs.org
___
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 onXO icon incomplete

[Art Hunkins]

No, I've been using the copy command (cp).

I hadn't thought of your option. (Thanks for the tip.)

cp does work on XO-1 though.

Art Hunkins

- Original Message - 
From: "Daniel Drake" 
To: "Art Hunkins" 
Cc: ; "James Cameron" 
Sent: Friday, October 16, 2009 7:06 AM
Subject: Re: [Sugar-devel] [Bug 422302] Re: Soas-2-beta: drop-down menu onXO 
icon incomplete


> 2009/10/13 Art Hunkins :
>> I was mistaken about this. Both SoaS (yes, Strawberry) and the XO-1 act
>> identically: downloaded activities register immediately; *copied* 
>> activities
>> (from a USB stick) require a restart to register.
>
> I'm not seeing this on XO-1.
>
> I plug a USB disk in, go to the journal, click the USB icon, then
> drag-and-drop the activity I want to install onto the journal icon in
> the bottom left. The activity is then immediately available from the
> home screen.
>
> Are you using a different process?
>
> Daniel
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel 

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [Karma] updating jsdoc for Karma

[Bryan Berry]

On Mon, 2009-10-19 at 16:45 -0500, Felipe López Toledo wrote:
> I have been figuring how to produce the full jsdoc documentation, but
> I haven't had any luck, 
> I have tried with @memberOf, @lends, @nameOf, and so on...

argh, is there any problem u r having? then I could try as well. U could
push your latest code back to g.sl.o and I could try from there

tks for clearing up the relation b/w KObject and Karma

do you think it would be a lot of work to refactor jquery.karma.js to
only use prototypal inheritance? I might try doing that at the beginning
of next month.

At this time, here is the list of changes I am planning to make on
jquery.karma.js

1) change from classical to prototypal inheritance
2) change k.library.images and k.library.sounds to just k.images and
k.sounds
3) Add KSVG as another type

The more I work w/ j.k.js, the more I realize what a great job u did w/
it. It is really, really useful.

-- 
Bryan W. Berry
Senior Engineer
OLE Nepal, http://www.olenepal.org

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] RFC: Kill the delayed menus for good

[Art Hunkins]

My vote is to eliminate the delayed palettes altogether.

They just get in my way, obscuring other items.

The right-click option is fully satisfactory. As a senior citizen (in motor 
activity, similar to a child), my errant attempts to click inside a palette 
that disappears on me, are highly frustrating.

Art Hunkins

- Original Message - 
From: "Eben Eliason" 
To: "Michael Stone" 
Cc: 
Sent: Wednesday, October 14, 2009 11:39 PM
Subject: Re: [Sugar-devel] RFC: Kill the delayed menus for good


On Wed, Oct 14, 2009 at 11:12 PM, Michael Stone  wrote:
> Eben,
>
> First, thanks for the interesting and detailed history of your vision. I
> very much appreciate your ability to generate thought experiments
> describing other ways that the world could be.
>
> Next...
>
> Eben wrote:
>>
>> Simon Schampijer  wrote:
>>
>> > You can use right click to get the menu immediately. The delay is on
>> > purpose.
>>
>> We should definitely get feedback. I wouldn't be entirely opposed to a
>> change, but I do want to make sure that we make such a change for the
>> right reasons, and that it's actually the right change to make.
>
> So try it, and encourage your friends to do the same! :)

I don't feel inclined to myself, as I've never had a problem with the
delay, and actually used to find the speed with which these palettes
obstructed my view of the screen frustrating before the delay was
increased. I assume there is a group of individuals — developers and
kids alike — who feel the same as I do, and others who feel the same
as you. Those that feel as you do, of course, should definitely try it
and provide feedback, which I'd be happy to hear.

I have no itch.

> (NB: merging it is a good way to accomplish this!)
>
>> The initial design intent was to develop a system which worked in a
>> sufficiently complete manner without needing palettes at all. Kids
>> should be able to start activities, resume activities, join
>> activities, write, paint, stop, etc. without ever seeing a palette at
>> all. [1] This is the "low floor". For kids with more experience or
>> curiosity, we decided to provide contextual palettes which grouped
>> related actions and provided more complex interactions with the
>> system. This is "no ceiling". Furthermore, we wanted to help introduce
>> kids to the availability of additional options in a discoverable way,
>> which is why the hover effect was chosen to provide increasing levels
>> of detail and interaction for a given object.
>
> This is a good story, but a bad implementation. A better implementation
> would be to provide the extra options in a *visible but unobtrusive

I disagree that this is an obviously better implementation. It's
"better" if you're one who frequently has needs for the additional
complexity. It's arguably not if you use only (or mostly) primary
actions.

> form* or, if you absolutely must hide them, to make them visible with a
> device like a "complexity slider" or like the new toolbar's "transient
> hover; lock on click" behavior.

Adding a preference for the delays for these palettes, as we have for
the frame, is a another reasonable possibility, and a literal
incarnation of the "complexity slider" you suggest.

> Remember -- comparisons should be made in a fixed visual field, not
> across multi-second long gulfs of time, cursor positioning, and fine
> motor control.
>
>> Finding that many kids were actually waiting for the palette to appear
>> always, instead of, for instance, simply clicking on an activity icon
>> to join it, encouraged us to INcrease the delay on the palettes to
>> help emphasize this as a secondary mechanism for interaction. A agree
>> that hovering in one place to click in another isn't great; but that's
>> also not the intended primary means of interaction, and should only
>> really be done when one of the secondary actions is desired.
>
> Understandable, but as you say, the result "isn't great". This makes it
> better. Try it! Merge it! (Then come up with something better.)

We had lots of trouble with palettes obscuring other elements of the
UI even with short delays, including, potentially, the desired target.
I can't imagine that this issue has gone away in the intervening
months, and removing the delay entirely seems it would exacerbate the
issue. Do you have any experiences to report in this regard?

>> Removing the delay pushes us, I fear, even farther away from an
>> interface in which nice friendly large clickable icons can be directly
>> manipulated and encourages every action to be done through a
>> contextual menu with a bunch of text in it. Is that really what we
>> want kids to face?
>
> It's better than the present. Again, merge it, then find something
> better.

You keep saying it's better, but fail to provide adequate reasoning or
heuristics for why you feel this to be so. Could you elaborate on the
problems you identified and the way in which this resolves them?

Also, again, it's only arguably better (though I don't fully
compr

Re: [Sugar-devel] [Karma] updating jsdoc for Karma

[Felipe López Toledo]

I have been figuring how to produce the full jsdoc documentation, but I
haven't had any luck, I have tried with @memberOf, @lends, @nameOf, and so
on...

2009/10/14 Bryan Berry 

> On Wed, 2009-10-14 at 18:24 -0500, Felipe López Toledo wrote:
> >
> > I will try to fix it this weekend, I will keep u on track of positive
> > or negative results.
>
> tks a lot dude
>
> quick questions, is KObject a separate class from Karma?
>
yes, Karma is a separated class that initializes i18n, graphics, etc stuff


>
> Are KImage, KSound, KSurface all members of both the Karma class and
> KObject or just KObject?
>
 the unique relation that has Karma with KImage, KSound, KSurface is the
shortcuts functions (for image, sound, surface).
The shortcuts are factory-functions (avoid using new) and, if necessary they
supply some extra configuration, as an example for KSurface.

KImage, KSound, KSurface inherits from KObject.


> KObject mimics uses pseudo-classical inheritance correct? so each
> KImage, KSound instance gets its own copy of KObject?

yes,  KImage, KSound and so on has their own copy of KObject, also they have
their own copy of KMedia.


> One drawback to
> this is that we have to load extra copies of the same KObject properties
> for each instance. If we used prototypal inheritance we would use a lot
> less memory as only the prototype object would take up memory. Would it
> be possible to use prototypal inheritance? possibly using the mixin
> pattern? just curious
>
yes, I think it's possible but the prototypal inheritance doesn't support
multiple inheritance.
Actually we don't use it, but when I was designing the structure I thought
it would be useful.


>
>
>
> --
> Bryan W. Berry
> Senior Engineer
> OLE Nepal, http://www.olenepal.org
>
> regards


-- 
Felipe López Toledo
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [Zero-install-devel] Summary of the chat on #sugar-meeting

[Wade Brainerd]

On Mon, Oct 19, 2009 at 6:59 AM, Tomeu Vizoso  wrote:
> On Sun, Oct 18, 2009 at 21:27, Michael Stone  wrote:
>> Dear z-i folks and sugar folks,
>>
>> Three members of the 0install.net community [1] met with several members
>> of the Sugar community [2] yesterday to exchange knowledge and, in the
>> case of the Sugar folks, to learn more about z-i and whether it might be
>> a good fit for use in Sugar activity installation.
>
> Hey, this is great stuff, thanks all and look forward for the next steps.

Indeed!

BTW, this is further out (years, if ever) but a friend of a friend is
working on a kernel patch that will help simplify packaging for
multiple architectures.

http://icculus.org/fatelf/

Wade
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [Karma] creating a map of Uruguay w/ SVG

[Bryan Berry]

Hey Gabriel,

I figured out how to add the cities as svg entities. I have a very crude
sample working so far w/ one city here:
http://github.com/bryanwb/Conozco-Uruguay/tree/svg-experiment

here is the svg map i did, starting w/ just one capital
http://github.com/bryanwb/Conozco-Uruguay/blob/svg-experiment/assets/generic/images/capitals.svg

the documentation on using svg w/ js is limited but it was all
worthwhile when i discovered I could scale the entire map w/ only one
line of code:

svgDoc.documentElement.currentScale = 0.7;

That scales everything in the svg map

Hopefully I will have more to show u in the next couple of days

-- 
Bryan W. Berry
Senior Engineer
OLE Nepal, http://www.olenepal.org

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [Karma] updating jsdoc for Karma

[Bryan Berry]

hey felipe, any luck w/ jsdocs?

also, is KObject a subclass of Karma?

On Wed, 2009-10-14 at 18:24 -0500, Felipe López Toledo wrote:
> Hi guys
> 
> 
> I realize that, unfortunately, JsDoc did not show all classes and
> methods documentation. Example: JsDoc produced documentation for
> KSound (constructor) but no its methods (play, pause, etc..)
> atm, If you want to read the full documentation you will need to read
> it from the code (js file)
> 
> 
> Bryan, thanks for fixing the Jquery-Anonymous- prefix
> I originally used @memberOf bu it produced unexpected results, instead
> of commenting those lines, I simply added '_'
> 
> 
> I will try to fix it this weekend, I will keep u on track of positive
> or negative results.
> 
> 
> regards
> 
> 2009/10/14 Bryan Berry 
> I changed some of the basic stuff in jsdocs but I still need
> Felipe's
> help when he gets a chance.
> 
> http://karma.sugarlabs.org/docs/
> 
> I got rid of the confusing Jquery-Anonymous- prefix that was
> in front of
> a lot of classes. I will take a look again at it tomorrow.
> 
> Felipe, you used the @memberOf_ tag in a number of places.
> Does that do
> anything different from @memberOf which doesn't have the
> trailing "_" ?
> 
> --
> Bryan W. Berry
> Senior Engineer
> OLE Nepal, http://www.olenepal.org
> 
> 
> 
> 
> -- 
> Felipe López Toledo
> 
-- 
Bryan W. Berry
Senior Engineer
OLE Nepal, http://www.olenepal.org

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Alpha release - Deducto and Color Deducto activity

[Walter Bender]

On Mon, Oct 19, 2009 at 3:24 PM, Dan Krejsa  wrote:
> Hi,
>
> Cool game! It really ought to be called 'Inducto', though.

I said the same thing to Jon Orwant, the author of the original version :)

-walter


-- 
Walter Bender
Sugar Labs
http://www.sugarlabs.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Alpha release - Deducto and Color Deducto activity

[Dan Krejsa]

Hi,

Cool game! It really ought to be called 'Inducto', though.

A few comments:

 -  I found the help and instructions not terribly clear.  I eventually figured
out what to do, but I'm not sure many children would have the patience.
Here's an initial attempt at an improved 'How to Play':

--
How to play:

   Start in the 'Sample' mode (Help -> Sample).

   Deducto displays a board that is a 5 by 5 grid of black and white squares.
   Some of the boards are 'True' and some of the boards are 'False'.
   You can ask Deducto to display a 'True' board by clicking on the 'True board'
   button, or to display a 'False' board by clicking on the 'False
board' button.

   All the 'True' boards have some property or pattern that all the
'False' boards lack.
   Try to figure out what the difference is between the 'True' and the
'False' boards.
   You can ask for as many samples as you like by clicking 'True
board' or 'False board'
   buttons as often as you like.  When you think you know the
difference and can tell
   whether a board is 'True' or 'False' on your own, resume the
testing part of the game
   (Resume -> Resume Game).

   In the testing mode, Deducto displays boards and asks you to identify
   whether the boards are 'True' or not.  If you think the board is
'True', press the 'Yes'
   button.  If you think the board is 'False', press the 'No' button.
Deducto will
   tell you whether your guess was correct or not.. If you get 5 correct answers
   in a row, Deducto will move to a higher level, with a different, usually more
   difficult rule telling whether a board is 'True' or 'False'.  Go
back to the Sample
   mode and try to figure out the new rule!

   If you guess wrong, you can also go back to the Sample mode to look
   at some more examples in the current level.

   ...

--
 - Working in jhbuild on Fedora 11, the 'Resume' tab and 'Sample' tabs
   don't seem to really be tabs; they are menu items. 'Sample' occurs under
   the 'Help' menu.  I would suggest instead of a separate sample tab,
   one added buttons for  'Give me a True sample' and 'Give me a False sample'
   to the main view.

- Moving the mouse over the array of squares, the white squares slightly
  dim and the black squares turn white.  This is misleading since it makes
  the squares seem as if they would respond to the mouse, but they don't.

- It wasn't at all clear to me how the 'Make New Game' feature worked,
  although I didn't spend a long time on it.

- Dan

On Fri, Oct 16, 2009 at 11:47 AM, Manusheel Gupta  wrote:
> Dear all,
>
> I am delighted to announce the alpha release of the Deducto and Color
> Deducto activities.
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [DESIGN] Re: [Bugs] #1508 UNSP: confusing wording on download from Browse

[Tomeu Vizoso]

On Mon, Oct 19, 2009 at 20:18, Wade Brainerd  wrote:
> On Mon, Oct 19, 2009 at 3:04 PM, Tomeu Vizoso  wrote:
>> On Mon, Oct 19, 2009 at 20:01, Wade Brainerd  wrote:
>>> Side note: Since the Journal displays the progress bar as files
>>> are downloaded, wouldn't it be cool if Browse just handed the download
>>> off to the Journal?  That would allow the download to continue even
>>> after Browse stops.  It would also allow the download to be resumed if
>>> the machine is restarted, network connection lost, etc.  Worthy
>>> Journal feature request?
>>
>> This was the desired user experience, but mozilla's architecture made
>> it quite hard without losing the ability to download inside existing
>> http sessions.
>
> I see what you mean about sessions.  Is there some way to detect
> whether a download is dependent on the browser session?
>
> Another option, though it would not allow later resuming, would be to
> let the Browse instance keep running even after the activity has
> "stopped".  It would just hide its main window and send some other
> termination notice to the Sugar shell.  The activity failure notice
> patch might be a good start; Browse could just send a
> NotifyActivityEnded message to the shell without terminating its
> process.

Yes, we could do something like that, though I'm afraid we would risk
trading considerable fragility to fundamental use cases in exchange of
lower gains. Though this largely depends on the effort put, so if
someone is so inclined...

Regards,

Tomeu


-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [DESIGN] Re: [Bugs] #1508 UNSP: confusing wording on download from Browse

[Wade Brainerd]

On Mon, Oct 19, 2009 at 3:04 PM, Tomeu Vizoso  wrote:
> On Mon, Oct 19, 2009 at 20:01, Wade Brainerd  wrote:
>> Side note: Since the Journal displays the progress bar as files
>> are downloaded, wouldn't it be cool if Browse just handed the download
>> off to the Journal?  That would allow the download to continue even
>> after Browse stops.  It would also allow the download to be resumed if
>> the machine is restarted, network connection lost, etc.  Worthy
>> Journal feature request?
>
> This was the desired user experience, but mozilla's architecture made
> it quite hard without losing the ability to download inside existing
> http sessions.

I see what you mean about sessions.  Is there some way to detect
whether a download is dependent on the browser session?

Another option, though it would not allow later resuming, would be to
let the Browse instance keep running even after the activity has
"stopped".  It would just hide its main window and send some other
termination notice to the Sugar shell.  The activity failure notice
patch might be a good start; Browse could just send a
NotifyActivityEnded message to the shell without terminating its
process.

-Wade
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [DESIGN] Re: [Bugs] #1508 UNSP: confusing wording on download from Browse

[Tomeu Vizoso]

On Mon, Oct 19, 2009 at 20:01, Wade Brainerd  wrote:
> On Mon, Oct 19, 2009 at 10:12 AM, Eben Eliason  wrote:
>> To stop the activity now now you must cancel your ongoing download.
>> [Cancel download] [Continue download]
>
> This sounds well thought out, but imagining the experience in my head
> makes me wonder a little.
>
> Two user perspectives:
> 1) Do I want to keep downloading or not?  Continuing the activity is
> the implicit choice.
> 2) Do I want to keep using the activity or not?  Continuing the
> download is the implicit choice.
>
> Since I clicked the [Stop] button, 2) feels more natural.  Whether to
> stop the activity should be the primary choice, with the download's
> continuation being implicit, since stopping the activity was the
> initiating action.
>
> In other words making a decision, then being asked an orthogonal
> question (with an implicit effect on the decision I made), seems off.
>
> Side note: Since the Journal displays the progress bar as files
> are downloaded, wouldn't it be cool if Browse just handed the download
> off to the Journal?  That would allow the download to continue even
> after Browse stops.  It would also allow the download to be resumed if
> the machine is restarted, network connection lost, etc.  Worthy
> Journal feature request?

This was the desired user experience, but mozilla's architecture made
it quite hard without losing the ability to download inside existing
http sessions.

I heard that WebKit has pluggable network backends, so that may make
it possible.

Regards,

Tomeu

-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [DESIGN] Re: [Bugs] #1508 UNSP: confusing wording on download from Browse

[Wade Brainerd]

On Mon, Oct 19, 2009 at 10:12 AM, Eben Eliason  wrote:
> To stop the activity now now you must cancel your ongoing download.
> [Cancel download] [Continue download]

This sounds well thought out, but imagining the experience in my head
makes me wonder a little.

Two user perspectives:
1) Do I want to keep downloading or not?  Continuing the activity is
the implicit choice.
2) Do I want to keep using the activity or not?  Continuing the
download is the implicit choice.

Since I clicked the [Stop] button, 2) feels more natural.  Whether to
stop the activity should be the primary choice, with the download's
continuation being implicit, since stopping the activity was the
initiating action.

In other words making a decision, then being asked an orthogonal
question (with an implicit effect on the decision I made), seems off.

Side note: Since the Journal displays the progress bar as files
are downloaded, wouldn't it be cool if Browse just handed the download
off to the Journal?  That would allow the download to continue even
after Browse stops.  It would also allow the download to be resumed if
the machine is restarted, network connection lost, etc.  Worthy
Journal feature request?

-Wade
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [DESIGN] Re: [Bugs] #1508 UNSP: confusing wording on download from Browse

[Eben Eliason]

Since the desire to stop the activity has already been conveyed by
clicking the Stop button, the real choice to be made is whether or not
the download should be cancelled. How about changing the wording to
convey this choice directly:

To stop the activity now now you must cancel your ongoing download.
[Cancel download] [Continue download]

Clicking [Cancel download] will cancel the download and stop the
activity (as was already requested by clicking Stop). I chose to keep
the word "cancel" in the "Cancel download" button because the term
"stop" is used in the UI as an action which can be resumed, which is
untrue of the download.

Clicking on [Continue download] will cause the alert to disappear, and
implicitly cancel the previously requested "stop" action on the
activity.


On Mon, Oct 19, 2009 at 9:54 AM, Walter Bender  wrote:
> In this particular case, we may want to say:
>
> Continue with download
>
> Stop download and stop browsing

This isn't bad either, though perhaps we could say the same in fewer
words: [Continue download] [Cancel and stop]

Eben


> -walter
>
> On Mon, Oct 19, 2009 at 9:09 AM, Wade Brainerd  wrote:
>> Yeah, Stop and Don't Stop sound best to me.  Cancel is almost never an
>> appropriate button; we should grep the codebase for it :)
>>
>> On Mon, Oct 19, 2009 at 8:35 AM, Tomeu Vizoso  wrote:
>>> On Mon, Oct 19, 2009 at 13:32, Gabriel Eirea  wrote:
 How about "Quit" and "Don't quit"?
>>>
>>> That would be better, though activities are stopped, rather than quitted.
>>>
>>> Thanks,
>>>
>>> Tomeu
>>>
 2009/10/19 Tomeu Vizoso :
> Any ideas for a better wording?
>
> Thanks,
>
> Tomeu
>
> On Sat, Oct 17, 2009 at 00:40, Sugar Labs Bugs
>  wrote:
>> #1508: confusing wording on download from Browse
>> --+-
>>    Reporter:  walter                     |          Owner:  erikos
>>        Type:  enhancement                |         Status:  new
>>    Priority:  Unspecified by Maintainer  |      Milestone:  Unspecified 
>> by Release Team
>>   Component:  Browse                     |        Version:  Git as of 
>> bugdate
>>    Severity:  Trivial                    |       Keywords:
>> Distribution:  Unspecified                |   Status_field:  Unconfirmed
>> --+-
>>  If you try to quit Browse in the middle of a download, you are told that
>>  quiting will "cancel" the download and you are presented with two 
>> buttons:
>>  cancel and stop. Hitting the stop button will cancel the download and
>>  hitting the cancel button will cancel the quitting, hence not cancel the
>>  download. I wonder if there are better words we can use to make this a 
>> bit
>>  less confusing.
>>
>> --
>> Ticket URL: 
>> Sugar Labs 
>> Sugar Labs bug tracking system
>> ___
>> Bugs mailing list
>> b...@lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/bugs
>>
>
>
>
> --
> «Sugar Labs is anyone who participates in improving and using Sugar.
> What Sugar Labs does is determined by the participants.» - David
> Farning
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>

>>>
>>>
>>>
>>> --
>>> «Sugar Labs is anyone who participates in improving and using Sugar.
>>> What Sugar Labs does is determined by the participants.» - David
>>> Farning
>>> ___
>>> Sugar-devel mailing list
>>> Sugar-devel@lists.sugarlabs.org
>>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>>
>> ___
>> Sugar-devel mailing list
>> Sugar-devel@lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>
>
>
>
> --
> Walter Bender
> Sugar Labs
> http://www.sugarlabs.org
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [DESIGN] Re: [Bugs] #1508 UNSP: confusing wording on download from Browse

[Walter Bender]

In this particular case, we may want to say:

Continue with download

Stop download and stop browsing

-walter

On Mon, Oct 19, 2009 at 9:09 AM, Wade Brainerd  wrote:
> Yeah, Stop and Don't Stop sound best to me.  Cancel is almost never an
> appropriate button; we should grep the codebase for it :)
>
> On Mon, Oct 19, 2009 at 8:35 AM, Tomeu Vizoso  wrote:
>> On Mon, Oct 19, 2009 at 13:32, Gabriel Eirea  wrote:
>>> How about "Quit" and "Don't quit"?
>>
>> That would be better, though activities are stopped, rather than quitted.
>>
>> Thanks,
>>
>> Tomeu
>>
>>> 2009/10/19 Tomeu Vizoso :
 Any ideas for a better wording?

 Thanks,

 Tomeu

 On Sat, Oct 17, 2009 at 00:40, Sugar Labs Bugs
  wrote:
> #1508: confusing wording on download from Browse
> --+-
>    Reporter:  walter                     |          Owner:  erikos
>        Type:  enhancement                |         Status:  new
>    Priority:  Unspecified by Maintainer  |      Milestone:  Unspecified 
> by Release Team
>   Component:  Browse                     |        Version:  Git as of 
> bugdate
>    Severity:  Trivial                    |       Keywords:
> Distribution:  Unspecified                |   Status_field:  Unconfirmed
> --+-
>  If you try to quit Browse in the middle of a download, you are told that
>  quiting will "cancel" the download and you are presented with two 
> buttons:
>  cancel and stop. Hitting the stop button will cancel the download and
>  hitting the cancel button will cancel the quitting, hence not cancel the
>  download. I wonder if there are better words we can use to make this a 
> bit
>  less confusing.
>
> --
> Ticket URL: 
> Sugar Labs 
> Sugar Labs bug tracking system
> ___
> Bugs mailing list
> b...@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/bugs
>



 --
 «Sugar Labs is anyone who participates in improving and using Sugar.
 What Sugar Labs does is determined by the participants.» - David
 Farning
 ___
 Sugar-devel mailing list
 Sugar-devel@lists.sugarlabs.org
 http://lists.sugarlabs.org/listinfo/sugar-devel

>>>
>>
>>
>>
>> --
>> «Sugar Labs is anyone who participates in improving and using Sugar.
>> What Sugar Labs does is determined by the participants.» - David
>> Farning
>> ___
>> Sugar-devel mailing list
>> Sugar-devel@lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>



-- 
Walter Bender
Sugar Labs
http://www.sugarlabs.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [DESIGN] Re: [Bugs] #1508 UNSP: confusing wording on download from Browse

[Wade Brainerd]

Yeah, Stop and Don't Stop sound best to me.  Cancel is almost never an
appropriate button; we should grep the codebase for it :)

On Mon, Oct 19, 2009 at 8:35 AM, Tomeu Vizoso  wrote:
> On Mon, Oct 19, 2009 at 13:32, Gabriel Eirea  wrote:
>> How about "Quit" and "Don't quit"?
>
> That would be better, though activities are stopped, rather than quitted.
>
> Thanks,
>
> Tomeu
>
>> 2009/10/19 Tomeu Vizoso :
>>> Any ideas for a better wording?
>>>
>>> Thanks,
>>>
>>> Tomeu
>>>
>>> On Sat, Oct 17, 2009 at 00:40, Sugar Labs Bugs
>>>  wrote:
 #1508: confusing wording on download from Browse
 --+-
    Reporter:  walter                     |          Owner:  erikos
        Type:  enhancement                |         Status:  new
    Priority:  Unspecified by Maintainer  |      Milestone:  Unspecified by 
 Release Team
   Component:  Browse                     |        Version:  Git as of 
 bugdate
    Severity:  Trivial                    |       Keywords:
 Distribution:  Unspecified                |   Status_field:  Unconfirmed
 --+-
  If you try to quit Browse in the middle of a download, you are told that
  quiting will "cancel" the download and you are presented with two buttons:
  cancel and stop. Hitting the stop button will cancel the download and
  hitting the cancel button will cancel the quitting, hence not cancel the
  download. I wonder if there are better words we can use to make this a bit
  less confusing.

 --
 Ticket URL: 
 Sugar Labs 
 Sugar Labs bug tracking system
 ___
 Bugs mailing list
 b...@lists.sugarlabs.org
 http://lists.sugarlabs.org/listinfo/bugs

>>>
>>>
>>>
>>> --
>>> «Sugar Labs is anyone who participates in improving and using Sugar.
>>> What Sugar Labs does is determined by the participants.» - David
>>> Farning
>>> ___
>>> Sugar-devel mailing list
>>> Sugar-devel@lists.sugarlabs.org
>>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>>
>>
>
>
>
> --
> «Sugar Labs is anyone who participates in improving and using Sugar.
> What Sugar Labs does is determined by the participants.» - David
> Farning
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [DESIGN] Re: [Bugs] #1508 UNSP: confusing wording on download from Browse

[Tomeu Vizoso]

On Mon, Oct 19, 2009 at 13:32, Gabriel Eirea  wrote:
> How about "Quit" and "Don't quit"?

That would be better, though activities are stopped, rather than quitted.

Thanks,

Tomeu

> 2009/10/19 Tomeu Vizoso :
>> Any ideas for a better wording?
>>
>> Thanks,
>>
>> Tomeu
>>
>> On Sat, Oct 17, 2009 at 00:40, Sugar Labs Bugs
>>  wrote:
>>> #1508: confusing wording on download from Browse
>>> --+-
>>>    Reporter:  walter                     |          Owner:  erikos
>>>        Type:  enhancement                |         Status:  new
>>>    Priority:  Unspecified by Maintainer  |      Milestone:  Unspecified by 
>>> Release Team
>>>   Component:  Browse                     |        Version:  Git as of 
>>> bugdate
>>>    Severity:  Trivial                    |       Keywords:
>>> Distribution:  Unspecified                |   Status_field:  Unconfirmed
>>> --+-
>>>  If you try to quit Browse in the middle of a download, you are told that
>>>  quiting will "cancel" the download and you are presented with two buttons:
>>>  cancel and stop. Hitting the stop button will cancel the download and
>>>  hitting the cancel button will cancel the quitting, hence not cancel the
>>>  download. I wonder if there are better words we can use to make this a bit
>>>  less confusing.
>>>
>>> --
>>> Ticket URL: 
>>> Sugar Labs 
>>> Sugar Labs bug tracking system
>>> ___
>>> Bugs mailing list
>>> b...@lists.sugarlabs.org
>>> http://lists.sugarlabs.org/listinfo/bugs
>>>
>>
>>
>>
>> --
>> «Sugar Labs is anyone who participates in improving and using Sugar.
>> What Sugar Labs does is determined by the participants.» - David
>> Farning
>> ___
>> Sugar-devel mailing list
>> Sugar-devel@lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>
>



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [DESIGN] Re: [Bugs] #1508 UNSP: confusing wording on download from Browse

[Tomeu Vizoso]

Any ideas for a better wording?

Thanks,

Tomeu

On Sat, Oct 17, 2009 at 00:40, Sugar Labs Bugs
 wrote:
> #1508: confusing wording on download from Browse
> --+-
>    Reporter:  walter                     |          Owner:  erikos
>        Type:  enhancement                |         Status:  new
>    Priority:  Unspecified by Maintainer  |      Milestone:  Unspecified by 
> Release Team
>   Component:  Browse                     |        Version:  Git as of bugdate
>    Severity:  Trivial                    |       Keywords:
> Distribution:  Unspecified                |   Status_field:  Unconfirmed
> --+-
>  If you try to quit Browse in the middle of a download, you are told that
>  quiting will "cancel" the download and you are presented with two buttons:
>  cancel and stop. Hitting the stop button will cancel the download and
>  hitting the cancel button will cancel the quitting, hence not cancel the
>  download. I wonder if there are better words we can use to make this a bit
>  less confusing.
>
> --
> Ticket URL: 
> Sugar Labs 
> Sugar Labs bug tracking system
> ___
> Bugs mailing list
> b...@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/bugs
>



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [Zero-install-devel] Summary of the chat on #sugar-meeting

[Tomeu Vizoso]

On Sun, Oct 18, 2009 at 21:27, Michael Stone  wrote:
> Dear z-i folks and sugar folks,
>
> Three members of the 0install.net community [1] met with several members
> of the Sugar community [2] yesterday to exchange knowledge and, in the
> case of the Sugar folks, to learn more about z-i and whether it might be
> a good fit for use in Sugar activity installation.

Hey, this is great stuff, thanks all and look forward for the next steps.

Regards,

Tomeu

> After the meeting, Thomas wrote up a great set of notes (mostly
> describing his answers to Ben's questions) here:
>
>   http://comments.gmane.org/gmane.comp.file-systems.zero-install.devel/2776
>
> Please peruse this QnA if you'd like to know what was discussed and
> please follow up with someone who seems approachable if you develop new
> questions as a result of reading.
>
> Next, it seems that several of the z-i participants decided after our
> meeting to try out Sugar (on a variety of platforms) and to share their
> experiences in replies to the z-i-d thread I mentioned above.
>
> Therefore, for your convenience, I have collected a few of their notable
> remarks in the sequel of this email. Please read through them and
> respond if you feel so moved.
>
> Kind regards,
>
> Michael
>
> P.S. - Eben and Sebastian: you are both personally CC'ed since I saw
> several experience reports that looked like they would be of specific
> interest to each of you.
>
> P.P.S. - Ben and Rubén: you are CC'ed because you both mentioned to me
> after the meeting that you found it useful for solidifying your
> perspective on the relevance of technology like z-i to Sugar. Could you
> each please reply with a summary of what you learned?
>
> [1]: The z-i folks: Anders [afb], Rene [rsl], and Thomas [talex]
> [2]: The sugar folks: Bernie [bernie], Sebastian [sdziallas],
>      Ben [bemasc], Aleksey [alsroot], Rubén [quidam] and myself
>
> Now for the experience reports:
>
> Anders F Björklund wrote:
>> I tried to use the Ubuntu 9.04 version of Sugar, but it seems like
>> it has some problems (wouldn't even start) and trying to use the PPA
>> version seems to have messed up the whole system (so had to revert)
>
>> Eventually I went with Fedora "Sugar on a Stick" (strawberry flavor),
>> but we couldn't really make sense of it in the default boot setting
>> with the black-and-white icons and all the small help text in english.
>
>> Will try to look for some better testing instructions, but so far
>> it has stumped both adult and child trying to run it on the Netbook.
>> (Couldn't even figure out how to turn it off, so had to hard-power.)
>
> --
>
> Thomas Leonard wrote:
>> Typing "halt" in the "Terminal" activity worked for me :-/
>
> --
>
> Rene Lopez wrote:
>> The version that worked right for me was 0.86 (Debian unstable) and it's
>> configured to work inside xephyr. I also didn't understood how it works
>> but so far this is what I have found:
>> * The X symbol represents you and your computer to shut it down right
>> click it and a menu should appear.
>
>> * The symbols that are around the X are the favorite Activities, left
>> click will open them.
>
>> * The small symbol under the X is the last used open activity.
>
>> * To switch applications you move the pointer to a corner and a frame
>> should appear.
>
>> * And finally if your computer only has a one button mouse you can leave
>> the button pressed to get the same behavior as the right click.
>
> --
>
> Anders F Björklund wrote:
>> So I guess my experience with Sugar was similar to their experience
>> with Zero Install and trying to run the old Subversion feed etc...
>> But it seems less than smooth (chunky?) with Ubuntu 9.04 or Fedora 11.
>
> --
>
> Rene Lopez wrote:
>> I think that the problem is that their target users have a teacher to
>> explain how to use it and the teacher has a printed manual so it's not
>> hard to them but for an outsider it will be very different to anything
>> that you have used and it doesn't self document making it somewhat
>> frustrating.
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] friendview.py

[Tomeu Vizoso]

On Sat, Oct 17, 2009 at 14:45, Eben Eliason  wrote:
> On Sat, Oct 17, 2009 at 9:40 AM, Wade Brainerd  wrote:
>> Yeah, P2P activity sharing would be awesome.
>>
>> http://wiki.sugarlabs.org/go/Development_Team/Almanac/Activity_Bundles
>> says "Activities are meant to be shared between children. If a child
>> doesn't have the activity, it is automatically transfered to the child
>> when he or she joins the shared activity." but I don't believe this
>> was ever implemented...?
>
> Right.
>
> To me, it sounds like the first step in building either of these
> systems (automatic p2p transfer, download from browse) is figuring out
> a way to publish the activity icon so that we DON'T have to show a
> question mark. I would much rather show the icon for the activity that
> the child doesn't have, and perhaps badge it in some way to indicate
> that they don't yet have it.
>
> This seems desirable regardless of which solution we choose to
> download the activity.

Tim, would you like at doing that with telepathy, or would you prefer
to first display a "missing" icon?

Thanks,

Tomeu

>
>
>> -Wade
>>
>> On Sat, Oct 17, 2009 at 9:35 AM, Benjamin M. Schwartz
>>  wrote:
>>> Tim McNamara wrote:
 Naturally, people will probably want to click on that question mark. Would
 we be able to have a dialogue like "Search for activity %s?" % name, which
 if accepted opens up Browse and searches http://activities.sugarlabs.org to
 download it?
>>>
>>> That would be about ten times better than the current behavior.
>>>
 This would be easiest if you can p2p file share activities...
 I've played around a bit, but it doesn't look especially obvious.
>>>
>>> Yes, that would be, by far, even better.  It shouldn't be incredibly
>>> difficult, since Telepathy provides us with a high-level file transfer
>>> operation, but there's still some code required to (1) request the
>>> transfer, (2) create a bundle if necessary, (3) transfer the bundle, (4)
>>> install the bundle, and then (5) launch it.
>>>
>>>
>>> ___
>>> Sugar-devel mailing list
>>> Sugar-devel@lists.sugarlabs.org
>>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>>
>>>
>> ___
>> Sugar-devel mailing list
>> Sugar-devel@lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [IAEP] Alpha release - Deducto and Color Deducto activity

[Tomeu Vizoso]

On Fri, Oct 16, 2009 at 19:47, Manusheel Gupta  wrote:
> Dear all,
>
> I am delighted to announce the alpha release of the Deducto and Color
> Deducto activities.

Congratulations to all involved!

Do they have localization setup? Seems like they have been downloaded
hundreds of times already, and I bet most are from South America. We
could ask teachers in olpc-sur to give feedback, or wait for versions
in Spanish to appear. What do you think?

Regards,

Tomeu

> Please visit -
>
> 1. Deducto home page - http://seeta.in/j/products-and-services/deducto.html
>
> 2. Color Deducto home page -
> http://seeta.in/j/products-and-services/color-deducto.html
>
> 3. User guide for Deducto -
> http://seeta.in/wiki/index.php?title=Deducto_User%E2%80%99s_Section
>
> 4. User guide for Color Deducto -
> http://seeta.in/wiki/index.php?title=Color_Deducto_User%E2%80%99s_Section
>
> 5. Download pages - the alpha version of these activities along with their
> source code can be downloaded from http://seeta.in/j/downloads.html or from
> activities.sugarlabs.org
> (http://activities.sugarlabs.org/en-US/sugar/addon/4220 and
> http://activities.sugarlabs.org/en-US/sugar/addon/4221).
>
> Many thanks to the developers Ashita Dadlani and Anisha Arora for their
> dedication and consistency during all the stages of the development;
> Satyajeet Singh, Assim Deodia, Swarandeep Singh and Vijit Singh for their
> support in training, development, localization and QA activities. Wish to
> express my gratitude to Walter Bender and Samuel J. Klein for their
> wonderful support and encouragement as always.
>
> We look forward to hearing your feedback and experience with Deducto and
> Color Deducto activities. If you would like to put in a feature request,
> please do so at http://testtrack.seeta.in.
>
> Hope you enjoy working with Deducto and Color Deducto activities. Wishing
> you a very Happy Diwali.
>
>
> Regards,
>
> Manu
>
>
>
> ___
> IAEP -- It's An Education Project (not a laptop project!)
> i...@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/iaep
>



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel