subject:"Re\: \[Sugar\-devel\] Activity"

Thanks, I await your testing of my pull request.

On Thu, Jan 21, 2016 at 07:13:47AM +0200, Tony Anderson wrote:
> Hi, James
> 
> It would seem the correct solution is to have Sugar implement
> the procedure specified in the 'low level activity'. The instance folder
> should be cleared when the activity quits. If an activity needs longer
> persistence, it can put the file in the data folder and then manage it.
> 
> The issue is storage. An XO-1 has 1GB total. When the available storage
> falls below 50MB, the "Journal is Full" modal dialog is shown (a non
> sequitor since the
> Journal may not be the culprit). Sugar provides no tools to the user to
> determine the cause of the problem or to deal with it. In my experience,
> deployments reflash losing all Journal data.
> 
> Tony
> 
> On 01/21/2016 02:19 AM, James Cameron wrote:
> >We can't know what is wrong, because the logs aren't available, but my
> >guess is one or more downloads were started, and the total for the day
> >reached 1.2 Gb.  That's all it takes.
> >
> >Downloads in progress are invisible to a user of Browse, so it is an
> >easy mistake to make.
> >
> >For data shared between instances, we must use the data directory, not
> >the instance or tmp directories, so any activity that does as you say
> >must be fixed.
> >
> >I've done some tests.
> >
> >During download, instance directory has a file .goutputstream-* which
> >will be cleared by _cleanup_temp_files in webactivity.py if Browse is
> >started the day after the files were modified.  Browse does not remove
> >these files on the day.  The code you refer to is only used when
> >Browse is still running, and only for the destination path files, not
> >the gio files referred to in #3973.
> >
> >Browse correctly uses data directory for places.db and gecko
> >certificates and cookies.
> >
> >So the scenario that Tony describes is likely to cause the problem.
> >
> >Also, it won't be fixed by stopping and starting Browse.
> >
> >But it will be fixed by my patch in combination with stopping and
> >starting Browse.
> >
> >On Wed, Jan 20, 2016 at 09:47:37AM -0300, Gonzalo Odiard wrote:
> >>A few issues:
> >>* Browse already have a mechanism to remove the temporary downloaded files,
> >>we need to know what is wrong [1].
> >>* Temporary directories are shared between instances, if we remove temporary
> >>directories
> >>at activity start or stop, we need check if there are other instances of the
> >>activity running.
> >>
> >>Gonzalo
> >>
> >>[1] [1]https://github.com/sugarlabs/browse-activity/blob/master/
> >>downloadmanager.py#L289
> >>
> >>On Wed, Jan 20, 2016 at 6:38 AM, James Cameron <[2]qu...@laptop.org> wrote:
> >>
> >> G'day Sam,
> >>
> >> The pull request I've made will handle a preserved .sugar directory on
> >> upgrade by deleting the directories the next time an activity is
> >> started, as well as when an activity is closed or crashes.
> >>
> >> Implemented in the shell, or sugar-launch, or activity to activity
> >> start, on behalf of the activity being started.
> >>
> >> That's option 2 and 4 from my previous post.
> >>
> >> Are there any activities that improperly depend on retaining data in
> >> these directories?
> >> On Wed, Jan 20, 2016 at 08:23:33PM +1100, Sam P. wrote:
> >> > Thanks for the good analysis James!
> >> >
> >> > I don't think that deleting on startup is an optimal idea.  It is
> >> > counter-intuitive that the user must open every activity on their
> >> computer when
> >> > they want to reclaim space.  It is also bad in the case of 
> >> infrequently
> >> used
> >> > activities.
> >> >
> >> > I think that a multi-pronged approach would be better.  As you 
> >> noted, the
> >> > activity clearing their tmp and instance folders themselves is 
> >> optimal
> >> (option
> >> > 3).  I agree with this, as it takes load out of the shell process and
> >> means
> >> > that the filesystem space is reclaimed a quick as possible.
> >> >
> >> > However, to deal with the issue of crashing or non-sugar3 
> >> activities, we
> >> could
> >> > also delete ALL tmp and instance folders during the shutdown process
> >> (after
> >> > stopping all activities is successful).  In the best case, this 
> >> should be
> >> as
> >> > quick as running ls on all of the folders (which is quick right?).  
> >> It
> >> also
> >> > helps users who are upgrading their system and preserving their 
> >> .sugar
> >> > directory.  The shell does also not need to be responsive during
> >> shutdown.
> >> >
> >> > Thanks,
> >> > Sam
> >> >
> >> > On Wed, Jan 20, 2016 at 1:50 PM, James Cameron 
> >> <[1][3]qu...@laptop.org>
> >> wrote:
> >> >
> >> > The API documentation was wrong, and has been edited.
> >> >
> >> > [2][4]https://wiki.sugarlabs.org/go/Development_Team/
> >> Low-level_Activity_API
> >> >
>

Re: [Sugar-devel] activity instance directory

2016-01-20 Thread Tony Anderson

Hi, James

It would seem the correct solution is to have Sugar implement
the procedure specified in the 'low level activity'. The instance folder
should be cleared when the activity quits. If an activity needs longer
persistence, it can put the file in the data folder and then manage it.

The issue is storage. An XO-1 has 1GB total. When the available storage
falls below 50MB, the "Journal is Full" modal dialog is shown (a non 
sequitor since the

Journal may not be the culprit). Sugar provides no tools to the user to
determine the cause of the problem or to deal with it. In my experience,
deployments reflash losing all Journal data.

Tony

On 01/21/2016 02:19 AM, James Cameron wrote:

We can't know what is wrong, because the logs aren't available, but my
guess is one or more downloads were started, and the total for the day
reached 1.2 Gb.  That's all it takes.

Downloads in progress are invisible to a user of Browse, so it is an
easy mistake to make.

For data shared between instances, we must use the data directory, not
the instance or tmp directories, so any activity that does as you say
must be fixed.

I've done some tests.

During download, instance directory has a file .goutputstream-* which
will be cleared by _cleanup_temp_files in webactivity.py if Browse is
started the day after the files were modified.  Browse does not remove
these files on the day.  The code you refer to is only used when
Browse is still running, and only for the destination path files, not
the gio files referred to in #3973.

Browse correctly uses data directory for places.db and gecko
certificates and cookies.

So the scenario that Tony describes is likely to cause the problem.

Also, it won't be fixed by stopping and starting Browse.

But it will be fixed by my patch in combination with stopping and
starting Browse.

On Wed, Jan 20, 2016 at 09:47:37AM -0300, Gonzalo Odiard wrote:

A few issues:
* Browse already have a mechanism to remove the temporary downloaded files,
we need to know what is wrong [1].
* Temporary directories are shared between instances, if we remove temporary
directories
at activity start or stop, we need check if there are other instances of the
activity running.

Gonzalo

[1] [1]https://github.com/sugarlabs/browse-activity/blob/master/
downloadmanager.py#L289

On Wed, Jan 20, 2016 at 6:38 AM, James Cameron <[2]qu...@laptop.org> wrote:

 G'day Sam,

 The pull request I've made will handle a preserved .sugar directory on
 upgrade by deleting the directories the next time an activity is
 started, as well as when an activity is closed or crashes.

 Implemented in the shell, or sugar-launch, or activity to activity
 start, on behalf of the activity being started.

 That's option 2 and 4 from my previous post.

 Are there any activities that improperly depend on retaining data in
 these directories?

 On Wed, Jan 20, 2016 at 08:23:33PM +1100, Sam P. wrote:

 > Thanks for the good analysis James!
 >
 > I don't think that deleting on startup is an optimal idea.  It is
 > counter-intuitive that the user must open every activity on their
 computer when
 > they want to reclaim space.  It is also bad in the case of infrequently
 used
 > activities.
 >
 > I think that a multi-pronged approach would be better.  As you noted, the
 > activity clearing their tmp and instance folders themselves is optimal
 (option
 > 3).  I agree with this, as it takes load out of the shell process and
 means
 > that the filesystem space is reclaimed a quick as possible.
 >
 > However, to deal with the issue of crashing or non-sugar3 activities, we
 could
 > also delete ALL tmp and instance folders during the shutdown process
 (after
 > stopping all activities is successful).  In the best case, this should be
 as
 > quick as running ls on all of the folders (which is quick right?).  It
 also
 > helps users who are upgrading their system and preserving their .sugar
 > directory.  The shell does also not need to be responsive during
 shutdown.
 >
 > Thanks,
 > Sam
 >
 > On Wed, Jan 20, 2016 at 1:50 PM, James Cameron <[1][3]qu...@laptop.org>
 wrote:
 >
 > The API documentation was wrong, and has been edited.
 >
 > [2][4]https://wiki.sugarlabs.org/go/Development_Team/
 Low-level_Activity_API
 >
 > Rainbow did delete instance and tmp.  Sugar did not.
 >
 > Rainbow has not been in OLPC OS for some time.  (/etc/olpc-security
 > must exist, /usr/bin/rainbow-run must be executable).
 >
 > Rainbow is not in other builds that use Sugar.
 >
 > Sugar activities that were coded for Rainbow, and against this
 > documentation, will leave an instance and tmp directory on the
 > system.  Every activity.
 >
 > Sugar must delete both directories.
 >
 > The next

Re: [Sugar-devel] activity instance directory

We can't know what is wrong, because the logs aren't available, but my
guess is one or more downloads were started, and the total for the day
reached 1.2 Gb.  That's all it takes.

Downloads in progress are invisible to a user of Browse, so it is an
easy mistake to make.

For data shared between instances, we must use the data directory, not
the instance or tmp directories, so any activity that does as you say
must be fixed.

I've done some tests.

During download, instance directory has a file .goutputstream-* which
will be cleared by _cleanup_temp_files in webactivity.py if Browse is
started the day after the files were modified.  Browse does not remove
these files on the day.  The code you refer to is only used when
Browse is still running, and only for the destination path files, not
the gio files referred to in #3973.

Browse correctly uses data directory for places.db and gecko
certificates and cookies.

So the scenario that Tony describes is likely to cause the problem.

Also, it won't be fixed by stopping and starting Browse.

But it will be fixed by my patch in combination with stopping and
starting Browse.

On Wed, Jan 20, 2016 at 09:47:37AM -0300, Gonzalo Odiard wrote:
> A few issues:
> * Browse already have a mechanism to remove the temporary downloaded files,
> we need to know what is wrong [1]. 
> * Temporary directories are shared between instances, if we remove temporary
> directories 
> at activity start or stop, we need check if there are other instances of the
> activity running.
> 
> Gonzalo
> 
> [1] [1]https://github.com/sugarlabs/browse-activity/blob/master/
> downloadmanager.py#L289
> 
> On Wed, Jan 20, 2016 at 6:38 AM, James Cameron <[2]qu...@laptop.org> wrote:
> 
> G'day Sam,
> 
> The pull request I've made will handle a preserved .sugar directory on
> upgrade by deleting the directories the next time an activity is
> started, as well as when an activity is closed or crashes.
> 
> Implemented in the shell, or sugar-launch, or activity to activity
> start, on behalf of the activity being started.
> 
> That's option 2 and 4 from my previous post.
> 
> Are there any activities that improperly depend on retaining data in
> these directories?
>
> On Wed, Jan 20, 2016 at 08:23:33PM +1100, Sam P. wrote:
> > Thanks for the good analysis James!
> >
> > I don't think that deleting on startup is an optimal idea.  It is
> > counter-intuitive that the user must open every activity on their
> computer when
> > they want to reclaim space.  It is also bad in the case of infrequently
> used
> > activities.
> >
> > I think that a multi-pronged approach would be better.  As you noted, 
> the
> > activity clearing their tmp and instance folders themselves is optimal
> (option
> > 3).  I agree with this, as it takes load out of the shell process and
> means
> > that the filesystem space is reclaimed a quick as possible.
> >
> > However, to deal with the issue of crashing or non-sugar3 activities, we
> could
> > also delete ALL tmp and instance folders during the shutdown process
> (after
> > stopping all activities is successful).  In the best case, this should 
> be
> as
> > quick as running ls on all of the folders (which is quick right?).  It
> also
> > helps users who are upgrading their system and preserving their .sugar
> > directory.  The shell does also not need to be responsive during
> shutdown.
> >
> > Thanks,
> > Sam
> >
> > On Wed, Jan 20, 2016 at 1:50 PM, James Cameron <[1][3]qu...@laptop.org>
> wrote:
> >
> >     The API documentation was wrong, and has been edited.
> >
> >     [2][4]https://wiki.sugarlabs.org/go/Development_Team/
> Low-level_Activity_API
> >
> >     Rainbow did delete instance and tmp.  Sugar did not.
> >
> >     Rainbow has not been in OLPC OS for some time.  (/etc/olpc-security
> >     must exist, /usr/bin/rainbow-run must be executable).
> >
> >     Rainbow is not in other builds that use Sugar.
> >
> >     Sugar activities that were coded for Rainbow, and against this
> >     documentation, will leave an instance and tmp directory on the
> >     system.  Every activity.
> >
> >     Sugar must delete both directories.
> >
> >     The next question is when?
> >
> >     0.  on reinstall of OLPC OS, or reboot of SoaS,
> >
> >     This is what we do at the moment.
> >
> >     1.  on Sugar start,
> >
> >     cleanup_temporary_files in sugar:src/jarabe/main.py might be
> extended,
> >     so that Sugar starts up and deletes the directories.
> >
> >     Disadvantage is a small delay during Sugar start, the need to 
> iterate
> >     over the bundle ids, and which list of bundles to use.
> >
> >     2.  on activity start,
> >
> >     The activity factory

Re: [Sugar-devel] activity instance directory

Tony,

Please test this pull request;
https://github.com/sugarlabs/sugar-toolkit-gtk3/pull/306

"Remove Rainbow, clear activity instance/ and tmp/

