Re: [Sugar-devel] Bug tracker enhancements

2009-07-09 Thread Bryan Berry
On Thu, 2009-07-09 at 07:45 +0200, Simon Schampijer wrote:
 Hi,
 
 Our current trac instance is missing some basic functionality:
 
 - versions per component: a really simple enhancement would be to have a 
 text field (maybe some versions (sugar core) you can select from) but 
 that we do not have to keep the list updated for each activity
 
 - milestones should be on a component basis as well (similar to versions)
 
 - I want to make certain fields only being available with certain 
 permissions (a milestone and priority can only be set by the mainteiner, 
 the severity by the bugsquad (see new fedora policy))
 
 - having a clear separation from the Soas component - if we have the 
 things from above this is maybe not as critical, otherwise I would 
 suggest to get a new instance for Soas
 
 
 Can someone help to get there? Is trac giving us that functionality? 
 Other trac software we should consider (besides bugzilla :)?

redmine,redmine,redmine  much easier to set up, maintain, administer
than trac and has a much more active community developing useful plugins

 Thanks,
 Simon
 ___
 Sugar-devel mailing list
 Sugar-devel@lists.sugarlabs.org
 http://lists.sugarlabs.org/listinfo/sugar-devel
-- 
Bryan W. Berry
Technology Director
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] Paint improvements?

2009-07-09 Thread Aleksey Lim
On Wed, Jul 08, 2009 at 07:41:33PM -0400, Caroline Meeks wrote:
 
  
  
   Nod, I've done that for Memorize and maybe we will for Paint too.  It
  will
   take some thought to get it right and I've got a lot on my plate right
  now.
   Worth it if it turns into code but right now I'm wondering what is the
  best
   path forward? Sugarizing Tux, Improving Paint or adding features to
  Colors?
   It mostly depends on what programmers out there are interested.
 
  If Tuxpaint satisfies all needs and new features list for Paint and
  Colors! is not short, I guess its much easier to add save-to-journal
  feature to Tuxpaint.
 
 
 I just spent some time with Tuxpaint.  I like it much better then paint.
 More features and they are easier to use.  We asked the students to create a
 picture for vocabulary words. I think some of the stamp features and such in
 Tuxpaint would have helped some of the kids without as much native atistic
 talent to still produce recognizable results.  I think the artists are going
 to go wild with some of the magic features.  It really looks like fun.
 
 I don't know how well it will work on a small screen like an XO or netbook.
 Maybe someone else can take a look?

its easy to test in sugar-emulator:
$ sugar-emulator -i 640x480

I run Tuxpaint in 640x480 and it looks nice(Tuxpaint scales pretty well)

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


Re: [Sugar-devel] Sugar on a Stick - and Csound

2009-07-09 Thread Tomeu Vizoso
On Tue, Jun 30, 2009 at 03:48, Aleksey Limalsr...@member.fsf.org wrote:
 On Mon, Jun 29, 2009 at 08:14:26PM -0400, Art Hunkins wrote:
 Does anyone have insight concerning this response from Victor Lazzarini of 
 the csound-devel listserv? (Victor wrote the csndsugui activity for Sugar 
 and is responsible for the Csound 5.08.91 rpm package.)

 My USB drive has nothing on it but Sugar, and we've no idea what module 
 Python is trying to load that might be absent.

 Thanks for any ideas. (Of course, when Csound 5.10 appears as a Sugar 
 update, I'll be installing it to see if this helps.)

 just an option,
 rebuild _csnd module in soas environment and it should fix problem anyway

Have filed https://bugzilla.redhat.com/show_bug.cgi?id=510423 about this.

Regards,

Tomeu

 --
 Aleksey
 ___
 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] Bug tracker enhancements

2009-07-09 Thread Simon Schampijer
On 07/09/2009 08:06 AM, Bryan Berry wrote:
 On Thu, 2009-07-09 at 07:45 +0200, Simon Schampijer wrote:
 Hi,

 Our current trac instance is missing some basic functionality:

 - versions per component: a really simple enhancement would be to have a
 text field (maybe some versions (sugar core) you can select from) but
 that we do not have to keep the list updated for each activity

 - milestones should be on a component basis as well (similar to versions)

 - I want to make certain fields only being available with certain
 permissions (a milestone and priority can only be set by the mainteiner,
 the severity by the bugsquad (see new fedora policy))

 - having a clear separation from the Soas component - if we have the
 things from above this is maybe not as critical, otherwise I would
 suggest to get a new instance for Soas


 Can someone help to get there? Is trac giving us that functionality?
 Other trac software we should consider (besides bugzilla :)?

 redmine,redmine,redmine  much easier to set up, maintain, administer
 than trac and has a much more active community developing useful plugins

Does redmine solve the cases I described above?

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


Re: [Sugar-devel] prep for an article

2009-07-09 Thread Tomeu Vizoso
On Thu, Jul 9, 2009 at 02:57, Eduardo H. Silvahoboprim...@gmail.com wrote:
 2009/7/8 Jeff Elkner j...@elkner.net:
 Ann,

 Luke tells me that:

 1. The chats are stored in the journal, but we don't know if there is an
 easy way to move them to a flash drive (Luke is trying as I type).

 Chat entries in the journal can be opened with Write..

Or any other text editor. You can put them into a usb stick by
dragging the journal entry to the stick icon in the bottom.

Regards,

Tomeu


 2. Alt-1 puts a screen shot in the journal.  We can drag it to a USB stick
 from there.

 Good questions... Thanks!

 jeff

 On Wed, Jul 8, 2009 at 4:42 PM, a k a.akenn...@gmail.com wrote:

 Jeff,
 Two quick questions:
 1) can we capture the text of the chats the students are having? (I'd like
 to do a linguistic analysis--ESPECIALLY if they chat after class--WILL THEY
 DISCUSS Scratch procedures?
 2) can we capture a photo (a still) of a Scratch screen? (to illustrate)
 hasta manana,
 aa


 ___
 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-devel] Nobody understands Keep

2009-07-09 Thread Daniel Drake
Hi,

Nobody in the world seems to understand the Keep button. People think
it's for regular saving and you should do it before you close or switch
away from your activity.

Even with all the expertise on-site they seem to have been advising the
(incorrect) use of the Keep button here:
http://lists.sugarlabs.org/archive/iaep/2009-July/007038.html
and then they wondered why they had 2 copies in the Journal.

I have seen misuse of this button by the country teams in Ethiopia and
Paraguay, in both cases they were giving teacher training and teaching
the teachers the wrong thing...

Perhaps it's time for a rethink/redesign.

This functionality could be moved to the journal itself, in a place
where it can be presented with more context, something like Create
duplicate copy. Or even some kind of visual feedback (to appear after
clicking Keep) that makes it pretty obvious that you've just forked your
work - that way you'd quickly learn the true functionality and know when
and when not to use it.

Daniel


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


Re: [Sugar-devel] Nobody understands Keep

2009-07-09 Thread Joshua N Pritikin
On Thu, Jul 09, 2009 at 09:52:23AM +0100, Daniel Drake wrote:
 Perhaps it's time for a rethink/redesign.

 This functionality could be moved to the journal itself, in a place
 where it can be presented with more context, something like Create
 duplicate copy. Or even some kind of visual feedback (to appear after
 clicking Keep) that makes it pretty obvious that you've just forked your
 work - that way you'd quickly learn the true functionality and know when
 and when not to use it.

Yes, 100% agree.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Nobody understands Keep

2009-07-09 Thread Martin Dengler
On Thu, Jul 09, 2009 at 09:52:23AM +0100, Daniel Drake wrote:
 Nobody in the world seems to understand the Keep button. People think
 it's for regular saving and you should do it before you close or switch
 away from your activity.

That's not far from the truth, right?  At least in any work-losing or
surprising way...

In case anyone lacks context, here's what the HIG says about keep:
it's saving a copy/backup file:

activities can ... specify keep-hints which prompt the system to
keep a copy. ... a child may choose to invoke a keep-hint by
selecting the keep in journal button ...
 -- 
http://wiki.sugarlabs.org/go/Design_Team/Human_Interface_Guidelines#The_Notion_of_.22Keeping.22

Are there any other discussions like activity versioning and datastore
versioning that are relevant that people could share for context?

 some kind of visual feedback (to appear after clicking Keep) that
 makes it pretty obvious that you've just forked your work - that way
 you'd quickly learn the true functionality and know when and when
 not to use it.

Good idea.

 Daniel

Martin


pgpWE2MkPSaZP.pgp
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Nobody understands Keep

2009-07-09 Thread Daniel Drake
On Thu, 2009-07-09 at 10:45 +0100, Martin Dengler wrote:
 On Thu, Jul 09, 2009 at 09:52:23AM +0100, Daniel Drake wrote:
  Nobody in the world seems to understand the Keep button. People think
  it's for regular saving and you should do it before you close or switch
  away from your activity.
 
 That's not far from the truth, right?  At least in any work-losing or
 surprising way...

