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] [IAEP] Journal criticism

2009-05-28 Thread Jonas Smedegaard
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160

On Thu, May 28, 2009 at 04:58:17AM -0400, Albert Cahalan wrote:
Tomeu Vizoso writes:
 I think it's very important if we want to keep pushing Sugar that we 
 distinguish between design decisions and bugs and unimplemented 
 features. If we bring down good design ideas not by themselves but 
 because of its implementation status, we risk ending up with nothing 
 that brings new value compared to existing desktops.

You say that like it would be a bad thing. The existing desktops
are at least time-tested. Learning to deal with the common features
of modern desktop systems is very valuable for children.

I flat out disagree that Sugar should be a learning experience towards 
using alternative user interfaces.

In that mindset we should mimic Word, Excel and the Windows desktop, not 
for the quality of their interface designs, but simply because they are 
expremely popular so getting acquainted to them is very valuable for 
children.


Kind regards,

  - Jonas

- -- 
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

  [x] quote me freely  [ ] ask before reusing  [ ] keep private
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEAREDAAYFAkoeXhkACgkQn7DbMsAkQLgOQACghzX9Ts4NNCUR09PevDZi9LDs
/1wAniwQFsPTn6KXe74NOEmuG/NpZjFt
=PWgK
-END PGP SIGNATURE-
___
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 James Zaki
Not sure where my complete email went... something to do with awaiting
approval I think.
But just for clarity to all, I said the arrowed  text.



2009/5/28 Albert Cahalan acaha...@gmail.com

 James Zaki writes:

  Understanding hierarchical file structures use the concepts of containers
  and recursion with no limits (except for total capacity). It is not
  naturally intuitive, like a tree where branches get smaller from the
 trunk
  with fruit/leaves only at the end nodes.
 
  Empirically I've seen many new people approach computers (non-tech
  elder-relatives included), and hierarchical structures are not initially
  utilised. It was a secondary focus that had to be learnt out of
 necessity.

 Perhaps the concept is easier to learn as a child. If you've gone
 many decades without it (non-tech elder relatives) and gotten set
 in your ways, you may be at a disadvantage.

 Let's not leave the next generation at a disadvantage too.

  Perhaps an activity/game could be made that teaches the concepts
  of a hierarchical file structure.

 That won't get enough use. Learning to deal with the general features
 of modern computing is much of the reason why the XO even exists, yet
 the children are denied the opportunity to learn about directories.

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


Re: [Sugar-devel] [IAEP] Journal criticism

2009-05-28 Thread Tomeu Vizoso
On Thu, May 28, 2009 at 12:07, Albert Cahalan acaha...@gmail.com wrote:
 2009/5/28 NoiseEHC noise...@freemail.hu:

 I think it's very important if we want to keep pushing Sugar that we
 distinguish between design decisions and bugs and unimplemented
 features. If we bring down good design ideas not by themselves but
 because of its implementation status, we risk ending up with nothing
 that brings new value compared to existing desktops.


 You say that like it would be a bad thing. The existing desktops
 are at least time-tested. Learning to deal with the common features
 of modern desktop systems is very valuable for children.


 This relies on the assumption that 8 years from now when children grow up we
 will still use directories. I do not dare to predict the future so I will
 leave it to you... :)

 In graphical environments alone, directories are over 25 years old.
 Since 8 is less than a third of that, there is only one safe bet.

 It'd be way more than 25 years, except that we didn't even have
 graphical environments much beyond that. Directories go back
 about 40 years. 8 years is just another 20%.

 This isn't the Microsoft Windows XP Service Pack 2 feature set.
 This is a concept that is pretty fundamental in computing.
 It crosses platforms, it's in our network protocols, and it's even
 required for all the programming languages that implement Sugar.

 The following things unfortunately cannot be done with a flat filesystem
 view:
 1. Revision based view.
 2. Tagging.

 First, I think you didn't mean flat. That's the Journal.
 Second, both flat and tree systems can handle that.

 It is a totally different problem that the current Journal barely implements
 those things but dropping it in favor of time-tested solutions is a
 mistake IMHO. (Note that no filesystem solves those problems I have
 mentioned.)

 No filesystem should! It looks like GNOME 3.0 will get you those
 features on top of a plain old UNIX-style filesystem tree though,
 without making the filesystem incompatible with both software
 and humans.

