from:"david"

nbsp;FWIW.nbsp; I have had a number of high school teacher and university 
instructors ask about using the xo as a language learning appliance.nbsp; The 
two reoccurring themes have been:XO as a portable language lab.Ability to 
develop a language learning activity which could tailor itself to the needs of 
an individual learner.nbsp;thanksdavid 
On  10/28/2008, 20:04, Gary C Martin ([EMAIL PROTECTED]) wrote:On 28 Oct 2008, 
at 23:46, Chris Ball wrote:  sugarGreaterThan Hi, sugarGreaterThan 
sugarGreaterThan I#39;m learning Spanish at the moment, and I wish the XO made 
it easier sugarGreaterThan for me.  I don#39;t have any knowledge of what the 
right way to do either sugarGreaterThan conventional or constructionist 
language learning on computers is; if sugarGreaterThan anyone has much 
experience with either, I#39;d love to hear about it. sugarGreaterThan 
sugarGreaterThan I have some obvious candidates for software that could be 
produced in sugarGreaterThan mind: sugarGreaterThan sugarGreaterThan   * A 
method -- similar to Scott#39;s recent GtkLabel overlay for   sugarGreaterThan 
allowing sugarGreaterThan strings inside Sugar and activities to be 
translated -- that   sugarGreaterThan does a sugarGreaterThan dictionary 
lookup of a word on the screen and overlays the sugarGreaterThan 
translation of that word
into a local language.  This should be sugarGreaterThan activity-agnostic, 
if possible.  For bonus points, translate sugarGreaterThan phrases instead 
of just words. sugarGreaterThan sugarGreaterThan   * Perhaps some kind of 
Pronunciation Activity that gives you words sugarGreaterThan in the target 
language, speaks them to you, explains what they sugarGreaterThan mean in 
your local language, and asks you to speak them back, sugarGreaterThan 
perhaps grading your response?  (All but the last part is already 
sugarGreaterThan possible to do manually in the Words activity, but not in 
a sugarGreaterThan structured way.) sugarGreaterThan sugarGreaterThan   * 
Is there any free content that matches iconic images to words, sugarGreaterThan 
so that language vocabulary could be taught even without textual 
sugarGreaterThan translation to a local language? sugarGreaterThan 
sugarGreaterThan Feel free to come up with questions/ideas around language 
learning on
sugarGreaterThan the XO in general in this thread, and they#39;ll make it into 
the sugarGreaterThan conference talk.  Still being worked on by Urko, but 
functioned quite well last time I   tested on an XO. I set it up with a bunch 
of pathophysiology term   flash card type questions/answers:
http://wiki.laptop.org/go/Assimilate  sugarGreaterThan Thanks, sugarGreaterThan 
sugarGreaterThan - Chris. sugarGreaterThan --  sugarGreaterThan Chris Ball
sugarGreaterThan ___ 
sugarGreaterThan Sugar mailing list sugarGreaterThan Sugar@lists.laptop.org 
sugarGreaterThan http://lists.laptop.org/listinfo/sugar  
___ Devel mailing list [EMAIL 
PROTECTED] http://lists.laptop.org/listinfo/devel
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

[sugar] Benefits of creating activities

Walter posed a question on how to communicate the benefits of developing
activities for Sugar in his last Sugar digest.  One approach is to look at
the philanthropic aspects of OLPC and SL for potential developers.

The primary goal of any non-profit is to accomplish the organization's
mission as stated in the mission statement.  The secondary goal is to engage
donors to share their time, talent, and money with the non-profit to help
accomplish the mission.

Step one: Communicate the organization's mission, vision, and values.  For
Sugar Labs, I see our mission as creating a good standard learning platform
around which individuals, organizations, and companies build educational
products.  Vision; students everywhere have access to Sugar.  A large part
of that vision depends on our ability to improve the technology and image of
Sugar to the point that Sugar is viewed as an asset to potential deployments
of OLPC.  Values; Provide a platform that will alway remain Free and Open.

Step two: Share mission, vision, and values. After communicating our MVV we
need to find ways in which our MVV coincides with a potential contributors
MMV.  Here the focus is not on having the donor give _to_ Sugar Labs.
Rather, it is to show how a donor can accomplish their personal goals
_through_ Sugar Labs.

Step two:  Show impact.  After communicating our MVV, we need to show a
potential contributor how they can use their time, talent, and money to have
a direct impact on accomplishing their personal goals through Sugar Labs.

thanks
david
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] Postponement of XOCamp Event to January

On Thu, Oct 30, 2008 at 12:44 PM, Tomeu Vizoso [EMAIL PROTECTED]wrote:

 On Thu, Oct 30, 2008 at 6:06 PM, C. Scott Ananian [EMAIL PROTECTED]
 wrote:
  On Wed, Oct 29, 2008 at 9:52 PM, Ed McNierney [EMAIL PROTECTED] wrote:
  The OLPC XOCamp event being planned for November 17 – 21 is being
 postponed
  until January, 2009.  The Fedora FUDCON conference is in Boston on
 January 9
 
  As should be clear, I'm not happy at all with how this is being handled.
 
  We will have Martin, Marco, Tomeu, and Bernie here the week of the
  17th (at least).  We should at least informally discuss 9.1 plans at
  that time.

 From my point of view, the situation is not so messed up as it could
 be seen from inside.


Scott, I agree that from the outside, things don't appear as messed up as
you might feel.  One of our goals in attracting outside developers to Sugar
is predictability through planning.

Open source development can be chaotic at the best of time.  We can reduce
some of that chaos by 'planning the work, and, working the plan.' and then
doing it again.  We want to reduce as many decisions as possible to
policies, but no more.

My concern with the XOcamp was the speed with which it was being put
together.  Rather than being a long term planning tool, holding the XOcamp
was becoming a fire which needed to be extinguished.

The XOCamp has been delayed, but this doesn't mean we need to stop any
 work. Stuff that is going to be worked on in the near future can still
 be discussed as we have been doing to date. I personally am not fully
 convinced of the XOCamp idea, but Scott is a smart guy and, as I still
 haven't attended properly to one, am happy to give him the benefit of
 the doubt.


I also support the idea that Scott is a bright guy.  For some time I have
been trying to figure out how to engage him more effectively in upstream
sugar development:)

Some people from outside have decided to visit Boston for some days,
 is their trip not useful because the XOCamp has been delayed? I don't
 think so at all! We have been working together for a long time and
 these have been exciting times. We surely have lots to talk, share,
 discuss, etc

 I'm confident that when the remotes come back to their homes, the work
 atmosphere will have improved significantly and this will reflect in
 our productivity.

 So, plans have changed, but are things really so bad?

 Regards,

 Tomeu
 ___
 Devel mailing list
 [EMAIL PROTECTED]
 http://lists.laptop.org/listinfo/devel

___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] Data Storage and User-facing System Requirements [was Re: 9.1 Proposal: Files]

2008-10-30 Thread david

On Thu, 30 Oct 2008, Benjamin M. Schwartz wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Erik Garrison wrote:
 It seems from my reading of mailing lists, IRC logs, and listening to
 conversations with people that we are trying to resolve all of these
 issues by implementing more code to get around difficulties imposed by
 our current data storage implementation and security model.

 My argument is that we can do less work and get an improved result from
 the user's perspective by removing the layers of code (datastore and
 security restrictions) which prevent applications from behaving as they
 normally do on other systems.

 Erik:  If you want applications to behave as they do on other systems,
 then why not just use an other system?

if Sugar is only the Journal then I would definantly say to not ship Sugar 
until it's ready, and even then I would question it's value.

however Sugar is a lot more than just the Journal.

The problem is the attitude that some people seem to have that becouse 
Sugar is new and innovative, all existing software should be re-written to 
use all the new Sugar goodies.

this means that until Sugar is complete and re-implements all the worlds 
software, there will be a significant number of people who cannot use it 
becouse it can't run something that they need

for a system that's running Linux on a x86 cpu, the fact that it can't use 
the vast majority of the software available today (including the 
opensource software) is embarrasing. but beyond that, it limits how 
effective the OLPC can be by limiting the users (and as a side effect, 
limiting developers)

it's time for everyone to give up the dream that Sugar will be the biggest 
OS in the world and everyone will adapt to it. (some people have 
acknowledged this publicly, most have accepted it privatly, but some 
people still seem to think that they can force the rest of the world to 
adapt to Sugar)