It's far from the truth in that it's not normally what you want to do.
To save your work, simply click the Stop button or change so that
another activity has focus. If you click Keep, you'll end up with 2
copies - one from when you clicked Keep, and one from when you clicked
Stop (or focused on another activity).

As far as I understand it, Keep is useful for these types of scenarios:
- you've done a lot of work but now it's time to refactor/reorganize the
whole thing. However you want to keep a copy of the rough version you
have now, as insurance or perhaps for reference while you re-mangle
the work.
- you've made a template for something, now you want to save that
template (as a blank template) before starting on a version where you
fill in the content.

Daniel


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


Re: [Sugar-devel] Nobody understands Keep

2009-07-09 Thread Martin Dengler
On Thu, Jul 09, 2009 at 11:22:16AM +0100, Daniel Drake wrote:
 On Thu, 2009-07-09 at 10:45 +0100, Martin Dengler wrote:
  On Thu, Jul 09, 2009 at 09:52:23AM +0100, Daniel Drake wrote:
   Nobody in the world seems to understand the Keep button. People think
   it's for regular saving and you should do it before you close or switch
   away from your activity.
  
  That's not far from the truth, right?  At least in any work-losing or
  surprising way...
 
 It's far from the truth in that it's not normally what you want to
 do.

My quoting-foo is bad, so I've caused confusion (in myself, too :)).

 To save your work, simply click the Stop button or change so that
 another activity has focus. If you click Keep, you'll end up with 2
 copies - one from when you clicked Keep, and one from when you clicked
 Stop (or focused on another activity).
 
 As far as I understand it, Keep is useful for these types of scenarios:
 - you've done a lot of work but now it's time to refactor/reorganize the
 whole thing. However you want to keep a copy of the rough version you
 have now, as insurance or perhaps for reference while you re-mangle
 the work.
 - you've made a template for something, now you want to save that
 template (as a blank template) before starting on a version where you
 fill in the content.

This is a great explanation -- it should be in the HIG or something.

 Daniel

Martin


pgpWVf3l0Cxrl.pgp
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Bug tracker enhancements

2009-07-09 Thread Bernie Innocenti
Adding Chris Rowe (also using Redmine) and Noah coderanger Kantrowitz,
of Trac fame.


On Thu, 2009-07-09 at 10:42 +0200, Simon Schampijer wrote:
 On 07/09/2009 08:06 AM, Bryan Berry wrote:
  On Thu, 2009-07-09 at 07:45 +0200, Simon Schampijer wrote:
  Hi,
 
  Our current trac instance is missing some basic functionality:
 
  - versions per component: a really simple enhancement would be to have a
  text field (maybe some versions (sugar core) you can select from) but
  that we do not have to keep the list updated for each activity
 
  - milestones should be on a component basis as well (similar to versions)
 
  - I want to make certain fields only being available with certain
  permissions (a milestone and priority can only be set by the mainteiner,
  the severity by the bugsquad (see new fedora policy))
 
  - having a clear separation from the Soas component - if we have the
  things from above this is maybe not as critical, otherwise I would
  suggest to get a new instance for Soas
 
 
  Can someone help to get there? Is trac giving us that functionality?
  Other trac software we should consider (besides bugzilla :)?
 
  redmine,redmine,redmine  much easier to set up, maintain, administer
  than trac and has a much more active community developing useful plugins
 
 Does redmine solve the cases I described above?
 
 Simon
 


-- 
   // Bernie Innocenti - http://codewiz.org/
 \X/  Sugar Labs   - http://sugarlabs.org/


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


Re: [Sugar-devel] css selector

2009-07-09 Thread Lucian Branescu
jQuery uses Sizzle, which uses native selectors whenever it can. You
can see in that graph the green bar (jQuery 1.2.7 experimental) is
only a sliver slower than native selectors, when available.

Even without native selectors, Sizzle is very fast and I doubt it'll
be a bottleneck for you. If I were you, I'd stick to jQuery or use
Sizzle directly if jQuery is inappropriate for some other reason.

2009/7/9 Bryan Berry br...@olenepal.org:
 for our code, i would prefer to use jquery selectors, it will make our
 code a lot more portable

 Also, for the purpose of getting translation strings, speed not so
 important.


 On Thu, 2009-07-09 at 01:53 -0500, Felipe López Toledo wrote:
 Hi Byan.

 Since I'm printing everything that seems useful, I found this:
 http://hacks.mozilla.org/2009/06/dom-selectors-api/

 summary: native css selectors are faster than other css selectors

 maybe it's not important.. but (for a moment) I was thinking jQuery
 css selector vs native css selectors: what do we must use?

 felipe
 --
 Bryan W. Berry
 Technology Director
 OLE Nepal, http://www.olenepal.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] Bug tracker enhancements

2009-07-09 Thread Bryan Berry
here is the main features page for redmine
http://www.redmine.org/wiki/redmine/Features

On Thu, 2009-07-09 at 10:42 +0200, Simon Schampijer wrote:
 On 07/09/2009 08:06 AM, Bryan Berry wrote:
  On Thu, 2009-07-09 at 07:45 +0200, Simon Schampijer wrote:
  Hi,

If u make each component a subproject, u can set individual milestones,
and milestones for the larger project

  - I want to make certain fields only being available with certain
  permissions (a milestone and priority can only be set by the mainteiner,
  the severity by the bugsquad (see new fedora policy)

users can have different roles in different projects/components

there is reporter, developer, administrator each w/ different rights

but u can also create custom roles, like in this image

http://www.redmine.org/screenshots/role_permissions.png

  - having a clear separation from the Soas component - if we have the
  things from above this is maybe not as critical, otherwise I would
  suggest to get a new instance for Soas
 

Most definitely in this case.

Another nice feature is that u can embed a google calendar into redmine,
w/ important dates, not necessarily code related, such as linux tag,
SoAS demos, community events.

There is also a neat Vote plugin which lets users
http://www.redmine.org/boards/3/topics/5506 
vote to indicate that particular issues are important to them.


-- 
Bryan W. Berry
Technology Director
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] prep for an article

2009-07-09 Thread Jeff Elkner
On Thu, Jul 9, 2009 at 6:04 AM, Martin Dengler mar...@martindengler.comwrote:

 On Wed, Jul 08, 2009 at 05:54:35PM -0400, Jeff Elkner wrote:
  On Wed, Jul 8, 2009 at 4:42 PM, a k a.akenn...@gmail.com wrote:
   1) can we capture the text of the chats the students are having?
   (I'd like to do a linguistic analysis--ESPECIALLY if they chat
   after class--WILL THEY DISCUSS Scratch procedures?
  1. The chats are stored in the journal, but we don't know if there is an
  easy way to move them to a flash drive (Luke is trying as I type).

 Are you going to tell the kids you're spying on their Chats? :(


 Of course we are, Martin!  In fact, I plan to use this opportunity as a
teachable moment to discuss the difference between public speech and
private speech and the implications of things like recorded chat files as
they impact privacy in the 21st century.

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


Re: [Sugar-devel] Bug tracker enhancements

2009-07-09 Thread Bernie Innocenti
On Thu, 2009-07-09 at 16:56 +0545, Bryan Berry wrote:
 here is the main features page for redmine
 http://www.redmine.org/wiki/redmine/Features
 
 On Thu, 2009-07-09 at 10:42 +0200, Simon Schampijer wrote:
  On 07/09/2009 08:06 AM, Bryan Berry wrote:
   On Thu, 2009-07-09 at 07:45 +0200, Simon Schampijer wrote:
   Hi,
 
 If u make each component a subproject, u can set individual milestones,
 and milestones for the larger project
 
   - I want to make certain fields only being available with certain
   permissions (a milestone and priority can only be set by the mainteiner,
   the severity by the bugsquad (see new fedora policy)
 
 users can have different roles in different projects/components
 
 there is reporter, developer, administrator each w/ different rights
 
 but u can also create custom roles, like in this image
 
 http://www.redmine.org/screenshots/role_permissions.png
 

Very interesting.  We have a demo redmine instance here:

  http://prj.sugarlabs.org/

Would you like to help configure it to give us an idea of how it would
work in practice?

-- 
   // Bernie Innocenti - http://codewiz.org/
 \X/  Sugar Labs   - http://sugarlabs.org/


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


Re: [Sugar-devel] Datastore redesign

2009-07-09 Thread Tomeu Vizoso
On Mon, Jul 6, 2009 at 16:33, Eben Eliasone...@laptop.org wrote:
 On Mon, Jul 6, 2009 at 10:02 AM, Sascha
 Silbesascha-ml-ui-sugar-de...@silbe.org wrote:
 On Mon, Jul 06, 2009 at 12:29:53PM +0200, Tomeu Vizoso wrote:

 Agreed. I have to say that your proposal is excellent, congratulations!

 Thanks, I'm flattered. :)


 Is the asynchronous API design useful enough to warrant more complex
 implementation?

 I'm not sure, but I think that whatever decision we take should be
 made based on actual usage of the DS. What about proposing an example
 of how an existing activity would be modified to use the new API?

 OK, will work on one.


  - For save() calls activity needs to wait for result (containing new
    version_id) before it can invoke save() again for the same object
    which can take quite some time if save() is sync - especially if other
    activities are saving at the same time.

 What about having a separate call that returns synchronously a new
 tree_id and/or version_id?

 Interesting idea, need to think about it. As we're going to use UUIDs not
 using requested versions shouldn't be an issue (for other version number
 schemes like the one you propose below holes in the numbering could be
 troublesome).

 I think holes can be expected, so we should definitely be prepared for them.


 Making the API fully asynchronous is the cause for much of the complexity
 of
 my proposal, but if we eliminate the queueing the response times for
 write
 accesses and checkout() can be very long even for unrelated operations.

 Why for unrelated operations?

 Because we're serializing VCS operations. They are IO bound (more
 specifically: disk bound) and parallelisation would only lead to IO
 starvation, especially for HDDs.


 # do we want an optimized way to determine (only) the branch HEADs of
 a given tree_id?

 This depends on the intended UI. My opinion is that if we branch at
 every interesting modification (triggered by the activity detecting an
 interesting change or by the user clicking on the Keep button), we

 I don't think we need to branch in these instances. These events
 should create new versions, but not necessarily new branches.