Sugar depended on Rainbow for clearing the activity instance/ and tmp/
directories.  But Rainbow is no longer used downstream.

 - remove support for Rainbow,

 - clear the contents of instance/ and tmp/ on start and stop,

 - avoid race when creating directories; don't check they exist before
   we create.

https://bugs.sugarlabs.org/ticket/4931

On Wed, Jan 20, 2016 at 01:50:31PM +1100, James Cameron wrote:
> The API documentation was wrong, and has been edited.
> 
> https://wiki.sugarlabs.org/go/Development_Team/Low-level_Activity_API
> 
> Rainbow did delete instance and tmp.  Sugar did not.
> 
> Rainbow has not been in OLPC OS for some time.  (/etc/olpc-security
> must exist, /usr/bin/rainbow-run must be executable).
> 
> Rainbow is not in other builds that use Sugar.
> 
> Sugar activities that were coded for Rainbow, and against this
> documentation, will leave an instance and tmp directory on the
> system.  Every activity.
> 
> Sugar must delete both directories.
> 
> The next question is when?
> 
> 
> 0.  on reinstall of OLPC OS, or reboot of SoaS,
> 
> This is what we do at the moment.
> 
> 
> 1.  on Sugar start,
> 
> cleanup_temporary_files in sugar:src/jarabe/main.py might be extended,
> so that Sugar starts up and deletes the directories.
> 
> Disadvantage is a small delay during Sugar start, the need to iterate
> over the bundle ids, and which list of bundles to use.
> 
> 
> 2.  on activity start,
> 
> The activity factory module function get_environment() in
> sugar-toolkit-gtk3:src/sugar3/activity/activityfactory.py
> might be extended to delete first, before making the directories.
> 
> Disadvantage is a small delay during activity start.
> 
> 
> 3.  on activity close
> 
> In the Activity class method _complete_close() in
> src/sugar3/activity/activity.py we might delete the directories as the
> activity is closing.
> 
> Disadvantage is that an activity that crashes won't delete the
> directories.
> 
> Advantage is that any waste will be cleaned as soon as possible.
> 
> 
> 4.  on activity close in shell
> 
> Disadvantage is that Sugar may be momentarily unresponsive when an
> activity closes or crashes.
> 
> 
> Can we work toward a consensus?
> 
> My preference is on activity start, since that is the last time it
> must be done to be consistent with the design intent.  Are you
> registered on github?
> 
> On Tue, Jan 19, 2016 at 01:47:23AM +0200, Tony Anderson wrote:
> > At a workshop I am giving in Rwanda, an XO got 'Journal Full'. It
> > turns out that the Browse instance folder was using 1.2GB of store.
> > 
> > The low-level API says:
> > 
> > $SUGAR_ACTIVITY_ROOT/instance/
> > This directory is used similar to a /var/tmp directory, being
> > backed by flash rather than by RAM. It is unique per instance. It is
> > used for transfer to and from the datastore (see keeping and
> > resuming). This directory is deleted when the activity exits
> > (specifically, as soon as all children of the activity's first
> > process die)
> > 
> > However, apparently in 0.106 this directory is not being deleted.
> > 
> > Tony
> 
> -- 
> James Cameron
> http://quozl.netrek.org/

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

Re: [Sugar-devel] activity instance directory

2016-01-20 Thread Sam P.

Thanks for the good analysis James!

I don't think that deleting on startup is an optimal idea.  It is
counter-intuitive that the user must open every activity on their computer
when they want to reclaim space.  It is also bad in the case of
infrequently used activities.

I think that a multi-pronged approach would be better.  As you noted, the
activity clearing their tmp and instance folders themselves is optimal
(option 3).  I agree with this, as it takes load out of the shell process
and means that the filesystem space is reclaimed a quick as possible.

However, to deal with the issue of crashing or non-sugar3 activities, we
could also delete ALL tmp and instance folders during the shutdown process
(after stopping all activities is successful).  In the best case, this
should be as quick as running ls on all of the folders (which is quick
right?).  It also helps users who are upgrading their system and preserving
their .sugar directory.  The shell does also not need to be responsive
during shutdown.

Thanks,
Sam

On Wed, Jan 20, 2016 at 1:50 PM, James Cameron  wrote:

> The API documentation was wrong, and has been edited.
>
> https://wiki.sugarlabs.org/go/Development_Team/Low-level_Activity_API
>
> Rainbow did delete instance and tmp.  Sugar did not.
>
> Rainbow has not been in OLPC OS for some time.  (/etc/olpc-security
> must exist, /usr/bin/rainbow-run must be executable).
>
> Rainbow is not in other builds that use Sugar.
>
> Sugar activities that were coded for Rainbow, and against this
> documentation, will leave an instance and tmp directory on the
> system.  Every activity.
>
> Sugar must delete both directories.
>
> The next question is when?
>
>
> 0.  on reinstall of OLPC OS, or reboot of SoaS,
>
> This is what we do at the moment.
>
>
> 1.  on Sugar start,
>
> cleanup_temporary_files in sugar:src/jarabe/main.py might be extended,
> so that Sugar starts up and deletes the directories.
>
> Disadvantage is a small delay during Sugar start, the need to iterate
> over the bundle ids, and which list of bundles to use.
>
>
> 2.  on activity start,
>
> The activity factory module function get_environment() in
> sugar-toolkit-gtk3:src/sugar3/activity/activityfactory.py
> might be extended to delete first, before making the directories.
>
> Disadvantage is a small delay during activity start.
>
>
> 3.  on activity close
>
> In the Activity class method _complete_close() in
> src/sugar3/activity/activity.py we might delete the directories as the
> activity is closing.
>
> Disadvantage is that an activity that crashes won't delete the
> directories.
>
> Advantage is that any waste will be cleaned as soon as possible.
>
>
> 4.  on activity close in shell
>
> Disadvantage is that Sugar may be momentarily unresponsive when an
> activity closes or crashes.
>
>
> Can we work toward a consensus?
>
> My preference is on activity start, since that is the last time it
> must be done to be consistent with the design intent.  Are you
> registered on github?
>
> On Tue, Jan 19, 2016 at 01:47:23AM +0200, Tony Anderson wrote:
> > At a workshop I am giving in Rwanda, an XO got 'Journal Full'. It
> > turns out that the Browse instance folder was using 1.2GB of store.
> >
> > The low-level API says:
> >
> > $SUGAR_ACTIVITY_ROOT/instance/
> > This directory is used similar to a /var/tmp directory, being
> > backed by flash rather than by RAM. It is unique per instance. It is
> > used for transfer to and from the datastore (see keeping and
> > resuming). This directory is deleted when the activity exits
> > (specifically, as soon as all children of the activity's first
> > process die)
> >
> > However, apparently in 0.106 this directory is not being deleted.
> >
> > Tony
>
> --
> James Cameron
> http://quozl.netrek.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] activity instance directory

G'day Sam,

The pull request I've made will handle a preserved .sugar directory on
upgrade by deleting the directories the next time an activity is
started, as well as when an activity is closed or crashes.

Implemented in the shell, or sugar-launch, or activity to activity
start, on behalf of the activity being started.

That's option 2 and 4 from my previous post.

Are there any activities that improperly depend on retaining data in
these directories?

On Wed, Jan 20, 2016 at 08:23:33PM +1100, Sam P. wrote:
> Thanks for the good analysis James!
> 
> I don't think that deleting on startup is an optimal idea.  It is
> counter-intuitive that the user must open every activity on their computer 
> when
> they want to reclaim space.  It is also bad in the case of infrequently used
> activities.
> 
> I think that a multi-pronged approach would be better.  As you noted, the
> activity clearing their tmp and instance folders themselves is optimal (option
> 3).  I agree with this, as it takes load out of the shell process and means
> that the filesystem space is reclaimed a quick as possible.
> 
> However, to deal with the issue of crashing or non-sugar3 activities, we could
> also delete ALL tmp and instance folders during the shutdown process (after
> stopping all activities is successful).  In the best case, this should be as
> quick as running ls on all of the folders (which is quick right?).  It also
> helps users who are upgrading their system and preserving their .sugar
> directory.  The shell does also not need to be responsive during shutdown.
> 
> Thanks,
> Sam
> 
> On Wed, Jan 20, 2016 at 1:50 PM, James Cameron <[1]qu...@laptop.org> wrote:
> 
> The API documentation was wrong, and has been edited.
> 
> [2]https://wiki.sugarlabs.org/go/Development_Team/Low-level_Activity_API
> 
> Rainbow did delete instance and tmp.  Sugar did not.
> 
> Rainbow has not been in OLPC OS for some time.  (/etc/olpc-security
> must exist, /usr/bin/rainbow-run must be executable).
> 
> Rainbow is not in other builds that use Sugar.
> 
> Sugar activities that were coded for Rainbow, and against this
> documentation, will leave an instance and tmp directory on the
> system.  Every activity.
> 
> Sugar must delete both directories.
> 
> The next question is when?
> 
> 0.  on reinstall of OLPC OS, or reboot of SoaS,
> 
> This is what we do at the moment.
> 
> 1.  on Sugar start,
> 
> cleanup_temporary_files in sugar:src/jarabe/main.py might be extended,
> so that Sugar starts up and deletes the directories.
> 
> Disadvantage is a small delay during Sugar start, the need to iterate
> over the bundle ids, and which list of bundles to use.
> 
> 2.  on activity start,
> 
> The activity factory module function get_environment() in
> sugar-toolkit-gtk3:src/sugar3/activity/activityfactory.py
> might be extended to delete first, before making the directories.
> 
> Disadvantage is a small delay during activity start.
> 
> 3.  on activity close
> 
> In the Activity class method _complete_close() in
> src/sugar3/activity/activity.py we might delete the directories as the
> activity is closing.
> 
> Disadvantage is that an activity that crashes won't delete the
> directories.
> 
> Advantage is that any waste will be cleaned as soon as possible.
> 
> 4.  on activity close in shell
> 
> Disadvantage is that Sugar may be momentarily unresponsive when an
> activity closes or crashes.
> 
> Can we work toward a consensus?
> 
> My preference is on activity start, since that is the last time it
> must be done to be consistent with the design intent.  Are you
> registered on github?
>
> On Tue, Jan 19, 2016 at 01:47:23AM +0200, Tony Anderson wrote:
> > At a workshop I am giving in Rwanda, an XO got 'Journal Full'. It
> > turns out that the Browse instance folder was using 1.2GB of store.
> >
> > The low-level API says:
> >
> > $SUGAR_ACTIVITY_ROOT/instance/
> >     This directory is used similar to a /var/tmp directory, being
> > backed by flash rather than by RAM. It is unique per instance. It is
> > used for transfer to and from the datastore (see keeping and
> > resuming). This directory is deleted when the activity exits
> > (specifically, as soon as all children of the activity's first
> > process die)
> >
> > However, apparently in 0.106 this directory is not being deleted.
> >
> > Tony
> 
> --
> James Cameron
> [3]http://quozl.netrek.org/
> ___
> Sugar-devel mailing list
> [4]Sugar-devel@lists.sugarlabs.org
> [5]http://lists.sugarlabs.org/listinfo/sugar-devel
> 
> References:
> 
> [1] mailto:qu...@laptop.org
> [2] https://wiki.sugarlabs.org/go/Development_Team/Low-level_Activity_API
> [3] http://quozl.netrek.org/
> [4] mailto:Sugar-devel@lists.sugarlabs.org

Re: [Sugar-devel] activity instance directory

2016-01-20 Thread Gonzalo Odiard

A few issues:
* Browse already have a mechanism to remove the temporary downloaded files,
we need to know what is wrong [1].
* Temporary directories are shared between instances, if we remove
temporary directories
at activity start or stop, we need check if there are other instances of
the activity running.

Gonzalo

[1]
https://github.com/sugarlabs/browse-activity/blob/master/downloadmanager.py#L289

On Wed, Jan 20, 2016 at 6:38 AM, James Cameron  wrote:

> G'day Sam,
>
> The pull request I've made will handle a preserved .sugar directory on
> upgrade by deleting the directories the next time an activity is
> started, as well as when an activity is closed or crashes.
>
> Implemented in the shell, or sugar-launch, or activity to activity
> start, on behalf of the activity being started.
>
> That's option 2 and 4 from my previous post.
>
> Are there any activities that improperly depend on retaining data in
> these directories?
>
> On Wed, Jan 20, 2016 at 08:23:33PM +1100, Sam P. wrote:
> > Thanks for the good analysis James!
> >
> > I don't think that deleting on startup is an optimal idea.  It is
> > counter-intuitive that the user must open every activity on their
> computer when
> > they want to reclaim space.  It is also bad in the case of infrequently
> used
> > activities.
> >
> > I think that a multi-pronged approach would be better.  As you noted, the
> > activity clearing their tmp and instance folders themselves is optimal
> (option
> > 3).  I agree with this, as it takes load out of the shell process and
> means
> > that the filesystem space is reclaimed a quick as possible.
> >
> > However, to deal with the issue of crashing or non-sugar3 activities, we
> could
> > also delete ALL tmp and instance folders during the shutdown process
> (after
> > stopping all activities is successful).  In the best case, this should
> be as
> > quick as running ls on all of the folders (which is quick right?).  It
> also
> > helps users who are upgrading their system and preserving their .sugar
> > directory.  The shell does also not need to be responsive during
> shutdown.
> >
> > Thanks,
> > Sam
> >
> > On Wed, Jan 20, 2016 at 1:50 PM, James Cameron <[1]qu...@laptop.org>
> wrote:
> >
> > The API documentation was wrong, and has been edited.
> >
> > [2]
> https://wiki.sugarlabs.org/go/Development_Team/Low-level_Activity_API
> >
> > Rainbow did delete instance and tmp.  Sugar did not.
> >
> > Rainbow has not been in OLPC OS for some time.  (/etc/olpc-security
> > must exist, /usr/bin/rainbow-run must be executable).
> >
> > Rainbow is not in other builds that use Sugar.
> >
> > Sugar activities that were coded for Rainbow, and against this
> > documentation, will leave an instance and tmp directory on the
> > system.  Every activity.
> >
> > Sugar must delete both directories.
> >
> > The next question is when?
> >
> > 0.  on reinstall of OLPC OS, or reboot of SoaS,
> >
> > This is what we do at the moment.
> >
> > 1.  on Sugar start,
> >
> > cleanup_temporary_files in sugar:src/jarabe/main.py might be
> extended,
> > so that Sugar starts up and deletes the directories.
> >
> > Disadvantage is a small delay during Sugar start, the need to iterate
> > over the bundle ids, and which list of bundles to use.
> >
> > 2.  on activity start,
> >
> > The activity factory module function get_environment() in
> > sugar-toolkit-gtk3:src/sugar3/activity/activityfactory.py
> > might be extended to delete first, before making the directories.
> >
> > Disadvantage is a small delay during activity start.
> >
> > 3.  on activity close
> >
> > In the Activity class method _complete_close() in
> > src/sugar3/activity/activity.py we might delete the directories as
> the
> > activity is closing.
> >
> > Disadvantage is that an activity that crashes won't delete the
> > directories.
> >
> > Advantage is that any waste will be cleaned as soon as possible.
> >
> > 4.  on activity close in shell
> >
> > Disadvantage is that Sugar may be momentarily unresponsive when an
> > activity closes or crashes.
> >
> > Can we work toward a consensus?
> >
> > My preference is on activity start, since that is the last time it
> > must be done to be consistent with the design intent.  Are you
> > registered on github?
> >
> > On Tue, Jan 19, 2016 at 01:47:23AM +0200, Tony Anderson wrote:
> > > At a workshop I am giving in Rwanda, an XO got 'Journal Full'. It
> > > turns out that the Browse instance folder was using 1.2GB of store.
> > >
> > > The low-level API says:
> > >
> > > $SUGAR_ACTIVITY_ROOT/instance/
> > > This directory is used similar to a /var/tmp directory, being
> > > backed by flash rather than by RAM. It is unique per instance. It
> is
> > > used for transfer to and from the datastore (see keeping and
> > > resuming). This

Re: [Sugar-devel] activity instance directory

2016-01-19 Thread James Cameron

The API documentation was wrong, and has been edited.

https://wiki.sugarlabs.org/go/Development_Team/Low-level_Activity_API

Rainbow did delete instance and tmp.  Sugar did not.

Rainbow has not been in OLPC OS for some time.  (/etc/olpc-security
must exist, /usr/bin/rainbow-run must be executable).

Rainbow is not in other builds that use Sugar.

Sugar activities that were coded for Rainbow, and against this
documentation, will leave an instance and tmp directory on the
system.  Every activity.

Sugar must delete both directories.

The next question is when?

0.  on reinstall of OLPC OS, or reboot of SoaS,

This is what we do at the moment.

1.  on Sugar start,

cleanup_temporary_files in sugar:src/jarabe/main.py might be extended,
so that Sugar starts up and deletes the directories.

Disadvantage is a small delay during Sugar start, the need to iterate
over the bundle ids, and which list of bundles to use.

2.  on activity start,

The activity factory module function get_environment() in
sugar-toolkit-gtk3:src/sugar3/activity/activityfactory.py
might be extended to delete first, before making the directories.

Disadvantage is a small delay during activity start.

3.  on activity close

In the Activity class method _complete_close() in
src/sugar3/activity/activity.py we might delete the directories as the
activity is closing.

Disadvantage is that an activity that crashes won't delete the
directories.

Advantage is that any waste will be cleaned as soon as possible.

4.  on activity close in shell

Disadvantage is that Sugar may be momentarily unresponsive when an
activity closes or crashes.

Can we work toward a consensus?

My preference is on activity start, since that is the last time it
must be done to be consistent with the design intent.  Are you
registered on github?

On Tue, Jan 19, 2016 at 01:47:23AM +0200, Tony Anderson wrote:
> At a workshop I am giving in Rwanda, an XO got 'Journal Full'. It
> turns out that the Browse instance folder was using 1.2GB of store.
> 
> The low-level API says:
> 
> $SUGAR_ACTIVITY_ROOT/instance/
> This directory is used similar to a /var/tmp directory, being
> backed by flash rather than by RAM. It is unique per instance. It is
> used for transfer to and from the datastore (see keeping and
> resuming). This directory is deleted when the activity exits
> (specifically, as soon as all children of the activity's first
> process die)
> 
> However, apparently in 0.106 this directory is not being deleted.
> 
> Tony

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

Re: [Sugar-devel] activity icon in svg ?

2014-06-25 Thread Gonzalo Odiard

svg is needed


On Wed, Jun 25, 2014 at 8:11 AM, Puneet Kaur puneet.gk...@gmail.com wrote:

 Hey,

 Just wished to ask that is it necessary for the activity icon to be in svg
 ? or we can also have it in png / jpg format ?






 Thanks,
 Puneet

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




-- 
Gonzalo Odiard

SugarLabs - Software for children learning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] activity icon in svg ?

2014-06-25 Thread Puneet Kaur

Thanks :-)


On Wed, Jun 25, 2014 at 4:49 PM, Gonzalo Odiard godi...@sugarlabs.org
wrote:

 svg is needed


 On Wed, Jun 25, 2014 at 8:11 AM, Puneet Kaur puneet.gk...@gmail.com
 wrote:

 Hey,

 Just wished to ask that is it necessary for the activity icon to be in
 svg ? or we can also have it in png / jpg format ?






 Thanks,
 Puneet

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




 --
 Gonzalo Odiard

 SugarLabs - Software for children learning

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

Re: [Sugar-devel] activity icon in svg ?

2014-06-25 Thread Sam Parkinson

It is needed for the XO colors.  That is when the icons start to have the
same colors as your XO Person.

You can always embed an image as base 64 in a svg (just drag it in using
inkscape from memory).


On Wed, Jun 25, 2014 at 9:19 PM, Gonzalo Odiard godi...@sugarlabs.org
wrote:

 svg is needed


 On Wed, Jun 25, 2014 at 8:11 AM, Puneet Kaur puneet.gk...@gmail.com
 wrote:

 Hey,

 Just wished to ask that is it necessary for the activity icon to be in
 svg ? or we can also have it in png / jpg format ?






 Thanks,
 Puneet

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




 --
 Gonzalo Odiard

 SugarLabs - Software for children learning

 ___
 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] activity icon in svg ?

2014-06-25 Thread Gonzalo Odiard

But should not be needed
We want all the icons have the same style.

http://wiki.sugarlabs.org/go/Human_Interface_Guidelines/The_Sugar_Interface/Icons


On Wed, Jun 25, 2014 at 8:33 AM, Sam Parkinson sam.parkins...@gmail.com
wrote:

 It is needed for the XO colors.  That is when the icons start to have
 the same colors as your XO Person.

 You can always embed an image as base 64 in a svg (just drag it in using
 inkscape from memory).


 On Wed, Jun 25, 2014 at 9:19 PM, Gonzalo Odiard godi...@sugarlabs.org
 wrote:

 svg is needed


 On Wed, Jun 25, 2014 at 8:11 AM, Puneet Kaur puneet.gk...@gmail.com
 wrote:

 Hey,

 Just wished to ask that is it necessary for the activity icon to be in
 svg ? or we can also have it in png / jpg format ?






 Thanks,
 Puneet

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




 --
 Gonzalo Odiard

 SugarLabs - Software for children learning

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





-- 
Gonzalo Odiard

SugarLabs - Software for children learning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Activity Hiding

2014-06-19 Thread James Cameron

I've had some success by renaming the Activities/Activity1 directory to 
/home/olpc to hide an activity, and rename it back later.

Requires skill with Terminal activity.

e.g.

mv Activities/Chat.activity ~  # to hide

mv Chat.activity Activities/   # to show

Might cause errors, not sure.  Please test.

-- 
James Cameron
http://quozl.linux.org.au/
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Activity Hiding

2014-06-19 Thread Walter Bender

that'll work. It may leave some funny artifacts in the journal: entries
associated with missing activities, but otherwise, it is not really any
different than uninstalling/ reinstalling.

-walter


On Thu, Jun 19, 2014 at 6:12 AM, James Cameron qu...@laptop.org wrote:

 I've had some success by renaming the Activities/Activity1 directory to
 /home/olpc to hide an activity, and rename it back later.

 Requires skill with Terminal activity.

 e.g.

 mv Activities/Chat.activity ~  # to hide

 mv Chat.activity Activities/   # to show

 Might cause errors, not sure.  Please test.

 --
 James Cameron
 http://quozl.linux.org.au/
 ___
 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] Activity Idea

2014-05-10 Thread Walter Bender

maybe consider making this a webservice like the facebook webservice? See
wiki.sugarlabs.org/go/Webservices

regards

-walter


On Sat, May 10, 2014 at 12:26 PM, Kartik Kumar Perisetla 
kartik.p...@gmail.com wrote:

 Hi All,

 I am planning to work upon an sugar activity which will be an native Sugar
 app of SlideShare platform. This will enable children using Sugar to share
 presentations on content network(SlideShare).

 For the first cut, I am planning to include search, content viewer and
 offline storage of presentations. This will give advantage to children to
 save presentations for offline views.

 What do you think about it?

 Cheers!
 --
 Regards,

 Kartik Perisetla

 ___
 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] Activity Idea

2014-05-10 Thread Walter Bender

correct URL

wiki.sugarlabs.org/go/Web_Services

Putlocker or gdrive may be the best examples


On Sat, May 10, 2014 at 12:34 PM, Walter Bender walter.ben...@gmail.comwrote:

 maybe consider making this a webservice like the facebook webservice? See
 wiki.sugarlabs.org/go/Webservices

 regards

 -walter


 On Sat, May 10, 2014 at 12:26 PM, Kartik Kumar Perisetla 
 kartik.p...@gmail.com wrote:

 Hi All,

 I am planning to work upon an sugar activity which will be an native
 Sugar app of SlideShare platform. This will enable children using Sugar to
 share presentations on content network(SlideShare).

 For the first cut, I am planning to include search, content viewer and
 offline storage of presentations. This will give advantage to children to
 save presentations for offline views.

 What do you think about it?

 Cheers!
 --
 Regards,

 Kartik Perisetla

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




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




-- 
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] Activity Idea

Hi Walter,

So what I understand is we allow children to share/upload their content on
Slideshare through Web service(consuming SlideShare web service natively in
sugar inspite of a separate activity altogether). Like child can upload a
presentation through context menu on presentation within Sugar. right ?

But, I was also planning to include mechanism to give access to millions of
presentation on SlideShare and offline storage mechanism. I strongly feel
that the way Wikipedia proved beneficial, access to presentation will also
benefit them.

Feel free to share your inputs !

Thanks!




On Sat, May 10, 2014 at 6:07 PM, Walter Bender walter.ben...@gmail.comwrote:

 correct URL

 wiki.sugarlabs.org/go/Web_Services

 Putlocker or gdrive may be the best examples


 On Sat, May 10, 2014 at 12:34 PM, Walter Bender 
 walter.ben...@gmail.comwrote:

 maybe consider making this a webservice like the facebook webservice? See
 wiki.sugarlabs.org/go/Webservices

 regards

 -walter


 On Sat, May 10, 2014 at 12:26 PM, Kartik Kumar Perisetla 
 kartik.p...@gmail.com wrote:

 Hi All,

 I am planning to work upon an sugar activity which will be an native
 Sugar app of SlideShare platform. This will enable children using Sugar to
 share presentations on content network(SlideShare).

 For the first cut, I am planning to include search, content viewer and
 offline storage of presentations. This will give advantage to children to
 save presentations for offline views.

 What do you think about it?

 Cheers!
 --
 Regards,

 Kartik Perisetla

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




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




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




-- 
Regards,

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

Re: [Sugar-devel] Activity Idea

2014-05-10 Thread Walter Bender

On Sat, May 10, 2014 at 12:48 PM, Kartik Kumar Perisetla 
kartik.p...@gmail.com wrote:

 Hi Walter,

 So what I understand is we allow children to share/upload their content on
 Slideshare through Web service(consuming SlideShare web service natively in
 sugar inspite of a separate activity altogether). Like child can upload a
 presentation through context menu on presentation within Sugar. right ?

 But, I was also planning to include mechanism to give access to millions
 of presentation on SlideShare and offline storage mechanism. I strongly
 feel that the way Wikipedia proved beneficial, access to presentation will
 also benefit them.

 Feel free to share your inputs !


Why not both?


 Thanks!




 On Sat, May 10, 2014 at 6:07 PM, Walter Bender walter.ben...@gmail.comwrote:

 correct URL

 wiki.sugarlabs.org/go/Web_Services

 Putlocker or gdrive may be the best examples


 On Sat, May 10, 2014 at 12:34 PM, Walter Bender 
 walter.ben...@gmail.comwrote:

 maybe consider making this a webservice like the facebook webservice?
 See wiki.sugarlabs.org/go/Webservices

 regards

 -walter


 On Sat, May 10, 2014 at 12:26 PM, Kartik Kumar Perisetla 
 kartik.p...@gmail.com wrote:

 Hi All,

 I am planning to work upon an sugar activity which will be an native
 Sugar app of SlideShare platform. This will enable children using Sugar to
 share presentations on content network(SlideShare).

 For the first cut, I am planning to include search, content viewer and
 offline storage of presentations. This will give advantage to children to
 save presentations for offline views.

 What do you think about it?

 Cheers!
 --
 Regards,

 Kartik Perisetla

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




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




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




 --
 Regards,

 Kartik Perisetla