Switching from 'the Journal is the main API, and we will implement some 
other mechansims to simulate a filesystem' to 'provide a POSIX filesystem 
and make the Journal be a view to that filesystem' would change the 
Journal from a liability to an asset.

it would eliminate one of the biggest barriers for existing software (the 
window manager stuff would just about cover the remainder), and with the 
Journal being optional it can be used where it makes sense, and bypassed 
where it doesn't make sense (or where it's not ready yet)

note that the POSIX filesystem does NOT mean that the user needs to 
directly access the filesystem on the nand, it could be that the file 
access is done through FUSE so that additional metadata can be stored 
along with the file. they key is that it needs to be transparent to the 
software so that existing software doesn't need to change.

David Lang
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] October 29 - Tarballs due for 0.83.1

On Wed, Oct 29, 2008 at 9:20 AM, Tomeu Vizoso [EMAIL PROTECTED] wrote:

 On Wed, Oct 29, 2008 at 2:52 PM, Benjamin M. Schwartz
 [EMAIL PROTECTED] wrote:
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA1
 
  Tomeu Vizoso wrote:
  I have stopped work on the DS and Journal because OLPC is apparently
  funding the development of a replacement for them
 
  Really?

 Well, it's at least apparent because both Scott and Erik have
 mentioned in public that they are working on their own replacements.
 OLPC management hasn't told me to stop working on the journal, but I
 don't see how I could keep working on it without risking to lose even
 more of my time. I asked Scott if he could say by Nov 17 if he thought
 that he would be able to ship his journal in 0.84 and he seemed to
 agree.

 I didn't got a single comment from OLPC engineers when I asked them
 about my DS replacement, so I guess it wasn't considered a worth
 possibility by them.

  We could easily hack the DS in 0.83 to return D-Bus strings for
  standard properties that are known (or rather, expected) to contain
  textual data, but introducing this inconsistency in the API may not be
  such a good idea.
 
  OK. What happens to Journal entries with non-Ascii titles?

 D-Bus strings are UTF-8 encoded, so that wouldn't be a problem.

 Regards,

 Ben,

Would you be willing to continue your work on the data store in closer
collaboration with Sugar Labs?

A few day ago there was a emotional appeal from OLPC about how to 'build
trust with the community.'  It would seem to me that communicating clearly
with outside developers would be the first step in building  trust.

thanks
david
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] USB Based Community Access - What could work technically?

*Clinic next door to a School* - A health clinic located right next door
Sasha's school has a close partnership with the school. Many students are
scene there so they decided to add a donated computer to their waiting room
just for kids to use Sugar. This computer still has its hard-drive, but its
dedicated for Sugar. Some of the basic sugar files are located on the hard
drive and it is set up to allow students to log out rather then shutting
down and restarting between each student.

This is an very interesting idea. A hybrid harddrive usb solutions. From a
technology perspective it would not be that hard to implement. When the
computer boots from the hard drive it waits at a login prompt for the user
to either login or insert a USB with the users /home directory. The current
generation of linux distribution has excellent support for DBUS to
communicate the status of hot swapped devices such as USBs.

A big advantage of this method would be to take advantage of the hard-drives
speed while storing user data on the USB. Furthermore, the users login
criteria would be stored on the USB. This would allow passwordless login.

The main concern that I have heard about storing user data on a USB is that
kids will lose them. Kids can be trusted not to lose their textbooks and
folders. Why not reverse the trend of shrinking USBs and make textbook
sized USBs for kids:) We make big pencils and big crayon for younger
students. Why not big USBs?
*
**The Zoo*:

This seems very similar to the clinic.
*
**YMCA*: After school and on snow days and vacations Sasha goes to the local
YMCA. There is a bank of 10 computers for kids to use. They are thin clients
run from one server. There is a USB port, and the user experience is just
like booting on a stand alone computer, except because it doesn't really
have to fully boot for each student switching users is much faster.

The difficulty here seems to be defining what is a thin client. One
interesting approach is the one taken in the
Extremadurahttp://www.hotcosta.com/Extremadura.Spain
* *region in spain. Several years ago they start putting computers on the
desks of all of the students in the region. Now, as the computers are
becoming outdated (the students have faster computers at home) they are
adding high powered servers to schools. By configuring the existing laptops
and desktops as clients for the new servers, they are able to extend usefull
life of the existing equipment by several years.

For this to become possiable with Sugar we will need to engage the LTSP
developers.*

At School*: Due to the E-Rate program Sasha's school and all the schools in
tow are well connected so the schools system decided to take advantage of
the economies of scale and hosts a large server centrally. In each classroom
there are thin clients and a USB port. The user experience is exactly the
same as at the YMCA, but in this case the server is located several miles
away.

A current preference for US schools seems to be using E-Rate to finance a
client server system where student can log into their virtual desktop from
anywhere that has Internet access.

This thinking seems to stem from the belief within the current generation of
school sysadmins that only they can be trusted with a student's data. A
second reason is that schools tend to integrate students systems to closely
with teachers administrative systems. As a result many districts are
putting a tremendous emphasis on backing up students data.

Client Server systems allow sysadmins to backup a student's data to school
or district level SAN. It has been awhile since I have gone to school, but
I can't remember anyone photo copying my notebooks so that I would have a
'backup' if I lost my original. On the contrary, I remember losing point
for losing my homework. It was called learning responsibility.

This belief also seems to stem from the quirk of human nature that if we pay
a consultant to install an expensive system, we tend to be happier then if
we install an inexpensive system our selves:(

On Wed, Oct 22, 2008 at 11:54 AM, Caroline Meeks [EMAIL PROTECTED]
wrote:

Hi,

This is a request for technical assistance for Sugar on a Stick.

It looks like we have a pilot school for our USB boot project, and a grant
proposal in so I am trying to think through various use cases around
creating ubiquitous access with a USB storage device. I've written up some
use cases here:

http://www.sugarlabs.org/go/DeploymentTeam/School_Key#Vision_of_different_ways_the_USB_might_work_in_the_students_environment

I'd love thoughts on what is feasible, how hard, and how much benefit would
each scenario actually provide.

I've done tests to show that Home and Grandma's are feasible. I'm
curious as to whether putting some of the boot files on the hard drive (Zoo)
could reduce boot time or have any other advanatages as most of our donated
computers will likely have working disk drives. I wonder if combining with
a LTSP or

Re: [sugar] USB Based Community Access - What could work technically?

My thought is that it provides a low cost initial entry point for
introducing Sugar.

I am under the impression that personal student notebooks will be the long
term solution.  In the mean time we should do whatever is necessary to make
Sugar available given the existing technological and purchasing environment.

One of the main reasons for moodle's success is the extremely low barrier to
entry.  In terms of student infrastructure all that is needed is a web
browser.  At the IT department level, all that is required is a moodle
server.  The servers can be purchased as a server in a box or an off site
service from several moodle partners for 10s of dollars per month.

Many moodle installations started in a single classroom that was lead by a
early adopter teacher.  The installations spread by other teachers seeing
the usefullness of moodle and students requesting moodle in their other
classes.

Sugar Labs can mimic this approach by creating an USB stick which converts
existing students computers, at no perment risk, to Sugar.  Sugar partners
can provide server hosting either on or off site.

thanks
david

On Thu, Oct 30, 2008 at 5:46 PM, Walter Bender [EMAIL PROTECTED]wrote:

 What is the current recommendation for a LiveUSB image?

 -walter

 On Thu, Oct 30, 2008 at 6:42 PM, David Farning [EMAIL PROTECTED]
 wrote:
  Clinic next door to a School - A health clinic located right next door
  Sasha's school has a close partnership with the school. Many students are
  scene there so they decided to add a donated computer to their waiting
 room
  just for kids to use Sugar. This computer still has its hard-drive, but
 its
  dedicated for Sugar. Some of the basic sugar files are located on the
 hard
  drive and it is set up to allow students to log out rather then shutting
  down and restarting between each student.
 
  This is an very interesting idea. A hybrid harddrive usb solutions.  From
 a
  technology perspective it would not be that hard to implement.  When the
  computer boots from the hard drive it waits at a login prompt for the
 user
  to either login or insert a USB with the users /home directory.  The
 current
  generation of linux distribution has excellent support for DBUS to
  communicate the status of hot swapped devices such as USBs.
 
  A big advantage of this method would be to take advantage of the
 hard-drives
  speed while storing user data on the USB.  Furthermore, the users login
  criteria would be stored on the USB.  This would allow passwordless
 login.
 
  The main concern that I have heard about storing user data on a USB is
 that
  kids will lose them.  Kids can be trusted not to lose their textbooks and
  folders.  Why not reverse the trend of shrinking USBs and make textbook
  sized USBs for kids:)  We make big pencils and big crayon for younger
  students. Why not big USBs?
 
  The Zoo: 
 
  This seems very similar to the clinic.
 
  YMCA: After school and on snow days and vacations Sasha goes to the local
  YMCA. There is a bank of 10 computers for kids to use. They are thin
 clients
  run from one server. There is a USB port, and the user experience is just
  like booting on a stand alone computer, except because it doesn't really
  have to fully boot for each student switching users is much faster.
 
  The difficulty here seems to be defining what is a thin client.  One
  interesting approach is the one taken in the Extremadura region in spain.
  Several years ago they start putting computers on the desks of all of the
  students in the region. Now, as the computers are becoming outdated (the
  students have faster computers at home) they are adding high powered
 servers
  to schools.  By configuring the existing laptops and desktops as clients
 for
  the new servers, they are able to extend usefull life of the existing
  equipment by several years.
 
  For this to become possiable with Sugar we will need to engage the LTSP
  developers.
 
 
  At School: Due to the E-Rate program Sasha's school and all the schools
 in
  tow are well connected so the schools system decided to take advantage of
  the economies of scale and hosts a large server centrally. In each
 classroom
  there are thin clients and a USB port. The user experience is exactly the
  same as at the YMCA, but in this case the server is located several miles
  away.
 
  A current preference for US schools seems to be using E-Rate to finance a
  client server system where student can log into their virtual desktop
 from
  anywhere that has Internet access.
 
  This thinking seems to stem from the belief within the current generation
 of
  school sysadmins that only they can be trusted with a student's data.  A
  second reason is that schools tend to integrate students systems to
 closely
  with teachers administrative systems.  As a result many districts are
  putting a tremendous emphasis on backing up students data.
 
  Client Server systems allow sysadmins to backup a student's data to
 school
  or district