In my proposal, branch is not a concept directly exposed to the user.
Is just an artefact that allows the journal to display the relevant
info to an user. If we branch at the following events, displaying only
HEADs of branches in the journal list view makes sense for the user:

- new tree_id,
- resume entry,
- keep button,
- after a big change in the activity model (user deletes the whole
drawing, etc).

There are other ways to manage what we want, but this approach made it
very easy to implement.

Just to make sure I'm understood, I see why using branches this way
may seem conceptually wrong, it's not how we would work in a VCS or
CMS. But by creating new branches at those points and displaying only
HEADs of branches in the list view is the simplest way I found of
displaying the relevant entries in a robust way (resisting activity
crashes).

 would like to display in the object list all the HEADs of each branch
 in each tree_id. In that case yes, we need a way to retrieve that list
 that is fast on both the client and the server side.

 My imagined usage of branches was to create them automatically upon altering
 a non-HEAD version.

 This makes sense to me, personally.

 A user basing off an old version could mean the newer version is broken
 (in that case promoting the new version to the HEAD of the current branch
 makes more sense) or that (s)he uses the older version as a kind of template
 to create derivates (so creating a branch would make most sense).
 But I'm open to alternative suggestions. We'd most likely need a way to
 explicitly create branches then.


 # using symlink instead of hardlink for incoming queue since we want
 to support directory trees, not just files

 What justifies this new requirement?

 That it's
 a) of use to activities (IIRC some of them use ZIP files right instead now),

 This has its own merits, though. Encapsulating the related files as a
 single archive makes transporting the file around, or sending it to a
 friend, trivial. It's good for the same reason that activity bundles
 are good.

But this may be considered an internal implementation detail of the
DS, unless we want to support users directly browsing the DS backend.

 b) easy enough to achieve with the new design and
 c) leads to better delta compression and thus disk space effiency.


 # since an index rebuild can take a lot of time we need to provide UI
 feedback while doing that

 Any I/O operation can potentially take a lot of time, but with the
 current version of the DS rebuilding an index with a few thousands of
 entries is not so slow on the XO. We should never need to rebuild the
 index, so this new requirement might not be justified (given the
 current resources, all the other work we need to do, etc).

 OK, good to know index rebuilding is fast. So the simple, 

Re: [Sugar-devel] Nobody understands Keep

2009-07-09 Thread Tomeu Vizoso
On Thu, Jul 9, 2009 at 12:29, Martin Denglermar...@martindengler.com wrote:
 On Thu, Jul 09, 2009 at 11:22:16AM +0100, Daniel Drake wrote:
 On Thu, 2009-07-09 at 10:45 +0100, Martin Dengler wrote:
  On Thu, Jul 09, 2009 at 09:52:23AM +0100, Daniel Drake wrote:
   Nobody in the world seems to understand the Keep button. People think
   it's for regular saving and you should do it before you close or switch
   away from your activity.
 
  That's not far from the truth, right?  At least in any work-losing or
  surprising way...

 It's far from the truth in that it's not normally what you want to
 do.

 My quoting-foo is bad, so I've caused confusion (in myself, too :)).

 To save your work, simply click the Stop button or change so that
 another activity has focus. If you click Keep, you'll end up with 2
 copies - one from when you clicked Keep, and one from when you clicked
 Stop (or focused on another activity).

 As far as I understand it, Keep is useful for these types of scenarios:
 - you've done a lot of work but now it's time to refactor/reorganize the
 whole thing. However you want to keep a copy of the rough version you
 have now, as insurance or perhaps for reference while you re-mangle
 the work.
 - you've made a template for something, now you want to save that
 template (as a blank template) before starting on a version where you
 fill in the content.

 This is a great explanation -- it should be in the HIG or something.

But the biggest problem is how do we explain this to users without
them having to read the HIG (or manual)?

Should be called Keep a copy?

Regards,

Tomeu

 Daniel

 Martin

 ___
 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] Bug tracker enhancements

2009-07-09 Thread Bryan Berry
sure, i can work on it. i can try to put a couple hours into it
tomorrow. 

can u send me the passwd in a pm?
On Thu, 2009-07-09 at 07:40 -0400, Bernie Innocenti wrote:
 On Thu, 2009-07-09 at 16:56 +0545, Bryan Berry wrote:
  here is the main features page for redmine
  http://www.redmine.org/wiki/redmine/Features
  
  On Thu, 2009-07-09 at 10:42 +0200, Simon Schampijer wrote:
   On 07/09/2009 08:06 AM, Bryan Berry wrote:
On Thu, 2009-07-09 at 07:45 +0200, Simon Schampijer wrote:
Hi,
  
  If u make each component a subproject, u can set individual milestones,
  and milestones for the larger project
  
- I want to make certain fields only being available with certain
permissions (a milestone and priority can only be set by the 
mainteiner,
the severity by the bugsquad (see new fedora policy)
  
  users can have different roles in different projects/components
  
  there is reporter, developer, administrator each w/ different rights
  
  but u can also create custom roles, like in this image
  
  http://www.redmine.org/screenshots/role_permissions.png
  
 
 Very interesting.  We have a demo redmine instance here:
 
   http://prj.sugarlabs.org/
 
 Would you like to help configure it to give us an idea of how it would
 work in practice?
 
-- 
Bryan W. Berry
Technology Director
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] Bug tracker enhancements

2009-07-09 Thread Bryan Berry
On Thu, 2009-07-09 at 07:40 -0400, Bernie Innocenti wrote:
 On Thu, 2009-07-09 at 16:56 +0545, Bryan Berry wrote:
 Would you like to help configure it to give us an idea of how it would
 work in practice?

bernie: to be productive i will occasionally need your help. What times
will u be online tomorrow?

It would help if u r using the latest stable version 0.8.4, which I
believe uses a newish version of rails
http://rubyforge.org/frs/?group_id=1850

-- 
Bryan W. Berry
Technology Director
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] Bug tracker enhancements

2009-07-09 Thread Bernie Innocenti
On Thu, 2009-07-09 at 17:53 +0545, Bryan Berry wrote:
 sure, i can work on it. i can try to put a couple hours into it
 tomorrow. 

You should have received login info by email.

-- 
   // Bernie Innocenti - http://codewiz.org/
 \X/  Sugar Labs   - http://sugarlabs.org/


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


Re: [Sugar-devel] Bug tracker enhancements

2009-07-09 Thread Bernie Innocenti
On Thu, 2009-07-09 at 18:01 +0545, Bryan Berry wrote:
 On Thu, 2009-07-09 at 07:40 -0400, Bernie Innocenti wrote:
  On Thu, 2009-07-09 at 16:56 +0545, Bryan Berry wrote:
  Would you like to help configure it to give us an idea of how it would
  work in practice?
 
 bernie: to be productive i will occasionally need your help. What times
 will u be online tomorrow?

Today I plan to be online all day.  Tomorrow I will be with a customer
all day, probably online but distracted and unresponsive.

-- 
   // Bernie Innocenti - http://codewiz.org/
 \X/  Sugar Labs   - http://sugarlabs.org/


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


Re: [Sugar-devel] Nobody understands Keep