-- 
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] Activity Idea

+1
Sure !

I assume I should be able to see and use facebook, twitter and Google Drive
web service within sugar which I am getting from here:
http://sugarlabs.org/~buildbot/docs/dev-environment.md.html

Please let me know whether I am cloning the right version of sugar to get
feel of web services within sugar.


Thanks,
Kartik


On Sat, May 10, 2014 at 6:25 PM, Walter Bender walter.ben...@gmail.comwrote:




 On Sat, May 10, 2014 at 12:48 PM, Kartik Kumar Perisetla 
 kartik.p...@gmail.com wrote:

 Hi Walter,

 So what I understand is we allow children to share/upload their content
 on Slideshare through Web service(consuming SlideShare web service natively
 in sugar inspite of a separate activity altogether). Like child can upload
 a presentation through context menu on presentation within Sugar. right ?

 But, I was also planning to include mechanism to give access to millions
 of presentation on SlideShare and offline storage mechanism. I strongly
 feel that the way Wikipedia proved beneficial, access to presentation will
 also benefit them.

 Feel free to share your inputs !


 Why not both?


 Thanks!




 On Sat, May 10, 2014 at 6:07 PM, Walter Bender 
 walter.ben...@gmail.comwrote:

 correct URL

 wiki.sugarlabs.org/go/Web_Services

 Putlocker or gdrive may be the best examples


 On Sat, May 10, 2014 at 12:34 PM, Walter Bender walter.ben...@gmail.com
  wrote:

 maybe consider making this a webservice like the facebook webservice?
 See wiki.sugarlabs.org/go/Webservices

 regards

 -walter


 On Sat, May 10, 2014 at 12:26 PM, Kartik Kumar Perisetla 
 kartik.p...@gmail.com wrote:

 Hi All,

 I am planning to work upon an sugar activity which will be an native
 Sugar app of SlideShare platform. This will enable children using Sugar to
 share presentations on content network(SlideShare).

 For the first cut, I am planning to include search, content viewer and
 offline storage of presentations. This will give advantage to children to
 save presentations for offline views.

 What do you think about it?

 Cheers!
 --
 Regards,

 Kartik Perisetla

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




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




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




 --
 Regards,

 Kartik Perisetla




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




-- 
Regards,

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

Re: [Sugar-devel] Activity Idea

2014-05-10 Thread Ignacio Rodríguez

 Please let me know whether I am cloning the right version of sugar to get
feel of web services within sugar.

Yes, the GitHub repositories are the most latest
https://github.com/sugarlabs

More information about Web Services (You can ask here, in the list :))
http://wiki.sugarlabs.org/go/Web_Services

Ignacio Rodríguez
fb.com/Ignacio.Rodriguez.UY
@NachoDeTodos https://twitter.com/NachoDeTodos
nachoe...@gmail.com


2014-05-10 10:10 GMT-03:00 Kartik Kumar Perisetla kartik.p...@gmail.com:

 +1
 Sure !

 I assume I should be able to see and use facebook, twitter and Google
 Drive web service within sugar which I am getting from here:
 http://sugarlabs.org/~buildbot/docs/dev-environment.md.html

 Please let me know whether I am cloning the right version of sugar to get
 feel of web services within sugar.


 Thanks,
 Kartik


 On Sat, May 10, 2014 at 6:25 PM, Walter Bender walter.ben...@gmail.comwrote:




 On Sat, May 10, 2014 at 12:48 PM, Kartik Kumar Perisetla 
 kartik.p...@gmail.com wrote:

 Hi Walter,

 So what I understand is we allow children to share/upload their content
 on Slideshare through Web service(consuming SlideShare web service natively
 in sugar inspite of a separate activity altogether). Like child can upload
 a presentation through context menu on presentation within Sugar. right ?

 But, I was also planning to include mechanism to give access to millions
 of presentation on SlideShare and offline storage mechanism. I strongly
 feel that the way Wikipedia proved beneficial, access to presentation will
 also benefit them.

 Feel free to share your inputs !


 Why not both?


 Thanks!




 On Sat, May 10, 2014 at 6:07 PM, Walter Bender 
 walter.ben...@gmail.comwrote:

 correct URL

 wiki.sugarlabs.org/go/Web_Services

 Putlocker or gdrive may be the best examples


 On Sat, May 10, 2014 at 12:34 PM, Walter Bender 
 walter.ben...@gmail.com wrote:

 maybe consider making this a webservice like the facebook webservice?
 See wiki.sugarlabs.org/go/Webservices

 regards

 -walter


 On Sat, May 10, 2014 at 12:26 PM, Kartik Kumar Perisetla 
 kartik.p...@gmail.com wrote:

 Hi All,

 I am planning to work upon an sugar activity which will be an native
 Sugar app of SlideShare platform. This will enable children using Sugar 
 to
 share presentations on content network(SlideShare).

 For the first cut, I am planning to include search, content viewer
 and offline storage of presentations. This will give advantage to 
 children
 to save presentations for offline views.

 What do you think about it?

 Cheers!
 --
 Regards,

 Kartik Perisetla

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




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




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




 --
 Regards,

 Kartik Perisetla




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




 --
 Regards,

 Kartik Perisetla

 ___
 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] Activity Idea

Thanks Ignacio ! :)
Saw your video as well: http://www.youtube.com/watch?v=vw_SiGs6nEc


Thanks !
Kartik


On Sat, May 10, 2014 at 7:18 PM, Ignacio Rodríguez nachoe...@gmail.comwrote:

  Please let me know whether I am cloning the right version of sugar to
 get feel of web services within sugar.

 Yes, the GitHub repositories are the most latest
 https://github.com/sugarlabs

 More information about Web Services (You can ask here, in the list :))
 http://wiki.sugarlabs.org/go/Web_Services

 Ignacio Rodríguez
 fb.com/Ignacio.Rodriguez.UY
 @NachoDeTodos https://twitter.com/NachoDeTodos
 nachoe...@gmail.com


 2014-05-10 10:10 GMT-03:00 Kartik Kumar Perisetla kartik.p...@gmail.com:

  +1
 Sure !

 I assume I should be able to see and use facebook, twitter and Google
 Drive web service within sugar which I am getting from here:
 http://sugarlabs.org/~buildbot/docs/dev-environment.md.html

 Please let me know whether I am cloning the right version of sugar to get
 feel of web services within sugar.


 Thanks,
 Kartik


 On Sat, May 10, 2014 at 6:25 PM, Walter Bender 
 walter.ben...@gmail.comwrote:




 On Sat, May 10, 2014 at 12:48 PM, Kartik Kumar Perisetla 
 kartik.p...@gmail.com wrote:

 Hi Walter,

 So what I understand is we allow children to share/upload their content
 on Slideshare through Web service(consuming SlideShare web service natively
 in sugar inspite of a separate activity altogether). Like child can upload
 a presentation through context menu on presentation within Sugar. right ?

 But, I was also planning to include mechanism to give access to
 millions of presentation on SlideShare and offline storage mechanism. I
 strongly feel that the way Wikipedia proved beneficial, access to
 presentation will also benefit them.

 Feel free to share your inputs !


 Why not both?


 Thanks!




 On Sat, May 10, 2014 at 6:07 PM, Walter Bender walter.ben...@gmail.com
  wrote:

 correct URL

 wiki.sugarlabs.org/go/Web_Services

 Putlocker or gdrive may be the best examples


 On Sat, May 10, 2014 at 12:34 PM, Walter Bender 
 walter.ben...@gmail.com wrote:

 maybe consider making this a webservice like the facebook webservice?
 See wiki.sugarlabs.org/go/Webservices

 regards

 -walter


 On Sat, May 10, 2014 at 12:26 PM, Kartik Kumar Perisetla 
 kartik.p...@gmail.com wrote:

 Hi All,

 I am planning to work upon an sugar activity which will be an native
 Sugar app of SlideShare platform. This will enable children using Sugar 
 to
 share presentations on content network(SlideShare).

 For the first cut, I am planning to include search, content viewer
 and offline storage of presentations. This will give advantage to 
 children
 to save presentations for offline views.

 What do you think about it?

 Cheers!
 --
 Regards,

 Kartik Perisetla

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




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




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




 --
 Regards,

 Kartik Perisetla




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




 --
 Regards,

 Kartik Perisetla

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





-- 
Regards,

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

Re: [Sugar-devel] Activity Idea

Hi,

When I am trying to access ~/.sugar/default from terminal in order to
install web service it gives me an error:
[image: Inline image 1]

Also, If I manually create that directory structure, the web service is not
listed under Configure web service section.

Any help will be appreciated.

Thanks!
Kartik Perisetla


On Sat, May 10, 2014 at 7:21 PM, Kartik Kumar Perisetla 
kartik.p...@gmail.com wrote:

 Thanks Ignacio ! :)
 Saw your video as well: http://www.youtube.com/watch?v=vw_SiGs6nEc


 Thanks !
 Kartik


 On Sat, May 10, 2014 at 7:18 PM, Ignacio Rodríguez nachoe...@gmail.comwrote:

  Please let me know whether I am cloning the right version of sugar to
 get feel of web services within sugar.

 Yes, the GitHub repositories are the most latest
 https://github.com/sugarlabs

 More information about Web Services (You can ask here, in the list :))
 http://wiki.sugarlabs.org/go/Web_Services

 Ignacio Rodríguez
 fb.com/Ignacio.Rodriguez.UY
 @NachoDeTodos https://twitter.com/NachoDeTodos
 nachoe...@gmail.com


 2014-05-10 10:10 GMT-03:00 Kartik Kumar Perisetla kartik.p...@gmail.com
 :

  +1
 Sure !

 I assume I should be able to see and use facebook, twitter and Google
 Drive web service within sugar which I am getting from here:
 http://sugarlabs.org/~buildbot/docs/dev-environment.md.html

 Please let me know whether I am cloning the right version of sugar to
 get feel of web services within sugar.


 Thanks,
 Kartik


 On Sat, May 10, 2014 at 6:25 PM, Walter Bender 
 walter.ben...@gmail.comwrote:




 On Sat, May 10, 2014 at 12:48 PM, Kartik Kumar Perisetla 
 kartik.p...@gmail.com wrote:

 Hi Walter,

 So what I understand is we allow children to share/upload their
 content on Slideshare through Web service(consuming SlideShare web service
 natively in sugar inspite of a separate activity altogether). Like child
 can upload a presentation through context menu on presentation within
 Sugar. right ?

 But, I was also planning to include mechanism to give access to
 millions of presentation on SlideShare and offline storage mechanism. I
 strongly feel that the way Wikipedia proved beneficial, access to
 presentation will also benefit them.

 Feel free to share your inputs !


 Why not both?


 Thanks!




 On Sat, May 10, 2014 at 6:07 PM, Walter Bender 
 walter.ben...@gmail.com wrote:

 correct URL

 wiki.sugarlabs.org/go/Web_Services

 Putlocker or gdrive may be the best examples


 On Sat, May 10, 2014 at 12:34 PM, Walter Bender 
 walter.ben...@gmail.com wrote:

 maybe consider making this a webservice like the facebook
 webservice? See wiki.sugarlabs.org/go/Webservices

 regards

 -walter


 On Sat, May 10, 2014 at 12:26 PM, Kartik Kumar Perisetla 
 kartik.p...@gmail.com wrote:

 Hi All,

 I am planning to work upon an sugar activity which will be an
 native Sugar app of SlideShare platform. This will enable children 
 using
 Sugar to share presentations on content network(SlideShare).

 For the first cut, I am planning to include search, content viewer
 and offline storage of presentations. This will give advantage to 
 children
 to save presentations for offline views.

 What do you think about it?

 Cheers!
 --
 Regards,

 Kartik Perisetla

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




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




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




 --
 Regards,

 Kartik Perisetla




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




 --
 Regards,

 Kartik Perisetla

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





 --
 Regards,

 Kartik Perisetla




-- 
Regards,

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

Re: [Sugar-devel] Activity Idea

2014-05-10 Thread Ignacio Rodríguez

No no.. Its normal because I've simulate that was on XO

Go: cd ~/sugar-build/home/default/.sugar

I think

(I dont remember now)

Ignacio Rodríguez
fb.com/Ignacio.Rodriguez.UY
@NachoDeTodos https://twitter.com/NachoDeTodos
nachoe...@gmail.com