Re: [sugar] USB Based Community Access - What could work technically?

On Thu, Oct 30, 2008 at 6:03 PM, Caroline Meeks
[EMAIL PROTECTED]wrote:



 On Thu, Oct 30, 2008 at 6:42 PM, David Farning [EMAIL PROTECTED]wrote:

 *Clinic next door to a School* - A health clinic located right next door
 Sasha's school has a close partnership with the school. Many students are
 scene there so they decided to add a donated computer to their waiting room
 just for kids to use Sugar. This computer still has its hard-drive, but its
 dedicated for Sugar. Some of the basic sugar files are located on the hard
 drive and it is set up to allow students to log out rather then shutting
 down and restarting between each student.

 This is an very interesting idea. A hybrid harddrive usb solutions.  From
 a technology perspective it would not be that hard to implement.  When the
 computer boots from the hard drive it waits at a login prompt for the user
 to either login or insert a USB with the users /home directory.  The current
 generation of linux distribution has excellent support for DBUS to
 communicate the status of hot swapped devices such as USBs.

 A big advantage of this method would be to take advantage of the
 hard-drives speed while storing user data on the USB.  Furthermore, the
 users login criteria would be stored on the USB.  This would allow
 passwordless login.

 The main concern that I have heard about storing user data on a USB is
 that kids will lose them.  Kids can be trusted not to lose their textbooks
 and folders.  Why not reverse the trend of shrinking USBs and make textbook
 sized USBs for kids:)  We make big pencils and big crayon for younger
 students. Why not big USBs?


 Yes I think loss will be an issue.

 Big is definitely an interesting idea. I also like the braclet USBs -
 http://www.ipromo.com/?fuseaction=product.productsid=106
 Mostly we have to make it cheap enough, and making replacing them easy
 enough that its not that big a deal if they are lost.


Yes, the ability to recreate a lost USB is important.  Modifying the
existing server backup mechanism to allow teachers to reflash a USB should
be relatively straight forward.



 *
 **The Zoo*: 

 This seems very similar to the clinic.


 Interestingly when I discussed this with Marco the Zoo is hard use case.
 Everywhere else we can assume the kids are all attending the same school
 district, thus we can assume they are all running the same version of
 Sugar.  For the Zoo we might have kids from different towns all coming with
 Sugar USBs but different versions.  This might be harder to support.
 However, this is a problem I would love to have!  Not very close to our
 current reality, so we don't need to focus on it. So basically, for right
 now its similar to the clinic.


 *
 **YMCA*: After school and on snow days and vacations Sasha goes to the
 local YMCA. There is a bank of 10 computers for kids to use. They are thin
 clients run from one server. There is a USB port, and the user experience is
 just like booting on a stand alone computer, except because it doesn't
 really have to fully boot for each student switching users is much faster.

 The difficulty here seems to be defining what is a thin client.  One
 interesting approach is the one taken in the 
 Extremadurahttp://www.hotcosta.com/Extremadura.Spain
 * *region in spain.  Several years ago they start putting computers on
 the desks of all of the students in the region. Now, as the computers are
 becoming outdated (the students have faster computers at home) they are
 adding high powered servers to schools.  By configuring the existing laptops
 and desktops as clients for the new servers, they are able to extend usefull
 life of the existing equipment by several years.

 For this to become possiable with Sugar we will need to engage the LTSP
 developers.**


 Yes, I emailed Eric Harrison and he believed it was possible.  But yes, we
 need someone very familiar with LTSP to do this.

 *


 At School*: Due to the E-Rate program Sasha's school and all the schools
 in town are well connected so the schools system decided to take advantage
 of the economies of scale and hosts a large server centrally. In each
 classroom there are thin clients and a USB port. The user experience is
 exactly the same as at the YMCA, but in this case the server is located
 several miles away.

 A current preference for US schools seems to be using E-Rate to finance a
 client server system where student can log into their virtual desktop from
 anywhere that has Internet access.

 This thinking seems to stem from the belief within the current generation
 of school sysadmins that only they can be trusted with a student's data.  A
 second reason is that schools tend to integrate students systems to closely
 with teachers administrative systems.  As a result many districts are
 putting a tremendous emphasis on backing up students data.

 Client Server systems allow sysadmins to backup a student's data to school
 or district level SAN.  It has been awhile since I have gone

[sugar] Sugar on Ubuntu LiveUSB is ready

It looks like our friends at Ubuntu have been hard at work building a
Subuntu live usb.  Simon Peter, also know as probono, has posted information
on downloading and building the usb at

http://dev.laptop.org/~probono/sbuntu/

Thanks to the Ubuntu SugarTeam for packaging Sugar on Ubuntu and to Probono
for building the sugar.squashfs.

David
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] 9.1 Proposal: Files

2008-10-29 Thread david

On Wed, 29 Oct 2008, Bill Bogstad wrote:

 On Wed, Oct 29, 2008 at 1:21 AM, Benjamin M. Schwartz
 [EMAIL PROTECTED] wrote:

 2) Data access and user-perceived reliability:

 Problem: Users can't find things because they're not providing enough
 metadata for search to work, and there's too much stuff for them to find
 it without search.

 ...
  - Reduce the number of unwanted objects that accumulate
   - by providing a draft mode option that does not produce any object
 - but still produces a listing in a separate Actions view (see
 http://wiki.laptop.org/go/Designs/Journal)
   - by resuming previous instances by default, so as to encourage
 continued work on existing objects

 Alternative proposal to encourage Journal use:

 When the system boots, start in the Activity view with the Journal;
 not in the Home view. Pre-populate Journal with entries for the
 recently written help manual and selected (3 or 4) entries for the
 most commonly used/popular activities.  This would emphasize the
 importance of the Journal in tying the whole system together.  By
 putting the help manual at the top, I believe the discoverability of
 many features/activities would be greatly increased.

the fact that they will quickly disappear off the screen, and may be 
auto-deleted by the system greatly limits their value.

David Lang

 Note: the pre-populated Journal entries would be no different then any
 other entry.  If the user doesn't want them anymore, they can delete
 them without any other consequence.  This is much like the initial
 mail messages that some mail clients use to demonstrate features to
 new users.

 Bill Bogstad
 ___
 Devel mailing list
 [EMAIL PROTECTED]
 http://lists.laptop.org/listinfo/devel

___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] Greetings from New Hampsire