As I said earlier, I would like to see hierarchical views of
filesystems in Sugar. They are waiting for someone to implement them.

I think we are beating a dead horse here.

http://coreygilmore.com/wp-content/uploads/2007/08/beating_a_dead_horse.jpg

Regards,

Tomeu
___
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 Jonas Smedegaard
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160

On Thu, May 28, 2009 at 12:29:23PM +0200, James Zaki wrote:
Not sure where my complete email went... something to do with awaiting
approval I think.

[actual content snipped]

Please subscribe to the lists that you post to, to bypass our spam 
screening process which causes delays and risk of lost emails.


Kind regards,

Jonas (one of only two list moderators - more volunteers appreciated!)

- -- 
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

  [x] quote me freely  [ ] ask before reusing  [ ] keep private
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEAREDAAYFAkoeb9IACgkQn7DbMsAkQLgzngCbBqCPIoKRoJbqEvSmHwUxdhXH
nCMAoIUoWKZFKa5OQpomsUadbVq+TdrB
=ZGFN
-END PGP SIGNATURE-
___
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 Jonas Smedegaard
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160

On Thu, May 28, 2009 at 06:18:35AM -0400, Albert Cahalan wrote:
On Thu, May 28, 2009 at 5:49 AM, Jonas Smedegaard d...@jones.dk wrote:
 On Thu, May 28, 2009 at 04:58:17AM -0400, Albert Cahalan wrote:
Tomeu Vizoso writes:

 I think it's very important if we want to keep pushing Sugar that 
 we distinguish between design decisions and bugs and unimplemented 
 features. If we bring down good design ideas not by themselves but 
 because of its implementation status, we risk ending up with 
 nothing that brings new value compared to existing desktops.

You say that like it would be a bad thing. The existing desktops are 
at least time-tested. Learning to deal with the common features of 
modern desktop systems is very valuable for children.

 I flat out disagree that Sugar should be a learning experience 
 towards using alternative user interfaces.

 In that mindset we should mimic Word, Excel and the Windows desktop, 
 not for the quality of their interface designs, but simply because 
 they are expremely popular so getting acquainted to them is very 
 valuable for children.

To the extent that there are common features that are highly
unlikely to change across versions or even OSes, definitely.

MacOS System 6, MacOS X, OS/2 Warp, and Windows Vista
have certain basic features in common. It's a safe bet to say that
most of these features will remain in the computers of 2017.

Actually, I am not so sure about that: I suspect user interfaces (as 
well as many other features of our society) do not evolve linear, but 
more and more rapidly transform.

So I am willing to challenge you in that bet. :-D

I suggest, for simplicity sake in our later judgement, that we limit the 
bet to do all popular computer desktop environments still use (and 
directly expose to the edn user) a hierarchical file system in 2017, as 
they did in 2009?

And I propose a symbolic item from looser to winner, with a fun 
punishment twist added: One bottle of bewerage of the winner's choosing, 
delivered personally at the winner's door step.

How does that sound?


Kind regards,

  - Jonas

- -- 
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

  [x] quote me freely  [ ] ask before reusing  [ ] keep private
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEAREDAAYFAkoeczYACgkQn7DbMsAkQLhjdACgg6Q4x+mudFAyWE7tZBMMkC1d
mdQAoISLHzNrsO5kO0WqCzjU977WKGU3
=mR8C
-END PGP SIGNATURE-
___
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 Eben Eliason
On Thu, May 28, 2009 at 5:34 AM, Albert Cahalan acaha...@gmail.com wrote:
 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