2014-05-10 11:12 GMT-03:00 Kartik Kumar Perisetla kartik.p...@gmail.com:

 Hi,

 When I am trying to access ~/.sugar/default from terminal in order to
 install web service it gives me an error:
 [image: Inline image 1]

 Also, If I manually create that directory structure, the web service is
 not listed under Configure web service section.

 Any help will be appreciated.

 Thanks!
 Kartik Perisetla


 On Sat, May 10, 2014 at 7:21 PM, Kartik Kumar Perisetla 
 kartik.p...@gmail.com wrote:

 Thanks Ignacio ! :)
 Saw your video as well: http://www.youtube.com/watch?v=vw_SiGs6nEc


 Thanks !
 Kartik


 On Sat, May 10, 2014 at 7:18 PM, Ignacio Rodríguez 
 nachoe...@gmail.comwrote:

  Please let me know whether I am cloning the right version of sugar to
 get feel of web services within sugar.

 Yes, the GitHub repositories are the most latest
 https://github.com/sugarlabs

 More information about Web Services (You can ask here, in the list :))
 http://wiki.sugarlabs.org/go/Web_Services

 Ignacio Rodríguez
 fb.com/Ignacio.Rodriguez.UY
 @NachoDeTodos https://twitter.com/NachoDeTodos
 nachoe...@gmail.com


 2014-05-10 10:10 GMT-03:00 Kartik Kumar Perisetla kartik.p...@gmail.com
 :

  +1
 Sure !

 I assume I should be able to see and use facebook, twitter and Google
 Drive web service within sugar which I am getting from here:
 http://sugarlabs.org/~buildbot/docs/dev-environment.md.html

 Please let me know whether I am cloning the right version of sugar to
 get feel of web services within sugar.


 Thanks,
 Kartik


 On Sat, May 10, 2014 at 6:25 PM, Walter Bender walter.ben...@gmail.com
  wrote:




 On Sat, May 10, 2014 at 12:48 PM, Kartik Kumar Perisetla 
 kartik.p...@gmail.com wrote:

 Hi Walter,

 So what I understand is we allow children to share/upload their
 content on Slideshare through Web service(consuming SlideShare web 
 service
 natively in sugar inspite of a separate activity altogether). Like child
 can upload a presentation through context menu on presentation within
 Sugar. right ?

 But, I was also planning to include mechanism to give access to
 millions of presentation on SlideShare and offline storage mechanism. I
 strongly feel that the way Wikipedia proved beneficial, access to
 presentation will also benefit them.

 Feel free to share your inputs !


 Why not both?


 Thanks!




 On Sat, May 10, 2014 at 6:07 PM, Walter Bender 
 walter.ben...@gmail.com wrote:

 correct URL

 wiki.sugarlabs.org/go/Web_Services

 Putlocker or gdrive may be the best examples


 On Sat, May 10, 2014 at 12:34 PM, Walter Bender 
 walter.ben...@gmail.com wrote:

 maybe consider making this a webservice like the facebook
 webservice? See wiki.sugarlabs.org/go/Webservices

 regards

 -walter


 On Sat, May 10, 2014 at 12:26 PM, Kartik Kumar Perisetla 
 kartik.p...@gmail.com wrote:

 Hi All,

 I am planning to work upon an sugar activity which will be an
 native Sugar app of SlideShare platform. This will enable children 
 using
 Sugar to share presentations on content network(SlideShare).

 For the first cut, I am planning to include search, content viewer
 and offline storage of presentations. This will give advantage to 
 children
 to save presentations for offline views.

 What do you think about it?

 Cheers!
 --
 Regards,

 Kartik Perisetla

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




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




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




 --
 Regards,

 Kartik Perisetla




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




 --
 Regards,

 Kartik Perisetla

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





 --
 Regards,

 Kartik Perisetla




 --
 Regards,

 Kartik Perisetla

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

Re: [Sugar-devel] Activity failed to start!

2014-03-23 Thread Daniel Narvaez

Try to run sugar-launch inside a sugar terminal, it doesn't work outside
sugar.