2009-07-09 Thread Martin Dengler
On Thu, Jul 09, 2009 at 02:03:06PM +0200, Tomeu Vizoso wrote:
 On Thu, Jul 9, 2009 at 12:29, Martin Denglermar...@martindengler.com wrote:
  On Thu, Jul 09, 2009 at 11:22:16AM +0100, Daniel Drake wrote:
  As far as I understand it, Keep is useful for these types of
  scenarios: - you've done a lot of work but now it's time to
  refactor/reorganize the whole thing. However you want to keep a
  copy of the rough version you have now, as insurance or perhaps
  for reference while you re-mangle the work.  - you've made a
  template for something, now you want to save that template (as a
  blank template) before starting on a version where you fill in
  the content.
 
  This is a great explanation -- it should be in the HIG or something.
 
 But the biggest problem is how do we explain this to users without
 them having to read the HIG (or manual)?

Of course.

 Should be called Keep a copy?

Backup?

  Daniel
 
  Martin

 Regards,
 
 Tomeu

Martin


pgpSt5Tw3PtSc.pgp
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Datastore redesign

2009-07-09 Thread Eben Eliason
On Thu, Jul 9, 2009 at 8:00 AM, Tomeu Vizosoto...@sugarlabs.org wrote:
 On Mon, Jul 6, 2009 at 16:33, Eben Eliasone...@laptop.org wrote:
 On Mon, Jul 6, 2009 at 10:02 AM, Sascha
 Silbesascha-ml-ui-sugar-de...@silbe.org wrote:
 On Mon, Jul 06, 2009 at 12:29:53PM +0200, Tomeu Vizoso wrote:

 Agreed. I have to say that your proposal is excellent, congratulations!

 Thanks, I'm flattered. :)


 Is the asynchronous API design useful enough to warrant more complex
 implementation?

 I'm not sure, but I think that whatever decision we take should be
 made based on actual usage of the DS. What about proposing an example
 of how an existing activity would be modified to use the new API?

 OK, will work on one.


  - For save() calls activity needs to wait for result (containing new
    version_id) before it can invoke save() again for the same object
    which can take quite some time if save() is sync - especially if other
    activities are saving at the same time.

 What about having a separate call that returns synchronously a new
 tree_id and/or version_id?

 Interesting idea, need to think about it. As we're going to use UUIDs not
 using requested versions shouldn't be an issue (for other version number
 schemes like the one you propose below holes in the numbering could be
 troublesome).

 I think holes can be expected, so we should definitely be prepared for 
 them.


 Making the API fully asynchronous is the cause for much of the complexity
 of
 my proposal, but if we eliminate the queueing the response times for
 write
 accesses and checkout() can be very long even for unrelated operations.

 Why for unrelated operations?

 Because we're serializing VCS operations. They are IO bound (more
 specifically: disk bound) and parallelisation would only lead to IO
 starvation, especially for HDDs.


 # do we want an optimized way to determine (only) the branch HEADs of
 a given tree_id?

 This depends on the intended UI. My opinion is that if we branch at
 every interesting modification (triggered by the activity detecting an
 interesting change or by the user clicking on the Keep button), we

 I don't think we need to branch in these instances. These events
 should create new versions, but not necessarily new branches.

 In my proposal, branch is not a concept directly exposed to the user.
 Is just an artefact that allows the journal to display the relevant
 info to an user. If we branch at the following events, displaying only
 HEADs of branches in the journal list view makes sense for the user:

 - new tree_id,
 - resume entry,
 - keep button,
 - after a big change in the activity model (user deletes the whole
 drawing, etc).

 There are other ways to manage what we want, but this approach made it
 very easy to implement.

 Just to make sure I'm understood, I see why using branches this way
 may seem conceptually wrong, it's not how we would work in a VCS or
 CMS. But by creating new branches at those points and displaying only
 HEADs of branches in the list view is the simplest way I found of
 displaying the relevant entries in a robust way (resisting activity
 crashes).

That's fine, assuming these are actually the entries we want to show,
but I'm not sure that's always the case. For instance, we might show
only the most recent version in the object view, while showing each
version within the action view. If we store action-objects as Ben
proposed, we may have an entirely different way of querying what
should be shown in the actions view anyway.

We've also had some ideas on how to expose the branching structure
within the version popup, in which case branching as one would in a
VCS would make more sense.

Eben

 would like to display in the object list all the HEADs of each branch
 in each tree_id. In that case yes, we need a way to retrieve that list
 that is fast on both the client and the server side.

 My imagined usage of branches was to create them automatically upon altering
 a non-HEAD version.

 This makes sense to me, personally.

 A user basing off an old version could mean the newer version is broken
 (in that case promoting the new version to the HEAD of the current branch
 makes more sense) or that (s)he uses the older version as a kind of template
 to create derivates (so creating a branch would make most sense).
 But I'm open to alternative suggestions. We'd most likely need a way to
 explicitly create branches then.


 # using symlink instead of hardlink for incoming queue since we want
 to support directory trees, not just files

 What justifies this new requirement?

 That it's
 a) of use to activities (IIRC some of them use ZIP files right instead now),

 This has its own merits, though. Encapsulating the related files as a
 single archive makes transporting the file around, or sending it to a
 friend, trivial. It's good for the same reason that activity bundles
 are good.

 But this may be considered an internal implementation detail of the
 DS, unless we want to support users directly 

Re: [Sugar-devel] SoAS Testing with XS

2009-07-09 Thread Caroline Meeks
It was worth a try but I see exactly the same behavior on the media lab
jabber server.

One thing I think I am noticing. It seems like one machine at a time is
connected to the Jabber Server.

What happens when a machine connects?
Is there anyway that one machine connecting could cause another to
disconnect?
Are these machines in some way replicating something about them when the
server things it should be unique?
Could there be some sort of firewall or a caching service that decides its a
duplicate and cuts one of them off?

On Wed, Jul 8, 2009 at 11:17 PM, Benjamin M. Schwartz 
bmsch...@fas.harvard.edu wrote:

 Caroline Meeks wrote:
 1. Fix Jabber collaboration - We have a mysterious bug (that is also
 being worked on in parallel) that keeps dropping the connection to the
 externally hosted Jabber Server (jabber.sl.org)

 That's irritating.   Have you tried other servers? For example,
 schoolserver.media.mit.edu has been very reliable for me.

 OLPC ran collaboration jabber servers for very large numbers of people
 following G1G1, and the only major problem was server overload (when
 serving far more than 18 users).  It is possible, and maybe the people who
 built those servers have some advice.

 --Ben




-- 
Caroline Meeks
Solution Grove
carol...@solutiongrove.com

617-500-3488 - Office
505-213-3268 - Fax
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Nobody understands Keep

2009-07-09 Thread Eben Eliason
On Thu, Jul 9, 2009 at 8:03 AM, Gary C Marting...@garycmartin.com wrote:
 On 9 Jul 2009, at 11:29, Martin Dengler wrote:

 On Thu, Jul 09, 2009 at 11:22:16AM +0100, Daniel Drake wrote:
 On Thu, 2009-07-09 at 10:45 +0100, Martin Dengler wrote:
 On Thu, Jul 09, 2009 at 09:52:23AM +0100, Daniel Drake wrote:
 Nobody in the world seems to understand the Keep button. People
 think
 it's for regular saving and you should do it before you close or
 switch
 away from your activity.

 +1


 That's not far from the truth, right?  At least in any work-losing
 or
 surprising way...

 It's far from the truth in that it's not normally what you want to
 do.

 My quoting-foo is bad, so I've caused confusion (in myself, too :)).

 To save your work, simply click the Stop button or change so that
 another activity has focus. If you click Keep, you'll end up with 2
 copies - one from when you clicked Keep, and one from when you
 clicked
 Stop (or focused on another activity).

 As far as I understand it, Keep is useful for these types of
 scenarios:
 - you've done a lot of work but now it's time to refactor/
 reorganize the
 whole thing. However you want to keep a copy of the rough version you
 have now, as insurance or perhaps for reference while you re-mangle
 the work.

Exactly.

 - you've made a template for something, now you want to save that
 template (as a blank template) before starting on a version where you
 fill in the content.

Not exactly. This would work, but I wouldn't call this a recommended
use. To start a new document from a template, it would be more
appropriate to Create a copy (which should exist in the Journal
itself), or Keep a copy (which would do the same thing, but from
within the activity)

 This is a great explanation -- it should be in the HIG or something.

 Hmmm, this still does not cover the special behaviour that Sugar now
 treats those Journal entries with. All these entries will have the
 same activity_id, Sugar shell uses this ID to know if it already has

Yes, that's intended. Keep actually means Keep a new version We
don't have proper versions yet, but that's the model.

 an Activity resumed. If an Activity with a matching activity_id is
 already instanced, resuming one of the older/newer entries will just
 switch you to the existing instance (with no change of content).
 Collaborating, with the Sugar shell treating any single entry in this
 long chain of entries as the same, is likely to cause quite some
 confusion for those involved as well...

 Perhaps visually showing all 'kept' entries as one single block (not
 multiple entries), with the past ones visually  'depreciated' in some

This was our thought behind the design mockups for the object view.
There would be one entry per object in the list, with a way to expand
or reveal past versions.

The opposite, however, is true of the design for the action list. Each
version is created as part of a unique activity session, so each of
these would be recorded as a distinct action, and refer to the
associated version.

 way (like old undo states), might help? Perhaps the keep button is
 just wrong altogether.