I'm pretty sure most of us agree, and that you already know, that this
is precisely not the case. Sugar was not designed so kids could learn
to use computers. It was designed so kids could learn. Learning about
computers is certainly a subset of that goal, but by no means the
primary one as you suggest.

/me notes the name of the list...

 the children are denied the opportunity to learn about directories.

An activity which presents these topics would provide such an
opportunity for those kids inclined to explore it, would it not? It
seems that you are confusing opportunity with obligation.

Incidentally, I would actually like to see some changes come about to
the underlying data structures of the Journal so that it isn't so
completely alienated from the filesystem itself. I think many others
would too, but I don't think that forcing that on kids is particularly
useful. Still, making underlying changes to provide the opportunity
for kids to dig in deeper — via an activity, or via the command line —
is a worthy goal.

Eben


 ___
 IAEP -- It's An Education Project (not a laptop project!)
 i...@lists.sugarlabs.org
 http://lists.sugarlabs.org/listinfo/iaep

___
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 NoiseEHC
There are 3 different ideas when we are talking about Journal vs 
Directories:
1. Whether we are limiting the user to use exactly one filtering 
category for his/her documents (and lets call them Files and the filter 
the Files' Directory) or we allow multiple filters (and call them Tags).
2. Whether we are showing the user a open/save dialog which has a 
Directory tree and File list or we just ask for a name and some tags for 
save and let the user filter open.

3. Whether the document store is a filesystem or a database.

so remembering these points, answers are inlined:

Albert Cahalan wrote:

In graphical environments alone, directories are over 25 years old.
Since 8 is less than a third of that, there is only one safe bet.

It'd be way more than 25 years, except that we didn't even have
graphical environments much beyond that. Directories go back
about 40 years. 8 years is just another 20%.
  


I am sure that 100 years ago when the car was invented, because humanity 
has been used horses for 5000 years and the next 100 years is only 2% of 
that, people predicted that we will still ride horses now



This isn't the Microsoft Windows XP Service Pack 2 feature set.
This is a concept that is pretty fundamental in computing.
It crosses platforms, it's in our network protocols, and it's even
required for all the programming languages that implement Sugar.

  


Having a filesystem does not conflict with that the user will never ever 
see one (3. is a differ idea than 2.).



The following things unfortunately cannot be done with a flat filesystem
view:
1. Revision based view.
2. Tagging.



First, I think you didn't mean flat. That's the Journal.
Second, both flat and tree systems can handle that.
  


I meant flat filesystem so I have written exactly that. I meant a 
filesystem which can be drawn on a 2D surface in a tree (where the files 
are leafs). Contrast it to a multidimensional filesystem where a File 
can have multiple Directories and which stores all the versions. See I 
do not want to argue over semantics so if we will have some system which 
can handle this multidimensional storage then we can call it a 
filesystem if you insist. After all a filesystem is just a database 
which maps names to disc block numbers (and the canceled WinFS was 
marketed as a filesystem after all). What is sure that this future 
filesystem will have a completely different access semantics that for 
example ext2.



It is a totally different problem that the current Journal barely implements
those things but dropping it in favor of time-tested solutions is a
mistake IMHO. (Note that no filesystem solves those problems I have
mentioned.)



No filesystem should! It looks like GNOME 3.0 will get you those
features on top of a plain old UNIX-style filesystem tree though,
without making the filesystem incompatible with both software
and humans.
  


Have you noticed that as the world evolved, filesystems gained 
unimaginable capabilities like resource forks, extended attributes, 
access control lists, transactions?
Is your point that we should drop the Journal just to be compatible with 
those softwares that possibly no child will ever use?


I would vote to make the Journal more usable rather than trying to stop 
the world.


___
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 Sean DALY
I, too, encounter difficulty finding elements in the Journal but
haven't found time yet to contribute to a feature discussion.

just 2 cents about hierarchical representation: it certainly has uses.
The coolest one I ever saw was 8 years ago by a company (trying to
remember the name) that provides intranet search to corporations:
users enter text in a Google-like box; the bottom half of the screen
shows hit-parade results (links) by relevancy, but the top half
dynamically generated a hierarchy by type: text file (subclassed by
format upon drilling down), media file, intranet web page, database
result (interrogation by prebuilt connectors), etc.

Clicking on any hierarchy entry regenerated the hit-parade by that type.

Private tagging was possible, tied to the user's profile but exportable.

Viewing rights were handled too; if unavailable to the profile, the
link would be greyed but the info source within the company shown, so
the user could militate for access (as opposed to not knowing its
existence).

Related: I heard Steve Jobs say in 1998 that folders were great for
small numbers of files, but it didn't scale... so he had resorted to
e-mailing files to himself, with different accounts and keywords in
the subject lines... and sort/filter available in mail software.
Today, OSX uses Spotlight which indexes not just text, but media
file metadata, a subject dear to my heart (the Ogg container is
well-suited to that).

However, since I find Spotlight windows a pain (the commandline
version is often faster), I continue to use the system I've used these
past ten years: e-mailing documents between my accounts adding as many
keywords as I can and searching in different ways (gmail search is not
bad but could actually be quite a lot better). I think the Journal
will be fine if additional search options are very carefully
selected... and as much metadata as possible is pulled out of media
files. I have found exiftool to be wonderful in this respect

Sean



On Thu, May 28, 2009 at 1:19 PM, Jonas Smedegaard d...@jones.dk wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: RIPEMD160

 On Thu, May 28, 2009 at 06:18:35AM -0400, Albert Cahalan wrote:
On Thu, May 28, 2009 at 5:49 AM, Jonas Smedegaard d...@jones.dk wrote:
 On Thu, May 28, 2009 at 04:58:17AM -0400, Albert Cahalan wrote:
Tomeu Vizoso writes:

 I think it's very important if we want to keep pushing Sugar that
 we distinguish between design decisions and bugs and unimplemented
 features. If we bring down good design ideas not by themselves but
 because of its implementation status, we risk ending up with
 nothing that brings new value compared to existing desktops.

You say that like it would be a bad thing. The existing desktops are
at least time-tested. Learning to deal with the common features of
modern desktop systems is very valuable for children.

 I flat out disagree that Sugar should be a learning experience
 towards using alternative user interfaces.

 In that mindset we should mimic Word, Excel and the Windows desktop,
 not for the quality of their interface designs, but simply because
 they are expremely popular so getting acquainted to them is very
 valuable for children.

To the extent that there are common features that are highly
unlikely to change across versions or even OSes, definitely.

MacOS System 6, MacOS X, OS/2 Warp, and Windows Vista
have certain basic features in common. It's a safe bet to say that
most of these features will remain in the computers of 2017.

 Actually, I am not so sure about that: I suspect user interfaces (as
 well as many other features of our society) do not evolve linear, but
 more and more rapidly transform.

 So I am willing to challenge you in that bet. :-D

 I suggest, for simplicity sake in our later judgement, that we limit the
 bet to do all popular computer desktop environments still use (and
 directly expose to the edn user) a hierarchical file system in 2017, as
 they did in 2009?

 And I propose a symbolic item from looser to winner, with a fun
 punishment twist added: One bottle of bewerage of the winner's choosing,
 delivered personally at the winner's door step.

 How does that sound?


 Kind regards,

  - Jonas

 - --
 * Jonas Smedegaard - idealist og Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

  [x] quote me freely  [ ] ask before reusing  [ ] keep private
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.9 (GNU/Linux)

 iEYEAREDAAYFAkoeczYACgkQn7DbMsAkQLhjdACgg6Q4x+mudFAyWE7tZBMMkC1d
 mdQAoISLHzNrsO5kO0WqCzjU977WKGU3
 =mR8C
 -END PGP SIGNATURE-
 ___
 IAEP -- It's An Education Project (not a laptop project!)
 i...@lists.sugarlabs.org
 http://lists.sugarlabs.org/listinfo/iaep

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