2008-10-25 Thread David Van Assche

Hi Brendan,

If you are using LTSP as your thin client technology, the majority of
your issues have already been taken care of. These include:
- collaboration via ejabberd.
- home folders stored on server so backups are just a server side
script (rsync.)
- activities can be installed through browse in the regular way (only
an admin can do that) and can be added removed as you wish, thereby
populating the program list. Unless u mean individual programs for
different users, in which case you'd probably need to virtualise sugar
somehow or create custom chroots for it.
- file server is not needed since you are in effect already storing
everything on the server.
- mounting local media (this is part of the underlying LTSP technology
and has been available to all LTSP distributions for several years
now. That means, usb, cdrom, hard drive, local printer, bluetooth, and
sound are all working for all LTSPed distros, including for sugar.

These issues are relatively straight forward to fix:
- printing should be an easy task to tackle, and just requires a
connection to cupsys (this is really up to the programs to support
this.)
- logout instead of exit (apart from the design change of the button)
- one simply needs to replicate the action of alt+cntrl+backspace
which exits the client with no hanging processes.
- Running just some sugar apps, or just one sugar app and not the
whole thing seems a little like a waste of time since its very fast
loading up and you need the underlying core anyway. I see no
significant gains by launching just one app on top of sugar instead of
all of it. However... you can do this with local apps, which is a
plugin for LTSP that allows you to install whichever program you like
directly into the thin client cpu and ram space, so it doesn't burden
the server (useful for heavy apps like firefox+flash, video editting,
blender, etc.

From what I can see, LTSP already does almost all of what you are
wanting it to do, unless you use some other thin client technology.

Kind Regards,
David Van Assche
www.nubae.com



On Sat, Oct 25, 2008 at 3:30 AM, David Farning [EMAIL PROTECTED] wrote:


 On Thu, Oct 23, 2008 at 3:25 PM, Brendan R. Powers [EMAIL PROTECTED]
 wrote:

 Greetings,

 Hey Brendan,
 Welcome to the list!

 Our company and developers are interested in getting involved with the
 development community for Sugar. We deploy Linux desktop solutions in
 schools in the United States via thin client and fat client methods. We
 believe that Sugar's collaboration tools, journal,  and other features could
 be very appealing to younger grade (elementary and middle school) students
 and teachers. Several of our schools are interested in using Sugar in the
 classrooms already on their thin client desktops.

 Very cool, we are interested in making Sugar available to a wider audience!


 We have the Ubuntu packages running fine, but it is evident that there are
 changes that should be made to Sugar when its not being used on the OLPC.
 Some of the challenges for deploying Sugar on desktops in a school
 environment are different than using it on standalone OLPCs, which need to
 be overcome for Sugar to take a major foothold independent of the OLPC.
 Below we have listed some of the issues we think need to be addressed based
 on our experience with working in schools.


 What would be your preferred work flow? One thought would be set up a
 client/server git tree for client/server development.  Then, the work you,
 and others do, can be pulled into the main tree.  In the near future,
 SugarLabs will be hosting a git server. Either we can host a C/S tree or you
 can host it yourself.

 Do you use LTSP as the basis for your client server technology?


 The technical challenges we see are mostly problems integrating sugar into
 a thin client architecture, and into the networks of schools. One of the
 most immediate changes we will need to make are customizations to the
 interface. For example, thin clients may not need the shutdown and reboot
 options, and need a logout option. There are other customizations that we
 may need to make, such as adding or removing items from the control panel.
 These sorts of changes are small, and once done will allow people to deploy
 sugar in a small classroom environment.

 On larger installations, schools will want sugar to integrate with there
 existing file and print servers, as well as some centralized administration
 of the sugar interface. Ideally, the journal and datastore would be stored
 on the file server in such a way as to allow teachers to access the saved
 activities from a normal Windows or Linux computer. It would be interesting
 to see if we could launch sugar activities without running the entire sugar
 interface. Also, local media attached to thin client may pose a challenge,
 as the normal ways to search for and mount media are not available.

 Another important aspect of larger sugar deployments would be the ability
 of admins to customize the user

Re: [sugar] Greetings from New Hampsire

2008-10-24 Thread David Farning

On Thu, Oct 23, 2008 at 3:25 PM, Brendan R. Powers [EMAIL PROTECTED]wrote:

 Greetings,


Hey Brendan,
Welcome to the list!


 Our company and developers are interested in getting involved with the
 development community for Sugar. We deploy Linux desktop solutions in
 schools in the United States via thin client and fat client methods. We
 believe that Sugar's collaboration tools, journal,  and other features could
 be very appealing to younger grade (elementary and middle school) students
 and teachers. Several of our schools are interested in using Sugar in the
 classrooms already on their thin client desktops.


Very cool, we are interested in making Sugar available to a wider audience!




 We have the Ubuntu packages running fine, but it is evident that there are
 changes that should be made to Sugar when its not being used on the OLPC.
 Some of the challenges for deploying Sugar on desktops in a school
 environment are different than using it on standalone OLPCs, which need to
 be overcome for Sugar to take a major foothold independent of the OLPC.
 Below we have listed some of the issues we think need to be addressed based
 on our experience with working in schools.



What would be your preferred work flow? One thought would be set up a
client/server git tree for client/server development.  Then, the work you,
and others do, can be pulled into the main tree.  In the near future,
SugarLabs will be hosting a git server. Either we can host a C/S tree or you
can host it yourself.

Do you use LTSP as the basis for your client server technology?


 The technical challenges we see are mostly problems integrating sugar into
 a thin client architecture, and into the networks of schools. One of the
 most immediate changes we will need to make are customizations to the
 interface. For example, thin clients may not need the shutdown and reboot
 options, and need a logout option. There are other customizations that we
 may need to make, such as adding or removing items from the control panel.
 These sorts of changes are small, and once done will allow people to deploy
 sugar in a small classroom environment.

 On larger installations, schools will want sugar to integrate with there
 existing file and print servers, as well as some centralized administration
 of the sugar interface. Ideally, the journal and datastore would be stored
 on the file server in such a way as to allow teachers to access the saved
 activities from a normal Windows or Linux computer. It would be interesting
 to see if we could launch sugar activities without running the entire sugar
 interface. Also, local media attached to thin client may pose a challenge,
 as the normal ways to search for and mount media are not available.

 Another important aspect of larger sugar deployments would be the ability
 of admins to customize the user interface. For example they may not want
 users to have access to the control panel, or may want to set up the list of
 activities per grade, and prevent users from installing there own
 activities.

 One of the most interesting aspects of sugar is its collaboration features,
 but this too poses some difficulties. In multi classroom environments its
 not clear how the collaboration would work. Ideally there would be one
 jabber server for the entire network. This would mean that every student on
 the network could see every other student on the network, when the desired
 behavior may be to only see the students in the current class.


Using the Jabber server in a non-xs environment is a issue on which we are
only just now starting to focus.  We have a lot of work to do.


 These are some of the issues were thinking about. We could solve most of
 these problem by creating our own custom build of sugar with the patches
 needed to integrate with our current software. However, we would rather work
 with the community to create solutions to the problems. For example, one of
 the things we would like to do is to extend the profile class to allow for
 multiple back ends, as well as the ability to store generic settings. This
 would allow us to integrate some of the important profile settings, such as
 the jabber server, into our management software, while at the same time
 keeping a consistent API and keeping our code separate from the sugar tree.


Thanks for you willingness to work with us!  By Monday, Marco our lead
developer will be able to answer you questions in more detail.

thanks
david


 We are very excited about the possibilities that sugar provides. We look
 forward to contributing to this project, and we are interested in your
 thoughts about these issues.



 ---
 Brendan Powers
 Resara LLC

 1.888.357.9195
 www.resara.com

 ___
 Sugar mailing list
 Sugar@lists.laptop.org
 http://lists.laptop.org/listinfo/sugar

___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] 9.1 Proposal: Printing support

2008-10-21 Thread david

On Tue, 21 Oct 2008, Martin Langhoff wrote:

 On Sat, Oct 18, 2008 at 9:24 AM, C. Scott Ananian [EMAIL PROTECTED] wrote:
 *But*, we should be able to:
*  Print postscript (or pdf, or whatever, just pick *one*) to
 school server via CUP (IPP?), and install a decent selection of
 printer drivers on the school server. Control panel for 'default
 printer name', fixed to 'XS' by default.

 Ok - adding the XS side of this is something we can do in the 9.1 lifecycle.

 As I mentioned in my other email, the mechanical part of getting
 printing done is not the most interesting part of the job. It's the
 social issues around it -- handling of quotas, priorities, etc that I
 think deserve most attention. Paper, ink and printer time are
 extremely valuable.

printer selection needs to happen on the client, but all the other things 
that you list are server-side issues, aren't they?

David Lang

___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

[sugar] Sugar, collaboration and LTSP on Ubuntu

2008-10-17 Thread David Van Assche

Hi there,
  with the generous help from #sugar devs I managed to get ltsp, sugar
and collaboration via ejabberd working on Ubuntu. This is really
exciting as it means walking into an existing networked lab with a
laptop, connecting it to the LAN, firing up sugar and letting all the
terminals enjoy the sugar experience with no installation necessary on
the cliens. The steps mentioned can be easily replicated on other
distros using the distro specific package manager. Here is a howto I
wrote:

http://www.nubae.com/sugar-on-ltsp-ubuntu-intrepid-ibex

Kind Regards,
David Van Assche
www.nubae.com
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] [K12OSN] Sugar, collaboration and LTSP on Ubuntu