I think it's really important to have a manual method of invoking the
equivalent of saving. Maybe labeling the Keep button something
like Keep extra version would help.

 Maybe Sascha's GSoC version work will help us sort out the correct
 behaviour here.

Yes, it may.

Eben

 Regards,
 --Gary

 ___
 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] Nobody understands Keep

2009-07-09 Thread Eben Eliason
On Thu, Jul 9, 2009 at 8:03 AM, Tomeu Vizosoto...@sugarlabs.org wrote:
 On Thu, Jul 9, 2009 at 12:29, Martin Denglermar...@martindengler.com wrote:
 On Thu, Jul 09, 2009 at 11:22:16AM +0100, Daniel Drake wrote:
 On Thu, 2009-07-09 at 10:45 +0100, Martin Dengler wrote:
  On Thu, Jul 09, 2009 at 09:52:23AM +0100, Daniel Drake wrote:
   Nobody in the world seems to understand the Keep button. People think
   it's for regular saving and you should do it before you close or switch
   away from your activity.
 
  That's not far from the truth, right?  At least in any work-losing or
  surprising way...

 It's far from the truth in that it's not normally what you want to
 do.

 My quoting-foo is bad, so I've caused confusion (in myself, too :)).

 To save your work, simply click the Stop button or change so that
 another activity has focus. If you click Keep, you'll end up with 2
 copies - one from when you clicked Keep, and one from when you clicked
 Stop (or focused on another activity).

 As far as I understand it, Keep is useful for these types of scenarios:
 - you've done a lot of work but now it's time to refactor/reorganize the
 whole thing. However you want to keep a copy of the rough version you
 have now, as insurance or perhaps for reference while you re-mangle
 the work.
 - you've made a template for something, now you want to save that
 template (as a blank template) before starting on a version where you
 fill in the content.

 This is a great explanation -- it should be in the HIG or something.

 But the biggest problem is how do we explain this to users without
 them having to read the HIG (or manual)?

 Should be called Keep a copy?

Careful, here. keep a copy really is a fundamentally different
action. Keeping a copy will result in a new tree_id; Just keeping (or
keeping a new version) will only result in a new version_id. We need
to find a way to make these actions distinct.

Eben


 Regards,

 Tomeu

 Daniel

 Martin

 ___
 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-devel] Fwd: SoAS Testing with XS

2009-07-09 Thread Gary C Martin
Sorry, this was meant to go to the list no just Caroline.

Begin forwarded message:

 From: Gary C Martin g...@garycmartin.com
 Date: 9 July 2009 15:54:34 BST
 To: Caroline Meeks carol...@solutiongrove.com
 Subject: Re: [Sugar-devel] SoAS Testing with XS

 On 9 Jul 2009, at 15:19, Caroline Meeks wrote:

 It was worth a try but I see exactly the same behavior on the media  
 lab jabber server.

 One thing I think I am noticing. It seems like one machine at a  
 time is connected to the Jabber Server.

 What happens when a machine connects?
 Is there anyway that one machine connecting could cause another to  
 disconnect?
 Are these machines in some way replicating something about them  
 when the server things it should be unique?
 Could there be some sort of firewall or a caching service that  
 decides its a duplicate and cuts one of them off?

 Ohh geeezz... How did you make the sticks? Did you boot one and  
 tweak it, then clone that one? There are all sorts of files  
 generated when you boot a system that make it unique that would need  
 to be very carefully erased to make the stick image was 'fresh'. No  
 one has a full list of all these files and their various  
 interactions, though I think some have tried.

 Regards,
 --Gary

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


Re: [Sugar-devel] [IAEP] Paint improvements?

2009-07-09 Thread Aleksey Lim
On Thu, Jul 09, 2009 at 07:28:09AM -0500, David Farning wrote:
 On Wed, Jul 8, 2009 at 5:41 PM, Aleksey Limalsr...@member.fsf.org wrote:
  On Wed, Jul 08, 2009 at 06:26:00PM -0400, Caroline Meeks wrote:
  Nod, I've done that for Memorize and maybe we will for Paint too.  It will
  take some thought to get it right and I've got a lot on my plate right now.
  Worth it if it turns into code but right now I'm wondering what is the best
  path forward? Sugarizing Tux, Improving Paint or adding features to Colors?
  It mostly depends on what programmers out there are interested.
 
  If Tuxpaint satisfies all needs and new features list for Paint and
  Colors! is not short, I guess its much easier to add save-to-journal
  feature to Tuxpaint.
 
 I am in occasional contact with Bill Kendrick the lead developer for
 tuxpaint.  I try to reach out to him and the rest of the tuxpaint team
 to work more closely with Sugar Labs.

The save-to-journal feature shouldn't be a problem(since this will be
local change in Tuxpaint's code).

The relly hard problem is sharing mode in Tuxpaint.

There is a ticket for this reason - #887

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


Re: [Sugar-devel] Sugar on a Stick - and Csound

2009-07-09 Thread Tomeu Vizoso
On Thu, Jul 9, 2009 at 17:29, Peter Robinsonpbrobin...@gmail.com wrote:
 Hi,

 Does your action on Tomeu's filing mean that this Python bindings issue is
 now fixed?

 No it doesn't, its just what I suspect is the issue. I don't currently
 have time to investigate it further so I put the note on the bug so if
 anyone else has the time it might provide direction for them.

I unfortunately also don't have time now, but from the look of it I
think Peter is on the right track.

 If so, any idea:
 1) when an SoaS update might be available?
 2) when it would be incorporated into Strawberry?

 I can't answer either of those.

You should get into contact with the SoaS team, I'm forwarding it
again to sugar-devel. Please keep conversations on-list so everybody
benefits from this info.

Regards,

Tomeu

 I'm anxious to test it.

 Thanks to both of you for your help.

 Art Hunkins

 Peter

 - Original Message - From: Tomeu Vizoso to...@sugarlabs.org
 To: Aleksey Lim alsr...@member.fsf.org
 Cc: Art Hunkins abhun...@uncg.edu; sugar-devel@lists.sugarlabs.org
 Sent: Thursday, July 09, 2009 4:16 AM
 Subject: Re: [Sugar-devel] Sugar on a Stick - and Csound


 On Tue, Jun 30, 2009 at 03:48, Aleksey Limalsr...@member.fsf.org wrote:

 On Mon, Jun 29, 2009 at 08:14:26PM -0400, Art Hunkins wrote:

 Does anyone have insight concerning this response from Victor Lazzarini
 of the csound-devel listserv? (Victor wrote the csndsugui activity for 
 Sugar
 and is responsible for the Csound 5.08.91 rpm package.)

 My USB drive has nothing on it but Sugar, and we've no idea what module
 Python is trying to load that might be absent.

 Thanks for any ideas. (Of course, when Csound 5.10 appears as a Sugar
 update, I'll be installing it to see if this helps.)

 just an option,
 rebuild _csnd module in soas environment and it should fix problem anyway

 Have filed https://bugzilla.redhat.com/show_bug.cgi?id=510423 about this.

 Regards,

 Tomeu

 --
 Aleksey
 ___
 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] [IAEP] Paint improvements?

2009-07-09 Thread Ton van Overbeek
On Thu, Jul 9, 2009 at 11:46 AM, Aleksey Limalsr...@member.fsf.org wrote:
 On Thu, Jul 09, 2009 at 07:28:09AM -0500, David Farning wrote:
 On Wed, Jul 8, 2009 at 5:41 PM, Aleksey Limalsr...@member.fsf.org wrote:
  On Wed, Jul 08, 2009 at 06:26:00PM -0400, Caroline Meeks wrote:
  Nod, I've done that for Memorize and maybe we will for Paint too.  It will
  take some thought to get it right and I've got a lot on my plate right 
  now.
  Worth it if it turns into code but right now I'm wondering what is the 
  best
  path forward? Sugarizing Tux, Improving Paint or adding features to 
  Colors?
  It mostly depends on what programmers out there are interested.
 
  If Tuxpaint satisfies all needs and new features list for Paint and
  Colors! is not short, I guess its much easier to add save-to-journal
  feature to Tuxpaint.
 
 I am in occasional contact with Bill Kendrick the lead developer for
 tuxpaint.  I try to reach out to him and the rest of the tuxpaint team
 to work more closely with Sugar Labs.

 The save-to-journal feature shouldn't be a problem(since this will be
 local change in Tuxpaint's code).

 The relly hard problem is sharing mode in Tuxpaint.

 There is a ticket for this reason - #887

 --
 Aleksey