On Saturday, 22 March 2014, Kamal Kaur kamal.kaur...@gmail.com wrote:

 Hello developers

 Can you please help me know the right way to download/install
 activities in sugar? I downloaded Etoys and Develop 40 from
 http://activities.sugarlabs.org/en-US/sugar/ from browser activity.
 Both are shown in journal. But when opened, activity icon flashes and
 there is a message: Activity failed to start Stop [ ] ( with stop
 button.

 Even I couldn't find the logs in log activity. While trying to find it
 out, I reached here:
 http://wiki.laptop.org/go/Python_Standard_Logging_in_Sugar

 And from the above link, I tried 'sugar-launch activity-name'
 command. Which gave the output:

 kamal@kamal:~/sugar-build$ sugar-launch Etoys
 The program 'sugar-launch' can be found in the following packages:
  * sugar-tools-0.84
  * sugar-tools-0.86
  * sugar-tools-0.88
  * sugar-tools-0.90
  * sugar-tools-0.96
 Try: sudo apt-get install selected package

 So I used apt-get to install Etoys. It has downloaded 44.3MBs data.
 But the same problem is there.

 What I'm doing wrong?




 --
 Kamaljeet Kaur

 kamalkaur188.wordpress.com
 ___
 Sugar-devel mailing list
 Sugar-devel@lists.sugarlabs.org javascript:;
 http://lists.sugarlabs.org/listinfo/sugar-devel



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

Re: [Sugar-devel] Activity failed to start!

2014-03-23 Thread Gonzalo Odiard

On Sat, Mar 22, 2014 at 7:46 PM, Kamal Kaur kamal.kaur...@gmail.com wrote:

 Hello developers

 Can you please help me know the right way to download/install
 activities in sugar? I downloaded Etoys and Develop 40 from
 http://activities.sugarlabs.org/en-US/sugar/ from browser activity.
 Both are shown in journal. But when opened, activity icon flashes and
 there is a message: Activity failed to start Stop [ ] ( with stop
 button.


To know where the logs are see:

http://developer.sugarlabs.org/dev-environment.md.html#dotsugar

Probably Develop  etoys problems are different.

If Develop log show simplejson import error, see this thread:
http://lists.sugarlabs.org/archive/sugar-devel/2014-February/047271.html

the error is already solved in git (git.sugarlabs.org/develop)
and a new release is planed soon, probably, next week.

About etoys, can you tell us what version are you using?
etoys need squeak vm. maybe is not available in your system or
the version don't match?

Gonzalo


 Even I couldn't find the logs in log activity. While trying to find it
 out, I reached here:
 http://wiki.laptop.org/go/Python_Standard_Logging_in_Sugar

 And from the above link, I tried 'sugar-launch activity-name'
 command. Which gave the output:

 kamal@kamal:~/sugar-build$ sugar-launch Etoys
 The program 'sugar-launch' can be found in the following packages:
  * sugar-tools-0.84
  * sugar-tools-0.86
  * sugar-tools-0.88
  * sugar-tools-0.90
  * sugar-tools-0.96
 Try: sudo apt-get install selected package

 So I used apt-get to install Etoys. It has downloaded 44.3MBs data.
 But the same problem is there.

 What I'm doing wrong?




 --
 Kamaljeet Kaur

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




-- 
Gonzalo Odiard

SugarLabs - Learning Software for children
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Activity Central's Sugar related priorities.

2013-11-06 Thread Daniel Narvaez

On 22 October 2013 21:41, NoiseEHC noise...@gmail.com wrote:

  You are right. The problem is that my views are exactly the opposite of
 the decided path to take.


I don't think that's true.

I'm one of the three developers involved in the web activities work and I
like many of your ideas. Manuel in his reply appeared to be interested too.
I have the feeling that if you look into it some more you might see the
paths are not that different. But even if you really think we got it all
wrong , I'd say we have been mostly researching so far... there is
certainly space to fix the direction.

Please get involved. Post your thoughts (constructive or not) when we
discuss topics we have been researching (I'd say we did that for any non
trivial topic so far). Make proposals, send patches.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Activity Central's Sugar related priorities.

2013-10-22 Thread NoiseEHC


Hi!

Took some time but finally set up my git account...


2 Journal

This is probably the issue we have been most aware of. I've been 
thinking in the per activity datastore direction too and I think it's 
probably the best one. Though as you say that involves UI redesign and 
we would need to figure out compatibility with existing activities. 
(Please share the webkit code, I don't know if I'll have time to hack 
on it but I did think to write something like that at some point, it 
would be interesting to look at it if nothing else).




I have put the ?latest? sources here:
https://github.com/NoiseEHC/sugar-webkit-native
It requires a yum install webkitgtk3-devel to be able to compile, 
unfortunately my XO-1.75 says that there are no more mirrors to try for 
mesa and libdrm dependencies so I could not try it under an ARM XO... (I 
did try it some time ago however it just stopped working.)
You may also need to create a test2/bin directory as git does not 
include it...
The code is full of static char buffers which should be fixed and it 
also crashes on an XO when you compile with webkit2gtk...




We probably all agree that it would be awesome to have something  that 
integrates well with Sugar and works transparently by reusing existing 
web technologies. I don't think that's easy to achieve though. It has 
been said in previous discussions that without the close integration 
between activities and system, Sugar would be just yet another suite 
of educational applications (and likely not the best of them). I very 
much agree and I think it's tricky to preserve that while moving to 
frameworks which are supposed to work everywhere.


We could have started with something more web developer friendly and 
incrementally integrated it into the native Sugar platform, for 
example by redesigning the Journal in the way you described, and 
somehow adapting native activities to the new design. Instead we went 
for something targeted at the current Sugar developers with the idea 
of making it incrementally more web friendly.


I have been on the fence on what was the best approach and I still am. 
Something to consider is that we barely have the resources to maintain 
the existing native code. I doubt, for example, that we would be able 
to ship a redesigned Journal. Consider also that the people most 
involved with this work has all a good knowledge of the Sugar platform 
but are not really web developers.




I fail to see why would it be bad if Sugar would be just yet another 
suite of educational applications. Currently the close integration 
between activities and system consist only of 3 DBUS methods, 4 X 
properties, the Journal as a filesystem and the presence service (which 
is desugarized if I remember correctly, you have to use Telepathy 
directly?). In my opinion the single most important thing would be to 
allow developing sugar applications directly in the PC browser (like 
firefox or chrome). If that would work then you could just go to a web 
conference and after giving a presentation about sugar-web you could ask 
the attended crowd to help you in the workshop by converting just 
ONE/person python activity into a web one and you are done with the 
conversion in a day... Obviously it would not make converting 
Write/TurtleArt/Etoys/Scratch easy but at least the rest would be done.


Now, if you go standard web, then you do not need the X properties, 
view-source is built into the browser (DBUS HandleViewSource) and DBUS 
SetActive can be done with webkitvisibilitychange event and timers. 
The only remaining thing would be handling the DBUS Invite.
Collaboration would most likely need an OT library which should have a C 
implementation on the XO to have usable speed.
The Journal simply can be implemented by the host application by 
providing either some standard file API implementation (like 
light-swift) or just providing a virtual page with links and POST.

https://github.com/bancek/light-swift

So if you already run a node.js server then probably it could host the 
activity's html files and could provide some virtual file GET/POST 
service in

http://localhost/journal/directory.json - this is for file list
http://localhost/journal/guidcomeshere - this is for GET/POST files

My plan was to support http://localhost directly from 
sugar-webkit-native (instead using file:// to be able to OAuth) and 
query/update the journal from there too but it is simpler from node.js 
if you are running it anyways. You can also assume that web developers 
have node.js running on their dev machine or already know how to install 
it. If you forget for a while to have collaboration from web apps then 
the rest can be done in no time IMHO.


So that was my $0.02. Obviously it can be too late to change plans but 
who knows. I have uploaded the source anyway so you can use it if you want.


Regards,
Andrew


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org

Re: [Sugar-devel] Activity Central's Sugar related priorities.

2013-10-22 Thread Gonzalo Odiard



 So that was my $0.02. Obviously it can be too late to change plans but who
 knows. I have uploaded the source anyway so you can use it if you want.


What I really don't understand is, if is all that easy why not be involved
and help?
The development of the web activities stuff was done in the open, mostly by
two developers,
manuq  dnarvaez. Then everyone who wanted help, could do it.
Say now how should be done, is  useless at least.
Talk is easy... as always, the devil is in the details. But you already
know that,
if not would not talk about unconstructive criticism

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

Re: [Sugar-devel] Activity Central's Sugar related priorities.

2013-10-22 Thread NoiseEHC




I have put the ?latest? sources here:
https://github.com/NoiseEHC/sugar-webkit-native
It requires a yum install webkitgtk3-devel to be able to compile, 
unfortunately my XO-1.75 says that there are no more mirrors to try 
for mesa and libdrm dependencies so I could not try it under an ARM 
XO... (I did try it some time ago however it just stopped working.)
You may also need to create a test2/bin directory as git does not 
include it...
The code is full of static char buffers which should be fixed and it 
also crashes on an XO when you compile with webkit2gtk...


Ehem, the source should be in a directory called test2 so it matches the 
name in the .info file... That is why it requires a test/bin subdir...

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

Re: [Sugar-devel] Activity Central's Sugar related priorities.

2013-10-22 Thread NoiseEHC


On 22/10/2013 21:21, Gonzalo Odiard wrote:



So that was my $0.02. Obviously it can be too late to change plans
but who knows. I have uploaded the source anyway so you can use it
if you want.


What I really don't understand is, if is all that easy why not be 
involved and help?
The development of the web activities stuff was done in the open, 
mostly by two developers,

manuq  dnarvaez. Then everyone who wanted help, could do it.
Say now how should be done, is  useless at least.
Talk is easy... as always, the devil is in the details. But you 
already know that,

if not would not talk about unconstructive criticism

Gonzalo



You are right. The problem is that my views are exactly the opposite of 
the decided path to take. I do not help developing because I totally 
oppose the current path, meaning that I do not believe that it can work. 
All the easy talk can be useful later *if* they decide to change paths. 
Or it will just remain an interesting viewpoint, but at least I tried.
So while you are right about the Talk is easy part as well, I could 
only help developing by finishing the native webkit app (because I 
believe in it), which would be totally wasted (parallel) effort. 
Actually that was the plan but then I run out of time and realized that 
the official project went a different direction anyway.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Activity Central's Sugar related priorities.

2013-10-17 Thread Manuel Quiñones

Hi NoiseEHC,

No, it won't... It already happened when Bryan Berry moved OLPC Nepal's
lessons from EToys to Flash, then to HTML5 and there were not any more
contributors. I mean, there are much more JS developers, so if you pay them
you can get cheaper talent, but there will be not too much more contributors
IMHO. The problem is that the current HTML5 work goes into a direction which
I am not sure that needed by anyone other than existing Sugar developers.

Well we are trying to go in the direction you mention below, that is
standard web development. So thanks for jumping in.

It all boils down to this simple question:
If you are a potential contributor wanting to develop some educational
activity (not a framework but some concrete lesson or stuff usable in a
lesson!!!) then which one would you use?
1. A HTML5 + JavaScript activity model called Sugar Web Activity, which
reaches 2-3 million children? (lets call it SWA)
2. A HTML5 + JavaScript activity model called HTML5 + JavaScript, which
reaches 1 billion children? (lets call it WEB)
I have not seen any compelling reason why would a potential contributor
(software developer from a developed country who has/likes children) choose
option 1 instead of 2...

Yes, option two... ideally. We should tend to zero Sugar specific
functionallities. I think it is a good compromise what we did: start
from simple web activities that already work side by side with GTK
ones, and tend to standard webapps.

Now I will not give you constructive criticism as that would allow answering
that I should not tell others what to do and it would be getting old...
Instead here is some nonconstructive criticism:

I think each of the following items deserve a thread on its own. Feel
free to continue discussion.

Some months ago I wanted to create a sample activity to present my point but
I have run out of time so unfortunately I cannot show it to you. It would
have been a Google Drive backed game with shared state (so the same as a
typical shared activity in Sugar) called Scrabble what I try to port to SWA.
It uses the following things which are trivial to use on the WEB but cannot
be found in SWA:

As far as I understand, Google Drive is an online service. Please
note that we are targetting offline webapps, as Sugar is meant to work
without an Internet connection. Of course it is not forbidden. And
Drive could be a nice datastore backend. But not the only one.

1. Sign in. There is no authorization API in SWA so using anything than the
local journal is problematic. Using Google's OAuth authentication from a
file:// protocol is impossible so if you want to support existing code then
you have to serve the activity from http://localhost...
https://developers.google.com/drive/about-auth

Daniel gave a good reply to this one.

2. Datastore. There is no way to access the Google Drive if you cannot
authenticate. I do not see why would anyone use a new JavaScript lib which
accesses only the journal when they are already familiar with some WEB
technology. Like WEBDAV or the OpenStack's SWIFT API.
http://docs.openstack.org/api/openstack-object-storage/1.0/content/storage-object-services.html

Nice. Reading about the WebDAV protocol and OpenStack SWIFT API.

Or simply using POST for uploading:
https://developers.google.com/drive/manage-uploads

Yeah, good point.

3. Collaboration. Using the Google Drive Realtime API is dead simple. It is
the most missing feature from SWA BTW.
https://developers.google.com/drive/realtime/

Interesting. It requires Internet.

I have looked at several open source Operational Transformations libraries
but did not have time to test their performance on an XO...

4. Using WebSockets for simple tasks. The autosaving can be implemented by
the almost standard webkitvisibilitychange event (but you have to compile
webkit with the appropriate parameters) and standard timers. Activity
startup is simplified with per activity data store (POST-ing to the same
server is the default on the WEB). I think it eliminates the communication
with Sugar so no need for WebSockets...

5. Android port. There already exists a multi-platform technology called
PhoneGap. It can target 100-200 million children so it can be called option
3 if you want... It can become obsolete as HTML5 provides more and more of
its features though.
http://phonegap.com/

So as I see you either create a framework which mimics Sugar and no web
developer will use it or create a framework which implements what a web
developer is already using or at least tries to somehow emulate it. So the
web developer does not have to modify his/her code and will consider porting
his/her application for a smaller platform. Of course that would require
OLPC/Sugarlabs to run free OpenStack/OAuth/OT servers for contributors
otherwise everybody will go with Google APIs which cannot easily be emulated
on an XO machine...

So, running and using those servers is what

Re: [Sugar-devel] Activity Central's Sugar related priorities.

2013-10-09 Thread NoiseEHC

On 07/10/2013 18:41, David Farning wrote:

Activity Central supports the recent HTML5 + JS work that is going
into sugar .100. It has the potential to take the OLPC vision to any
device which runs a browser while simultaneously *increasing* the
potential activity *developer* *pool* by several orders of magnitude. This
is an excellent area for community lead research. Activity Central
will be doing activity side work to test the viability of the
framework for client deployments.

No, it won't... It already happened when Bryan Berry moved OLPC Nepal's
lessons from EToys to Flash, then to HTML5 and there were not any more
contributors. I mean, there are much more JS developers, so if you pay
them you can get cheaper talent, but there will be not too much more
contributors IMHO. The problem is that the current HTML5 work goes into
a direction which I am not sure that needed by anyone other than
existing Sugar developers.

Now I will not give you constructive criticism as that would allow
answering that I should not tell others what to do and it would be
getting old... Instead here is some nonconstructive criticism:

Some months ago I wanted to create a sample activity to present my point
but I have run out of time so unfortunately I cannot show it to you. It
would have been a Google Drive backed game with shared state (so the
same as a typical shared activity in Sugar) called Scrabble what I try
to port to SWA. It uses the following things which are trivial to use on
the WEB but cannot be found in SWA:

1. Sign in. There is no authorization API in SWA so using anything than
the local journal is problematic. Using Google's OAuth authentication
from a file:// protocol is impossible so if you want to support existing
code then you have to serve the activity from http://localhost...

https://developers.google.com/drive/about-auth

2. Datastore. There is no way to access the Google Drive if you cannot
authenticate. I do not see why would anyone use a new JavaScript lib
which accesses only the journal when they are already familiar with some
WEB technology. Like WEBDAV or the OpenStack's SWIFT API.

http://docs.openstack.org/api/openstack-object-storage/1.0/content/storage-object-services.html
Or simply using POST for uploading:
https://developers.google.com/drive/manage-uploads

3. Collaboration. Using the Google Drive Realtime API is dead simple. It
is the most missing feature from SWA BTW.

https://developers.google.com/drive/realtime/
I have looked at several open source Operational Transformations
libraries but did not have time to test their performance on an XO...

4. Using WebSockets for simple tasks. The autosaving can be implemented
by the almost standard webkitvisibilitychange event (but you have to
compile webkit with the appropriate parameters) and standard timers.
Activity startup is simplified with per activity data store (POST-ing to
the same server is the default on the WEB). I think it eliminates the
communication with Sugar so no need for WebSockets...

5. Android port. There already exists a multi-platform technology called
PhoneGap. It can target 100-200 million children so it can be called
option 3 if you want... It can become obsolete as HTML5 provides more
and more of its features though.

http://phonegap.com/

So as I see you either create a framework which mimics Sugar and no web
developer will use it or create a framework which implements what a web
developer is already using or at least tries to somehow emulate it. So
the web developer does not have to modify his/her code and will consider
porting his/her application for a smaller platform. Of course that would
require OLPC/Sugarlabs to run free OpenStack/OAuth/OT servers for
contributors otherwise everybody will go with Google APIs which cannot
easily be emulated on an XO machine...

But as this discussion already happened and I have already written
enough now, I just finish here. (In the following link you can replace
the phrase Per Activity Data Store with Standard WEB Storage to be
relevant...)

http://lists.sugarlabs.org/archive/sugar-devel/2010-June/024589.html

Thank you for your attention!
Andrew

ps:
Now to say something constructive as well, some more words about the
Journal. Recently I was watching one of Walter Bender's talks where he
was

Re: [Sugar-devel] Activity Central's Sugar related priorities.

2013-10-09 Thread Daniel Narvaez

On 9 October 2013 22:51, NoiseEHC noise...@gmail.com wrote:

 Now I will not give you constructive criticism as that would allow
 answering that I should not tell others what to do and it would be
 getting old... Instead here is some nonconstructive criticism:


I don't know if it's constructive or not, but I'd say it's certainly
useful. You are identifying the major limitations of the current sugar-web
framework. Just some notes about them.

1 Inability to do OAuth

This has been discussed for Firefox OS too and as far as I know there is no
good solution for it yet. I won't claim to understand all the security
implications, tough the basic issue seems to run content from the web
inside an higher privileged application. In our case it's worst because we
don't support hosted web applications at all.

2 Journal

This is probably the issue we have been most aware of. I've been thinking
in the per activity datastore direction too and I think it's probably the
best one. Though as you say that involves UI redesign and we would need to
figure out compatibility with existing activities. (Please share the webkit
code, I don't know if I'll have time to hack on it but I did think to write
something like that at some point, it would be interesting to look at it if
nothing else).

3 Collaboration

One of the reasons we haven't tackled it yet is that we think something
like what you proposed might be a better solution than trying to wrap the
current native framework (which is also known to be very unreliable).

So as I see you either create a framework which mimics Sugar and no web
 developer will use it or create a framework which implements what a web
 developer is already using or at least tries to somehow emulate it. So the
 web developer does not have to modify his/her code and will consider
 porting his/her application for a smaller platform.


We probably all agree that it would be awesome to have something  that
integrates well with Sugar and works transparently by reusing existing web
technologies. I don't think that's easy to achieve though. It has been said
in previous discussions that without the close integration between
activities and system, Sugar would be just yet another suite of educational
applications (and likely not the best of them). I very much agree and I
think it's tricky to preserve that while moving to frameworks which are
supposed to work everywhere.

We could have started with something more web developer friendly and
incrementally integrated it into the native Sugar platform, for example by
redesigning the Journal in the way you described, and somehow adapting
native activities to the new design. Instead we went for something targeted
at the current Sugar developers with the idea of making it incrementally
more web friendly.

I have been on the fence on what was the best approach and I still am.
Something to consider is that we barely have the resources to maintain the
existing native code. I doubt, for example, that we would be able to ship a
redesigned Journal. Consider also that the people most involved with this
work has all a good knowledge of the Sugar platform but are not really web
developers.

Just my $0.02. Manuel might want to post his perspective too.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Activity Central's Sugar related priorities.

2013-10-09 Thread Daniel Narvaez

On 10 October 2013 00:22, Daniel Narvaez dwnarv...@gmail.com wrote:

 1 Inability to do OAuth

 This has been discussed for Firefox OS too and as far as I know there is
 no good solution for it yet. I won't claim to understand all the security
 implications, tough the basic issue seems to run content from the web
 inside an higher privileged application. In our case it's worst because we
 don't support hosted web applications at all.


I don't fully  understand the problems involved yet but mozilla seems to
have a found a solution to this

https://bugzilla.mozilla.org/show_bug.cgi?id=852720

We do have a stable origin already given by the app:// protocol we are
using. Though I'm not sure that's the only requirement (the discussion on
the bug report is long and a bit confusing).
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Activity Central's Sugar related priorities.

2013-10-09 Thread Walter Bender

Excuse the top post: FWIW, I have most of a Sugar authentication with
Google Drive working. (For the almost finished Gdrive webservice.)

-walter

On Wed, Oct 9, 2013 at 8:04 PM, Daniel Narvaez dwnarv...@gmail.com wrote:
 On 10 October 2013 00:22, Daniel Narvaez dwnarv...@gmail.com wrote:

 1 Inability to do OAuth

 This has been discussed for Firefox OS too and as far as I know there is
 no good solution for it yet. I won't claim to understand all the security
 implications, tough the basic issue seems to run content from the web inside
 an higher privileged application. In our case it's worst because we don't
 support hosted web applications at all.


 I don't fully  understand the problems involved yet but mozilla seems to
 have a found a solution to this

 https://bugzilla.mozilla.org/show_bug.cgi?id=852720

 We do have a stable origin already given by the app:// protocol we are
 using. Though I'm not sure that's the only requirement (the discussion on
 the bug report is long and a bit confusing).

 ___
 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] Activity Central's Sugar related priorities.

2013-10-08 Thread Daniel Narvaez

On 8 October 2013 01:45, Ruben Rodríguez ru...@activitycentral.com wrote:

 Also, there are some bits of code in both Sugar and the activities
 that assume to be running on Fedora, or even on an XO, and those need
 cleaning.


Please fix those bits directly upstream! I have not seen any patch related
to this effort yet.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Activity Central's Sugar related priorities.

2013-10-08 Thread David Farning

On Mon, Oct 7, 2013 at 6:07 PM, Samuel Greenfeld greenf...@laptop.org wrote:
 This actually is kind of what I meant (and perhaps should be a separate
 thread).

 My understanding is that deployments nowadays are the primary parties
 funding Sugar development.  And the deployments or their contractors
 sometimes duplicate work, run into debates upstreaming things, and/or may
 choose to keep some things semi-private to differentiate their products.

 So apart from major functionality like HTML5 activities, a lot of peripheral
 development is happening downstream-first.  And when we do try to do major
 cross-group development like the GTK3 port, this has lead to finger-pointing
 behind the scenes where it is claimed others are not doing what they
 promised.

 To the best of my knowledge no single organization currently employs enough
 developers and/or contractors to keep Sugar development alive.  I am not
 certain what the best approach to take is when this is the case.

Thanks to everyone for their feedback on this thread.

As Samuel points out, over the last several years, the ecosystem has
evolved from a single entity into a number of organisations with
overlapping, but not identical, goals. This opens the door for a
competitive ecosystem such as the kernel which thrives by making it
more effective to compete on top of a collaboratively developed
foundation rather than going it alone.

In this case, I don't know how the upstream / downstream relationship
will look. My feeling is that it will require us as individuals and
organizations to look at how we currently benefit (and struggle) by
competing and how we can set aside our egos and benefit by
collaborating.

In the coming weeks, Ruben and Anish will be available on the mailing
lists and at the conference in San Francisco to discuss if working
together is mutually desirable.

From there, we can go in to the technical aspects of how to make that happen.

 On Mon, Oct 7, 2013 at 6:22 PM, James Cameron qu...@laptop.org wrote:

 On Tue, Oct 08, 2013 at 12:00:47AM +0200, Daniel Narvaez wrote:
  Well everyone seems to be developing their own version of Sugar
  seems to be more than that. But maybe I'm just reading too much into
  it.
 
  There aren't multiple groups of people or individuals developing
  sugar on their own. As far as I know all the work that is being done
  these days is going upstream.

 Good.  I only know of four Sugars.  Sugar upstream, Dextrose, what is
 in OLPC OS, and what is in the Australian builds.  There might be
 more, but I'm not aware of them.  I also don't know the difference
 between each.

 --
 James Cameron
 http://quozl.linux.org.au/
 ___
 Devel mailing list
 de...@lists.laptop.org
 http://lists.laptop.org/listinfo/devel



 ___
 Devel mailing list
 de...@lists.laptop.org
 http://lists.laptop.org/listinfo/devel




-- 
David Farning
Activity Central: http://www.activitycentral.com
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Activity Central's Sugar related priorities.

2013-10-07 Thread Samuel Greenfeld

Disclaimer: These are my personal views, and are not the official views of
OLPC.


   - It should be fine to discuss anything Sugar-related on the
   sugarlabs.org development lists.  Sugar Labs does not use any OLPC
   hosting services, and is an independent group as part of the Software
   Freedom Conservancy.

   - I cannot comment on future OLPC hardware plans.  If OLPC was to
   publicly announce their intent to go in a similar direction the
   laptop.org mailing lists might be appropriate; however otherwise they
   may not be.

   It sounds like you are discussing a software change for different
   hardware than anything OLPC related though.

   Other vendors besides OLPC have sold laptops with Sugar preinstalled on
   top of Fedora or Ubuntu in the past, so you are not breaking new ground.

   - Updating the Sugar release in Ubuntu sounds like something everyone
   could benefit from, not just Dextrose users.  Is there any reason not to
   base most of this work starting with upstream Sugar  existing Ubuntu
   packages?

   - In general one of my frustrations lately is that now that we no longer
   publicly review patches on this mailing list, everyone seems to be
   developing their own version of Sugar.

   While some of these changes may make it back upstream it would be nice
   to see EduJAM and OLPC-SF discussion about trying to limit this.

   I know Activity Central is trying to publicly state a bit what they're
   up to, and Walter does his weekly state of the union reports.  I also
   personally hear some private updates as well.  But the different working
   styles of the various groups is starting to confuse me as to which way
   Sugar is going as a whole.




On Mon, Oct 7, 2013 at 12:41 PM, David Farning dfarn...@activitycentral.com
 wrote:

 As a data point for other decision makers and a follow up to some of
 the recent threads on the future of Sugar, I would like to share
 Activity Central's Sugar priorities for the next six months.

 Activity Central supports the recent HTML5 + JS work that is going
 into sugar .100. It has the potential to take the OLPC vision to any
 device which runs a browser while simultaneously increasing the
 potential activity developer pool by several orders of magnitude. This
 is an excellent area for community lead research. Activity Central
 will be doing activity side work to test the viability of the
 framework for client deployments.

 As a more incremental approach, Activity Central will continue our
 deployment-centric work by porting Dextrose to Ubuntu. A concern among
 deployments is the future availability of hardware to support their
 current investment. Deployments are concerned that laptop support will
 stop before tablets are ready for use in the field. Because of the
 controversial nature of this work and the potential for disruption it
 may cause to the Association, we understand if some people would
 prefer to sit this out.

 Would either of these list be appropriate to continue these
 discussions about this downstream efforts to port sugar to Ubuntu for
 use on hardware not sold by the Association?

 Phase one has been a poof of concept as seen at
 http://wiki.sugarlabs.org/go/Ubuntu (ongoing)
 Phase two will be opening the project to the community.
 Phases three will be testing and piloting by deployments.

 --
 David Farning
 Activity Central: http://www.activitycentral.com
 ___
 Devel mailing list
 de...@lists.laptop.org
 http://lists.laptop.org/listinfo/devel

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

Re: [Sugar-devel] Activity Central's Sugar related priorities.

On 7 October 2013 19:24, Samuel Greenfeld greenf...@laptop.org wrote:



- Updating the Sugar release in Ubuntu sounds like something everyone
could benefit from, not just Dextrose users.  Is there any reason not to
base most of this work starting with upstream Sugar  existing Ubuntu
packages?


+1



- In general one of my frustrations lately is that now that we no
longer publicly review patches on this mailing list, everyone seems to be
developing their own version of Sugar.


Can you elaborate on this one? I haven't noticed this kind of change (and
we have not been reviewing most patches on the mailing list since a long
long time, well before the github switch).
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Activity Central's Sugar related priorities.

On 7 October 2013 18:41, David Farning dfarn...@activitycentral.com wrote:

 Would either of these list be appropriate to continue these
 discussions about this downstream efforts to port sugar to Ubuntu for
 use on hardware not sold by the Association?

 Phase one has been a poof of concept as seen at
 http://wiki.sugarlabs.org/go/Ubuntu (ongoing)
 Phase two will be opening the project to the community.
 Phases three will be testing and piloting by deployments.


I would like to understand better what you mean with porting. It should
just be matter of writing package specs  (or really fixing the existing
ones...), no?

If there is any more work involved strongly suggest  you first discuss it
on this mailing list, then have it done upstream directly. That way the
whole community will benefit from your effort and you will benefit from the
community input. Upstreaming after the fact rarely works.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Activity Central's Sugar related priorities.

2013-10-07 Thread Gonzalo Odiard

In general one of my frustrations lately is that now that we no longer
publicly review patches on this mailing list, everyone seems to be
developing their own version of Sugar.


 Can you elaborate on this one? I haven't noticed this kind of change (and
 we have not been reviewing most patches on the mailing list since a long
 long time, well before the github switch).