2008-10-17 Thread David Farning

Great Work David!
How long do you think it will take to push modified ejabber .debs through the 
Ubuntu packaging process?
thanks
David 
 

On  10/17/2008, 11:10, David Van Assche ([EMAIL PROTECTED]) wrote:Hi there,   
with the generous help from #sugar devs I managed to get ltsp, sugar and 
collaboration via ejabberd working on Ubuntu. This is really exciting as it 
means walking into an existing networked lab with a laptop, connecting it to 
the LAN, firing up sugar and letting all the terminals enjoy the sugar 
experience with no installation necessary on the cliens. The steps mentioned 
can be easily replicated on other distros using the distro specific package 
manager. Here is a howto I wrote:  
http://www.nubae.com/sugar-on-ltsp-ubuntu-intrepid-ibex  Kind Regards, David 
Van Assche www.nubae.com  ___ 
K12OSN mailing list [EMAIL PROTECTED] 
https://www.redhat.com/mailman/listinfo/k12osn For more info see /www.k12os.org


___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] code contributions to Sugar (was Re: Sugar Clock)

2008-10-15 Thread David Farning

A good first towards solving this challenge is developing a project level self 
awareness of the different types of decisions we make.
1. Pedagogical 
2. Technical
3. Political
 
As a general rule we should strive to make decisions base on their pedagogical 
soundness, technical merit, and political expediency; In that order.  I am not 
sure how to implement this. Maybe they should be stated project values?
thanks
david 

On  10/15/2008, 03:30, Tomeu Vizoso ([EMAIL PROTECTED]) wrote:On Tue, Oct 14, 
2008 at 9:27 PM, Benjamin M. Schwartz  wrote:   P.S. I think this is a good 
example of why contributing to Sugar is  necessarily hard.  Many small 
technical contributions from the community  require significant policy 
decisions by the leaders.  When Sugar's  subsystems are as mature and 
rationalized as the kernel's, then perhaps we  will be able to add small 
components without needing big decisions, but  that point is still years away. 
 Anybody has ideas about how we could improve this? One thing that may help is 
the recent refactoring that Marco made in the shell. Adding a clock widget to 
the frame is now a matter of dropping a .py file in the extensions/deviceicon 
directory. What else needs to happen?  Regards,  Tomeu 
___ Sugar mailing list 
Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar


___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] Give a Laptop, Change the World : G1G1 2008

2008-10-08 Thread David Farning

This is also a Sugar Labs branding issue.  Sugar Learning Platform does a
better job of conveying we are not a stand alone solution.  We are a common
point of collaboration on which educators and developers build solutions for
their own unique classrooms and situations.

thanks
david

On Wed, Oct 8, 2008 at 10:57 AM, Tomeu Vizoso [EMAIL PROTECTED] wrote:

 On Wed, Oct 8, 2008 at 5:52 PM, Eben Eliason [EMAIL PROTECTED]
 wrote:
  On Wed, Oct 8, 2008 at 7:58 AM, Walter Bender [EMAIL PROTECTED]
 wrote:
  I prefer the Sugar learning platform
 
  +1 from me as well.  (I'm torn on platform vs. environment; the
  latter actually sounds a little friendlier, to me.)

 I guess in platform Sugar would be supporting learning, where in
 environment Sugar would be where learning happens. I would vote for
 platform, as the learning really happens inside the user.

 Regards,

 Tomeu


  - Eben
 
  -walter
 
  On Wed, Oct 8, 2008 at 4:35 AM, Tomeu Vizoso [EMAIL PROTECTED]
 wrote:
  On Tue, Oct 7, 2008 at 11:49 PM, Samuel Klein [EMAIL PROTECTED] wrote:
 
  The laptops feature the latest release of the Sugar window manager,
 ...
 
  I think we should be able to find a better term than window manager,
  Matchbox is the window manager used in 8.2 and it hasn't been modified
  by OLPC. Some suggestions:
 
  - learning environment,
  - collaborative user interface,
 
  etc
 
  Regards,
 
  Tomeu
  ___
  Sugar mailing list
  Sugar@lists.laptop.org
  http://lists.laptop.org/listinfo/sugar
 
 
 
 
  --
  Walter Bender
  Sugar Labs
  http://www.sugarlabs.org
  ___
  Devel mailing list
  [EMAIL PROTECTED]
  http://lists.laptop.org/listinfo/devel
 
 
 ___
 Devel mailing list
 [EMAIL PROTECTED]
 http://lists.laptop.org/listinfo/devel

___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

[sugar] Sugar on Mandriva

2008-09-29 Thread David Farning

Does anyone on the list have contacts at Mandriva.  I'll start the process
of pushing Sugar through Mandriva.  I have very little experience with the
Mandriva community.

thanks
david
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

[sugar] pydocweb regression fixed

2008-09-25 Thread David Farning

The regression in pydocweb is fixed.  I will go through the list of
docstrings requiring review.

Morgs, thanks for all the work on the network strings!

thanks
david
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] Now YOU can write API documentation

2008-09-24 Thread David Farning

On Wed, 2008-09-24 at 13:55 +0200, Morgan Collett wrote:
  thanks
  david
 
 I've started on sugar.network as I went through that code recently.
 
 Here's an issue with pydocweb:
 http://sugarlabs1.xen.prgmr.com/pydocweb/doc/sugar.network.GlibTCPServer/
 doesn't show the name of a method starting with _ - _handle_accept. I
 knew it existed, so I manually edited the URL to
 get to 
 http://sugarlabs1.xen.prgmr.com/pydocweb/doc/sugar.network.GlibTCPServer._handle_accept/
 which I edited.
 
 Bug? Feature?
 

It is a feature.  Pydocweb is set to not publish private methods and
classes.  The idea is to create the documentation that is most
appreciated by application developers.  Should we change this?

As of yesterday, we hit a regression where some of the public methods
are not being imported correctly.  We are working on the issue.
http://api.sugarlabs.org/ is importing all of the functions correctly I
believe. 


thanks
david


___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] apis at 4%

On Mon, 2008-09-22 at 10:15 +0200, Marco Pesenti Gritti wrote:

  Yes, pydocweb uses merge from GNUs RCS to handle changes between the
  docstrings in the pydocweb database and the source code.  Whatever merge
  can not figure out, is flagged for editor attention.
 
 I will commit it, let me know if it causes any problem.
 
The changes you made to the git tree have propagated back to pydocweb.
They have been flagged for merging at
http://sugarlabs1.xen.prgmr.com/pydocweb/merge/ .

Until I feel comfortable that pydocweb is working correctly, it is
re-syncing from dev.laptop.org every six hours.  Then, I will reduce the
syncing to every 24 hours.