As someone who has hacked on Albert Cahalan's original XO-1 port of Tuxpaint
(see the tuxpaint entry on http://wiki.laptop.org/go/Activities/All)
I'd be glad to help
with further sugarizing tuxpaint.
What I did was to adapt it to the rainbow requirements for the XO-1 (store
data in the right directories, etc.) and proper startup from the ring.
No integration with the journal or implementation of sharing.

Note that a full installation of tuxpaint is very big, due to all the
examples and translations. Probably too big for a 1G stick SoaS.

Aleksey, what are your ideas about integration with the journal? Provide
a python glue layer? Or implement it directly in C?

Anyway, let me know what I can do.

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


Re: [Sugar-devel] Nobody understands Keep

2009-07-09 Thread Greg Smith
Hi All,

8 months in the tank at 1CC sitting next to Eben, you'd think I know
how this was designed to work ;-(

I've actually read the HIG too!

I see two case here:
Case 1 - Create something in one activity and then use it right away another.
I forgot that switching to a new activity puts a copy of the old one
on the Journal (20+ e-mails on that subject alone last year!). I'll
try Paint then just switch to Memorize next time I'm in a class and
see if that works and makes sense to the kids. One additional
confusion is that Memorize has Save Game and Load Game options. You
need to create a game then save it then load it from the Journal to
play a new game you just created. Looks like the programmer for
Memorize didn't grok the HIG details on Keep either, or did they?

Case 2 - Create something in one activity then create something else
in the same activity.
The launch, create, quit, launch again work flow seems inelegant to
say the least. A New button which saves the current file and opens a
new blank file sounds like nice way to make this easier. BTW
everyone I have seen use Sugar has trouble finding the Stop button.

FYI my philosophy is that the user is never wrong. They may do
something which results in unanticipated consequences or they may do
something which the programmer didn't intend, but its never wrong.
If they click a few extra times or lose their data until they figure
out a way to do what they want, so be it. The tools are there to be
used as they see fit.

The trainer on the other hand should know better...

Thanks,

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


Re: [Sugar-devel] Fwd: SoAS Testing with XS

2009-07-09 Thread Dave Bauer
On Thu, Jul 9, 2009 at 11:00 AM, Gary C Marting...@garycmartin.com wrote:
 Sorry, this was meant to go to the list no just Caroline.

 Begin forwarded message:

 From: Gary C Martin g...@garycmartin.com
 Date: 9 July 2009 15:54:34 BST
 To: Caroline Meeks carol...@solutiongrove.com
 Subject: Re: [Sugar-devel] SoAS Testing with XS

 On 9 Jul 2009, at 15:19, Caroline Meeks wrote:

 It was worth a try but I see exactly the same behavior on the media
 lab jabber server.

 One thing I think I am noticing. It seems like one machine at a
 time is connected to the Jabber Server.

 What happens when a machine connects?
 Is there anyway that one machine connecting could cause another to
 disconnect?
 Are these machines in some way replicating something about them
 when the server things it should be unique?
 Could there be some sort of firewall or a caching service that
 decides its a duplicate and cuts one of them off?

 Ohh geeezz... How did you make the sticks? Did you boot one and
 tweak it, then clone that one? There are all sorts of files
 generated when you boot a system that make it unique that would need
 to be very carefully erased to make the stick image was 'fresh'. No
 one has a full list of all these files and their various
 interactions, though I think some have tried.


The jabber id is generated from ~/.sugar/owner.key.
Removing ~/.sugar/owner.key and ~/.sugar/owner.key.pub generates a new
key after reboot and the jabber id is reset.

Dave

 Regards,
 --Gary

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




-- 
Dave Bauer
d...@solutiongrove.com
http://www.solutiongrove.com
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] [IAEP] Paint improvements?

2009-07-09 Thread Aleksey Lim
On Thu, Jul 09, 2009 at 12:07:11PM -0400, Ton van Overbeek wrote:
 On Thu, Jul 9, 2009 at 11:46 AM, Aleksey Limalsr...@member.fsf.org wrote:
  On Thu, Jul 09, 2009 at 07:28:09AM -0500, David Farning wrote:
  On Wed, Jul 8, 2009 at 5:41 PM, Aleksey Limalsr...@member.fsf.org wrote:
   On Wed, Jul 08, 2009 at 06:26:00PM -0400, Caroline Meeks wrote:
   Nod, I've done that for Memorize and maybe we will for Paint too.  It 
   will
   take some thought to get it right and I've got a lot on my plate right 
   now.
   Worth it if it turns into code but right now I'm wondering what is the 
   best
   path forward? Sugarizing Tux, Improving Paint or adding features to 
   Colors?
   It mostly depends on what programmers out there are interested.
  
   If Tuxpaint satisfies all needs and new features list for Paint and
   Colors! is not short, I guess its much easier to add save-to-journal
   feature to Tuxpaint.
  
  I am in occasional contact with Bill Kendrick the lead developer for
  tuxpaint.  I try to reach out to him and the rest of the tuxpaint team
  to work more closely with Sugar Labs.
 
  The save-to-journal feature shouldn't be a problem(since this will be
  local change in Tuxpaint's code).
 
  The relly hard problem is sharing mode in Tuxpaint.
 
  There is a ticket for this reason - #887
 
  --
  Aleksey
 
 As someone who has hacked on Albert Cahalan's original XO-1 port of Tuxpaint
 (see the tuxpaint entry on http://wiki.laptop.org/go/Activities/All)
 I'd be glad to help
 with further sugarizing tuxpaint.
 What I did was to adapt it to the rainbow requirements for the XO-1 (store
 data in the right directories, etc.) and proper startup from the ring.
 No integration with the journal or implementation of sharing.
 
 Note that a full installation of tuxpaint is very big, due to all the
 examples and translations. Probably too big for a 1G stick SoaS.
 
 Aleksey, what are your ideas about integration with the journal? Provide
 a python glue layer? Or implement it directly in C?

I kept in mind implementing it in Tuxpaint's code in C, since DS API is just
dbus API(the good example is etoys) but I didnt think about it yet.

 Anyway, let me know what I can do.

maybe implementing save-to-Journal feature ;)

if you are interested in sent me your nick on git.sl.o and I'll add you
to commiter list of http://git.sugarlabs.org/projects/tux-paint.
I keep upstream code in upstream branch(now its 0.9.20), you would
want to switch it to new release or trunk, then just rewrite upstream
branch(I guess its not worth keeping all upstream commits)

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


[Sugar-devel] Please use Feature 0.86 category for all 0.86 features

2009-07-09 Thread Aleksey Lim
Hi all,

I think having all 0.86 features in one category Feature 0.86 makes process
easier(for developers and users).

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


Re: [Sugar-devel] [IAEP] [Marketing] netbook as terminology

2009-07-09 Thread Bastien
Dave Bauer dave.ba...@gmail.com writes:

 On Fri, Jul 3, 2009 at 12:19 PM, Bastien bastiengue...@googlemail.com wrote:

 Yes.  In the meantime, I would *love* to see the XS server running, and
 a tutorial on how to use Sugar with non-XO computers connected thru a XS
 server...  IMHO it's a promise that OLPC/Sugar cannot afford to bypass.

 This is already working. For example, if you use Sugar on a Stick you are 
 using
 an XS that can work with XO and non-XO computers today. This is 0.5.2 XS
 installed from the ISO and regularly updated via yum. If you take any
 installation of Sugar and set the collaboration server to jabber.sugarlabs.org
 it should work. No special configuration is needed to support Sugar on non-XO
 computers that I am aware of.

Thanks.  But that's when the Sugar machines are connected to the
internet, right?

What I was looking for is a How to set up a school server? when you
don't have internet - i.e. when you need to use the server as an access
point.  This might be of interest in some of the french school we plan
to deploy Soas.

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


[Sugar-devel] Switching between activities? (was Re: Nobody understands Keep)

2009-07-09 Thread Bastien
Hi all,

Greg Smith gregsmit...@gmail.com writes:

 I forgot that switching to a new activity puts a copy of the old one
 on the Journal (20+ e-mails on that subject alone last year!). 

This comment and Daniel's ones about the Keep button just make me wonder
why Sugar should allow several activities to be open at the same time. 

Any strong case where this can be relevant?

Actually I'm not suggesting to ditch switching itself, I just realized
that switching could be quit-and-fetch-another-activity-from-journal.

Then it would make sense to have another instance of the activity stored
in the journal when switching to an activity.

 FYI my philosophy is that the user is never wrong. 

I have the same.  And I've seen many instances with the XO where I had
to explain why children shouldn't launch more than 3 or 4 activities.
Hence this proposal.  Perhaps you considered this idea before - in that
case I'm interested in reading thru the discussion.

Thanks,

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


Re: [Sugar-devel] Switching between activities? (was Re: Nobody understands Keep)

2009-07-09 Thread Walter Bender
The biggest downside is that some activities are very slow to launch...
especially on the XO.

-walter

On Thu, Jul 9, 2009 at 7:30 PM, Bastien bastiengue...@googlemail.comwrote:

 Hi all,

 Greg Smith gregsmit...@gmail.com writes:

  I forgot that switching to a new activity puts a copy of the old one
  on the Journal (20+ e-mails on that subject alone last year!).

 This comment and Daniel's ones about the Keep button just make me wonder
 why Sugar should allow several activities to be open at the same time.

 Any strong case where this can be relevant?

 Actually I'm not suggesting to ditch switching itself, I just realized
 that switching could be quit-and-fetch-another-activity-from-journal.

 Then it would make sense to have another instance of the activity stored
 in the journal when switching to an activity.

  FYI my philosophy is that the user is never wrong.

 I have the same.  And I've seen many instances with the XO where I had
 to explain why children shouldn't launch more than 3 or 4 activities.
 Hence this proposal.  Perhaps you considered this idea before - in that
 case I'm interested in reading thru the discussion.

 Thanks,

 --
  Bastien
 ___
 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] Switching between activities?