I think the change was the movement to github.
If we can add sugar-devel mailing list to the github mail destinations,
that can be solved.

Gonzalo




 ___
 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] Activity Central's Sugar related priorities.

On Monday, 7 October 2013, Gonzalo Odiard wrote:

 In general one of my frustrations lately is that now that we no longer
 publicly review patches on this mailing list, everyone seems to be
 developing their own version of Sugar.


 Can you elaborate on this one? I haven't noticed this kind of change (and
 we have not been reviewing most patches on the mailing list since a long
 long time, well before the github switch).


 I think the change was the movement to github.
 If we can add sugar-devel mailing list to the github mail destinations,
 that can be solved.


I was mostly concerned about Samuel feeling that everyone is developing
they're own version of Sugar. I don't see that or at least I don't see
differences with the past.

We probably can have sugar-devel as email destination... Though I'm not
sure why people wouldn't just watch the modules they are interested in? It
seems more flexible. Anyway not opposed to send all modules to the whole
mailing list if there is consensus on that.


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

Re: [Sugar-devel] Activity Central's Sugar related priorities.

2013-10-07 Thread Gonzalo Odiard

On Mon, Oct 7, 2013 at 3:58 PM, Daniel Narvaez dwnarv...@gmail.com wrote:

 On 7 October 2013 18:41, David Farning dfarn...@activitycentral.comwrote:

 Would either of these list be appropriate to continue these
 discussions about this downstream efforts to port sugar to Ubuntu for
 use on hardware not sold by the Association?

 Phase one has been a poof of concept as seen at
 http://wiki.sugarlabs.org/go/Ubuntu (ongoing)
 Phase two will be opening the project to the community.
 Phases three will be testing and piloting by deployments.


 I would like to understand better what you mean with porting. It should
 just be matter of writing package specs  (or really fixing the existing
 ones...), no?


I agree. Have Sugar working on Ubuntu would be great, but would be mainly:
* Solve dependencies in ubuntu (update/fix packages)
* Make Sugar work with other dependencies when is not possible.

In the first case, upstream is Ubuntu, in the second case, upstream is
Sugarlabs.
In both cases, working with upstream is the best solution in the long run,
while I understand for Dextrose is useful have some exclusive features,
I hope you avoid the shortcut and plan thinking in the future.

Gonzalo



 If there is any more work involved strongly suggest  you first discuss it
 on this mailing list, then have it done upstream directly. That way the
 whole community will benefit from your effort and you will benefit from the
 community input. Upstreaming after the fact rarely works.

 ___
 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] Activity Central's Sugar related priorities.

2013-10-07 Thread Martin Langhoff

On Mon, Oct 7, 2013 at 12:41 PM, David Farning
dfarn...@activitycentral.com wrote:
 As a more incremental approach, Activity Central will continue our
 deployment-centric work by porting Dextrose to Ubuntu.

From a deploy to XOs PoV that sounds like a ton of work. You'll
grind against a lot of little problems.

Fedora is no longer behind nor problematic. That was very much true in
earlier times. Some innovative things in Fedora (ie: systemd) have
been very well integrated with the Sugar stack. And some changes in
the Ubuntu pipeline are likely to cause some havoc.

From a work for AC customers already using Ubuntu, it probably makes
more sense. Still, the odd directions Ubuntu seems to be going are a
bit of a wildcard. I honestly hope that they settle a bit and make
life for their downstreams a bit easier.

cheers,


m
-- 
 martin.langh...@gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Activity Central's Sugar related priorities.

I agree with Martin on the odd directions Ubuntu is exhibiting; it may
be safer to target Debian instead, from which support for Ubuntu will
generally follow.

(On the other hand, I lack evidence to agree with claims about the
stability or direction of Fedora.  So few people I know use it.)

-- 
James Cameron
http://quozl.linux.org.au/
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Activity Central's Sugar related priorities.

Daniel Narvaez wrote:
 Gonzalo Odiard wrote:
  Daniel wrote:
   Gonzalo Odiard wrote:
Samuel Wrote:
In general one of my frustrations lately is that now that we no
longer publicly review patches on this mailing list, everyone
seems to be developing their own version of Sugar.
  
   Can you elaborate on this one? I haven't noticed this kind of
   change (and we have not been reviewing most patches on the mailing
   list since a long long time, well before the github switch).
 
  I think the change was the movement to github.  If we can add
  sugar-devel mailing list to the github mail destinations, that can
  be solved.

 I was mostly concerned about Samuel feeling that everyone is
 developing they're own version of Sugar. I don't see that or at
 least I don't see differences with the past.

I agree with Samuel; that with the loss of public review of patches
participation in development has been confined to those who take the
trouble to visit a web site.

(The reviews by mail were also stimulating other discussion on list).

So on the theory that developers are developing with less review (even
though it might be unseen greater review), this leads to the
conclusion that Sugar is being developed by these developers on their
own.

And, actually, I'm fine with that.  A smaller group can achieve more
if they are able to use these new tools effectively.

I have not been effective since that change, but you would have seen
that a review counter or tracking?  Has there been a measure of review
rate?

 We probably can have sugar-devel as email destination... Though I'm
 not sure why people wouldn't just watch the modules they are
 interested in? It seems more flexible. Anyway not opposed to send
 all modules to the whole mailing list if there is consensus on
 that.

I don't see how watching the modules they are interested in is more
flexible, nor whether greater flexibility increases the
communication.

Please don't configure github to send links to the patches; they have
to be the patches themselves.  They should also have a from address
that matches the originator.

What used to happen was easy.  Get a mail with the patch.  Scroll it
down while reviewing it.  When the cognitive dissonance hits a
threshold, hit the reply button and begin a comment.  Press send.

Mail is a store and forward architecture.  I can use mail without
having to wait for an internet connection.  Github is not so lucky:

$ ping -n github.com
rtt min/avg/max/mdev = 288.440/606.297/1049.233/262.776 ms, pipe 2

-- 
James Cameron
http://quozl.linux.org.au/
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Activity Central's Sugar related priorities.

On 7 October 2013 23:39, James Cameron qu...@laptop.org wrote:

 I agree with Samuel; that with the loss of public review of patches
 participation in development has been confined to those who take the
 trouble to visit a web site.

 (The reviews by mail were also stimulating other discussion on list).

 So on the theory that developers are developing with less review (even
 though it might be unseen greater review), this leads to the
 conclusion that Sugar is being developed by these developers on their
 own.


Well everyone seems to be developing their own version of Sugar seems to
be more than that. But maybe I'm just reading too much into it.

There aren't multiple groups of people or individuals developing sugar on
their own. As far as I know all the work that is being done these days is
going upstream.


 And, actually, I'm fine with that.  A smaller group can achieve more
 if they are able to use these new tools effectively.

 I have not been effective since that change, but you would have seen
 that a review counter or tracking?


I can't parse this question.


  Has there been a measure of review
 rate?


We usually have 1 reviewer per patch. All the patches that have been
submitted so far has been reviewed and landed.

 We probably can have sugar-devel as email destination... Though I'm
  not sure why people wouldn't just watch the modules they are
  interested in? It seems more flexible. Anyway not opposed to send
  all modules to the whole mailing list if there is consensus on
  that.

 I don't see how watching the modules they are interested in is more
 flexible, nor whether greater flexibility increases the
 communication.


Because if we send patches to the mailing I'm pretty sure some people will
be annoyed. In fact someone got annoyed when he was added to the reviewers
group and started getting email.


 Please don't configure github to send links to the patches; they have
 to be the patches themselves.  They should also have a from address
 that matches the originator.


I highly doubt what you want is possible, at least without doing
substantial work... If you have time feel free.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Activity Central's Sugar related priorities.

2013-10-07 Thread Manuel Quiñones

2013/10/7 James Cameron qu...@laptop.org:
 Daniel Narvaez wrote:
 Gonzalo Odiard wrote:
  Daniel wrote:
   Gonzalo Odiard wrote:
Samuel Wrote:
In general one of my frustrations lately is that now that we no
longer publicly review patches on this mailing list, everyone
seems to be developing their own version of Sugar.
  
   Can you elaborate on this one? I haven't noticed this kind of
   change (and we have not been reviewing most patches on the mailing
   list since a long long time, well before the github switch).
 
  I think the change was the movement to github.  If we can add
  sugar-devel mailing list to the github mail destinations, that can
  be solved.

 I was mostly concerned about Samuel feeling that everyone is
 developing they're own version of Sugar. I don't see that or at
 least I don't see differences with the past.

 I agree with Samuel; that with the loss of public review of patches
 participation in development has been confined to those who take the
 trouble to visit a web site.

 (The reviews by mail were also stimulating other discussion on list).

 So on the theory that developers are developing with less review (even
 though it might be unseen greater review), this leads to the
 conclusion that Sugar is being developed by these developers on their
 own.

 And, actually, I'm fine with that.  A smaller group can achieve more
 if they are able to use these new tools effectively.

 I have not been effective since that change, but you would have seen
 that a review counter or tracking?  Has there been a measure of review
 rate?

 We probably can have sugar-devel as email destination... Though I'm
 not sure why people wouldn't just watch the modules they are
 interested in? It seems more flexible. Anyway not opposed to send
 all modules to the whole mailing list if there is consensus on
 that.

 I don't see how watching the modules they are interested in is more
 flexible, nor whether greater flexibility increases the
 communication.

