[Sugar-devel] Using Sugarizer as development environment for Sugar Web Activities

Lionel Laské lionel at olpc-france.org
Sat Feb 15 15:58:57 EST 2014

Hi Daniel, hi Sam,

Except if I don't understand your idea, copying the result of the "volo
create" command is exactly what I've done in my Sugarizer ActivityTemplate
directory [1]. So a new developer just need to copy this directory to
create its new activity.

The problem is that currently the sugar-web framework for Sugarizer is
slightly different than the one for Sugar. It's mainly related to
datastore.js and dbus.js that use localstorage and querystring handling.
I'm sure it could be re-conciliated if we find a way to differentiate
running in Sugar and running in Sugarizer. In my opinion, it's the major
issue, then developers will be free to use any development environment.

@Daniel, You're right, I'm going to update the png.



2014-02-15 21:26 GMT+01:00 Daniel Narvaez <dwnarvaez at gmail.com>:

> Yeah my concern with that was conficts between files with are checked in
> git and those pulled by volo. Normally you don't want to include the libs
> in git for that reason. Though here it's probably fine because people won't
> base their activities on the git repository, just on the files contained in
> it. So that's probably the best solution. And we can link directly to the
> zip file in the documentation.
> On 15 February 2014 20:52, Sam Parkinson <sam.parkinson3 at gmail.com> wrote:
>> I totally agree we need to do that, or maybe we could just include the
>> libs in sugarlabs/sugar-web-template? Most people know how to press the
>> download as zip button on github.
>> On Feb 15, 2014 11:10 PM, "Daniel Narvaez" <dwnarvaez at gmail.com> wrote:
>>> On 14 February 2014 21:27, Lionel Laské <lionel at olpc-france.org> wrote:
>>>> 2014-02-14 14:13 GMT+01:00 Daniel Narvaez <dwnarvaez at gmail.com>:
>>>>> Though I would like Sugarizer to be gradually merged into sugar-web
>>>>> and the differences between the two environments to be reduced as much as
>>>>> possible. Tons of do this on osbuild, do that on sugarizer is not going to
>>>>> be maintainable.
>>>> +1. Be sure that I don't want to transform Sugarizer into a new Sugar,
>>>> the more Sugar and Sugarizer could have in common, the better it will be.
>>>>> My main doubt is the node dependency, I tend to think we should
>>>>> require it outside osbuild too. There are just too many useful tools in the
>>>>> node ecosystem these days to avoid it... But of course there is an argument
>>>>> that it would be making the barrier higher.
>>>> I'm a big fan of node.js but yes, I think it's a barrier. My dream is
>>>> to have only a dependence on the browser and on... copy file. Even git is
>>>> too complex for me!
>>> What about publishing the result of volo create as a zip and changing
>>> the documentation to point to it instead of the command. It seems like that
>>> would remove the barrier and at the same time allow to use volo when
>>> needed/wanted. Of course we first need to actually make a sugar-web that
>>> works both in the browser and in sugar but as soon as that's done...
>>> _______________________________________________
>>> Sugar-devel mailing list
>>> Sugar-devel at lists.sugarlabs.org
>>> http://lists.sugarlabs.org/listinfo/sugar-devel
> --
> Daniel Narvaez
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20140215/a5f97db9/attachment.html>

More information about the Sugar-devel mailing list