Syncing from git requires a 'sugar-jhbuild build.'  By parsing the
string from .../sugar-jhbuild/install/libs/python2.5/sitepackages/ , the
module reflection and introspection features work better.  It is kind of
expensive.  If tinderbox is rebuilding, and pydocweb is resyncing,  It
can take 30 seconds to get the web site to respond.

   There is a long line in alert.py which is causing a pylint warning.
  Could you turn off the documentation related pylint warnings for now?  I
  am getting hundreds of warnings from pydocweb about errors in our
  docstrings:(  Over the next few weeks we can work through the pydocweb
  warnings, then turn the pylint warning back on.
 
 The warning I have is just a line too long, so not documentation
 specific and it's the only one I'm getting. I'm not sure which errors
 you are referring to here?
 
Pydocweb has a bunch of user configurable documentation warnings to report such 
as;
line length longer the 80 chars, missing docstrings, missing parameter
list, missing brief..

  * I think it would be better to keep the top block of documentation
  under the license.
 
  Which file was mangled? I can file a bug about the location of package
  level docstrings.
 
 alert.py
bug filed

thanks
david

___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] apis at 4%

On Mon, 2008-09-22 at 13:17 +0200, Marco Pesenti Gritti wrote:
 Another thing... Is it possible to setup things so that one of the
 core developers has a quick look to the docs before they go in? (So
 that we have a chance to detect mistakes or to just improvements). I
 think it would be important especially in the beginning...

What do you suggest?

I can go back to filing bugs in the tracker or I can post patches to the
mailing list.

Generating the initial api documentation has an inherent tension.  

Nobody knows how to get starting writing the 1250+ blank docstrings in
Sugar.  Hence, they have been sitting for empty.

Following the theory of 'worse is better' we at least need to stub out
the docstrings before others will join in the effort.  The initial
quality of the docstring will be embarrassingly low.  

We can improve bad.  The hard step is ironically going from blank to
bad.

On the other hand, the edits we are making via pydocweb are all to
docstrings.  We can't mess up the code.

thanks
david

___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] apis at 4%

On Mon, 2008-09-22 at 17:11 +0200, Marco Pesenti Gritti wrote:
 On Mon, Sep 22, 2008 at 4:42 PM, David Farning [EMAIL PROTECTED] wrote:
  What do you suggest?
 
 If I understand your explanations correctly, the system already
 support some kind of review workflow... could devs just get involved
 into it?
YES anyone can get involved:)

Create a login
I'll add your permissions
Edit

  I can go back to filing bugs in the tracker or I can post patches to the
  mailing list.
 
  Generating the initial api documentation has an inherent tension.
 
  Nobody knows how to get starting writing the 1250+ blank docstrings in
  Sugar.  Hence, they have been sitting for empty.
 
  Following the theory of 'worse is better' we at least need to stub out
  the docstrings before others will join in the effort.  The initial
  quality of the docstring will be embarrassingly low.
 
  We can improve bad.  The hard step is ironically going from blank to
  bad.
 
 Yeah. I'm not suggesting to block you on very detailed review like I'd
 do if it was code. I just suspect that having a very high level look
 to the stuff which is going in might help to improve quality quite a
 bit without slowing you down too much...
 
 One way to do it, without blocking you on reviews, would be that we
 have a look to the documentation done so far and we post suggestions
 to the list.
 

Take a look at http://sugarlabs1.xen.prgmr.com/pydocweb/doc/ .  On the
initial pass, I can tag modified strings 'Need Review'.  Then a dev can
go through looking for technical errors and marking them 'Needs work
(reviewed)'. Then I can commit the strings.

By iterating between Needs editing, Needs Review, and Needs Work.  We
can work independently, while gradually increasing the quality of the
docstrings.

pydoceweb has a nice comment system.  So comments (about the
comments)can be attached to individual docstrings.

thanks
dfarning 

___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

[sugar] how scipy uses pydocweb

I just recieved some link about how pydocweb is being used in
documenting scipy.

Joe Harrington's Project Overview:
http://conference.scipy.org/proceedings/SciPy2008/paper_7/
Stefan Van der Walt's Technical Overview:
http://conference.scipy.org/proceedings/SciPy2008/paper_5/

You might also be interested in what the Matplotlib project is doing
with Sphinx:
http://conference.scipy.org/proceedings/SciPy2008/paper_6/

thanks
david

___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

[sugar] apis at 4%

2008-09-21 Thread David Farning

Looking for a few people to help us hit the 5% mark for API being
written.  I hit the 4%[1] this morning:)

I am mostly stubbing out sugar.graphics with parameter lists for
function call.  It seems much easier to start from sometime rather a
blank page.

The patches are flowing into the git tree correctly.  If you find bugs
or anything that looks kludge in the system, please let us know.  This
is the first time pydocweb has been used 'in the wild.' 

thanks
david

1. http://sugarlabs1.xen.prgmr.com/pydocweb/stats/

___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] apis at 4%

2008-09-21 Thread David Farning

On Sun, 2008-09-21 at 23:35 +0200, Marco Pesenti Gritti wrote:
 On Sun, Sep 21, 2008 at 7:00 PM, David Farning [EMAIL PROTECTED] wrote:
 
  The patches are flowing into the git tree correctly.  If you find bugs
  or anything that looks kludge in the system, please let us know.  This
  is the first time pydocweb has been used 'in the wild.'
 
 It's great to see progress on this!
 
 A couple of things:
 
 * Is it ok to commit changes to the documentation in git? 
Yes

 Will pydocweb pick them up?
Yes, pydocweb uses merge from GNUs RCS to handle changes between the
docstrings in the pydocweb database and the source code.  Whatever merge
can not figure out, is flagged for editor attention.

  There is a long line in alert.py which is causing a pylint warning.
Could you turn off the documentation related pylint warnings for now?  I
am getting hundreds of warnings from pydocweb about errors in our
docstrings:(  Over the next few weeks we can work through the pydocweb
warnings, then turn the pylint warning back on. 

 * I think it would be better to keep the top block of documentation
 under the license.

Which file was mangled? I can file a bug about the location of package
level docstrings.

thanks
david

___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] Supporting desktop applications, extending the EWMH spec

2008-09-19 Thread david

On Fri, 19 Sep 2008, Sayamindu Dasgupta wrote:

 Hello all,
 Marco and I have been discussing on how to make a window manager like
 Metacity fit into the Sugar environment, and based on our current
 discussions, as well as past discussions, it seems clear that we need
 changes to the Extended Window Manager Hints spec[1]. For details on
 why we want to do that, take a look at the first draft of the proposal
 at http://dev.laptop.org/~sayamindu/sugar_metacity/draft_1.txt

 The simplest way to do this is mentioned in the draft, namely, to have
 a new _NET_WM_WINDOW_TYPE hint, called _NET_WM_WINDOW_TYPE_NETBOOK_APP
 (feel free to suggest a better name :-P). All sugar activities are
 hinted as _NET_WM_WINDOW_TYPE_NETBOOK_APP, and the window manager
 maximizes and undecorates them.

_NET_WM_WINDOW_KIOSK would seem to be a little better to me.

netbook_app seems to imply something hardware specific, and it's not at 
all clear that it's appropriate for all netbooks.

kiosk mode implies a specific type of use, which isn't quite the same 
thing, but I think the effect of it would be the same, and that is a term 
that's already understood.

 However, Marco suggests that for applications like Firefox, or
 Thunderbird, we may actually want them to be in maximized+undecorated
 in Sugar as well, to maximize screen real estate usage. In such a
 situation, things become a bit more complicated. Marco suggests a
 double hint, some thing like _NET_WM_WINDOW_TYPE_NORMAL |
 _NET_WM_WINDOW_TYPE_APPLICATION. In a normal desktop environment the
 second _NET_WM_WINDOW_TYPE_APPLICATION will not have any effect, but
 in Sugar, _NET_WM_WINDOW_TYPE_APPLICATION will be honoured, and
 windows having this hint will be maximized + undecorated.

 However, this brings up two problems
 a) applications like firefox will need to be modified so that they set
 the _NET_WM_WINDOW_TYPE_APPLICATION hint (ideally we would like to run
 the applications unmodified).
 b) one of the major reasons why we can do away with the decorations in
 case of sugar activities is that they are designed to work well
 without decorations (eg: a large close button on the window itself).
 otoh, most desktop applications do not have this, and the close button
 is usually somewhere hidden in the menu. In some cases the close
 button may not be accessible at all (eg: a rogue popup in firefox
 which somehow circumvents the popup blocker and disables the menubar).
 Note that this is a problem with the existing Firefox activity as
 well.