2009-07-09 Thread Bastien
Walter Bender walter.ben...@gmail.com writes:

 The biggest downside is that some activities are very slow to launch...
 especially on the XO.

I guess the downside for children to get stuck with too many open
activities on their XO is bigger than that of waiting for an activity 
to launch -- especially when using the computer for learning purpose,
where you don't really need to switch between many activities.

This argument holds /a fortiori/ on other hardware, where launchtime 
is better.

Anyway, was just a thought.

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


[Sugar-devel] GPA collaboration Issues - owner key theory

2009-07-09 Thread Caroline Meeks
We will delete  ~/.sugar/owner.key and ~/.sugar/owner.key.pub when we reburn
the sticks on Monday.

However, my problem with this theory is that l've been cloning pretty much
the same Stick from FOSSVT on.  Other places we have multiple people using
the same stick without this problem.  However, we have mostly be using
wireless not wired. Woudl that make a difference?

On Thu, Jul 9, 2009 at 1:55 PM, Dave Bauer dave.ba...@gmail.com wrote:

 On Thu, Jul 9, 2009 at 11:00 AM, Gary C Marting...@garycmartin.com
 wrote:
  Sorry, this was meant to go to the list no just Caroline.
 
  Begin forwarded message:
 
  From: Gary C Martin g...@garycmartin.com
  Date: 9 July 2009 15:54:34 BST
  To: Caroline Meeks carol...@solutiongrove.com
  Subject: Re: [Sugar-devel] SoAS Testing with XS
 
  On 9 Jul 2009, at 15:19, Caroline Meeks wrote:
 
  It was worth a try but I see exactly the same behavior on the media
  lab jabber server.
 
  One thing I think I am noticing. It seems like one machine at a
  time is connected to the Jabber Server.
 
  What happens when a machine connects?
  Is there anyway that one machine connecting could cause another to
  disconnect?
  Are these machines in some way replicating something about them
  when the server things it should be unique?
  Could there be some sort of firewall or a caching service that
  decides its a duplicate and cuts one of them off?
 
  Ohh geeezz... How did you make the sticks? Did you boot one and
  tweak it, then clone that one? There are all sorts of files
  generated when you boot a system that make it unique that would need
  to be very carefully erased to make the stick image was 'fresh'. No
  one has a full list of all these files and their various
  interactions, though I think some have tried.
 

 The jabber id is generated from ~/.sugar/owner.key.
 Removing ~/.sugar/owner.key and ~/.sugar/owner.key.pub generates a new
 key after reboot and the jabber id is reset.

 Dave

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



 --
 Dave Bauer
 d...@solutiongrove.com
 http://www.solutiongrove.com
 ___
 Sugar-devel mailing list
 Sugar-devel@lists.sugarlabs.org
 http://lists.sugarlabs.org/listinfo/sugar-devel




-- 
Caroline Meeks
Solution Grove
carol...@solutiongrove.com

617-500-3488 - Office
505-213-3268 - Fax
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] GPA collaboration Issues - owner key theory

2009-07-09 Thread Dave Bauer
Are you sure? I think we were deleting ~/.sugar completely before.

Trying to save the journal etc makes it more complex.


On Thu, Jul 9, 2009 at 9:53 PM, Caroline Meekscarol...@meekshome.com wrote:
 We will delete  ~/.sugar/owner.key and ~/.sugar/owner.key.pub when we reburn
 the sticks on Monday.

In addition to ~/.gconf and ~/.gconfd

Dave


 However, my problem with this theory is that l've been cloning pretty much
 the same Stick from FOSSVT on.  Other places we have multiple people using
 the same stick without this problem.  However, we have mostly be using
 wireless not wired. Woudl that make a difference?

 On Thu, Jul 9, 2009 at 1:55 PM, Dave Bauer dave.ba...@gmail.com wrote:

 On Thu, Jul 9, 2009 at 11:00 AM, Gary C Marting...@garycmartin.com
 wrote:
  Sorry, this was meant to go to the list no just Caroline.
 
  Begin forwarded message:
 
  From: Gary C Martin g...@garycmartin.com
  Date: 9 July 2009 15:54:34 BST
  To: Caroline Meeks carol...@solutiongrove.com
  Subject: Re: [Sugar-devel] SoAS Testing with XS
 
  On 9 Jul 2009, at 15:19, Caroline Meeks wrote:
 
  It was worth a try but I see exactly the same behavior on the media
  lab jabber server.
 
  One thing I think I am noticing. It seems like one machine at a
  time is connected to the Jabber Server.
 
  What happens when a machine connects?
  Is there anyway that one machine connecting could cause another to
  disconnect?
  Are these machines in some way replicating something about them
  when the server things it should be unique?
  Could there be some sort of firewall or a caching service that
  decides its a duplicate and cuts one of them off?
 
  Ohh geeezz... How did you make the sticks? Did you boot one and
  tweak it, then clone that one? There are all sorts of files
  generated when you boot a system that make it unique that would need
  to be very carefully erased to make the stick image was 'fresh'. No
  one has a full list of all these files and their various
  interactions, though I think some have tried.
 

 The jabber id is generated from ~/.sugar/owner.key.
 Removing ~/.sugar/owner.key and ~/.sugar/owner.key.pub generates a new
 key after reboot and the jabber id is reset.

 Dave

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



 --
 Dave Bauer
 d...@solutiongrove.com
 http://www.solutiongrove.com
 ___
 Sugar-devel mailing list
 Sugar-devel@lists.sugarlabs.org
 http://lists.sugarlabs.org/listinfo/sugar-devel



 --
 Caroline Meeks
 Solution Grove
 carol...@solutiongrove.com

 617-500-3488 - Office
 505-213-3268 - Fax




-- 
Dave Bauer
d...@solutiongrove.com
http://www.solutiongrove.com
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] GPA collaboration Issues - owner key theory

2009-07-09 Thread Walter Bender
Have we experimented with unmodified keys?

-walter

On Thu, Jul 9, 2009 at 9:53 PM, Caroline Meeks carol...@meekshome.comwrote:

 We will delete  ~/.sugar/owner.key and ~/.sugar/owner.key.pub when we
 reburn the sticks on Monday.

 However, my problem with this theory is that l've been cloning pretty much
 the same Stick from FOSSVT on.  Other places we have multiple people using
 the same stick without this problem.  However, we have mostly be using
 wireless not wired. Woudl that make a difference?

 On Thu, Jul 9, 2009 at 1:55 PM, Dave Bauer dave.ba...@gmail.com wrote:

 On Thu, Jul 9, 2009 at 11:00 AM, Gary C Marting...@garycmartin.com
 wrote:
  Sorry, this was meant to go to the list no just Caroline.
 
  Begin forwarded message:
 
  From: Gary C Martin g...@garycmartin.com
  Date: 9 July 2009 15:54:34 BST
  To: Caroline Meeks carol...@solutiongrove.com
  Subject: Re: [Sugar-devel] SoAS Testing with XS
 
  On 9 Jul 2009, at 15:19, Caroline Meeks wrote:
 
  It was worth a try but I see exactly the same behavior on the media
  lab jabber server.
 
  One thing I think I am noticing. It seems like one machine at a
  time is connected to the Jabber Server.
 
  What happens when a machine connects?
  Is there anyway that one machine connecting could cause another to
  disconnect?
  Are these machines in some way replicating something about them
  when the server things it should be unique?
  Could there be some sort of firewall or a caching service that
  decides its a duplicate and cuts one of them off?
 
  Ohh geeezz... How did you make the sticks? Did you boot one and
  tweak it, then clone that one? There are all sorts of files
  generated when you boot a system that make it unique that would need
  to be very carefully erased to make the stick image was 'fresh'. No
  one has a full list of all these files and their various
  interactions, though I think some have tried.
 

 The jabber id is generated from ~/.sugar/owner.key.
 Removing ~/.sugar/owner.key and ~/.sugar/owner.key.pub generates a new
 key after reboot and the jabber id is reset.

 Dave

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



 --
 Dave Bauer
 d...@solutiongrove.com
 http://www.solutiongrove.com
 ___
 Sugar-devel mailing list
 Sugar-devel@lists.sugarlabs.org
 http://lists.sugarlabs.org/listinfo/sugar-devel




 --
 Caroline Meeks
 Solution Grove
 carol...@solutiongrove.com

 617-500-3488 - Office
 505-213-3268 - Fax

 ___
 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] GPA collaboration Issues - keepalive theory