James, Sam, I see this as a question of taste.

At least starters find very odd emails with patch format in pain text.
 At least one reviewer (me) find very odd copy/pasting the email
content to a file in order to give the patch a test.  And we had the
problem of email-patches being forgotten in the flow of threads.  That
is fixed, with zero patches in queue.

As Daniel said, you can receive email notifications from GitHub by
watching repositories.

 Please don't configure github to send links to the patches; they have
 to be the patches themselves.  They should also have a from address
 that matches the originator.

 What used to happen was easy.  Get a mail with the patch.  Scroll it
 down while reviewing it.  When the cognitive dissonance hits a
 threshold, hit the reply button and begin a comment.  Press send.

 Mail is a store and forward architecture.  I can use mail without
 having to wait for an internet connection.  Github is not so lucky:

 $ ping -n github.com
 rtt min/avg/max/mdev = 288.440/606.297/1049.233/262.776 ms, pipe 2

 --
 James Cameron
 http://quozl.linux.org.au/
 ___
 Devel mailing list
 de...@lists.laptop.org
 http://lists.laptop.org/listinfo/devel



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

Re: [Sugar-devel] Activity Central's Sugar related priorities.

On 8 October 2013 00:08, Manuel Quiñones ma...@laptop.org wrote:

 James, Sam, I see this as a question of taste.


Exactly.

The sooner people understand that, the sooner we will stop having
discussions about the review process over and over :)
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Activity Central's Sugar related priorities.

On Tue, Oct 08, 2013 at 12:00:47AM +0200, Daniel Narvaez wrote:
 Well everyone seems to be developing their own version of Sugar
 seems to be more than that. But maybe I'm just reading too much into
 it.
 
 There aren't multiple groups of people or individuals developing
 sugar on their own. As far as I know all the work that is being done
 these days is going upstream.

Good.  I only know of four Sugars.  Sugar upstream, Dextrose, what is
in OLPC OS, and what is in the Australian builds.  There might be
more, but I'm not aware of them.  I also don't know the difference
between each.

-- 
James Cameron
http://quozl.linux.org.au/
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Activity Central's Sugar related priorities.

2013-10-07 Thread Peter Robinson

On Mon, Oct 7, 2013 at 10:10 PM, James Cameron qu...@laptop.org wrote:
 I agree with Martin on the odd directions Ubuntu is exhibiting; it may
 be safer to target Debian instead, from which support for Ubuntu will
 generally follow.

 (On the other hand, I lack evidence to agree with claims about the
 stability or direction of Fedora.  So few people I know use it.)

So few people I know use Windows but that doesn't mean it's no longer
prevalent, from what I've seen there's been quite a large swing back
to it due to the problems with Ubuntu and most of the upstream
developers of a lot of the stack that sugar relies upon now use Fedora
as their core development OS because of the issues they see with
Ubuntu.

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

Re: [Sugar-devel] Activity Central's Sugar related priorities.

On 8 October 2013 00:22, James Cameron qu...@laptop.org wrote:

 On Tue, Oct 08, 2013 at 12:00:47AM +0200, Daniel Narvaez wrote:
  Well everyone seems to be developing their own version of Sugar
  seems to be more than that. But maybe I'm just reading too much into
  it.
 
  There aren't multiple groups of people or individuals developing
  sugar on their own. As far as I know all the work that is being done
  these days is going upstream.

 Good.  I only know of four Sugars.  Sugar upstream, Dextrose, what is
 in OLPC OS, and what is in the Australian builds.  There might be
 more, but I'm not aware of them.  I also don't know the difference
 between each.


Australia builds have apparently a few non-yet-upstreamed patches. Both
Gonzalo and Walter are very much involved in upstream work, I'm absolutely
confident they will upstream as soon as it make sense.

OLPC OS is pretty much all upstream, as far as I know.

Dextrose. I know they accumulated non-upstream patches in the past. We
landed a couple of features coming from there before the freeze. I'm not
sure what is going on these days, which is why I wanted to know more from
David about the porting they are doing.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Activity Central's Sugar related priorities.

2013-10-07 Thread Walter Bender

My 2 cents:

Since the switch to github, we've have a much better turn-around on
reviews and we've attacked new reviewers. I think those data speak for
themselves. As Daniel said, we welcome help further shaping the
process.

regards.

-walter

On Mon, Oct 7, 2013 at 6:08 PM, Manuel Quiñones ma...@laptop.org wrote:
 2013/10/7 James Cameron qu...@laptop.org:
 Daniel Narvaez wrote:
 Gonzalo Odiard wrote:
  Daniel wrote:
   Gonzalo Odiard wrote:
Samuel Wrote:
In general one of my frustrations lately is that now that we no
longer publicly review patches on this mailing list, everyone
seems to be developing their own version of Sugar.
  
   Can you elaborate on this one? I haven't noticed this kind of
   change (and we have not been reviewing most patches on the mailing
   list since a long long time, well before the github switch).
 
  I think the change was the movement to github.  If we can add
  sugar-devel mailing list to the github mail destinations, that can
  be solved.

 I was mostly concerned about Samuel feeling that everyone is
 developing they're own version of Sugar. I don't see that or at
 least I don't see differences with the past.

 I agree with Samuel; that with the loss of public review of patches
 participation in development has been confined to those who take the
 trouble to visit a web site.

 (The reviews by mail were also stimulating other discussion on list).

 So on the theory that developers are developing with less review (even
 though it might be unseen greater review), this leads to the
 conclusion that Sugar is being developed by these developers on their
 own.

 And, actually, I'm fine with that.  A smaller group can achieve more
 if they are able to use these new tools effectively.

 I have not been effective since that change, but you would have seen
 that a review counter or tracking?  Has there been a measure of review
 rate?

 We probably can have sugar-devel as email destination... Though I'm
 not sure why people wouldn't just watch the modules they are
 interested in? It seems more flexible. Anyway not opposed to send
 all modules to the whole mailing list if there is consensus on
 that.

 I don't see how watching the modules they are interested in is more
 flexible, nor whether greater flexibility increases the
 communication.

 James, Sam, I see this as a question of taste.

 At least starters find very odd emails with patch format in pain text.
  At least one reviewer (me) find very odd copy/pasting the email
 content to a file in order to give the patch a test.  And we had the
 problem of email-patches being forgotten in the flow of threads.  That
 is fixed, with zero patches in queue.

 As Daniel said, you can receive email notifications from GitHub by
 watching repositories.

 Please don't configure github to send links to the patches; they have
 to be the patches themselves.  They should also have a from address
 that matches the originator.

 What used to happen was easy.  Get a mail with the patch.  Scroll it
 down while reviewing it.  When the cognitive dissonance hits a
 threshold, hit the reply button and begin a comment.  Press send.

 Mail is a store and forward architecture.  I can use mail without
 having to wait for an internet connection.  Github is not so lucky:

 $ ping -n github.com
 rtt min/avg/max/mdev = 288.440/606.297/1049.233/262.776 ms, pipe 2

 --
 James Cameron
 http://quozl.linux.org.au/
 ___
 Devel mailing list
 de...@lists.laptop.org
 http://lists.laptop.org/listinfo/devel



 --
 .. manuq ..
 ___
 Devel mailing list
 de...@lists.laptop.org
 http://lists.laptop.org/listinfo/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] Activity Central's Sugar related priorities.

On 8 October 2013 01:07, Samuel Greenfeld greenf...@laptop.org wrote:

 This actually is kind of what I meant (and perhaps should be a separate
 thread).


To simplify things I will only answer about the 0.100 release cycle. Things
have changed a lot anyway and it's probably not worth focusing on the past.


 My understanding is that deployments nowadays are the primary parties
 funding Sugar development.  And the deployments or their contractors
 sometimes duplicate work, run into debates upstreaming things, and/or may
 choose to keep some things semi-private to differentiate their products.


There has been debate only about one set of patches which was too big and
complicated to review. Someone took care of splitting it up in the end
though and it landed.

I'm not aware of duplicate work. I'm not aware of semi-private things used
to differentiate products.


 So apart from major functionality like HTML5 activities, a lot of
 peripheral development is happening downstream-first.  And when we do try
 to do major cross-group development like the GTK3 port, this has lead to
 finger-pointing behind the scenes where it is claimed others are not doing
 what they promised.


I don't think a lot of development is happening downstream. I have to admit
I don't have much visibility about Dextrose/Activity Central though.

I think it's fine for some development to land downstream first, as long as
it is discussed openly from the beginning. It's often a good way to try
things out...


 To the best of my knowledge no single organization currently employs
 enough developers and/or contractors to keep Sugar development alive.  I am
 not certain what the best approach to take is when this is the case.


I'm more concerned that even summing up the resources, there might not be
enough to keep development alive. It really worried me that very little
testing, bug triaging and bug fixing is happening for 0.100.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Activity Central's Sugar related priorities.

2013-10-07 Thread Walter Bender

On Mon, Oct 7, 2013 at 6:00 PM, Daniel Narvaez dwnarv...@gmail.com wrote:
 On 7 October 2013 23:39, James Cameron qu...@laptop.org wrote:

 I agree with Samuel; that with the loss of public review of patches
 participation in development has been confined to those who take the
 trouble to visit a web site.

 (The reviews by mail were also stimulating other discussion on list).

 So on the theory that developers are developing with less review (even
 though it might be unseen greater review), this leads to the
 conclusion that Sugar is being developed by these developers on their
 own.


 Well everyone seems to be developing their own version of Sugar seems to
 be more than that. But maybe I'm just reading too much into it.

I am only aware of one group developing their own version of Sugar:
Activity Central. There is the Sugar Network project as well, but that
is more about glue around Sugar. Gonzalo and I are working with Sugar
upstream in Australia (although we are ahead of master in a few places
as Sugar 100 has been in freeze).


 There aren't multiple groups of people or individuals developing sugar on
 their own. As far as I know all the work that is being done these days is
 going upstream.


regards.

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

Re: [Sugar-devel] Activity Central's Sugar related priorities.

2013-10-07 Thread Ruben Rodríguez

2013/10/7 Daniel Narvaez dwnarv...@gmail.com:

 I would like to understand better what you mean with porting. It should just
 be matter of writing package specs  (or really fixing the existing ones...),
 no?

Mainly, but since we work with Ubuntu LTS for the deployment's benefit
we had to backport patches into gobject-introspection and other libs.
Also, there are some bits of code in both Sugar and the activities
that assume to be running on Fedora, or even on an XO, and those need
cleaning.


-- 
Rubén Rodríguez
Activity Central: http://activitycentral.com

Facebook: https://activitycentral.com/facebook
Google+: https://activitycentral.com/googleplus
Twitter: https://activitycentral.com/twitter
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Activity Central's Sugar related priorities.

2013-10-07 Thread Walter Bender

On Mon, Oct 7, 2013 at 7:45 PM, Ruben Rodríguez
ru...@activitycentral.com wrote:

 Also, there are some bits of code in both Sugar and the activities
 that assume to be running on Fedora, or even on an XO, and those need
 cleaning.

Be nice to know about these so we can fix them.

thx


 --
 Rubén Rodríguez
 Activity Central: http://activitycentral.com

 Facebook: https://activitycentral.com/facebook
 Google+: https://activitycentral.com/googleplus
 Twitter: https://activitycentral.com/twitter
 ___
 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] Activity Central's Sugar related priorities.

2013-10-07 Thread Ruben Rodríguez

2013/10/7 Gonzalo Odiard gonz...@laptop.org:
 I agree. Have Sugar working on Ubuntu would be great, but would be mainly:
 * Solve dependencies in ubuntu (update/fix packages)
 * Make Sugar work with other dependencies when is not possible.

 In the first case, upstream is Ubuntu, in the second case, upstream is
 Sugarlabs.
 In both cases, working with upstream is the best solution in the long run,
 while I understand for Dextrose is useful have some exclusive features,
 I hope you avoid the shortcut and plan thinking in the future.

Idealy, yes. But to make Sugar work with an already released version
of Ubuntu there is nothing to upstream as you cannot ask for library
updates after the release, so we need to do it on the side. But it
would be nice to have the latest Sugar working natively on the next
Ubuntu LTS, and that is included in the project plans.


-- 
Rubén Rodríguez
Activity Central: http://activitycentral.com

Facebook: https://activitycentral.com/facebook
Google+: https://activitycentral.com/googleplus
Twitter: https://activitycentral.com/twitter
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Activity Central's Sugar related priorities.

2013-10-07 Thread Ruben Rodríguez

2013/10/8 Walter Bender walter.ben...@gmail.com:
 Be nice to know about these so we can fix them.


Sure thing! We just finished with the first leg of the project and the
resultant image is getting tested now, so soon I'll start sending
patches. There are usually small things, like scripts written in bash
(ubuntu uses dash), checking for distro specific files or paths, and
the like.

Anyway most of the work was related to make 0.98 work on Ubuntu 12.04,
something that in general would not require upstreaming for either
Sugar or Ubuntu.

-- 
Rubén Rodríguez
Activity Central: http://activitycentral.com

Facebook: https://activitycentral.com/facebook
Google+: https://activitycentral.com/googleplus
Twitter: https://activitycentral.com/twitter
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Activity Central's Sugar related priorities.