you can't cover every case, but even if the menubar is disabled, the 
keystroke combination to close the window works.

David Lang

___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] G1G1v2 Activities

2008-09-19 Thread david

On Thu, 18 Sep 2008, [EMAIL PROTECTED] wrote:

 benjamin m. schwartz wrote:
  Chris Ball wrote:
  | So, we shipped 19 activities with G1G1v1; that means the ten activities
  | people vote for here are likely to be a subset of that list, and we
  | aren't learning much about what new things we should include.  People
  | replying might decide to give 20 suggestions instead of 10, or to omit
  | original G1G1 activities from their list.
  |
 
  Also, G1G1v1 shipped with the old Sugar interface, which made managing
  large numbers of installed Activities very difficult.  By contrast, the
  new Sugar UI means that we could easily ship 100 Activities, with only 15
  starred by default.  Activities' average size on disk varies
  substantially, but many simpler ones are only about 100 KB, compressed.
  100 Activities * 100 KB = 10 MB, or 1% of the disk.  Each additional
  Activity provides more opportunity for exploration, and makes the
  experience more enjoyable, so I would advocate for shipping as many as
  possible.

 i disagree, to the extent that the activities appear on the laptop
 in a completely unorganized fashion -- there's no real notion of
 topic, or testedness, or age-appropriateness.  too many can make
 the prospect of exploring them overwhelming, especially given how
 long it takes to try them, and that most of the names bear almost
 no relation to the content.  i think it's better to ship a a good
 representative sample, and clear instructions (somewhere -- is it
 at least in a pre-loaded library page?) on how to explore and get
 more from our wiki.

isn't there an activity to manage activities? is there any way to order 
them so that this one shows up first?

If so, then I would say ship as close to everything as possible, with the 
idea that this management activity will help the user remove what they 
don't want easily.

not everyone who's playing around with an XO has network connectivity, 
which makes it _far_ easier to remove stuff that you don't care about then 
to add additional stuff in later.

I suspect that most of the G1G1 laptops out there are running the default 
set of activities.

Also, if you don't know what types of activities exist, you won't go 
looking for them. if you have lots of samples it's far easier to think of 
other similar things to look for.


In fact, thinking about this as I've been typing this message, I think it 
would be a _good_thing_ if there was an entry for every activity that's 
supported, even if all that the 'activity' consists of is a web page that 
shows what the activity is and has a link to download it (useful for 
activities that are otherwise too large or not appropriate for all ages)

David Lang
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] Sugar API documentation

2008-09-09 Thread David Farning

On Tue, 2008-09-09 at 16:24 +0200, Tomeu Vizoso wrote:
 On Tue, Sep 9, 2008 at 4:17 PM, Walter Bender [EMAIL PROTECTED] wrote:
  We certainly could do something equivalent to the Austin sprint. All
  being in the room together made a big difference for that initial
  push.
 
 Yes, I'm not sure Sugar developers are in a good moment to travel
 again, but if some people wanted to meet in person we could be at IRC
 answering questions.
 

Have CCed Greg (the event guy)

Janet provided an interesting link[1] to a doc marathon held by the
scipy guys.  

As I saw it, the synergistic value from the sprint came from three
areas:
1.  Overcoming the initial lack of momentum.  Putting a number of
talented writers together in a isolated environment to focus on the
particular task of creating end user documentation.

2.  Finding initial direction.  The hard work of Anne putting together
the initial chapter lists and rough outlines.

3.  Creating momentum.  This was dependent on first meeting 1 and 2.
The combination of various subject matter experts: XO, Sugar and
Technical writing all interacting with the FM tool chain.

I would like to try to put some thing similar together for API
documentation in the next couple of months.

thanks
dfaning

 1.
http://conference.scipy.org/static/wiki/joe_harrington_docmarathon.pdf

___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

[sugar] [Fwd: Debian-Edu Skolelinux Developer Gathering in Oslo, Norway, October 10.-12.]

2008-09-05 Thread David Farning

An interesting event for any of our Europe based friends.

SkoleLinux is(can be) a valuable partner to Sugar Labs!

 Forwarded Message 
 From: Lars Risan [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Subject: Debian-Edu Skolelinux Developer Gathering in Oslo, Norway,
 October 10.-12.
 Date: Fri, 5 Sep 2008 23:27:32 +0200

 Dear all,

 The Free Software in Schools Norway (FRISK) board are happy to
 announce a Developer Gathering to be held in Oslo on OCTOBER the 10th
 - 12th, at the Department of Informatics, University of Oslo.
 Please read more here: http://friprogramvareiskolen.no/Gathering/2008-10-Oslo

 The gathering is followed by a one day User Conference in down-town
 Oslo, October 13th, with a broad list of speakers, please follow this
 link:
 http://friprogramvareiskolen.no/Gathering/2008-10-UC-Oslo.

 We do hope and believe that this gathering will be an occasion for
 people to meet from many places of the world. please sogn in and sign
 on the sooner the better! Hope to see may of you!!

 Welcome,
 Lars

 You can register in two ways:

1. enter your details into the list at the bottom of the Gathering
 web-page (if you are a registered user of the Wiki)
2. send an email message to [EMAIL PROTECTED] (or
 [EMAIL PROTECTED] ), containing the following information:
   *  Subject: Yes, I will participate in the developer
 gathering dates Body:
 o Your name
 o Your travel expenses (if you are or plan to be an
 active developer, translator or contributor to Skolelinux).
 o Which part of the gathering you are joining
 (conference, technical/testing, translation, system
 user/documentation, facilitators)
 o If you are joining us for dinner on Thursday, Friday
 and/or Saturday
 o If you are a developer, we would like to know which
 Bug(s) you are going to work on as well. Our bugs can be found at
   http://bugs.skolelinux.org/

___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

[sugar] Fragmenting or providing a foothold?


It appears that the consensus is to keep activity developers and sugar
developers united on the same ML.

Instead of talking specifically about the activities list, I would like
to talk more generally about community growth.

This discussion is premised on the belief that the future of the Sugar
Learning Platform depends on two factors: Continuing the vision of
learning through 'sharing, reflection, and exploration.'  At the same
time, we must provide enough value to technical and educational
communities that they want to support and spread this vision.

One method of implementing this vision is to evolve Sugar Labs to a
structure similar to the Eclipse Foundation[1].  At is core, Eclipse is
an open learning platform.  Sugar is an open learning platform.  The
value in Eclipse is in the ecosystem surrounding the platform; the
users, the contributors, and the developers.  The value in Sugar will be
in our ecosystem;  the students, teachers, contributors, and developers
who extend and improve the platform. 

Theses student, teacher, contributor, and developer groups will evolve
from community seeds that we plant now.  My role for the last couple of
months has been to plant and foster these communities until they are
self sustaining.  When looking for places to start and foster
communities around Sugar Labs, I have been looking for three criteria:
1.  Will the new community provide benefit to the Sugar Labs community?
Do our goal coincide?  2. Is the community growing?  3.  Is the
community developing internal leadership?

With this in mind, the goal of creating new mailing lists is not to
fragment the existing community.  It is to create footholds for other
communities to develop around the central learning platform.

thanks
dfarning  



1. http://www.eclipse.org/


___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] Sugar on the BeagleBoard using the OpenEmbedded toolkit.

On Wed, 2008-09-03 at 13:14 -0700, Edward Cherlin wrote:
 On Mon, Sep 1, 2008 at 3:57 AM, Koen Kooi [EMAIL PROTECTED] wrote:
 
  Op 22 aug 2008, om 02:29 heeft David Farning het volgende geschreven:
 
  Welcome to the Sugar on the BeagleBoard project.  It seems that we have
  all of the pieces in place to do a port.
 
 Very good. Thank you.
 
 I see that BeagleBoards list at $149. Do you have any idea of quantity
 pricing? Apparently TI sells them only through Digikey, which only
 gives single-unit prices on its site. I can see applications for data
 acquisition and control worldwide, as well as for teaching embedded
 systems development. I am thinking of possibilities for placement of
 systems through microfinance, assuming that we can find and document
 ways to increase income using BeagleBoard+Sugar more efficiently than
 by other methods.