2009-07-09 Thread Caroline Meeks
The other theory we are working on is that something is not set to long
enough in keepalive

This theory is based on the logs saying that jabber had been disconnected
probably because gabble and died. We are thinking that actually the
hardware/network might just be slow.

Collabora suggested that keepalive might be the problem.

Has anybody put eyeballs on this code? Is there a timeout somewhere that we
could extend?

I am camping this weekend. We will next be at GPA for tesing on Tuesday.

Thanks!
Caroline

-- 
Caroline Meeks
Solution Grove
carol...@solutiongrove.com

617-500-3488 - Office
505-213-3268 - Fax
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] GPA collaboration Issues - owner key theory

2009-07-09 Thread Dave Bauer
I tested this on my eeePC with soas.

First I deleted gconf/gconfd and I got to pick my name and colors, but
my jabber id was the same.

So I removed owner.key(.pub) without gconf and i got a new key and my
jabber id changed.

I think it can't hurt to try it quick on some of the sticks before
they are reburned.

Dave

On Thu, Jul 9, 2009 at 9:56 PM, Walter Benderwalter.ben...@gmail.com wrote:
 Have we experimented with unmodified keys?

 -walter

 On Thu, Jul 9, 2009 at 9:53 PM, Caroline Meeks carol...@meekshome.com
 wrote:

 We will delete  ~/.sugar/owner.key and ~/.sugar/owner.key.pub when we
 reburn the sticks on Monday.

 However, my problem with this theory is that l've been cloning pretty much
 the same Stick from FOSSVT on.  Other places we have multiple people using
 the same stick without this problem.  However, we have mostly be using
 wireless not wired. Woudl that make a difference?

 On Thu, Jul 9, 2009 at 1:55 PM, Dave Bauer dave.ba...@gmail.com wrote:

 On Thu, Jul 9, 2009 at 11:00 AM, Gary C Marting...@garycmartin.com
 wrote:
  Sorry, this was meant to go to the list no just Caroline.
 
  Begin forwarded message:
 
  From: Gary C Martin g...@garycmartin.com
  Date: 9 July 2009 15:54:34 BST
  To: Caroline Meeks carol...@solutiongrove.com
  Subject: Re: [Sugar-devel] SoAS Testing with XS
 
  On 9 Jul 2009, at 15:19, Caroline Meeks wrote:
 
  It was worth a try but I see exactly the same behavior on the media
  lab jabber server.
 
  One thing I think I am noticing. It seems like one machine at a
  time is connected to the Jabber Server.
 
  What happens when a machine connects?
  Is there anyway that one machine connecting could cause another to
  disconnect?
  Are these machines in some way replicating something about them
  when the server things it should be unique?
  Could there be some sort of firewall or a caching service that
  decides its a duplicate and cuts one of them off?
 
  Ohh geeezz... How did you make the sticks? Did you boot one and
  tweak it, then clone that one? There are all sorts of files
  generated when you boot a system that make it unique that would need
  to be very carefully erased to make the stick image was 'fresh'. No
  one has a full list of all these files and their various
  interactions, though I think some have tried.
 

 The jabber id is generated from ~/.sugar/owner.key.
 Removing ~/.sugar/owner.key and ~/.sugar/owner.key.pub generates a new
 key after reboot and the jabber id is reset.

 Dave

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



 --
 Dave Bauer
 d...@solutiongrove.com
 http://www.solutiongrove.com
 ___
 Sugar-devel mailing list
 Sugar-devel@lists.sugarlabs.org
 http://lists.sugarlabs.org/listinfo/sugar-devel



 --
 Caroline Meeks
 Solution Grove
 carol...@solutiongrove.com

 617-500-3488 - Office
 505-213-3268 - Fax

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




 --
 Walter Bender
 Sugar Labs
 http://www.sugarlabs.org





-- 
Dave Bauer
d...@solutiongrove.com
http://www.solutiongrove.com
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] GPA collaboration Issues - keepalive theory

2009-07-09 Thread Martin Langhoff
On Fri, Jul 10, 2009 at 1:59 PM, Caroline
Meekscarol...@solutiongrove.com wrote:
 The other theory we are working on is that something is not set to long
 enough in keepalive

The logs we saw earlier were clearly of a domain vs IP address mismatch.

Did you try the fix that I've suggested (changing the 'jabber server'
setting on the clients to match the expected domain name)? After the
change, did it work?

If things still fail, the logs should look radically different after
that change. Are there new logs?

cheers,


m
-- 
 martin.langh...@gmail.com
 mar...@laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Nobody understands Keep

2009-07-09 Thread Eben Eliason
On Thu, Jul 9, 2009 at 7:55 PM, Eduardo H. Silvahoboprim...@gmail.com wrote:
 2009/7/9 Tomeu Vizoso to...@sugarlabs.org:
 On Thu, Jul 9, 2009 at 12:29, Martin Denglermar...@martindengler.com wrote:
 On Thu, Jul 09, 2009 at 11:22:16AM +0100, Daniel Drake wrote:
 On Thu, 2009-07-09 at 10:45 +0100, Martin Dengler wrote:
  On Thu, Jul 09, 2009 at 09:52:23AM +0100, Daniel Drake wrote:
   Nobody in the world seems to understand the Keep button. People think
   it's for regular saving and you should do it before you close or switch
   away from your activity.
 
  That's not far from the truth, right?  At least in any work-losing or
  surprising way...

 It's far from the truth in that it's not normally what you want to
 do.

 My quoting-foo is bad, so I've caused confusion (in myself, too :)).

 To save your work, simply click the Stop button or change so that
 another activity has focus. If you click Keep, you'll end up with 2
 copies - one from when you clicked Keep, and one from when you clicked
 Stop (or focused on another activity).

 As far as I understand it, Keep is useful for these types of scenarios:
 - you've done a lot of work but now it's time to refactor/reorganize the
 whole thing. However you want to keep a copy of the rough version you
 have now, as insurance or perhaps for reference while you re-mangle
 the work.
 - you've made a template for something, now you want to save that
 template (as a blank template) before starting on a version where you
 fill in the content.

 This is a great explanation -- it should be in the HIG or something.

 But the biggest problem is how do we explain this to users without
 them having to read the HIG (or manual)?

 Should be called Keep a copy?

 +1
 For a while, in the pt_PT translation of Sugar I did, I named the Keep
 button as Keep a copy.

I urge again that keep a copy is not what is intended, in the long
run. Without proper versions, of course, this is effectively how it
behaves. Therefore, it's no surprise many saw it this way. But with
versions, the keep button is actually a keep new version button.
As mentioned before, a new version retains the tree_id, whereas a
true copy does not.

Since versions are on the way, we should make sure to clarify the distinction!

Eben



 Regards,

 Tomeu

 Daniel

 Martin

 ___
 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-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Add ability to record to Speak?

2009-07-09 Thread Caroline Meeks
On Thu, Jul 9, 2009 at 10:50 PM, Muriel de Souza Godoi 
murielgo...@gmail.com wrote:

 Hi all,

 I've been away from Sugar for a long time... but keep reading the mailing
 lists :)

 I will be on vacation until July 20th, but after that  I can face this as a
 new effort to help Sugar

 What about a different approach? Add the speak capability to memorize...

 Can memorize just use the speak library and pronounce the cards?
 What do you think?


Thats an interesting idea too!  Especially if you could have the speak face
on the card doing the talking.  He is so engaging.  I think you want the
capability to not show the print as the idea might well be to recognize the
sounds and match them to the written word.

Thanks!



 Muriel

 2009/7/8 Aleksey Lim alsr...@member.fsf.org

 On Wed, Jul 08, 2009 at 04:55:36PM -0400, Caroline Meeks wrote:
  Hi,
 
  We worked with 3rd going into 4th graders at the GPA in Boston today
 making
  memorize games using social studies terms.  The kids drew pictures and
 added
  them to the memorize game.
 
  The kids are very interested in making the computer talk.   The lab
  computers (this is SoaS not XO) have headsets but do not have
 microphones.
 
  What I'd like to do is let the kids type into Speak, record it, then use
  that recording in their memorize games.
 
  I'm hoping that someone will find this easy and be able to give me a new
  version of Speak by next Weds? :)

 But current Speak version can record sounds and save recorded sounds to
 the journal.

 There could be one issue with setting up record volums(since 0.84 doesnt
 let users control it) but it could be fixed by alsamixer -V capture
 command from Terminal, later SoaS should store these settings between
 boot sessions.

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




 --
 Muriel de Souza Godoi
 Universidade Tecnológica Federal do Paraná




-- 
Caroline Meeks
Solution Grove
carol...@solutiongrove.com

617-500-3488 - Office
505-213-3268 - Fax
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel