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

[Bert Freudenberg]

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.

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 -