The BeagleBoard is a development platform for introducing developers to
the OMAP35x family of processors.  I don't believe that it was meant for
endusers.  The interesting question I my mind is, 'Who will be the first
to leverage the chipset into low cost thin clients or laptops for use
classrooms?'

thanks
dfarning  

___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] finding sugarlabs.org resources

On Wed, 2008-09-03 at 11:15 -0400, Mikus Grinbergs wrote:
  Mikus, when the appropriate lists are decided on and created, you will
  find them at http://lists.sugarlabs.org/
 
 I could find lists.sugarlabs.org now that I knew what I was looking 
 for (and did not use the sugarlabs.org search engine).
 
 Please make http://lists.sugarlabs.org easier to find for people who 
 do not know ahead of time what to look for.
 

You are correct Mikus,  we need to give the wiki a clean up soon;(

thanks
dfarning 

___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] Developing activities.

On Tue, 2008-09-02 at 13:25 -0400, Brian Jordan wrote:

  1.  Create [EMAIL PROTECTED] mailing list.  We have discussed
  this a few time over the last few months.  Now that we are getting
  distro (other the OLPC) related comments the time seems right
 
  2. Create [EMAIL PROTECTED] mailing list.  This will focus
  on activity developer related issues.
 
 
 I think we have been thinking very similar thoughts -- I had
 [EMAIL PROTECTED] set up on August 12.
 
 http://lists.laptop.org/pipermail/activities/2008-August/thread.html
 
 If we do use [EMAIL PROTECTED] as the Sugar activity
 development mailing list, could you somehow import the past
 conversations from [EMAIL PROTECTED] into
 [EMAIL PROTECTED]'s archives?


Thanks, I was not aware that you set up [EMAIL PROTECTED];(

thanks
Dfarning

___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] OT: Anybody worked with robot and OLPC

2008-09-02 Thread David Farning

On Mon, 2008-09-01 at 19:01 -0500, Rafael Enrique Ortiz Guerrero wrote:
 Hi 
 
 maybe this can be of interest,
 
 http://wiki.laptop.org/go/Peripherals/Robots
 
 this is planned  with open hardware.
 
 http://wiki.laptop.org/go/Open_Hardware.
 
 
 
 On Mon, Sep 1, 2008 at 6:42 PM, Carlos mauro [EMAIL PROTECTED]
 wrote:
 Hello Friends.
 
 Someone made a robot using only the OLPC. There is a project
 to adapt to the OLPC iRobot of microsoft.
 
 I am going to bring the artificial intelligence. The teacher
 will use the robotic irobor and microsoft for the course. I
 wonder if you could use an OLPC to make a robot and program
 intelligent agents. The idea is a purely academic post so that
 in future we will work with cooperative multi robot players.

On a related note... The open embedded[1] guys are making good progress
on porting Sugar to the open embedded platform.  In particular the
effort is being driven by the desire to run sugar on the Beagleboard[2].

A project that would make the transition from a turtle cursor, in turtle
art, to a little robotic turtle zipping around around the room would be
very cool.  

thanks
dfarning

1. http://wiki.openembedded.net/index.php/Main_Page

2. http://beagleboard.org/

___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

[sugar] Developing activities.

2008-09-02 Thread David Farning

For those who have not yet gotten a chance to look at the results of
Morgs activity developers survey.  It is available at
http://wiki.laptop.org/go/User:Morgs/Activities_survey/Recommendations .
There is a lot of good stuff in there;)

Steps Sugar Labs Should take to improve the situation:  Now that the
distros are starting to pick up speed, I will focus on activities.  As
always, help is appreciated and advice is grudgingly accepted.  

1.  Create [EMAIL PROTECTED] mailing list.  We have discussed
this a few time over the last few months.  Now that we are getting
distro (other the OLPC) related comments the time seems right

2. Create [EMAIL PROTECTED] mailing list.  This will focus
on activity developer related issues.

3.  Improve API documentation.  Last week at the Book Sprint, I met a
professional writer who does Python api documentation for a living.  She
is willing to help us get our documentation processes set up and get us
started.

4.  Work on the getting involved documentation on the Sugar Wiki.

5.  Move the Sugar documentation from w.l.o to w.s.o.  When I started
this move a few moths ago, I am afraid that it was seen as a power grab
for Sugar Labs.  I will restart this move if I receive buy-in and
support from OLPC personal.

6. Using AMO as an activities server.  There are many advantages to
using Amo as an activity server. The issues that i ran into was the need
to push some patches back to mozilla to abstract the types of files AMO
serves.  With the patch set, modifing amo to meet our needs would be
pretty straight forward.  Without the patches being accepted we would
have to fork the code amo codebase.

thanks
dfarning

___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

[sugar] Sugar API documentation

2008-09-02 Thread David Farning

After some discussions with Janet Swisher last week I thought it was
time to take another stab at API documentation for sugar.

Background:
Several months ago I started experimenting with several tools to
generate API documentation from the source code.

After several misguided efforts, I settled on the following work flow to
build the docs:

1. Build sugar via sugar jhbuild.
2. run epydoc against the install direrectoy built by jhbuild.
3. Upload the contents of apidocs/*  to api.sugarlabs.org .
4. Repeat.

The work flow to contribute to the documentation is as follows:
1.  Pull git tree.
2.  Add documentation.
3.  Submit patch to SL.

What should/can we do to improve this workflow?  Cause right now no work
is flowing;(

Another possibility is to use pydocweb.  You can see an example at
http://sd-2116.dedibox.fr/pydocweb/wiki/Front%20Page/ .

Janet, could you point us to a good style guide?  There seem to be as
many way to document python as there are open source projects.

thanks
dfarning

___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] Reference Platform for Sugar ?

On Sun, 2008-08-31 at 19:41 +0200, Marco Pesenti Gritti wrote:
 On Sun, Aug 31, 2008 at 4:16 PM, Mikus Grinbergs [EMAIL PROTECTED] wrote:
  With Sugar releases being separate from OLPC releases, is there
  an 'Official Platform' on which to validate that everything works?
 
 I'm not sure to fully understand your question. Sugar can run of
 multiple platforms, I wouldn't consider any of them like official,
 but clearly OLPC is by far the most important of them at the moment.
 
Good morning Mikus;)

Thanks for you help last week.  If, by reference platform, you are
referring to a specific distribution, release, and packages set for
Sugar development.  Then, no, there is no reference platform.

One of our goals is to be distribution agnostic.  From a development
point of view this allows us to create an abstraction barrier between
Sugar and the platform underneath it.

From a social point of view we avoid the 'distro wars.'  We can focus on
being the best learning platform.  The system integrators and deployers
can chose us or not chose us, based on their current market needs.

Thanks
dfarning

___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] LiveCD LiveUSB

On Sun, 2008-08-31 at 13:21 -0400, Ivan Krstić wrote:
 On Aug 31, 2008, at 7:42 AM, Jani Monoses wrote:
  I do not know where ISOs could be hosted though.
 
 
 SugarLabs can host them.
 
I am a bit reluctant to host them at Sugar Labs.  We are pushing to
brand Sugar as distribution agnostic.  So, distributing a Ubuntu based
live cd and live USB seems a bit disingenuous.


With that being said http://download.sugarlabs.org/sugar/liveimages/
 looks pretty good until we can find someone else to host them.  Would
just seen me the details on how and where to upload the images.
 

thanks
dfarning 

___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] LiveCD LiveUSB

On Mon, 2008-09-01 at 17:28 -0400, Greg Dekoenigsberg wrote:
 On Mon, 1 Sep 2008, Ivan Krstić wrote:
 
  On Sep 1, 2008, at 5:23 PM, David Farning wrote:
  I am a bit reluctant to host them at Sugar Labs.  We are pushing to
  brand Sugar as distribution agnostic.  So, distributing a Ubuntu based
  live cd and live USB seems a bit disingenuous.
 
  No, it would be disingenuous if we also refused to host _other_ live 
  CDs. Precisely because we're distro agnostic, we should provide 
  resources to all those interested in making Sugar more widely 
  available. I am happy to have a 'unofficial' or 'contrib' directory in 
  the download tree to indicate SugarLabs didn't produce the images.
 
 I agree with Ivan here.  Whomsoever has bandwidth, let them host.
 
Sounds reasonable.  Where should I upload the images?

thanks
dfarning 

___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] Release Cycle - Responsibilities