[Sugar-devel] [REMINDER] Development team meeting --- 05. June 2012 (15:00 UTC)

[Walter Bender]

On Mon, Jun 11, 2012 at 9:56 AM, Bert Freudenberg <bert at freudenbergs.de> wrote:
> On 2012-06-11, at 15:15, Walter Bender wrote:
>>
>> On Mon, Jun 4, 2012 at 6:10 PM, Simon Schampijer <simon at schampijer.de> wrote:
>>>
>>> - developing Activities on the XO: maybe we should include git in the builds
>>> to start with (at least on the 1.5 and 1.75)? the rpm with the deps
>>> (perl-Error + perl-Git) is 3.2MB, installed 14MB, maybe it can be reduced as
>>> well with making some of the deps optional? There are still people dreaming
>>> of simple activity to develop and modify activities for the XO (several
>>> attempts have been made here)
>>
>> Slight aside
>>
>> In Amazonas last week, I had the teachers use the Duplicate feature to
>> clone an activity (in this specific case, Labyrinth) so that they
>> could fix a bug. They used JAMEdit to make their changes. What was
>> missing was git, so that they could create a patch (to submit
>> upstream) and/or create a new bundle for distribution. So +1 for
>> adding git to the Standard Sugar build.
>
> That would mean XO bundles need to ship with their git repositories. Increases the installed size by two, at least.

Not necessarily. You can just run git init to create a new repository
on the clone, for example.

>
> Or there would have to be a mechanism to fetch the git data (e.g. if the activity info included a repo url and commit number). That's actually how we do it in Etoys (though not using git but Monticello) - you can modify it and then diff against a version downloaded from the repository.
>
> Another idea avoiding the download would be to diff the original and the copy. For that you just need a tiny shellscript (or a few lines of python).
>
>>> - developing Sugar on the XO: I did modify Marco's Makefile a bit to build
>>> on the XO and install in the system path, have to clean that up, but that
>>> work quite well at least for the toolkit and the artwork, the shell is a bit
>>> more tricky if you mess it up (but there are tricks with starting sugar from
>>> the xterm or in GNOME to work around that)
>>
>> As per an early thread, it would be nice to be able to clone Sugar
>> (perhaps using the same View Source mechanism we have for activities)
>> and run the cloned version from ~/
>>
>> The issue I never resolved is what to do when you have an error that
>> prevents the cloned version from launching.
>
>
> When launching the clone one could have a timeout after a couple seconds. E.g. make it write a file when it has properly started. Wait for the file to appear, and if it doesn't, abort the launch, and offer to try again or run the system version instead.
>
> Another idea would be to have the system version detect there is a user version, and show a choice which one to launch. If you kill it via ctrl-alt-backspace (or reset or whatever), you would get back to the choice menu.
>
> - Bert -
>
>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel



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