Re: [Sugar-devel] [UKids] Re: [Announcement] Sugarizer v0.8 is available for your device

[Bert Freudenberg]

Steve,

append "=url-for-project" to the URL. e.g.

https://squeak.js.org/etoys/#fullscreen=http://www.squeakland.org/content/showcase/everyone/accounts/mrsteve/Balance%20Scale.014.pr

- Bert -

On Wed, Jan 11, 2017 at 3:06 AM, Steve Thomas <sthom...@gosargon.com> wrote:

>
> Bert,
>
> Works on Chromebook.
>
> Is there anyway to open a Etoys project I already created? Perhaps as a
> parameter in the URL pointing to somewhere I uploaded the file?
>
> Thanks,
> Stephen
>
> On Sun, Jan 8, 2017 at 3:39 PM, Bert Freudenberg <b...@freudenbergs.de>
> wrote:
>
>> Hi Steve,
>>
>> have you tried plain Etoys on a Chromebook?
>>
>> https://squeak.js.org/etoys/#fullscreen
>>
>> Also, we have an experimental Chrome app here:
>> https://chrome.google.com/webstore/detail/etoys/pfddkmhbbphp
>> elipkocbhmgbofdoagpi
>>
>> - Bert -
>>
>> On Sat, Jan 7, 2017 at 10:46 PM, Lionel Laské <lionel.la...@gmail.com>
>> wrote:
>>
>>>
>>> Hi Steve,
>>>
>>> Yes, unfortunately EToys could have some limitation because it need to
>>> load a full VM to run, it's why it not appear as favorite by default.
>>> I'm CC'ed Bert that could help you on it.
>>>
>>> Regards.
>>>
>>>   Lionel.
>>>
>>>
>>> 2017-01-06 23:21 GMT+01:00 Steve Thomas <sthom...@gosargon.com>:
>>>
>>>> Okay, I tried restarting Chrome a second time and now Etoys opens on
>>>> Mac. But had an issue saving. I'll investigate further.
>>>>
>>>> Hoping to get Etoys (et al) working on Chromebook's so I can get
>>>> teachers in my kids school to start using it.
>>>>
>>>> Cheers,
>>>> Stephen
>>>>
>>>> On Fri, Jan 6, 2017 at 5:15 PM, Steve Thomas <sthom...@gosargon.com>
>>>> wrote:
>>>>
>>>>> Lionel,
>>>>>
>>>>> This is great work, thank you.
>>>>>
>>>>> Ran into a few issues trying to run Etoys (Turtle Blocks seems to run
>>>>> just fine), :
>>>>>
>>>>>1. Added Chrome extension but Etoys did not run, just got black
>>>>>screen.
>>>>>   1. Tried on Mac and Windows using latest Chrome, waited about 5
>>>>>   minutes+
>>>>>2. Also downloaded from iTunes onto my Mac and had same issue
>>>>>
>>>>> Thanks,
>>>>> Stephen
>>>>>
>>>>>
>
>
> --
>
> To some of us, writing computer programs is a fascinating game. A program
> is a building of thought. It is costless to build, weightless, growing
> easily under our typing hands. If we get carried away, its size and
> complexity will grow out of control, confusing even the one who created it.
> This is the main problem of programming. It is why so much of today's
> software tends to crash, fail, screw up.
>
> When a program works, it is beautiful. The art of programming is the skill
> of controlling complexity. The great program is subdued, made simple in its
> complexity.
>
> - Martin Harverbeke (from Eloquent JavaScript
> <http://eloquentjavascript.net/index.html>)
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [UKids] Re: [Announcement] Sugarizer v0.8 is available for your device

[Bert Freudenberg]

Hi Steve,

have you tried plain Etoys on a Chromebook?

https://squeak.js.org/etoys/#fullscreen

Also, we have an experimental Chrome app here:
https://chrome.google.com/webstore/detail/etoys/
pfddkmhbbphpelipkocbhmgbofdoagpi

- Bert -

On Sat, Jan 7, 2017 at 10:46 PM, Lionel Laské 
wrote:

>
> Hi Steve,
>
> Yes, unfortunately EToys could have some limitation because it need to
> load a full VM to run, it's why it not appear as favorite by default.
> I'm CC'ed Bert that could help you on it.
>
> Regards.
>
>   Lionel.
>
>
> 2017-01-06 23:21 GMT+01:00 Steve Thomas :
>
>> Okay, I tried restarting Chrome a second time and now Etoys opens on Mac.
>> But had an issue saving. I'll investigate further.
>>
>> Hoping to get Etoys (et al) working on Chromebook's so I can get teachers
>> in my kids school to start using it.
>>
>> Cheers,
>> Stephen
>>
>> On Fri, Jan 6, 2017 at 5:15 PM, Steve Thomas 
>> wrote:
>>
>>> Lionel,
>>>
>>> This is great work, thank you.
>>>
>>> Ran into a few issues trying to run Etoys (Turtle Blocks seems to run
>>> just fine), :
>>>
>>>1. Added Chrome extension but Etoys did not run, just got black
>>>screen.
>>>   1. Tried on Mac and Windows using latest Chrome, waited about 5
>>>   minutes+
>>>2. Also downloaded from iTunes onto my Mac and had same issue
>>>
>>> Thanks,
>>> Stephen
>>>
>>>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Issue tracking on Github?

[Bert Freudenberg]

On 18.05.2016, at 17:01, Dave Crossland <d...@lab6.com> wrote:
> On 18 May 2016 at 10:54, Bert Freudenberg <b...@freudenbergs.de 
> <mailto:b...@freudenbergs.de>> wrote:
> On 18.05.2016, at 16:26, Dave Crossland <d...@lab6.com 
> <mailto:d...@lab6.com>> wrote:
>> 
>> Hi
>> 
>> On 18 May 2016 at 09:57, Tony Anderson <tony_ander...@usa.net 
>> <mailto:tony_ander...@usa.net>> wrote:
>> Its an educational project. An example is 
>> https://github.com/ezequielpereira/Bridge 
>> <https://github.com/ezequielpereira/Bridge>. This version of the 
>> Bridge-activity was developed as part of GCI. 
>> The zip downloaded from github is named Bridge-master.zip. I copied the zip 
>> to an XO-1.75, unzipped, and ran setup.py dist_xo. The result was a 
>> proper xo bundle which installed and ran. 
>> 
>> Sounds good :)
>>  
>> However, it failed to start: import error lib/box2d_32/_Box2D.so.
>> 
>> Is that error a bug in the program?
> 
> More likely an intel / arm problem. The XO-1.75 needs ARMv7 binaries, while 
> older XOs used x86. The activity bundle would have to include .so files for 
> each supported architecture. I don’t think we ever extended the bundle 
> structure to properly handle multi-arch, it was designed for 
> platform-independent code like Python.
> 
> Okay cool :)
> 
> Can the bundle structure deal with this in an ad-hoc way, or does it need 
> changes to the Sugar Desktop platform itself? 

The bundle can have arbitrary library folders, but the activity would need to 
implement selecting the right binary for the current architecture.

- Bert -



smime.p7s
Description: S/MIME cryptographic signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Issue tracking on Github?

[Bert Freudenberg]

On 18.05.2016, at 16:26, Dave Crossland  wrote:
> 
> Hi
> 
> On 18 May 2016 at 09:57, Tony Anderson  > wrote:
> Its an educational project. An example is 
> https://github.com/ezequielpereira/Bridge 
> . This version of the 
> Bridge-activity was developed as part of GCI. 
> The zip downloaded from github is named Bridge-master.zip. I copied the zip 
> to an XO-1.75, unzipped, and ran setup.py dist_xo. The result was a 
> proper xo bundle which installed and ran.
> 
> Sounds good :)
>  
> However, it failed to start: import error lib/box2d_32/_Box2D.so.
> 
> Is that error a bug in the program?

More likely an intel / arm problem. The XO-1.75 needs ARMv7 binaries, while 
older XOs used x86. The activity bundle would have to include .so files for 
each supported architecture. I don’t think we ever extended the bundle 
structure to properly handle multi-arch, it was designed for 
platform-independent code like Python.

- Bert -





smime.p7s
Description: S/MIME cryptographic signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Javascript Activities

[Bert Freudenberg]

On 24.04.2016, at 06:41, Dave Crossland  wrote:
> On 23 April 2016 at 22:52,  > wrote:
> E-Toys is just a black screen on my Note 5.
> 
> That's a pity! Etoys seems to me to be one of the most important yet 
> undervalued Sugar Activities :) 

Pulling in a newer version of SqueakJS might help with that.

> The "Squeakers DVD" in http://squeakland.org/resources/audioVisual/ 
>  is cool, shows how powerful it 
> can be for learning! :)

- Bert -



smime.p7s
Description: S/MIME cryptographic signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Active development

[Bert Freudenberg]

On 18.04.2016, at 17:28, Dave Crossland  wrote:
> 
> Hi
> I spent a lot of time yesterday reading about the history of smalltalk, and 
> it seems undervalued. 
> 
> http://activities.sugarlabs.org/en-US/sugar/search?q=squeak=all 
>  only 
> produces 1 result, etoys. 

When OLPC development was started, Squeak was indeed considered as an 
implementation language, but ultimately Python was selected in the hope of 
tapping into the larger open-source community (the Smalltalk developer 
community is quite small compared to Python users). Alan even gave a keynote at 
Pycon but I don’t think it actually lead to a big influx of developers for 
Sugar.

Etoys has been pretty much the only non-Python activity for a very long time 
(I’m not sure if there is another one nowadays). See
https://wiki.sugarlabs.org/go/Development_Team/Low-level_Activity_API 


> Are any other activities written in squeak?

Very few, but yes:

http://activities.sugarlabs.org/en-US/sugar/addon/4054 

http://activities.sugarlabs.org/en-US/sugar/addon/4235 


… and some more at:
http://hpi.uni-potsdam.de/hirschfeld/projects/olpc/

> Can other activities be made within etoys? 

In Etoys you create projects, and there is a way to make a Sugar activity from 
a project, but that is more of an experimental feature, we never added a proper 
UI:


- Bert -





smime.p7s
Description: S/MIME cryptographic signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [IAEP] [SLOB] Meeting reminder

[Bert Freudenberg]

On 05.10.2015, at 16:23, Adam Holt <h...@laptop.org> wrote:
> 
> On Mon, Oct 5, 2015 at 7:05 PM, James Cameron <qu...@laptop.org 
> <mailto:qu...@laptop.org>> wrote:
> G'day Walter,
> 
> It has emerged that 23 UTC is not 6pm Boston.
> 
> Could meetings be called using only UTC please?  ;-)
> 
> If so use:
> http://google.com/search?q=utc+time <http://google.com/search?q=utc+time>
> 
> I like Bert Freudenberg prefer to pick 1 real city where many of us Actually 
> Live, whichever one does not matter -- but including that 1 single link 
> (whichever) keeps everyone honest:
> http://google.com/search?q=nyc+time <http://google.com/search?q=nyc+time>
> http://google.com/search?q=lima+time <http://google.com/search?q=lima+time>
> http://google.com/search?q=boston+time 
> <http://google.com/search?q=boston+time>
> http://google.com/search?q=montevideo+time 
> <http://google.com/search?q=montevideo+time>
I’m pretty sure that as an ombudsperson I should step in only when there is a 
conflict ;)

But I’ll say that we have had good experience sending meeting announcements 
with a link to the time web site, showing the desired time as local plus a 
gazillion other time zones. Here’s what it would have looked like for Boston 
6pm:

http://www.timeanddate.com/worldclock/fixedtime.html?msg=SLOBs+Meeting=20151005T18=43
 
<http://www.timeanddate.com/worldclock/fixedtime.html?msg=SLOBs+Meeting=20151005T18=43>

At the bottom it even lists the time in UTC for James ;) 

- Bert -

> On Sun, Oct 04, 2015 at 11:00:29AM -0400, Walter Bender wrote:
> > Tomorrow (5 October) is the first Monday of the month. We will have a
> > meeting at 23:00 UTC (6PM in Boston; 4PM in Managua; 6PM in
> > Port-au-Prince; 7PM in Asuncion; 8PM in Montevideo; 8PM in BA;
> > midnight in Paris; 4:30 AM in Dehli; 10AM (+1) in Sydney).
> >
> > Please join us.
> >
> > regards.
> >
> > -walter
> > --
> > Walter Bender
> > Sugar Labs
> > http://www.sugarlabs.org <http://www.sugarlabs.org/>
> > ___
> > Sugar-devel mailing list
> > Sugar-devel@lists.sugarlabs.org <mailto:Sugar-devel@lists.sugarlabs.org>
> > http://lists.sugarlabs.org/listinfo/sugar-devel 
> > <http://lists.sugarlabs.org/listinfo/sugar-devel>
> 
> --
> James Cameron
> http://quozl.linux.org.au/ <http://quozl.linux.org.au/>
> ___
> IAEP -- It's An Education Project (not a laptop project!)
> i...@lists.sugarlabs.org <mailto:i...@lists.sugarlabs.org>
> http://lists.sugarlabs.org/listinfo/iaep
> 
> -- 
>  <http://lists.sugarlabs.org/listinfo/iaep> 
> <http://lists.sugarlabs.org/listinfo/iaep>Unsung Heroes of OLPC, interviewed 
> live @  <http://lists.sugarlabs.org/listinfo/iaep>http://unleashkids.org 
> <http://unleashkids.org/> !
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel






smime.p7s
Description: S/MIME cryptographic signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [IAEP] Planning for the future (Samuel Greenfeld)

[Bert Freudenberg]

On 25.02.2015, at 13:22, Nick Doiron ndoi...@mapmeld.com wrote:
 
 I've worked with the project for some time, as a developer, teacher, and 
 teacher-trainer.
 
 There have been triumphs and setbacks in the past, but I can't escape this 
 observation: when people have a choice, they choose not to use Sugar.  For 
 many schools, they have what was donated and there is no choice. When OLPC 
 started, Android was an independent concept for a feature phone and not a 
 choice for anyone. But if members of our community are talking about a major 
 project in today's world, examine why the wider world isn't using Sugar at 
 the same level that they adopt other edu-tech, like Scratch. Time and time 
 again, local teachers are doing everything we ask, and our true limit is the 
 technology and UX.
 
 As a developer, I have lost track of which of my activities might run on 
 modern Sugar. I've seen simple UIs and browser-based activities stop working, 
 not because of shaky code, but because dropdown menus got deprecated, or 
 browser embedding was switched out with a different library. There are 
 reasons behind these code changes, like touch-enabled UI, but were these 
 reasons so real?  At the end of all this continuing development, when I use 
 an XO-1 in Haiti, I see the same Sugar that we used in 2011, but with fewer 
 working activities.
 
 I am interested in the future of Sugar in the same way that I'm interested in 
 the future of television. The next big thing is not a revision of the old, 
 but something very new, something more attuned to the web and open source 
 ecosystem as it exists today.
 
 -- Nick Doiron


+1

- Bert -



smime.p7s
Description: S/MIME cryptographic signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [SoaS] Testing Sugar Activities Fedora-Live-SoaS-i686-21_Beta-4

[Bert Freudenberg]

On 23.11.2014, at 20:25, Iain Brown Douglas i...@browndouglas.plus.com wrote:
 
 On Sat, 2014-11-22 at 16:16 +0100, Bert Freudenberg wrote:
 On 22.11.2014, at 15:15, Jean THIERY jean.thi...@modlibre.info wrote:
 
 EToys-116 displays
 « Cannot find image file: squeak, did you run 'initsqueak -m'? »
 After clicking on this message,
 the screen is filled by cars and is not usable.
 
 That looks weird ... does it work if you run etoys from the Terminal 
 activity?
 
 Thank you Bert for your reply,
 
 Yes, Etoys starts ok when I simply:
 
 run etoys from the Terminal activity.
 
 Why is this? what is wrong with the Sugar launcher?

I have no idea. The error message should actually mean it doesn't work at all. 
But you're saying it is running, albeit incorrectly (screen filled with 
cars). Maybe those two are unrelated. The latter might have to do with being 
run full-screen vs. windowed. We didn't change anything in Etoys so I think it 
must be some environmental change?

- Bert -



smime.p7s
Description: S/MIME cryptographic signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [SoaS] Testing Sugar Activities Fedora-Live-SoaS-i686-21_Beta-4

[Bert Freudenberg]

 On 22.11.2014, at 15:15, Jean THIERY jean.thi...@modlibre.info wrote:
 
 EToys-116 displays
 « Cannot find image file: squeak, did you run 'initsqueak -m'? »
 After clicking on this message,
 the screen is filled by cars and is not usable.

That looks weird ... does it work if you run etoys from the Terminal activity?

- Bert -





smime.p7s
Description: S/MIME cryptographic signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [Announcement] Sugarizer v0.5 is available for your device

[Bert Freudenberg]

On 17.10.2014, at 08:25, Lionel Laské lio...@olpc-france.org wrote:

 Hi all,
  
 I'm proud to announce the fifth version (0.5) of Sugarizer, a taste of Sugar 
 for any device.
  
 http://sugarizer.org

Very nice!

 New Etoys activity (beta)

I've made some good progress on this since you grabbed a copy, you may want to 
update :)
http://bertfreudenberg.github.io/SqueakJS/etoys/

There are quitSqueak() and onQuit() functions now which should make it easier 
for you to hook it up. See for example
https://github.com/bertfreudenberg/SqueakJS/blob/master/benchmark/benchmark.js

- Bert -





smime.p7s
Description: S/MIME cryptographic signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] From GConf to GSettings

[Bert Freudenberg]

 On 26.12.2013, at 18:02, Emil Dudev emildu...@gmail.com wrote:
 
 As GConf is deprecated, it should be replaced by GSettings.
 
 I've made a patch that will change most of the code to use GSettings.
 (I'm not sure how to include the link, as it will cause the mail to be
 sent to the spam folder).
 
 Moving to GSettings is not something easy. The biggest issue is the
 compatibility of the activities.
 How should it be handled?
 I'm not sure how many activities use GConf. I was able to find only 3:
 read and write (using sugar's speech settings), and browse. But I'm
 sure there are more activities.

Etoys reads the Sugar nick name and colors from the .gconf files. 

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

Re: [Sugar-devel] [ANN] SqueakJS

[Bert Freudenberg]

Thank you! :)

For those who don't want to read the explanations, just see the demo:

http://bertfreudenberg.github.io/SqueakJS/demo/simple.html

- Bert -

On 2013-12-23, at 15:46, Gonzalo Odiard gonz...@laptop.org wrote:

 Impressive!
 
 Gonzalo
 
 
 On Fri, Dec 20, 2013 at 6:30 PM, Bert Freudenberg b...@freudenbergs.de 
 wrote:
 Hi folks,
 
 this is still far from running Etoys in the browser, but it does work 
 surprisingly well:
 
 http://croquetweak.blogspot.de/2013/12/squeakjs-lively-squeak-vm.html
 
 Have a great Christmas!
 
 - Bert -



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

[Sugar-devel] [ANN] SqueakJS

[Bert Freudenberg]

Hi folks,

this is still far from running Etoys in the browser, but it does work 
surprisingly well:

http://croquetweak.blogspot.de/2013/12/squeakjs-lively-squeak-vm.html

Have a great Christmas!

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

Re: [Sugar-devel] [SoaS] Etoys in Sugar was: SoaS v10 testing and a few minor issues with 0.100

[Bert Freudenberg]

On 19.11.2013, at 17:33, Peter Robinson pbrobin...@gmail.com wrote:

 On Tue, Nov 19, 2013 at 12:39 PM, Peter Robinson pbrobin...@gmail.com 
 wrote:
 On Tue, Nov 19, 2013 at 5:33 PM, Gonzalo Odiard gonz...@laptop.org wrote:
 
 - The eToys activity (version 116) does not start properly
  then displays
  « cannot find image file: squeak, did you run 'inisqueak-m' ? »
 
 This was ticketed here,
 https://bugs.sugarlabs.org/ticket/4415
 
 Ah. I even commented on that, apparently :)
 
 
 The eToys developers are basically unresponsive, I'm in two minds
 whether we even bother to ship it because they can't be bothered doing
 things like updating to the latest sugar by migrating away from
 sugar-presence-service/ which was deprecated a long time ago.
 
 This is a rather non-trivial change to Etoys, whereas keeping the 
 sugar-presence-service emulation around is pretty trivial.
 
 Yes it would be good to do it, no I have not had the time. Nor someone else.
 
 You've had 3 odd years.

Yes. It never got to the top of my priority list. Mea culpa.

 But made Etoys work even if the emulated presence service is not around. So 
 everything except collaborating should work fine.
 
 How? what release, how was it communicated?

Etoys 5. We last talked about it on the SoaS list on June 7 2012. I wrote in 
reply to Manuel Kaufmann:

With regard to sharing, the only difference between Etoys 4 and Etoys 5 is 
that 
Etoys 5 will still work if the presence service fails, whereas Etoys 4 showed 
an error on startup.

 But this looks like a different problem, right?
 
 Yes.
 
 Care to elaborate?

The startup error cannot find image file: squeak is not related to the 
presence service at all, because it happens before Etoys is even started up. 
So, yes, this looks like a different problem. But without further information 
I can not elaborate, unfortunately.

- Bert -


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

Re: [Sugar-devel] Translating etoys home screen

[Bert Freudenberg]

On 08.10.2013, at 22:56, Daniel Drake d...@laptop.org wrote:

 Hi Bert,
 
 Could you advise on how we could translate the etoys home screen to Armenian?
 
 I see:
 
 http://forum.world.st/How-to-translate-strings-in-Home-pr-td3527757.html
 
 However the crucial how to translate link there is broken.

Ah, that's on the old wiki:
http://oldwiki.squeakland.org/display/sq/How+to+translate+Projects

Would be great if someone could make a more thorough step-by-step guide, like 
the one for the help system:

http://oldwiki.squeakland.org/display/sq/How+to+translate+the+Quick+Guides

However, these are different in that a separate project is used per language 
and loaded on demand, whereas for the home-screen (and projects in general) all 
the translations live in a single project together.

 The first step in this translation would be to generate a list of
 strings so that I can pass them on for translation.


Yes. Unfortunately our in-project translation is not set up for gettext, and 
the home screen is just a project as far as the system is concerned.

Once you have changed the home screen project, you need to switch to the hidden 
Unnamed1 project (via ctrl-shift-w) and save the etoys image.

- Bert -


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

Re: [Sugar-devel] How to deploy the webactivity libraries

[Bert Freudenberg]

On 2013-05-29, at 16:46, Daniel Drake d...@laptop.org wrote:

 In other words, I imagine that for activities that meet a certain
 level of complexity/functionality, there will commonly be some point
 at which they cross the line and start depending something specific in
 the underlying system, which breaks any dreams of self contained
 activities. If I'm right, maybe we should consider dropping that as a
 realistic possibility for a reliable experience.

Not being able to achieve 100% independence is no reason to ditch the idea 
completely. 

Bundling as much as possible in an activity keeps the interface between the 
activity and the outside world very small. There are a lot fewer things that 
can go wrong. And that's a Good Thing :)

- Bert -


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

[Sugar-devel] Collaboration API (was Re: HTML5 Activities page on the Wiki)

[Bert Freudenberg]

On 2013-04-30, at 12:23, Daniel Narvaez dwnarv...@gmail.com wrote:

 Hi Lionel,
 
 nice write up. 
 
 the only thing I'd change is probably to use Collaboration or something in 
 place of Telepathy. Just to make it clear we are after a generic API that can 
 work on other platforms too, rather than just wrapping telepathy.

Will that new Collaboration API be made available to non-HTML activities, too? 
And how will it be different from the deprecated Presence Service?

- Bert -

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

Re: [Sugar-devel] Collaboration API (was Re: HTML5 Activities page on the Wiki)

[Bert Freudenberg]

On 2013-04-30, at 12:54, Daniel Narvaez dwnarv...@gmail.com wrote:

 On 30 April 2013 12:35, Bert Freudenberg b...@freudenbergs.de wrote:
 Will that new Collaboration API be made available to non-HTML activities, 
 too? And how will it be different from the deprecated Presence Service?
 
 No, the idea is that the public API layer will be javascript,

Of course.

 the rest being internal implementation detail.

It is indeed the implementation details I'm talking about. The Javascript API 
could use an identical Python API. And that API could then be used both by 
Javascript activities and other activities, too. This would simplify the 
development process for all, because activity developers would not have to talk 
to Telepathy directly.

You have to implement the new API anyway. The question is simply, where to put 
that code. If you put it in the Sugar Shell and expose it via DBus, it will be 
available to all activity developers. The Javascript API would simply be a very 
thin layer that use it. OTOH, if you put that code only into the HTML activity 
support, you now have created two different ways to implement collaboration in 
Sugar. You will have to document separately, learn separately, maintain 
separately. 

- Bert -


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

Re: [Sugar-devel] Collaboration API (was Re: HTML5 Activities page on the Wiki)

[Bert Freudenberg]

On 2013-04-30, at 14:13, Daniel Narvaez dwnarv...@gmail.com wrote:

 On 30 April 2013 14:00, Bert Freudenberg b...@freudenbergs.de wrote:
 It is indeed the implementation details I'm talking about. The Javascript 
 API could use an identical Python API. And that API could then be used both 
 by Javascript activities and other activities, too. This would simplify the 
 development process for all, because activity developers would not have to 
 talk to Telepathy directly.
 
 You have to implement the new API anyway. The question is simply, where to 
 put that code. If you put it in the Sugar Shell and expose it via DBus, it 
 will be available to all activity developers. The Javascript API would 
 simply be a very thin layer that use it. OTOH, if you put that code only 
 into the HTML activity support, you now have created two different ways to 
 implement collaboration in Sugar. You will have to document separately, 
 learn separately, maintain separately.
 
 One problem with that approach is that we don't have a way for javascript to 
 talk dbus directly. We could perhaps build one but it's probably going to be 
 non trivial.

If you google javascript dbus you will find several bindings. But since you 
are implementing the HTML activity framework in Python anyway you wouldn't even 
need that.

 It's also worrying that one of the reason to deprecate the old Presence 
 Service seems to have been avoiding the extra IPC layer, which we would be 
 reintroducing here. 

So how would your Javascript API work, if not via IPC?

- Bert -


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

[Sugar-devel] Fwd: [ANN] Four new OLPC Games by the Software Architecture Group

[Bert Freudenberg]

Begin forwarded message:

 From: Michael Perscheid michaelpersch...@googlemail.com
 Subject:ANN] Four new OLPC Games by the Software Architecture Group
 Date: 16. April 2013 08:22:27 GMT-07:00
 To: Squeak in Germany / Squeak in Deutschland 
 squeak...@lists.squeakfoundation.org
 Reply-To: Squeak in Germany / Squeak in Deutschland 
 squeak...@lists.squeakfoundation.org
 
 Hi all,
 
 we'd like to announce that we published four new games for the OLPC/XO laptop 
 (also available 
 for Standard Squeak, MIT license). They have been developed by students in 
 the last semesters 
 of our software architecture lecture (Hasso-Plattner-Institute, University of 
 Potsdam).
 
 http://www.hpi.uni-potsdam.de/swa/projects/olpc/index.html
 (or: http://www.hpi.uni-potsdam.de/hirschfeld/projects/olpc/index.html)
 
 In particular, we thank the following students for their course work and 
 Matthias Springer for 
 porting the projects to the XO. 
 
 BroBreakout
   Fabio Niephaus, Daniel Werner, Philipp Otto, Frank Blechschmidt
 PetConnect
   Jaqueline Pollak, Daniel Neuschaefer-Rube, Jakob Reschke, Judith 
 Hartmann
 BDBoulderDash
   Johannes Koch, Tim Friedrich, Johannes Villmow, Felix Wolff
 SpaceCleanup
   Kai Fabian, Dominik Moritz, Malte Swart, Matthias Springer
 
 More games are coming soon...
 
 Best,
 Michael
 
 ---
 Michael Perscheid
 michaelpersch...@googlemail.com
 
 http://www.michaelperscheid.de/
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [PATCH Etoys] Use ALSA sound backend if available

[Bert Freudenberg]

On 15.04.2013, at 07:53, Daniel Drake d...@laptop.org wrote:

 Hi,
 
 
 On Wed, Mar 27, 2013 at 1:10 PM, Daniel Drake d...@laptop.org wrote:
 Extend the sound backend selection code to consider using ALSA.
 On XO-1.75 and XO-4 this fixes sound in etoys with squeak-vm-4.x.
 It also fixes XO-4 sound recording which was not working on any previous
 version.
 
 Ping, any news here?
 
 Thanks
 Daniel


Ah, I'm sorry, didn't get to it yet. Thanks for the reminder!

- Bert -


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

Re: [Sugar-devel] Sugar future

[Bert Freudenberg]

On 12.04.2013, at 15:39, Caryl Bigenho cbige...@hotmail.com wrote:

 O.K. So... now it is time to divide and conquer!

Is it?

 That is... divide the work up into doable little projects and conquer the 
 huge task of getting Sugar Activities onto Android and possibly other 
 platforms.

IMHO the individual activities are *not* what makes Sugar such a compelling 
proposition. Sure, having some of them as apps on other platforms would be 
nice. But isn't collaborating and sharing at the heart of Sugar? The Journal as 
central UI? The effortless discovery of your peers in the neighborhood view? 
Etc? *That* experience would have to be ported to another platform first, and 
then the activities can follow. Otherwise, it's just a bunch of random apps, of 
which there are plenty already in the various app stores.

- Bert -

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

Re: [Sugar-devel] Fwd: Unable to exit Etoys.

[Bert Freudenberg]

On 2013-02-13, at 17:17, Rafael Ortiz raf...@activitycentral.com wrote:

 
 Hi 
 
 We are having an error while trying to exit etoys
 
 
 
 Sugar Activity: Etoys v 113
 
 Steps to Reproduce:
 
 1. Open Etoys activity from Home/List View
 2. Perform a few operations
 3. Click on 'X' button on top right of the activity menu
 
 Expected Result: Etoys Activity should exit without any errors
 
 Actual Result: Etoys Activity does not exit; neither from the activity menu, 
 nor from 'Stop' option from the frame.
 System has to be rebooted to exit from Etoys!
 
 Evidence: Screenshot and Logs attached

I could not read attachments. Perhaps better attach them to a bug report?

In any case, if Etoys itself is still responsive, exiting should work fine, 
too, but it will ask first. Does clicking the (X) in the Etoys tool bar not 
work?

- Bert -


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

Re: [Sugar-devel] Fwd: Unable to exit Etoys.

[Bert Freudenberg]

On 2013-02-13, at 17:51, Rafael Ortiz raf...@activitycentral.com wrote:

 Hi Bert.
 
 
 On Wed, Feb 13, 2013 at 11:42 AM, Bert Freudenberg b...@freudenbergs.de 
 wrote:
 
 On 2013-02-13, at 17:17, Rafael Ortiz raf...@activitycentral.com wrote:
 
 
  Hi
 
  We are having an error while trying to exit etoys
 
 
 
  Sugar Activity: Etoys v 113
 
  Steps to Reproduce:
 
  1. Open Etoys activity from Home/List View
  2. Perform a few operations
  3. Click on 'X' button on top right of the activity menu
 
  Expected Result: Etoys Activity should exit without any errors
 
  Actual Result: Etoys Activity does not exit; neither from the activity 
  menu, nor from 'Stop' option from the frame.
  System has to be rebooted to exit from Etoys!
 
  Evidence: Screenshot and Logs attached
 
 I could not read attachments. Perhaps better attach them to a bug report?
 
 
 Ticket created 
 http://bugs.sugarlabs.org/ticket/4428

You attached the same bad files to the bug report.

 In any case, if Etoys itself is still responsive, exiting should work fine, 
 too, but it will ask first. Does clicking the (X) in the Etoys tool bar not 
 work?
 
 The (X) Etoys tool bar doesn't work either. 
 
 It ask for ''Are you sure you want to leave etoys?'' and then you click 
 ''yes''..but
 it doesn't complete the action.

That is curious indeed. Seeing the log might be helpful.

- Bert -


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

Re: [Sugar-devel] Fwd: Unable to exit Etoys.

[Bert Freudenberg]

On 2013-02-13, at 18:09, Rafael Ortiz raf...@activitycentral.com wrote:

 On Wed, Feb 13, 2013 at 11:57 AM, Rafael Ortiz raf...@activitycentral.com 
 wrote:
 Ticket created
 http://bugs.sugarlabs.org/ticket/4428
 
 The relevant log is Etoys.txt.

That log is about Etoys trying to read the Sugar user name. 

What does your .gconf/desktop/sugar/user/%gconf.xml look like?

OTOH, this error should happen at the startup of Etoys, not when quitting. Are 
you sure this log is produced after pressing the exit button, not before?

Also, when Etoys hangs after pressing the exit button (does it?), try 
pressing alt-period (alt + .) which is Etoys' user interrupt key. That 
should also dump the stack in the log file, and would show what exactly Etoys 
is doing. Of course, you're welcome to press the debug button in the pink 
interrupt dialog and take a look around ;)

- Bert -

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

Re: [Sugar-devel] [PATCH sugar] Fallback to _NET_WM_PID to map windows to activities

[Bert Freudenberg]

On 2013-02-02, at 13:18, Daniel Narvaez dwnarv...@gmail.com wrote:

 From: Daniel Narvaez dwnarv...@gmail.com
 
 Most toolkits supports that property, so this allows to
 write activities without setting our own custom properties,
 which is very handy if you are not using python or are not
 able to go that low level.
 
 This is similar to what gnome-shell is doing. Simplifying
 a bit their logic to map windows to applications is
 
 1 Check WM_CLASS
 2 Check _NET_WM_PID
 3 Check startup notification properties
 
 Now 1 is not good enough for us. They map multiple windows
 to the same application, while for us every window is a
 separate activity. About 3, we don't currently implement
 startup notification but we could in the future. In that
 case it could just be a fallback.

Sounds like a very good idea to use standard properties, yes.

 It probably make sense to keep our own custom properties
 as 1, for complicated cases like running the window in a
 subprocess.

Does anyone remember why we introduced the custom properties, instead of using 
the PID? Adding these was a hassle so there must have been a good reason.

- Bert -

 ---
 src/jarabe/model/shell.py  | 44 +---
 src/jarabe/view/service.py |  6 +++---
 2 files changed, 28 insertions(+), 22 deletions(-)
 
 diff --git a/src/jarabe/model/shell.py b/src/jarabe/model/shell.py
 index 437ff90..c6fe742 100644
 --- a/src/jarabe/model/shell.py
 +++ b/src/jarabe/model/shell.py
 @@ -54,7 +54,8 @@ class Activity(GObject.GObject):
 LAUNCH_FAILED = 1
 LAUNCHED = 2
 
 -def __init__(self, activity_info, activity_id, color, window=None):
 +def __init__(self, activity_info, activity_id, bundle_id, color,
 + window=None, pid=None):
 Initialise the HomeActivity
 
 activity_info -- sugar3.activity.registry.ActivityInfo instance,
 @@ -74,6 +75,8 @@ class Activity(GObject.GObject):
 self._activity_info = activity_info
 self._launch_time = time.time()
 self._launch_status = Activity.LAUNCHING
 +self._bundle_id = bundle_id
 +self._pid = pid
 
 if color is not None:
 self._color = color
 @@ -204,16 +207,13 @@ class Activity(GObject.GObject):
 return self._windows[0]
 return None
 
 -def get_type(self):
 +def get_bundle_id(self):
 Retrieve the activity bundle id for future reference
 -if not self._windows:
 -return None
 -else:
 -return SugarExt.wm_get_bundle_id(self._windows[0].get_xid())
 +self._bundle_id
 
 def is_journal(self):
 Returns boolean if the activity is of type JournalActivity
 -return self.get_type() == 'org.laptop.JournalActivity'
 +return self._bundle_id == 'org.laptop.JournalActivity'
 
 def get_launch_time(self):
 Return the time at which the activity was first launched
 @@ -225,9 +225,7 @@ class Activity(GObject.GObject):
 
 def get_pid(self):
 Returns the activity's PID
 -if not self._windows:
 -return None
 -return self._windows[0].get_pid()
 +return self._pid
 
 def get_bundle_path(self):
 Returns the activity's bundle directory
 @@ -530,13 +528,20 @@ class ShellModel(GObject.GObject):
 
 activity_id = SugarExt.wm_get_activity_id(xid)
 
 -service_name = SugarExt.wm_get_bundle_id(xid)
 -if service_name:
 +bundle_id = SugarExt.wm_get_bundle_id(xid)
 +if bundle_id:
 registry = get_registry()
 -activity_info = registry.get_bundle(service_name)
 +activity_info = registry.get_bundle(bundle_id)
 else:
 activity_info = None
 
 +if not activity_id and window.get_pid():
 +for home_activity in self._activities:
 +launch_status = home_activity.get_launch_status()
 +if home_activity.get_pid() == window.get_pid() and \
 +launch_status == Activity.LAUNCHING:
 +activity_id = home_activity.get_activity_id()
 +
 if activity_id:
 home_activity = self.get_activity_by_id(activity_id)
 
 @@ -551,7 +556,7 @@ class ShellModel(GObject.GObject):
 logging.debug('first window registered for %s', activity_id)
 color = self._shared_activities.get(activity_id, None)
 home_activity = Activity(activity_info, activity_id,
 - color, window)
 + bundle_id, color, window=window)
 self._add_activity(home_activity)
 else:
 logging.debug('window registered for %s', activity_id)
 @@ -626,15 +631,16 @@ class ShellModel(GObject.GObject):
 self.emit('activity-removed', home_activity)
 

Re: [Sugar-devel] Hacking onto the appearing and hiding of OSK

[Bert Freudenberg]

On 2013-01-28, at 19:16, Paul Fox p...@laptop.org wrote:

 certainly not my call, but stealing keys which have always been
 intended for activities to use seems like it shouldn't be done
 lightly.


+1

- Bert -


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

Re: [Sugar-devel] How to detect touch of ebook mode?

[Bert Freudenberg]

For an activity example using multitouch see this:

http://activities.sugarlabs.org/sugar/addon/4611/

- Bert -

On 2012-12-06, at 12:17, Gonzalo Odiard gonz...@laptop.org wrote:

 For a example about how to catch touch events:
 
 http://git.sugarlabs.org/many-tests/mainline/blobs/master/touch_test.py
 
 In this case, touch events and mouse events are managed in the same way
 
 Gonzalo
 
 On Thu, Dec 6, 2012 at 12:23 AM, Ariel Calzada ar...@activitycentral.com 
 wrote:
 Hi!
 
 I'm sorry if this has been asked before but I woud like to know how to catch 
 touch events or e-book mode programmatically?
 
 Regards,
 
 -- 
 Ariel Calzada
 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] Multi-touch test activity

[Bert Freudenberg]

On 2012-11-06, at 23:50, Martin Langhoff martin.langh...@gmail.com wrote:

 On Sun, Nov 4, 2012 at 8:29 PM, Bert Freudenberg b...@freudenbergs.de wrote:
 Ah, thanks. I wasn't even going to file a bug report about the aliasing 
 because that is a limitation inherent to the kind of sensor we have.
 
 There are of course limitations, but we are in the process of tuning
 and tightening things on the IR.

Okay. The breaking up of touch contacts was surprising. I attached a photo here:

http://dev.laptop.org/ticket/12282

 All sensor types have some forms of aliasing. If you know how, you can
 confuse capacitive sensors too :-)

Yep. You may find my updated activity version useful in testing:

http://activities.sugarlabs.org/en-US/sugar/addon/4611/

I modified it to keep displaying the last touches.

Single-touch works pretty well already, tweaking multi-touch sounds good :)

- Bert -


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

[Sugar-devel] Multi-touch test activity

[Bert Freudenberg]

Hi folks,

I made a simple Sugar activity to test the XO-4's multi-touch screen:

http://activities.sugarlabs.org/en-US/sugar/addon/4611/

It works fine most of the time. Sometimes the touch contact ends unexpectedly 
without lifting the finger.

It also demonstrates that the Neonode sensor's two touch points are not 
independent: If you put down two fingers simultaneously, it does not know in 
which of the 4 possible positions the two fingers are (it only knows that 2 
horizontal and 2 vertical beams got obstructed) and so it has to guess. Also, 
the tracking sometimes switches over, e.g. when doing a pinch-zoom using your 
right hand.

For activity developers this means that pinch/zoom and rotation gestures will 
work fine, but we cannot rely on truly independent touch tracking.

Also, two-finger sweeps are not always recognized as two fingers if they are 
held close together.

Nonetheless, it is fun to play with if you happen to have an XO-4 Touch :)

Source code:

http://git.sugarlabs.org/testmultitouch/mainline

Patches welcome, but I want to keep the source simple, this is not going to 
become another Paint activity.

- Bert -

PS: Could some admin please delete the accidental non-mainline repo in 
http://git.sugarlabs.org/testmultitouch/ ? Keep mainline, remove 
testmultitouch. Thanks.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Multi-touch test activity

[Bert Freudenberg]

Ah, thanks. I wasn't even going to file a bug report about the aliasing because 
that is a limitation inherent to the kind of sensor we have.

Thinking about this a little bit more, only pinch/zoom will be fine. Rotation 
can still go in the wrong direction if the driver guesses the intersections 
wrongly.

- Bert -

On 2012-11-05, at 01:55, fors...@ozonline.com.au wrote:

 See also http://dev.laptop.org/ticket/12161
 
 Tony
 
 Hi folks,
 
 I made a simple Sugar activity to test the XO-4's multi-touch screen:
 
  http://activities.sugarlabs.org/en-US/sugar/addon/4611/
 
 It works fine most of the time. Sometimes the touch contact ends 
 unexpectedly without lifting the finger.
 
 It also demonstrates that the Neonode sensor's two touch points are not 
 independent: If you put down two fingers simultaneously, it does not know in 
 which of the 4 possible positions the two fingers are (it only knows that 2 
 horizontal and 2 vertical beams got obstructed) and so it has to guess. 
 Also, the tracking sometimes switches over, e.g. when doing a pinch-zoom 
 using your right hand.
 
 For activity developers this means that pinch/zoom and rotation gestures 
 will work fine, but we cannot rely on truly independent touch tracking.
 
 Also, two-finger sweeps are not always recognized as two fingers if they are 
 held close together.
 
 Nonetheless, it is fun to play with if you happen to have an XO-4 Touch :)
 
 Source code:
 
  http://git.sugarlabs.org/testmultitouch/mainline
 
 Patches welcome, but I want to keep the source simple, this is not going to 
 become another Paint activity.
 
 - Bert -
 
 PS: Could some admin please delete the accidental non-mainline repo in 
 http://git.sugarlabs.org/testmultitouch/ ? Keep mainline, remove 
 testmultitouch. Thanks.
 

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

Re: [Sugar-devel] [IAEP] Sugar Digest 2012-09-18

[Bert Freudenberg]

On 2012-09-24, at 01:40, James Cameron qu...@laptop.org wrote:

 On Sun, Sep 23, 2012 at 07:53:35PM -0300, Gonzalo Odiard wrote:
 Paint activity was developed by a Brazilian team and a lot of variables
 had Portuguese names.
 Whit the time, we changed a lot, but there are a few pending.
 
 It is irritating that we still store source code in linear text files
 without built-in internationalisation.
 
 As you change these names, they become far less useful to programmers
 who use that language.
 
 The development system would be more open and inclusive if there was a
 way to keep variable names, and other text, in multiple languages.
 
 I've seen nothing yet that achieves this.  It would require editor
 application support.


Tile-based programming systems like Etoys, Scratch, or Turtle Art make this a 
lot easier. They at least support switching the names of built-in functions and 
objects.

Translating user-defined names is harder, but not impossible. I don't know of 
any deployment-ready system, but there have been at least demos, e.g. the 2004 
TranSqueak project (details below, though I couldn't find a PDF online).

- Bert -

TranSqueak - making the world a smaller place: on-the-fly translation of Etoy 
projects and instant messaging

AUTHORS: Michael Rüger, Yoshiki Ohshima (Viewpoints Research Institute, 
Glendale, CA, USA)

PUBLISHED: Proceedings of Second International Conference on Creating, 
Connecting and Collaborating through Computing (C5), 2004.

ABSTRACT: This work presents an extension to the existing multilingualization 
work (ml7n) which allows people to collaborate on Squeak Etoy projects across 
different natural languages. Squeak etoys support several languages, both 
ISO-Latin based ones (erg., English, German, French), and nonISO languages 
(e.g., Japanese). Switching between languages for the Etoy tiles is fairly easy 
to support as the tiles provide a predefined set of words and phrases, which 
only need to be translated once. There are two areas where we need to go beyond 
the predefined and pretranslated set of phrases: user supplied names and 
communication between collaborators. This work presents an approach based on 
online translation services. We demonstrate a working prototype and a first 
analysis of the feasibility of this approach.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [DESIGN] Examples objects support for activities.

[Bert Freudenberg]

On 2012-08-31, at 21:54, Gonzalo Odiard godi...@gmail.com wrote:

 * IMHO the code added to enable configure the examples directory is so 
 complicate,
 and do not add too much value. I think is better use a fixed examples or 
 samples
 (as in TurtleArt). If the maintainer want use it, should follow the 
 convention.

We are talking about pretty much just two lines:

+if cp.has_option(section, 'examples_path'):
+self._examples_path = cp.get(section, 'examples_path')

I don't see why you would consider that too complicated. It adds value for 
activities that already have examples, when relocating them isn't that easy. 
That's a lot of bang for the buck IMHO.

- Bert -


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

Re: [Sugar-devel] activity sandbox

[Bert Freudenberg]

On 2012-08-28, at 15:53, Gonzalo Odiard gonz...@laptop.org wrote:

 On Tue, Aug 28, 2012 at 10:49 AM, blekros sugar blekros.su...@gmail.com 
 wrote:
 I'd like to use Eclipse with PyDev on Windows to try to build activities.
 
 Has the Sugar shell been ported to Windows (x86) or Android or iOS or as a 
 chrome / firefox plugin so that I can use my existing environments without 
 VMWare or VirtualBox?
 
 
 No. Sugar run in a linux os.

Right. Sugar activities do not only require the Sugar Shell to run. They are 
full-fledged Linux applications that follow a few additional conventions to 
function well in Sugar. But that means that they need a full Linux + X11 
operating system stack to work.

 I can't find anything resembling an object model, or class diagram that 
 shows the architectural breakdown of Sugar.   Where to look?
 
 Sadly, our documentation is not in a good shape.
 Today, the best doc is the code itself. 

Well, there still is *some* documentation for activity authors.

We have a nice book:

http://en.flossmanuals.net/make-your-own-sugar-activities/

And for a more low-level understanding there is this documentation page:

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

More documentation resources are listed at

http://wiki.sugarlabs.org/go/Activity_Team/Resources

- Bert -


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

Re: [Sugar-devel] activity sandbox

[Bert Freudenberg]

On 2012-08-29, at 17:01, blekros sugar blekros.su...@gmail.com wrote:

 Thanks, I'll check out the documentation and get up to speed a little more.  
 Meantime --
 
 I just want to make sure I understand:
 
 1.   Sugar activities *are* Python scripts

... usually. Any programming language is fine for writing Sugar activities, as 
long as it can connect to D-Bus and provide an X11 user interface. But writing 
them in Python is a lot simpler because you can make use of the Sugar Toolkit 
(a Python library used by. One example of an activity not written in Python is 
Etoys.

 -- but they use Linux-specific packages, instead of using os.* or sys.* 
 packages, which wrap the OS that lies beneath.   Same for GTK+.  The GUI 
 cannot be made to use ported versions of the GTK+ API.

That's pretty much correct. At least no-one has seriously tried to make Sugar 
work elsewhere.

 2.  The Sugar shell is not a service layer between the bare metal Linux OS 
 and Sugar presentation (its desktop) .  In other words, the shell cannot be 
 updated to plug into to modern device OSes such as I/Pad or Android.

Well porting the shell is maybe not that hard, but that wouldn't mean the 
activities simply work, too. That's because activities are not coded purely 
against the Sugar API but may make use of stuff more generally available in 
Linux. OTOH some simple activities might just work.

 3.  No one has attempted to port Activities, i.e. the FUN stuff,  to Browser 
 apps (HTML 5 + Javascript) so any kid with a smart phone could play with, 
 say, Physics, or Turtle.

It wouldn't be so much porting as reimplementing. Also you would need a 
framework for collaboration and journaling first (which is what distinguishes 
Sugar most from other environments). Individual activities aren't all that 
interesting IMHO, equivalent apps can be found for pretty much any platform. 
The way activities are assembled into a whole learning environment is Sugar's 
raison d'etre.

- Bert -

 
 
 Brad
 
 
 
 
 
 
 On Wed, Aug 29, 2012 at 7:15 AM, Bert Freudenberg b...@freudenbergs.de 
 wrote:
 On 2012-08-28, at 15:53, Gonzalo Odiard gonz...@laptop.org wrote:
 
  On Tue, Aug 28, 2012 at 10:49 AM, blekros sugar blekros.su...@gmail.com 
  wrote:
  I'd like to use Eclipse with PyDev on Windows to try to build activities.
 
  Has the Sugar shell been ported to Windows (x86) or Android or iOS or as a 
  chrome / firefox plugin so that I can use my existing environments without 
  VMWare or VirtualBox?
 
 
  No. Sugar run in a linux os.
 
 Right. Sugar activities do not only require the Sugar Shell to run. They are 
 full-fledged Linux applications that follow a few additional conventions to 
 function well in Sugar. But that means that they need a full Linux + X11 
 operating system stack to work.
 
  I can't find anything resembling an object model, or class diagram that 
  shows the architectural breakdown of Sugar.   Where to look?
 
  Sadly, our documentation is not in a good shape.
  Today, the best doc is the code itself.
 
 Well, there still is *some* documentation for activity authors.
 
 We have a nice book:
 
 http://en.flossmanuals.net/make-your-own-sugar-activities/
 
 And for a more low-level understanding there is this documentation page:
 
 http://wiki.sugarlabs.org/go/Development_Team/Low-level_Activity_API
 
 More documentation resources are listed at
 
 http://wiki.sugarlabs.org/go/Activity_Team/Resources
 
 - Bert -
 
 
 

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

Re: [Sugar-devel] [DESIGN] Examples objects support for activities.

[Bert Freudenberg]

On 2012-08-22, at 04:27, Martin Abente wrote:

 Hello everyone:
 
 From the meeting notes and Bert suggestion I have what could be called the 
 version 2 of this feature, greatly simplified and complies with everyones 
 rightful suggestions.
 
 To avoid spaming (for some time) the sugar-devel ML I will post the patches 
 just here:
 
 sugar: 
 http://www.sugarlabs.org/~tch/patches/examples/sugar/0001-Examples-objects-support-V2.patch
 sugar-toolkit: 
 http://www.sugarlabs.org/~tch/patches/examples/sugar-toolkit/0001-Examples_path-activity-info.patch
 
 Feedback is welcome!
 tch

I have not tried it, but by eyeballing the code looks fine :)

- Bert -


 On Tue, Aug 21, 2012 at 3:42 PM, Martin Abente 
 martin.abente.lah...@gmail.com wrote:
 I don't see why not, we can achieve both things :). Maybe someone have 
 another opinion regarding this?
 
 
 On Tue, Aug 21, 2012 at 3:07 PM, Bert Freudenberg b...@freudenbergs.de 
 wrote:
 On 2012-08-21, at 20:17, Martin Abente wrote:
 
  The design I implemented works like this:
 
  a. activity developers or deployments add a new examples folder inside 
  the activity bundle with their examples objects.
  b. when the activity starts, the example folder will be accessible through 
  the journal as new volume option, and also from __any__ ObjectChooser.
  c. Only one volume button will be shown, even when many instances of the 
  activity are running.
  d. The example folder will disappear from the journal when the last 
  instance is closed.
  [...]
  Waiting for more feedback... :)
 
 And in another thread:
 
  instead of a magic directory name, couldn't the activity.info file have a 
  new entry giving the examples path?
 
 
  What I tried, or I am trying, to do is to make this feature available as 
  easy as we can, so even deployments could add their own examples with very 
  little technical knowledge requirements. That why I try this convention 
  (magical) idea.
 
 
 Okay, so by default it should look for a directory named examples. But 
 maybe a different path could be set in activity.info?
 
 - Bert -
 
 
 ___
 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] [PATCH sugar] Example objects support

[Bert Freudenberg]

On 2012-08-21, at 15:38, Sascha Silbe wrote:

 Martin Abente Lahaye martin.abente.lah...@gmail.com writes:
 
 +def _add_activity_example(self, home_activity):
 +examples_path = os.path.join(home_activity.get_bundle_path(),
 +'examples')
 +
 +if not os.path.exists(examples_path):
 +return
 
 If you add a guard against home_activity.get_bundle_path() returning
 None, you can drop the special-casing for the Journal activity.


I like the general idea very much. However, instead of a magic directory name, 
couldn't the activity.info file have a new entry giving the examples path?

This could be encapsulated in a function home_activity.get_examples_path().

The advantage of this would be that activities could specify a directory 
(relative to the bundle directory) that fits their structure better than having 
to put the examples into a fixed location in the bundle. In very special cases 
they could even give an absolute path, e.g. Etoys examples are in 
/usr/share/etoys/ExampleEtoys ...

- Bert -

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

Re: [Sugar-devel] [DESIGN] Examples objects support for activities.

[Bert Freudenberg]

On 2012-08-21, at 20:17, Martin Abente wrote:

 The design I implemented works like this:
 
 a. activity developers or deployments add a new examples folder inside the 
 activity bundle with their examples objects.
 b. when the activity starts, the example folder will be accessible through 
 the journal as new volume option, and also from __any__ ObjectChooser.
 c. Only one volume button will be shown, even when many instances of the 
 activity are running.
 d. The example folder will disappear from the journal when the last instance 
 is closed.
 [...]
 Waiting for more feedback... :)

And in another thread:

 instead of a magic directory name, couldn't the activity.info file have a 
 new entry giving the examples path?
 

 What I tried, or I am trying, to do is to make this feature available as easy 
 as we can, so even deployments could add their own examples with very little 
 technical knowledge requirements. That why I try this convention (magical) 
 idea.


Okay, so by default it should look for a directory named examples. But maybe 
a different path could be set in activity.info?

- Bert -


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

Re: [Sugar-devel] Engadget post on XO Touch

[Bert Freudenberg]

On 26.07.2012, at 20:21, Mike Lee wrote:

 Here's a cool demo of the Neonode multitouch frame:
 
 http://www.slashgear.com/neonode-3d-touch-headed-to-tablets-and-phones-hands-on-28215933/
 
 Not only multi-touch, but also entry direction and tilt. For a dollar!

Well, for tilt you would need to stack multiple frames on top of each other as 
they did in that prototype. For a touch-screen you would want it to be as thin 
as possible, that would mean single-layer. The Kindle Touch and Nook use 
Neonode zForce touch sensors, too. Here's a nice animation showing the 
principle:

http://www.neonode.com/solutions/zforce

Does anyone know how the multi-touch stuff is going to be exposed in Linux?

- Bert -


 
 Seems like this would be great as a retrofit kit.
 
 Mike
 
 On Thu, Jul 26, 2012 at 11:09 PM, Sameer Verma sve...@sfsu.edu wrote:
 www.engadget.com/2012/07/26/olpc-xo-touch-1-75-to-use-neonode-tech/
 
 The post says as yet unreleased XO 1.75. What's the official status
 on the 1.75? Still as yet unreleased?
 
 cheers,
 Sameer


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

[Sugar-devel] [RELEASE] Etoys 5.0.2408

[Bert Freudenberg]

This is a bugfix release for 5.0.

== Sources ==

http://download.sugarlabs.org/sources/sucrose/glucose/etoys/etoys-5.0.2408.tar.gz

== Changes ==

* Updated translation: bn, da, de, es, hy, nl, pt, sv, zh_CN
* Added translations: hus, en_GB
* Sugar: fix choosing objects from external media instead of Journal, and 
handle non-ASCII filenames
* make saved projects that do not use new features more likely to work in 
earlier versions of Etoys (SQ-1095)
* adds a preference, 'singlePixelNib', so the smallest brush will draw with a 
one-pixel-wide nib (SQ-1004)
* fix dropping a GIF image into Etoys (SQ-1094)
* mark month names and weekday names for translation (SQ-1102)
* some ScratchConnect fixes from Koji Yokokawa (SQ-1085, SQ-1086, SQ-1087)
* better comment in POT for translators about the meta-phrases 'Language-Name' 
and 'Language-Direction'
* Move ScratchClient to 'Tools' category
* Revert addition of graph-location watcher items to Morph's extras menu. The 
viewer is a better way to get watchers.
* minor fixes (SQ-811, SQ-869, SQ-1036, SQ-1045, SQ-1051, SQ-1088, SQ-1096, 
SQ-1099)

- Bert - (for the Etoys team)

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

Re: [Sugar-devel] sugarless.py Implode version

[Bert Freudenberg]

On 29.06.2012, at 02:00, James Cameron wrote:

 On Thu, Jun 28, 2012 at 11:36:25AM -0300, Gonzalo Odiard wrote:
 +1 to keep the sugarless version working.
 In the future, I hope we have more activities working in Gnome too.
 
 I would like to see every activity as a menu option in the GNOME
 menus.  ;-}


Really?

Starting up Sugar in a window and auto-launching one of its activities would 
probably be a modestly simple change. Although it would be not as efficient as 
running Sugar on its own. (and the problem of keybindings in emulated Sugar is 
still unresolved, right?)

- Bert -

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

Re: [Sugar-devel] [IAEP] Sugar as a Mac Ap?

[Bert Freudenberg]

On 2012-06-14, at 12:54, Peter Robinson wrote:

 On Wed, Jun 13, 2012 at 5:42 PM, Walter Bender walter.ben...@gmail.com 
 wrote:
 
 So the question is: is there a Linux/Gnome VM for the iPad? iPhone? 
 iWhatever?
 
 No because Apply explicitly doesn't allow other languages so we can't
 run python which means we need some form of python - objective-C
 compiler or similar to be able to run it on those sort of devices.

Not true. Not since 2010 anyway. You can now code iOS apps in any language you 
want. There are apps in the Apple App Store written in Squeak, and Lua, and I 
guess many other languages. E.g. here is a Python environment:

http://itunes.apple.com/us/app/python-for-ios/id485729872?mt=8

There are of course other reasons why you wouldn't get Sugar into the app store 
(see e.g. my message from yesterday). But the programming language is no 
problem.

- Bert -


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

Re: [Sugar-devel] [PATCH sugar] Journal: rename object_id argument to object_id_or_path

[Bert Freudenberg]

On 2012-06-13, at 01:37, James Cameron wrote:

 Reviewed-by: James Cameron qu...@laptop.org


Thanks, James and Walter. 

I forgot to point out that there is no functional change in the patch. Just 
renaming of arguments and variables. This should not have any effects on 
calling code, unless they use keyword arguments (I did not find any occurrence, 
and it seems unlikely).

- Bert -


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

Re: [Sugar-devel] [IAEP] Sugar as a Mac Ap?

[Bert Freudenberg]

On 2012-06-13, at 18:42, Walter Bender wrote:

 Etoys runs in a virtual machine. Once that VM is ported to a new
 environment, Etoys will run.
 Sugar on the other hand is a desktop and collection of applications
 that require Linux and the Gnome toolkit (among other dependencies).
 Once a Linux VM with Gnome is running in an environment, the process
 of porting Sugar is *relatively* painless.
 
 So the question is: is there a Linux/Gnome VM for the iPad? iPhone? iWhatever?
 
 -walter


Apple wouldn't allow a generic VM into their App Store. The only unrestricted 
environment on the iPad is the web browser.

I think Sugar's open and collaborative philosophy is fundamentally incompatible 
with Apple's current developer guidelines.

You could port single Sugar activities to the iPad, but since users would be 
prevented from changing them, Sugar's idea of learning by hacking would be lost.

- Bert -

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

Re: [Sugar-devel] Sugar module build is broken by translations

[Bert Freudenberg]

On 2012-06-13, at 17:41, Simon Schampijer wrote:

 Sadly, we break rather often lately after pushes from pootle. There is no 
 verification done inside pootle itself :/
 
 Regards,
Simon


Maybe msgfmt errors should be treated as warnings unless you're trying to 
deployment a bundle.

- Bert -


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

Re: [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 si...@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 -


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

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

[Bert Freudenberg]

On 2012-06-11, at 16:16, Walter Bender wrote:

 On Mon, Jun 11, 2012 at 9:56 AM, Bert Freudenberg b...@freudenbergs.de 
 wrote:
 On 2012-06-11, at 15:15, Walter Bender wrote:
 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.

How would that help submitting proper patches?

(I'm not opposed to including git, just saying that for proper patches you need 
the proper commit history)

 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).


This diffing would have the same effect as patches made from a new git 
repository.

- Bert -

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

Re: [Sugar-devel] Squeak / Etoys development under Sugar (was: Object Chooser)

[Bert Freudenberg]

On 07.06.2012, at 21:36, Ajay Garg wrote:

 Thanks Bert for the reply.
 
 On Thu, Jun 7, 2012 at 8:27 PM, Bert Freudenberg b...@freudenbergs.de wrote:
 On 07.06.2012, at 15:57, Ajay Garg wrote:
 
  Hi Bert.
 
  a)
  Could you give a rough idea, as to what is the release cycle for squeak-vm?
 
 There is no fixed release cycle, releases are done as needed and as time 
 permits. Once or twice a year has been typical.
 
 What is your time frame? If need be one could package a Squeak VM + patches.
 
 Well, we need the squeak-vm (with the Mpeg3Plugin.c fix) for ceibal 
 right-away.

What do you mean, for ceibal?

OLPC is working on 11.3.1, which is based on Sugar 0.94, but appears to be 
fairly stable. 12.x is in the works too but a bit further off. I'd have assumed 
that Plan Ceibal takes the latest OLPC release and customizes it. Is that not 
so? How does your release process work? 

 It will be best, if you could provide with any of the following options  ::
 
 a)
 squeak-vm-4.4.47 RPM for x86 AND squeak-vm-4.4.47 RPM for ARM.
 
OR
 b)
 squeak-vm-4.4.47 SRPM.

I can't provide any of that. My spare time is limited, you know ;)

(I am a freelancing developer, but my schedule is pretty full. I take on the 
occasional contract, in particular if 

 So, all we need to do is replace the old etoys.image and etoys.changes with 
 the latest etoys.image and etoys.changes, respectively?
 If yes, then we would be needing the SRPM for etoys-5.0.2406. (Or the older 
 SRPM for etoys-4.1 would do ?)

Err, not so fast. What I described is how you can develop stuff, and how you 
can test stuff that is in development.

You're welcome to submit fixes upstream. Here's a brief Etoys developer how-to:

http://etoys.squeak.org/svn/trunk/Documentation/Developer-HowTo.txt

Also, please subscribe to etoys-dev and tell us what you're doing:

http://lists.squeakland.org/mailman/listinfo/etoys-dev

- Bert -

PS: it would be nice if you could disable the HTML mails in your client. Makes 
proper quoting hard.

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

Re: [Sugar-devel] Squeak / Etoys development under Sugar (was: Object Chooser)

[Bert Freudenberg]

On 2012-06-08, at 15:20, Ajay Garg wrote:
 On Fri, Jun 8, 2012 at 5:48 PM, Bert Freudenberg b...@freudenbergs.de wrote:
 On 07.06.2012, at 21:36, Ajay Garg wrote:
 
  Well, we need the squeak-vm (with the Mpeg3Plugin.c fix) for ceibal 
  right-away.
 
 What do you mean, for ceibal?
 
 OLPC is working on 11.3.1, which is based on Sugar 0.94, but appears to be 
 fairly stable. 12.x is in the works too but a bit further off. I'd have 
 assumed that Plan Ceibal takes the latest OLPC release and customizes it. Is 
 that not so? How does your release process work?
 
 Well yes, that is exactly what Plan Ceibal does.
 We do the release work, as and when required by Ceibal.

So which version are you working on? 11.3.1 or 12.1.0? I am confused by you 
saying you need it right-away, since OLPC has not released anything yet that 
you then could customize and test.

The two Etoys regressions I'm aware of in 12.1.0 is that the camera does not 
work (because the new squeak vm has not been released nor packaged) and that 
sharing doesn't work with a jabber server (because the presence service breaks 
when using gabble). There may also still be sound playing/recording issues. 

Are you tracking this work on dev.laptop.org? Or at sugarlabs? Somewhere else? 
I'm also confused by who does what, when.

  So, all we need to do is replace the old etoys.image and etoys.changes 
  with the latest etoys.image and etoys.changes, respectively?
  If yes, then we would be needing the SRPM for etoys-5.0.2406. (Or the 
  older SRPM for etoys-4.1 would do ?)
 
 Err, not so fast. What I described is how you can develop stuff, and how you 
 can test stuff that is in development.
 
 You're welcome to submit fixes upstream. Here's a brief Etoys developer 
 how-to:
 
http://etoys.squeak.org/svn/trunk/Documentation/Developer-HowTo.txt
 
 Also, please subscribe to etoys-dev and tell us what you're doing:
 
http://lists.squeakland.org/mailman/listinfo/etoys-dev
 
 
 Bert, I am sorry, as I wasn't clear. The detailed use-case follows ::
 
 a)
 There is the branch etoys 5.0
 
 b)
 However, there are still some packages, which need updating (via update code 
 from server). Done.
 
 c)
 Now, all that is needed to be done, is to package etoys in such a way, that 
 etoys-image (when next launched), does not re-need update code from server.
 Of course, any local changes (that have been not been pushed upstream), don't 
 take effect. The important thing is that, the upstreamed changes should be 
 the latest one. No update code from server should be needed again.
 
 I was asking about this use-case. In this, would the simple replacements of 
 etoys.image, and etoys.contents work?

It might work, but I'd rather follow proper procedure. We are planning a bugfix 
release for Etoys, just like Sugar had bug fix releases for 0.96.

Also, I was under the impression that you were looking into the MP3 rewind 
problem. If you have a fix for that you should submit it upstream. Or at least 
open a ticket at

http://tracker.squeakland.org/

 PS: it would be nice if you could disable the HTML mails in your client. 
 Makes proper quoting hard.

Still HTML.

- Bert -


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

Re: [Sugar-devel] [SoaS] Etoys in RC4 SoaS-v7 does not start when jabber is connected. ( f17 release is imminent )

[Bert Freudenberg]

On 07.06.2012, at 12:54, Manuel Kaufmann wrote:

 On Wed, Jun 6, 2012 at 12:46 PM, Bert Freudenberg b...@freudenbergs.de 
 wrote:
 Both Etoys 4 and Etoys 5 work fine with the presence service in Sugar 0.94 
 (tested on XO-1.5, 11.3.1 build 885).
 
 I'm not sure to understand this comment. Are you saying that Etoys 5
 works fine but it can not be shared or works fine means that you can
 run it and play with Etoys but alone?

I'm saying that sharing works. Both in Etoys 4 and Etoys 5. But only if the 
presence service works.

If the presence service does not work, sharing does not work in Etoys.

With regard to sharing, the only difference between Etoys 4 and Etoys 5 is that 
Etoys 5 will still work if the presence service fails, whereas Etoys 4 showed 
an error on startup.

 I am re-implementing the presence service in Etoys, but this is going to 
 take a while longer. If you want sharing to work with Etoys right now, the 
 easiest would be to fix the presence service (which is a Python task, so may 
 be easier for you).
 
 Maybe I can help with this but I have no idea about presence
 service, I should study about it. Is there a ticket with this issue
 with a bit of history that I can read to catch up?

Hmm, the history goes back a couple of years. There probably is a ticket, and a 
mailing list discussion. Here is the removal feature page:

http://wiki.sugarlabs.org/go/Features/Remove_Presence_Service

This ticket describes the current problem:

http://bugs.sugarlabs.org/ticket/3498

The presence service crashes when it is trying to use gabble (that is, a jabber 
server). It appears to work fine with salut (that is, in the local network 
without a server).

- Bert -


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

[Sugar-devel] Squeak / Etoys development under Sugar (was: Object Chooser)

[Bert Freudenberg]

On 07.06.2012, at 15:57, Ajay Garg wrote:

 Hi Bert.
 
 a)
 Could you give a rough idea, as to what is the release cycle for squeak-vm?

There is no fixed release cycle, releases are done as needed and as time 
permits. Once or twice a year has been typical.

What is your time frame? If need be one could package a Squeak VM + patches.

 b)
 Also, I installed etoys-5.0.2406 rpm; and did (as told by you) update code 
 from server.
 However, upon reboot, I again have to do update code from server.

No need to reboot, quitting Etoys is enough. Any changes made are not 
permanent, to encourage free experimentation without breaking anything. 
Normally Etoys only stores projects (which can contain code), the image is 
read-only.

 So, is there a way that a final etoys image (incorporating all the latest 
 changes) can be retrieved (locally)? That is, we may do all the updating from 
 update code from server, and then transfer the final etoys.image at will?

Of course there is a way ;)

First, copy some files from /usr/share/etoys over to Etoys' 
$SUGAR_ACTIVITY_ROOT/data direcory:

[olpc@xo-a7-4a-a4 ~]$ cd .sugar/default/org.vpri.EtoysActivity/data
[olpc@xo-a7-4a-a4 data]$ cp /usr/share/etoys/etoys.{image,changes} .
[olpc@xo-a7-4a-a4 data]$ ln -s 
/usr/share/etoys/{locale,ExampleEtoys,EtoysV5.stc} .
[olpc@xo-a7-4a-a4 data]$ ll
insgesamt 17424
-rw-r--r-- 1 olpc olpc 5014  7. Jun 14:34 etoys.changes
-rw-r--r-- 1 olpc olpc 17823140  7. Jun 14:34 etoys.image
lrwxrwxrwx 1 olpc olpc   28  7. Jun 14:34 EtoysV5.stc - 
/usr/share/etoys/EtoysV5.stc
lrwxrwxrwx 1 olpc olpc   29  7. Jun 14:34 ExampleEtoys - 
/usr/share/etoys/ExampleEtoys
lrwxrwxrwx 1 olpc olpc   23  7. Jun 14:34 locale - /usr/share/etoys/locale
drwxrwxr-x 3 olpc olpc 4096  7. Jun 14:20 MyEtoys
drwxrwx--- 3 olpc olpc 4096 31. Mai 17:53 private

(you could also make the files in /usr/etoys/share writable, but copying is 
safer)
(if your XO uses Rainbow security, the Etoys $SUGAR_ACTIVITY_ROOT will be 
somewhere in the isolation directory instead)

The next time you launch Etoys, it will use this image at 
$SUGAR_ACTIVITY_ROOT/data/etoys.image instead. (Etoys also looks for a 
developer image on a USB stick, see Etoys.activity/bin/etoys-activity and use 
whatever is most convenient)

Now you are ready for serious Squeak development.

1) The secret is Alt-Shift-W. Press this to bring up the full Squeak world menu.
2) From the menu, choose previous project. This will jump to a hidden unnamed 
project. You should recolor this project to remind you this is not the default 
Etoys anymore (right-click, use the lower-right halo handle to choose a 
different background color)
3) Load updates
4) Press Alt-Shift-W again, choose save and quit. Do not use save as or 
save new version because those would create new file names.

Done. The next time you launch Etoys, you will see it using your image (because 
of the different background color). Always go back to the top-level project 
before saving. Of course, this will also retain all changes you make, windows 
you have open etc. Make yourself a nice dev environment :)

(there is an older version of these instructions, plus a nice tutorial, at 
http://wiki.laptop.org/go/Smalltalk_Development_on_XO )

- Bert -


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

Re: [Sugar-devel] Object Chooser (was Re: Etoys mp3 files)

[Bert Freudenberg]

On 06.06.2012, at 20:19, Ajay Garg ajaygargn...@gmail.com wrote:

 When a file was checked out from the datastore, an activity needs to delete 
 it when it is done. Etoys deletes the file when the file object is released 
 (using a finalizer). I guess the MPEGPlayer stores only the name, closes the 
 file, and tries to re-open it from the same name. If the original file object 
 has been garbage-collected already, the finalizer will have deleted the file. 
 Thus, trying to re-open it will fail.
 
 
 I guess this is what is happening.
 
 
 Some thoughts ::
 
 a)
 So, the reason that things work fine in the case of USB drives, is because 
 there is always a reference to the file by the OS. Thus, the file itself is 
 never deleted.

Yes.


 b)
 More importantly, WHY WOULD MPEGPLAYER NEED TO DELETE THE FILE? CAN THE FILE 
 SIMPLY NOT BE ACCESSED IN A UNIFORM MANNER FROM BOTH JOURNAL AND USB PEN 
 DRIVES?
 As part of this, I tried using the journal file simply (without making its 
 copy). So, now Rewind worked. But the next time, Rewind did not work, 
 apparently because the file was deleted.
 
 
 So,
 WHY WOULD MPEGPLAYER NEED TO DELETE THE FILE? CAN THE FILE SIMPLY NOT BE 
 ACCESSED IN A UNIFORM MANNER FROM BOTH JOURNAL AND USB PEN DRIVES, WITHOUT 
 HAVING THE NEED TO DELETE THE FILE ALTOGETHER?
 

Because that is how the Sugar datastore works:

http://wiki.sugarlabs.org/go/Development_Team/Low-level_Activity_API#Keeping_and_Resuming

When you call get_filename() on the datastore object, a copy is made by the 
datastore, which the activity needs to delete.

And it's not the MPEG player which deletes the file, but SugarLauncher.

 On an unrelated note :: Thanks a ton for the tutorials on  squeak. I could 
 finally do some live debugging :D :D
 Thanks again.
 
 Thanks and Regards,
 Ajay

Hehe. Be careful, you may like what you learn ;)

(in that case, you should maybe get someone to send you to the Smalltalks 
conference in Argentina in November)

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

Re: [Sugar-devel] Object Chooser (was Re: Etoys mp3 files)

[Bert Freudenberg]

On 06.06.2012, at 16:00, Ajay Garg wrote:

 Hi Bert.
 
 Is there a way to do a textual search for a text across the entire code?
 For example, I am trying to search for the string Rewind across the code, 
 but cannot find a single occurrence (via Ctrl-f and Ctrl-g).

Yes, ctrl-shift-E.

There is a command key list in the help menu. 

Also, there is a Squeak-beginners mailing list:

http://lists.squeak.org/mailman/listinfo/beginners

And some documentation links on the Squeak website:

http://squeak.org/Documentation/

- Bert -

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

Re: [Sugar-devel] Object Chooser (was Re: Etoys mp3 files)

[Bert Freudenberg]

On 05.06.2012, at 07:25, Ajay Garg wrote:

 
 Just wish to confirm, if the following hold true ::
 
 a)
 As mentioned in one of the earlier emails, 'get_properties' method needs to 
 succeed to open a journal/external-USB-drive object.
 So, my query is : is the end-result just opening of the file (from 
 journal/external-USB-drive), or something more too ?

The Etoys code just assumed that object_id was in fact an UID for the 
datastore. To get the file associated with a UID you need to call 
get_properties. However, what we get from the object chooser is not always a 
UID, but sometimes a full path. We must not call get_properties on that, but 
simply open it.

 b)
 If the answer to a) is just opening the file, then I presume your commit 
 fixes/enhances the case of opening the file from external-USB-drive ?

Yes, my fix to Etoys means that it can now use the object chooser to open files 
from external USB drive.

- Bert -


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

Re: [Sugar-devel] Object Chooser (was Re: Etoys mp3 files)

[Bert Freudenberg]

On 05.06.2012, at 07:31, Ajay Garg wrote:

 Also, is there a 'development-branch for etoys :-P , from where etoys binary 
 can be downloaded, and tested ?

We only build new images in the hot development phase before a new release.

In between, you can test by loading updates from inside Etoys:

* make sure you use the latest release image (Etoys 5.0.2406)
* to check version, choose help - about this system from the view source 
menu (ctrl-comma)
* to update, choose help - update code from server from the same menu, 
answer yes to load the latest packages

After updating, the system version will include a repository version and date. 
After my fix it's v1637 and 4 June 2012.

- Bert -


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

[Sugar-devel] Fwd: Scratch source code version 1.4.0.6 released

[Bert Freudenberg]

Begin forwarded message:

 From: Amos Blanton a...@scratch.mit.edu
 Subject: Scratch source code version 1.4.0.6 released
 Date: 5. Juni 2012 03:23:50 MESZ
 To: Linux Scratch li...@scratch.mit.edu, scra...@lists.launchpad.net, 
 Debian Bugs 471...@bugs.debian.org
 
 We've released an update to the GPL v2 Scratch source code ,  now available 
 here:
 
 http://download.scratch.mit.edu/scratch-1.4.0.6.src.tar.gz
 
 1.4.0.6 changes:
 * Fix for blank screen bug when image is run on current Squeak VMs (Thanks 
 to Bert Freudenberg for the fix.) 
 * Squeak source code for version of Scratch 1.4 modified for XO / Sugar
 
 Scratch On!
 Amos
 Scratch Team


This now could be used to make a GPL Scratch activity.

- Bert -


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

Re: [Sugar-devel] Object Chooser

[Bert Freudenberg]

On 05.06.2012, at 09:21, Sascha Silbe wrote:

 Bert Freudenberg b...@freudenbergs.de writes:
 
 On 04.06.2012, at 14:13, Bert Freudenberg wrote:
 
 So you're saying that in the response, the second argument would more
 properly be named object_id_or_full_path. And to distinguish the two
 cases, we have to look at its first character: if it is '/' then it's
 a path, otherwise an object id. 
 
 Yes, exactly.
 
 
 I now extended that documentation page with the object_id_or_full_path
 argument discussion.
 
 Thanks! Just one minor point (re. this is a utf8-encoded absolute path
 to a file): Unix paths are sequences of octets (binary strings), not
 character strings. In most cases the path will be the representation of
 a character string in some encoding (and Sugar only works with the UTF-8
 encoding). But it's never the other way around (the path itself getting
 UTF-8 encoded). However, you do have a point in that paths that are not
 a valid UTF-8 representation of some character string will cause the
 Object Chooser to break.

You're right. I removed the encoding part from the API doc.

 Are there any other places in the API where instead of an object id we have 
 to expect a full path instead?
 
 I would expect only the Journal D-Bus API to work this way. So
 org.laptop.Journal.ShowObject() should be the only other place where
 object_id or a full path is used (resp. supported).


Okay. I checked, ShowObject() indeed supports a full path. Which can be 
anywhere on the system, actually. Opening a file from there copies it to the 
Journal.

I will send a patch to rename object_id. That should alert future users that 
object_id might also be a path.

- Bert -


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

[Sugar-devel] [PATCH sugar] Journal: rename object_id argument to object_id_or_path

[Bert Freudenberg]

In particular, this shows up in DBus introspection. The rename should
alert API users not to expect only an object_id.

Signed-off-by: Bert Freudenberg b...@freudenbergs.de
---
 src/jarabe/journal/journalactivity.py |   24 
 1 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/src/jarabe/journal/journalactivity.py 
b/src/jarabe/journal/journalactivity.py
index bb1c7f6..bb45cf2 100644
--- a/src/jarabe/journal/journalactivity.py
+++ b/src/jarabe/journal/journalactivity.py
@@ -66,19 +66,19 @@ class JournalActivityDBusService(dbus.service.Object):
 
 @dbus.service.method(J_DBUS_INTERFACE,
 in_signature='s', out_signature='')
-def ShowObject(self, object_id):
-Pop-up journal and show object with object_id
+def ShowObject(self, object_id_or_path):
+Pop-up journal and show object_id_or_path
 
-logging.debug('Trying to show object %s', object_id)
+logging.debug('Trying to show object %s', object_id_or_path)
 
-if self._parent.show_object(object_id):
+if self._parent.show_object(object_id_or_path):
 self._parent.reveal()
 
 def _chooser_response_cb(self, chooser, response_id, chooser_id):
 logging.debug('JournalActivityDBusService._chooser_response_cb')
 if response_id == gtk.RESPONSE_ACCEPT:
-object_id = chooser.get_selected_object_id()
-self.ObjectChooserResponse(chooser_id, object_id)
+object_id_or_path = chooser.get_selected_object_id()
+self.ObjectChooserResponse(chooser_id, object_id_or_path)
 else:
 self.ObjectChooserCancelled(chooser_id)
 chooser.destroy()
@@ -99,7 +99,7 @@ class JournalActivityDBusService(dbus.service.Object):
 return chooser_id
 
 @dbus.service.signal(J_DBUS_INTERFACE, signature='ss')
-def ObjectChooserResponse(self, chooser_id, object_id):
+def ObjectChooserResponse(self, chooser_id, object_id_or_path):
 pass
 
 @dbus.service.signal(J_DBUS_INTERFACE, signature='s')
@@ -224,8 +224,8 @@ class JournalActivity(JournalWindow):
 self.set_canvas(self._main_view)
 self._main_view.show()
 
-def _show_secondary_view(self, object_id):
-metadata = model.get(object_id)
+def _show_secondary_view(self, object_id_or_path):
+metadata = model.get(object_id_or_path)
 try:
 self._detail_toolbox.entry_toolbar.set_metadata(metadata)
 except Exception:
@@ -242,12 +242,12 @@ class JournalActivity(JournalWindow):
 self.set_canvas(self._secondary_view)
 self._secondary_view.show()
 
-def show_object(self, object_id):
-metadata = model.get(object_id)
+def show_object(self, object_id_or_path):
+metadata = model.get(object_id_or_path)
 if metadata is None:
 return False
 else:
-self._show_secondary_view(object_id)
+self._show_secondary_view(object_id_or_path)
 return True
 
 def __volume_changed_cb(self, volume_toolbar, mount_point):
-- 
1.7.3.2

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

Re: [Sugar-devel] Object Chooser (was Re: Etoys mp3 files)

[Bert Freudenberg]

On 05.06.2012, at 15:33, Ajay Garg wrote:

 Bert, 
 
 A small query ::
 
 I have the version etoys4.1.
 Is the 5.0.2406 version based on a higher release version of Fedora?

Fedora is a Linux distribution. Etoys is an application. Your question makes no 
sense to me.

Or are you asking if Etoys 5 requires Fedora 17? No, it does not. Etoys is 
cross-platform and hopefully works everywhere. See

http://squeakland.org/download/

And poke around on that site to see what makes Etoys special (and not just 
weird). In particular, read the articles at

http://squeakland.org/resources/articles/

For testing purposes I build my own rpms (including etoys 5):

http://etoys.laptop.org/

Or you might install from the source tar balls at

http://download.sugarlabs.org/sources/sucrose/glucose/etoys/

[You can actually update from etoys 4.1 but that's not officially supported. It 
will take a lot longer, and you will not get the new supporting files like 
translations etc. You need to say yes when asked to advance to etoys 5, no 
when asked to load newest packages. Then update again, this time you can say 
yes to the newest packages.]

- Bert -

 Regards,
 Ajay
 
 
 On Tue, Jun 5, 2012 at 1:45 PM, Bert Freudenberg b...@freudenbergs.de wrote:
 On 05.06.2012, at 07:31, Ajay Garg wrote:
 
  Also, is there a 'development-branch for etoys :-P , from where etoys 
  binary can be downloaded, and tested ?
 
 We only build new images in the hot development phase before a new release.
 
 In between, you can test by loading updates from inside Etoys:
 
 * make sure you use the latest release image (Etoys 5.0.2406)
 * to check version, choose help - about this system from the view source 
 menu (ctrl-comma)
 * to update, choose help - update code from server from the same menu, 
 answer yes to load the latest packages
 
 After updating, the system version will include a repository version and 
 date. After my fix it's v1637 and 4 June 2012.
 
 - Bert -
 
 
 ___
 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] 0.96 Change?

[Bert Freudenberg]

On 05.06.2012, at 10:04, Sascha Silbe wrote:

 Art Hunkins abhun...@uncg.edu writes:
 
 I notice that for Sugar 0.96 it seems necessary, in copying a file from the 
 Terminal to a USB stick, to do:
  cp myfile.py /run/media/liveuser/myUSB/myfile.py (perhaps I've got 
 liveuser and myUSB reversed)
 instead of the much simpler (in 0.94 and before):
  cp myfile.py /media/myUSB/myfile.py
 (two new levels!)
 
 That's a change on the distro level (Fedora resp. systemd in this case),
 not in Sugar. When running Sugar 0.96 on most other distros (that don't
 use systemd), it will still be /media/medium name. When running Sugar
 0.94 (or really any version of Sugar) on Fedora 17, it will also be
 /run/media/user name/medium name. You can't derive the path to use
 From the Sugar version. For use in Activities, let me quote a recent
 mail of mine:
 
 They should use proper API (gio on recent distros, HAL on old OLPC OS
 builds) rather than hardcoding paths. Check out the gio VolumeMonitor
 API documentation [1] and see _find_media() [2] in Backup [3] for an
 example (including fallback to HAL).
 
 
 [1] http://developer.gnome.org/gio/stable/GVolumeMonitor.html
 [2] https://git.sugarlabs.org/backup/mainline/blobs/master/backup.py#line671
 [3] http://activities.sugarlabs.org/en-US/sugar/addon/4326

I put that info into the documentation at

http://wiki.sugarlabs.org/go/Development_Team/Low-level_Activity_API#External_Media

- Bert -


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

Re: [Sugar-devel] [SoaS] Etoys translations

[Bert Freudenberg]

On 05.06.2012, at 16:39, Simon Schampijer wrote:

 On 06/01/2012 05:24 PM, Bert Freudenberg wrote:
 On 28.05.2012, at 21:48, Bert Freudenberg wrote:
 
 On 28.05.2012, at 20:29, Peter Robinson wrote:
 
 As mentioned previously look at the other Activities, like TurtleArt,
 it works like the rest of the distro translation stuff, I'm not sure
 if there's other sugar bits that assist with that.
 
 Other activities have only a single mo file. Other activities use the 
 gettext library so they do not have to worry about where the files are.
 
 Etoys has multiple mo files. Etoys does not use gettext, so it needs to 
 know where to find the translation files.
 
 I would add that other activities only have translated LC_MESSAGES. Etoys 
 also has translated QuickGuides, see its current locale directory.
 
 It's precisely about those differences I'm asking you for clarification. 
 See my previous message.
 
 Until now, Etoys just did its own thing, and that worked fine. But there 
 must be a good reason why you want the mo files in the system default 
 directory. (What is that reason, btw?) So I'm trying to find a way to make 
 it happen. If I know what the constraints are, we surely can find a way to 
 make it fit.
 
 - Bert -
 
 
 So, what are the constraints?
 
 - Bert -
 
 Hi Bert,
 
 so looks like the main issue about translations is installing the .mo files 
 on a non standard place in a non standard way.
 
 A few questions around the topic:
 
 - can the mo files be in one file?

Due to the high number of translatable phrases, translators prefer separate PO 
files. Squeak + Etoys has more strings than the rest of Sugar combined. 

We could merge all MO files in the build process (and this would have some 
other advantages, so I like it), but it would be another specialty of Etoys 
where PO names to not match the MO.

 - if not, can they be renamed with a prefix like you suggested?

I see no technical reason why that should not work. It will require code 
changes, but they should be minor. And it will require coordination with Pootle 
- I could easily change the file names in SVN, but Pootle may get confused.

 - as far as I understood you don't use gettext, I presume that is out of 
 question, right?

Someone would need to write a Squeak VM plugin wrapping gettext. Not out of the 
question, but unlikely.

However, any of the above only concerns MO files. As I asked previously:

In addition to the gettext files, Etoys also has translated QuickGuides (and 
may later have translated example projects etc). See its current locale 
directory, e.g.

http://etoys.squeak.org/svn/trunk/Etoys/locale/de/

Since these files are quite large, it would totally make sense to e.g. include 
them in language packs. But should they be in /usr/share/locale? If not, then 
why can't the rest of the Etoys locale files stay in /usr/share/etoys/locale?

 I am sure we can sort this out in one way or another to make Peter's life 
 easier.

I certainly hope so!

 Thanks,
   Simon
 
 PS: I am sending you good energy to finally do the move handle presence 
 inside Etoys, so we can kill the PS. I know you are on your own in Etoys land 
 atm...but you are skilled :)

Oh I feel the wave of energy coming ... :)

- Bert -


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

Re: [Sugar-devel] Object Chooser (was Re: Etoys mp3 files)

[Bert Freudenberg]

On 05.06.2012, at 15:57, Bert Freudenberg wrote:

 On 05.06.2012, at 15:33, Ajay Garg wrote:
 
 Bert, 
 
 A small query ::
 
 I have the version etoys4.1.
 Is the 5.0.2406 version based on a higher release version of Fedora?
 
 Fedora is a Linux distribution. Etoys is an application. Your question makes 
 no sense to me.
 
 Or are you asking if Etoys 5 requires Fedora 17? No, it does not. Etoys is 
 cross-platform and hopefully works everywhere. See
 
   http://squeakland.org/download/
 
 And poke around on that site to see what makes Etoys special (and not just 
 weird). In particular, read the articles at
 
   http://squeakland.org/resources/articles/
 
 For testing purposes I build my own rpms (including etoys 5):
 
   http://etoys.laptop.org/
 
 Or you might install from the source tar balls at
 
   http://download.sugarlabs.org/sources/sucrose/glucose/etoys/
 
 [You can actually update from etoys 4.1 but that's not officially supported. 
 It will take a lot longer, and you will not get the new supporting files like 
 translations etc. You need to say yes when asked to advance to etoys 5, 
 no when asked to load newest packages. Then update again, this time you can 
 say yes to the newest packages.]
 
 - Bert -

Oh, and news from the dev meeting: Peter packaged Etoys 5 for Fedora. If you 
give it karma after testing, it should become an update soonish:

https://admin.fedoraproject.org/updates/etoys-5.0.2406-1.fc17

Direct RPM link:

http://kojipkgs.fedoraproject.org/packages/etoys/5.0.2406/1.fc17/noarch/etoys-5.0.2406-1.fc17.noarch.rpm


- Bert -


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

Re: [Sugar-devel] Object Chooser (was Re: Etoys mp3 files)

[Bert Freudenberg]

On 05.06.2012, at 22:53, Ajay Garg wrote:

 Hi Bert.
 
 There is good news, and (rather mild bad news).
 
 
 I updated the code from etoys4.1 to etoys5.0, as suggested by you via update 
 code from server, and the following use-cases worked perfectly as expected ::
 
 
 a)
 Open an mp3 from a USB pen-drive via journal-object-chooser.
 Click Play in MPEG player.
 The mp3 starts playing.
 Click Stop.
 Click Play.
 mp3 resumes playing.
 Click Stop.
 Click Rewind.
 Click Play.
 mp3 starts playing from the beginning.
 
 
 b)
 Open an mp3 from a USB pen-drive via journal-object-chooser.
 Click Open.
 Click Play.
 The mp3 starts playing.
 Click Stop.
 Click Play.
 mp3 resumes playing.
 Click Stop.
 Click Rewind.
 Click Play.
 mp3 starts playing from the beginning.
 
 
 c)
 Open an mp3 from the journal via journal-object-chooser.
 Click Play in MPEG player.
 The mp3 starts playing.
 Click Stop.
 Click Play.
 mp3 resumes playing.
 Click Stop.
 Click Rewind.
 Click Play.
 mp3 DOES NOT PLAY. Instead an error comes up, saying that the file-name has 
 changed.
 
 
 d)
 Open an mp3 from the journal via journal-object-chooser.
 Click Open.
 Click Play.
 The mp3 starts playing.
 Click Stop.
 Click Play.
 mp3 resumes playing.
 Click Stop.
 Click Rewind.
 Click Play.
 mp3 DOES NOT PLAY. Instead an error comes up, saying that the file-name has 
 changed.
 
 
 e)
 I tried steps a), b), c), d) with etoys4.1.
 a) and b) failed (for obvious reasons).
 c) and d) ALSO failed, with the same symptoms.

So it plays once and but not again. I have a hunch.

When a file was checked out from the datastore, an activity needs to delete it 
when it is done. Etoys deletes the file when the file object is released (using 
a finalizer). I guess the MPEGPlayer stores only the name, closes the file, and 
tries to re-open it from the same name. If the original file object has been 
garbage-collected already, the finalizer will have deleted the file. Thus, 
trying to re-open it will fail.

 f)
 I tried installing the new rolled out etoys-5.0.2406-1.fc17.noarch.rpm
 However, it needed a squeak-vm greater than 3.10.
 Now, I had uninstalled the squeak-vm, and installed it instead via source 
 (for 4.0 branch).
 So, I installed the rpm by sudo rpm -i --nodeps 
 etoys-5.0.2406-1.fc17.noarch.rpm.
 a) and b) CONTINUED TO FAIL (meaning that the change did not take effect).

It's not yet in 5.0.2406. You need to update code from server.

 So, Bert,
 
 (i)
 Could the new rpm for squeak-vm (from 4.0 branch) also be rolled out; so that 
 the mpeg-plugin change could also be tested end-to-end.

It would be a good idea to package the current 4.4.7 Squeak VM in any case. But 
it does not have my latest patches yet. I've sent the patches two weeks ago, 
but there was no new release yet.

 (ii)
 Kindly provide me a snapshot of your last commit, so that I may go through 
 the mechanics of making the change in etoys. I would then subequently like to 
 fix cases c) and d)  :-)

I'm not quite sure what you mean with snapshot of your last commit?

Fixing the c) and d) cases is not exactly a task I would give to a new Squeak 
programmer. You're welcome to surprise me, of course ;) You would have to start 
at SugarLauncher's getFile: method.

- Bert -

 
 Thanks a ton 
 
 
 Thanks and Regards,
 Ajay
 
 
 
 
 
 On Tue, Jun 5, 2012 at 10:26 PM, Bert Freudenberg b...@freudenbergs.de 
 wrote:
 
 On 05.06.2012, at 15:57, Bert Freudenberg wrote:
 
  On 05.06.2012, at 15:33, Ajay Garg wrote:
 
  Bert,
 
  A small query ::
 
  I have the version etoys4.1.
  Is the 5.0.2406 version based on a higher release version of Fedora?
 
  Fedora is a Linux distribution. Etoys is an application. Your question 
  makes no sense to me.
 
  Or are you asking if Etoys 5 requires Fedora 17? No, it does not. Etoys is 
  cross-platform and hopefully works everywhere. See
 
http://squeakland.org/download/
 
  And poke around on that site to see what makes Etoys special (and not just 
  weird). In particular, read the articles at
 
http://squeakland.org/resources/articles/
 
  For testing purposes I build my own rpms (including etoys 5):
 
http://etoys.laptop.org/
 
  Or you might install from the source tar balls at
 
http://download.sugarlabs.org/sources/sucrose/glucose/etoys/
 
  [You can actually update from etoys 4.1 but that's not officially 
  supported. It will take a lot longer, and you will not get the new 
  supporting files like translations etc. You need to say yes when asked to 
  advance to etoys 5, no when asked to load newest packages. Then update 
  again, this time you can say yes to the newest packages.]
 
  - Bert -
 
 Oh, and news from the dev meeting: Peter packaged Etoys 5 for Fedora. If you 
 give it karma after testing, it should become an update soonish:
 
 https://admin.fedoraproject.org/updates/etoys-5.0.2406-1.fc17
 
 Direct RPM link:
 
 http://kojipkgs.fedoraproject.org/packages/etoys/5.0.2406/1.fc17/noarch/etoys-5.0.2406-1.fc17

Re: [Sugar-devel] Etoys mp3 files

[Bert Freudenberg]

Just replying to tie up one loose end here ...

On 01.06.2012, at 07:53, Ajay Garg wrote:

 Thanks Bert.
 
 1)
 Bert, I re-compiled after installing all the header- and devel- packages as 
 told by you (after incorporating a blocker-fix as per 
 http://comments.gmane.org/gmane.comp.lang.smalltalk.squeak.general/146266).

Ah, the UUID thing. Rats. I brought it up on the upstream dev list again.

I gave you a slightly wrong build requirements list. Instead of uuid-devel you 
need libuuid-devel. And you must uninstall uuid-devel because the build gets 
confused if you have two uuid.h files installed, it chooses the wrong one.

We'll hopefully fix the uuid.h detection properly now ...

- Bert -


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

[Sugar-devel] Object Chooser (was Re: Etoys mp3 files)

[Bert Freudenberg]

On 04.06.2012, at 13:43, Sascha Silbe wrote:

 It's quite likely that Etoys doesn't implement its side of the
 essentially undocumented Object Chooser API of Sugar 0.84+ correctly. In
 particular, the object_id parameter of the ObjectChooserResponse signal
 will contain a) the data store object id (currently stored as property
 'uid') for Journal objects or b) the full path to the file for entries
 stored on external storage media.

That is indeed the first time I hear of that. Yes, Etoys expects the chooser's 
response to be an object_id as per documentation at


http://wiki.sugarlabs.org/go/Development_Team/Low-level_Activity_API#Choosing_Objects

So you're saying that in the response, the second argument would more properly 
be named object_id_or_full_path. And to distinguish the two cases, we have to 
look at its first character: if it is '/' then it's a path, otherwise an object 
id. 

Are there any other places in the API where instead of an object id we have to 
expect a full path instead?

- Bert -


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

[Sugar-devel] SUGAR_LANGPACKDIR

[Bert Freudenberg]

On 04.06.2012, at 18:51, Simon Schampijer wrote:

 +langpackdir = client.get_string('/desktop/sugar/i18n/langpackdir')
 +if langpackdir is not None and langpackdir:
 +os.environ['SUGAR_LANGPACKDIR'] = langpackdir

How should activities use SUGAR_LANGPACKDIR? Google comes up empty.

- Bert -

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

Re: [Sugar-devel] SUGAR_LANGPACKDIR

[Bert Freudenberg]

On 04.06.2012, at 19:15, Simon Schampijer wrote:

 On 06/04/2012 07:04 PM, Bert Freudenberg wrote:
 On 04.06.2012, at 18:51, Simon Schampijer wrote:
 
 +langpackdir = client.get_string('/desktop/sugar/i18n/langpackdir')
 +if langpackdir is not None and langpackdir:
 +os.environ['SUGAR_LANGPACKDIR'] = langpackdir
 
 How should activities use SUGAR_LANGPACKDIR? Google comes up empty.
 
 - Bert -
 
 This is only a workaround for a bug:
 
 http://bugs.sugarlabs.org/ticket/3654
 
 http://lists.sugarlabs.org/archive/sugar-devel/2012-May/037678.html
 
 The initial idea is described at, it is a gconf variable:
 http://wiki.sugarlabs.org/go/Features/Enhanced_Gettext
 
 Regards,
   Simon

Well, env vars are much easier to deal with than gconf. Is this something an 
activity can rely on now?

How about SUGAR_LOCALEDIR? Is that always ${SUGAR_BUNDLE_PATH}/locale ?

Reading the code, the procedure seems to be to pick the latest MO file found in 
any of these directories

${SUGAR_LOCALEDIR}  (from ${SUGAR_BUNDLE_PATH}/locale )
${SUGAR_LANGPACKDIR}(from gconf 
/desktop/sugar/i18n/langpackdir )
${prefix}/share/locale  (where prefix is compiled into the 
bundle, typically /usr or /usr/local)

and where latest MO means opening all MO files and comparing their 
‘PO-Revision-Date:’ header.

Is that interpretation correct? And complete?

- Bert -


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

Re: [Sugar-devel] Object Chooser (was Re: Etoys mp3 files)

[Bert Freudenberg]

On 04.06.2012, at 14:13, Bert Freudenberg wrote:

 On 04.06.2012, at 13:43, Sascha Silbe wrote:
 
 It's quite likely that Etoys doesn't implement its side of the
 essentially undocumented Object Chooser API of Sugar 0.84+ correctly. In
 particular, the object_id parameter of the ObjectChooserResponse signal
 will contain a) the data store object id (currently stored as property
 'uid') for Journal objects or b) the full path to the file for entries
 stored on external storage media.
 
 That is indeed the first time I hear of that. Yes, Etoys expects the 
 chooser's response to be an object_id as per documentation at
 
   
 http://wiki.sugarlabs.org/go/Development_Team/Low-level_Activity_API#Choosing_Objects
 
 So you're saying that in the response, the second argument would more 
 properly be named object_id_or_full_path. And to distinguish the two cases, 
 we have to look at its first character: if it is '/' then it's a path, 
 otherwise an object id. 

I now extended that documentation page with the object_id_or_full_path argument 
discussion.

Also, I committed a fix for Etoys, will be in the next release.

This question remains:

 Are there any other places in the API where instead of an object id we have 
 to expect a full path instead?

- Bert -


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

Re: [Sugar-devel] Etoys mp3 files

[Bert Freudenberg]

Hi Ajay,

the entire source code is accessible from Etoys, by pressing the view-source 
key (or ctrl-comma), as I mentioned earlier. Open a System Browser to see the 
entire tree. This is not just a viewer, but you can modify the live system.

Smalltalk (of which Squeak is a dialect) does not use 
source-code-in-text-files. That idea was abandoned back in the early 70ies. 
Instead, we modify objects directly in memory. E.g., adding a method means 
adding a CompiledMethod object to the class object's method dictionary. For 
safety we also log source code changes to a database, but that's only secondary.

The primary means of saving is dumping the whole object memory to disc (that's 
the etoys.image file). When loading it back into memory, execution resumes 
exactly where it left off. There is no main function, although you register 
certain objects to be notified on resume. That way, the system has been running 
forever. There are objects in it that were created 30 years ago. Which is 
pretty cool, in my opinion, but quite a bit different from most other 
programming systems today.

In any case, Etoys comes with all the Squeak tools to inspect and modify 
itself. The central class managing Sugar integration is called SugarLauncher. 
The entry point is its startUp method.

- Bert -

On 02.06.2012, at 07:18, Ajay Garg a...@activitycentral.com wrote:

 Hi Bert.
 
 
 
 Would it be possible for you to provide with the following ::
 
 a)
 Core etoys-code (the complete source tree is highly desirable :-)  ).
 
 b)
 Sugar glue-code.
 
 
 Thanks and Regards,
 Ajay
 
 On Fri, Jun 1, 2012 at 11:23 AM, Ajay Garg a...@activitycentral.com wrote:
 Thanks Bert.
 
 1)
 Bert, I re-compiled after installing all the header- and devel- packages as 
 told by you (after incorporating a blocker-fix as per 
 http://comments.gmane.org/gmane.comp.lang.smalltalk.squeak.general/146266).
 
 However, I still am not able to hear any sound.
 
 
 2)
 I also tried copying all the so.* files from my Dell laptop (where the sound 
 was being heard) to the XO-1 (where sound is not being heard).
 However, still no sound is heard.
 
 
 So, I guess that now, there is some etoys software-hardware 
 intervention-issue that might be blocking the final destination (it must be 
 noted that sound is heard fine, outside the context of etoys).
 
 
 Any ideas will be gratefully appreciated; me too is looking into this.
 
 
 Thanks and Regards,
 Ajay
 
 
 
 
 On Fri, Jun 1, 2012 at 2:23 AM, Bert Freudenberg b...@freudenbergs.de wrote:
 I sent my patch to the upstream maintainer (Ian Piumarta). I'm hopeful there 
 will be a new 4.x VM release very soon.
 
 That new release will also help with Scratch because it will have the Scratch 
 plugins (so the Scratch XO bundle do not need any binaries inside anymore), 
 and with Etoys 5 (which needs a new Camera plugin). 4.4.7 already helps DrGeo 
 (which uses a newer Squeak format), and on 64 bit hosts (because many of the 
 32/64 bit problems have been worked out), and has numerous other improvements.
 
 Similarly, the dprintf bug you see has been fixed in 2009 according to the 
 change log. It really makes not much sense trying to fix that old codebase. 
 Rather package the new 4.x VM.
 
 Btw, here is a list of build requirements for squeak-vm (you need to watch 
 the install log to make sure that plugins and features are not disabled 
 because of missing dev headers):
 
 gcc make cmake pulseaudio-libs-devel alsa-lib-devel nas-devel libogg-devel 
 libvorbis-devel speex-devel uuid-devel dbus-devel pango-devel gstreamer-devel 
 mesa-libGL-devel libX11-devel libXext-devel libXrender-devel freetype-devel
 
 - Bert -
 
 PS: I found an MPEG movie that works 
 http://esug.org/data/HistoricalDocuments/Smalltalk80/st80-low.mpg
 
 On 30.05.2012, at 19:42, Ajay Garg wrote:
 
  Thanks Bert.
  It worked at my side too 
 
  The mp3 played fine at my end though :| :)
 
  However, I now face the ubiquitous packaging issue. As it stands out, the 
  src-rpm available is squeak-vm-3.10.5-5.fc14.src.rpm, which has some very 
  different installation schemes as compared to the 
  http://www.squeakvm.org/unix/release/Squeak-4.4.7.2357-src.tar.gz; scheme.
 
  Worse, the make for 3.10.5-5 variant fails with the error ::
 
  
  In file included from 
  /home/ajay/rpmbuild/SOURCES/Squeak-3.10-5/platforms/unix/vm/debug.c:3:0:
  /usr/include/stdio.h:419:66: error: macro dprintf passed 3 arguments, but 
  takes just 1
  /home/ajay/rpmbuild/SOURCES/Squeak-3.10-5/platforms/unix/vm/debug.c: In 
  function ‘__sq_assert’:
  /home/ajay/rpmbuild/SOURCES/Squeak-3.10-5/platforms/unix/vm/debug.c:21:3: 
  warning: incompatible implicit declaration of built-in function ‘abort’
  make[1]: *** [debug.o] Error 1
  make: *** [vm/vm.a] Error 2
  
 
 
 
  So, does there exist a way to make a rpm out

Re: [Sugar-devel] [SoaS] Etoys translations

[Bert Freudenberg]

On 28.05.2012, at 21:48, Bert Freudenberg wrote:

 On 28.05.2012, at 20:29, Peter Robinson wrote:
 
 As mentioned previously look at the other Activities, like TurtleArt,
 it works like the rest of the distro translation stuff, I'm not sure
 if there's other sugar bits that assist with that.
 
 Other activities have only a single mo file. Other activities use the gettext 
 library so they do not have to worry about where the files are.
 
 Etoys has multiple mo files. Etoys does not use gettext, so it needs to know 
 where to find the translation files.

I would add that other activities only have translated LC_MESSAGES. Etoys also 
has translated QuickGuides, see its current locale directory.

 It's precisely about those differences I'm asking you for clarification. See 
 my previous message.
 
 Until now, Etoys just did its own thing, and that worked fine. But there must 
 be a good reason why you want the mo files in the system default directory. 
 (What is that reason, btw?) So I'm trying to find a way to make it happen. If 
 I know what the constraints are, we surely can find a way to make it fit.
 
 - Bert -


So, what are the constraints?

- Bert -


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

Re: [Sugar-devel] Etoys mp3 files

[Bert Freudenberg]

On 31.05.2012, at 19:33, Ajay Garg wrote:

 Ok,
 
 After much of head-banging, I finally compared the strace dumps from my Dell 
 laptop, and my XO-1.
 I noted that, that on Dell, squeakvm was being launched from 
 /usr/local/lib, while on XO-1, from /usr/bin.
 
 I made the required changes, and surprisingly, everything fell in place.
 
 Well.. only to the point of starting the etoys :\
 
 
 Now, upon launching the sugar-etoys, and navigating to Supplies - Object 
 Catalog - Multimedia - MPEGPlayer - Open - Choosing a file - 
 Clicking OK, thankfully, the abandon error is no more seen :) :) :)
 
 However, when I press Play, NOTHING happens. I don't hear any sound, nor do 
 I see any error (The mp3 is fine otherwise, it playes well via gst-launch).

Well, does sound work in Etoys otherwise? Like, in the car's viewer, if you 
click the yellow exclamation mark button next to car make sound, do you hear 
anything?

Also, the position slider should start moving.

 Bert, is there a mechanism wherein I can see SOMEthing, which may give a clue 
 as to why no sound can be heard (even an error somewhere here and there might 
 be useful, but it needs to be seen first :D )

Well, you have the full Squeak development environment at your disposal, if you 
care to learn how to use it ;)

You can press the view-source key on the XO, or Control-Comma. That gives you 
access to the dev tools. Execute any code you see or type anywhere by pressing 
Control-D (or Control-P or Control-I, just try the difference on 3+4, for 
example).

Also, you should enable the debugHaloHandle preference. Then right-clicking 
will give you a wrench icon in the halo, that lets you explore the object on 
screen. (I usually keep this enabled using the set automatically on 
startup... preference menu item)

If you have an object selected in the object explorer, press ctrl-b to open a 
source code browser. Or click the middle mouse button to bring up a menu 
(control-click works if you only have two buttons).

That's pretty much all you need to figure out what's going on :)

- Bert -


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

Re: [Sugar-devel] Etoys mp3 files

[Bert Freudenberg]

On 31.05.2012, at 20:02, Ajay Garg wrote:

 On Thu, May 31, 2012 at 11:24 PM, Bert Freudenberg b...@freudenbergs.de 
 wrote:
 On 31.05.2012, at 19:33, Ajay Garg wrote:
 
 However, when I press Play, NOTHING happens. I don't hear any sound, nor 
 do I see any error (The mp3 is fine otherwise, it playes well via 
 gst-launch).
 
 Well, does sound work in Etoys otherwise? Like, in the car's viewer, if you 
 click the yellow exclamation mark button next to car make sound, do you 
 hear anything?
 
 Also, when I press the exclamation mark - set in between Car script1 and 
 ticking - I hear no sound.

Okay, so sound output is broken.

 Any quick idea ?
 Otherwise I am going into the depths pointed by you :D

The Squeak tools are unlikely to help in this case. Sounds more like a VM 
problem - make sure the right sound module is selected (ALSA or OSS or Pulse). 
See the /usr/bin/etoys script and squeak -help. The VM is just a C program 
that you debug pretty much like any other C program (even though parts of it 
are generated from Squeak code).

Also, if you compiled the VM yourself, pay attention to the configure output. 
If you do not have the right dev packages installed, some modules will be 
disabled and do not get built.

Also note there are various tickets regarding sound on d.l.o.

- Bert -

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

Re: [Sugar-devel] Etoys mp3 files

[Bert Freudenberg]

I sent my patch to the upstream maintainer (Ian Piumarta). I'm hopeful there 
will be a new 4.x VM release very soon.

That new release will also help with Scratch because it will have the Scratch 
plugins (so the Scratch XO bundle do not need any binaries inside anymore), and 
with Etoys 5 (which needs a new Camera plugin). 4.4.7 already helps DrGeo 
(which uses a newer Squeak format), and on 64 bit hosts (because many of the 
32/64 bit problems have been worked out), and has numerous other improvements.

Similarly, the dprintf bug you see has been fixed in 2009 according to the 
change log. It really makes not much sense trying to fix that old codebase. 
Rather package the new 4.x VM.

Btw, here is a list of build requirements for squeak-vm (you need to watch the 
install log to make sure that plugins and features are not disabled because of 
missing dev headers):

gcc make cmake pulseaudio-libs-devel alsa-lib-devel nas-devel libogg-devel 
libvorbis-devel speex-devel uuid-devel dbus-devel pango-devel gstreamer-devel 
mesa-libGL-devel libX11-devel libXext-devel libXrender-devel freetype-devel

- Bert -

PS: I found an MPEG movie that works 
http://esug.org/data/HistoricalDocuments/Smalltalk80/st80-low.mpg

On 30.05.2012, at 19:42, Ajay Garg wrote:

 Thanks Bert.
 It worked at my side too 
 
 The mp3 played fine at my end though :| :)
 
 However, I now face the ubiquitous packaging issue. As it stands out, the 
 src-rpm available is squeak-vm-3.10.5-5.fc14.src.rpm, which has some very 
 different installation schemes as compared to the 
 http://www.squeakvm.org/unix/release/Squeak-4.4.7.2357-src.tar.gz; scheme. 
 
 Worse, the make for 3.10.5-5 variant fails with the error ::
 
 
 In file included from 
 /home/ajay/rpmbuild/SOURCES/Squeak-3.10-5/platforms/unix/vm/debug.c:3:0:
 /usr/include/stdio.h:419:66: error: macro dprintf passed 3 arguments, but 
 takes just 1
 /home/ajay/rpmbuild/SOURCES/Squeak-3.10-5/platforms/unix/vm/debug.c: In 
 function ‘__sq_assert’:
 /home/ajay/rpmbuild/SOURCES/Squeak-3.10-5/platforms/unix/vm/debug.c:21:3: 
 warning: incompatible implicit declaration of built-in function ‘abort’
 make[1]: *** [debug.o] Error 1
 make: *** [vm/vm.a] Error 2
 
 
 
 
 So, does there exist a way to make a rpm out of 4.4.7.2357 variant, with 
 the Mpeg3Plugin/config.cmake patch applied?
 
 
 Thanks a ton for your time.
 
 
 Thanks and Regards,
 Ajay

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

Re: [Sugar-devel] Etoys mp3 files

[Bert Freudenberg]

.  
 false] whileFalse.  nil]}
 [] in BlockContextnewProcess {[self value.  Processor terminateActive]}
 ##
 
 On Wed, May 30, 2012 at 10:59 AM, Ajay Garg a...@activitycentral.com wrote:
 Thanks Bert for the reply.
 
 I downloaded the source from 
 http://www.squeakvm.org/unix/release/Squeak-4.4.7.2357-src.tar.gz, did make 
 and sudo make install.
 
 It seemed to work, but there was no improvement while playing Supplies - 
 Object Catalogue - Multimedia - MPEGPlayer -''DELTA.MPG.
 
 One thing I noted that all plugins file are of form so.*, whereas I believe 
 that in unix they should be of the form *.so. For example, the generated 
 Mpeg3Plugin file is so.Mpeg3Plugin, and not Mpeg3Plugin.so - something 
 which is expected for shared-object files in the unix world.
 
 Am I missing something?
 
 
 Thanks and Regards,
 Ajay
 
 
 On Wed, May 30, 2012 at 2:25 AM, Bert Freudenberg b...@freudenbergs.de 
 wrote:
 So problem a) is Sugar, problem b) squeak. I'll ignore a). For b):
 
 You do not need gstreamer, but rather Squeak's Mpeg3Plugin which has its own 
 decoder. This is not shipped in Fedora due to mp3 licensing concerns. You 
 need to copy it from an old UY bundle (there might be a x86 copy in some 
 tracker ticket on d.l.o). If need be you can also compile it from a Squeak VM 
 source tar ball (likely needed for ARM).
 
 - Bert -
 
 On 29.05.2012, at 22:26, Ajay Garg a...@activitycentral.com wrote:
 
 Well, there are two different issues ::
 
 a)
 First is the data-store issue.
 
 As seen from the logs, the (mp3) file that was opened, was present in a USB 
 pen drive.
 ANY ENTRY, when accessed via USB-pen-drive, will give this error (i.e. mp3, 
 jpeg, png - any file).
 
 CAUSE ::
 ===
 
 The code in carquinol package, presumes the data-to-be-accessed coming 
 from the journal.
 
 
 
 SOLUTION ::
 ==
 
 As happens with all entries that are accessed from USB pen-drives, these 
 entries too need to be copied first to the journal, to maintain 
 compatability.
 
 
 
 SOLUTION-IMPLEMENTATION-REQUIREMENT ::
 =
 
 The etoys-sugar-code is needed, wherein a flag may be passed to 
 objectchooser, to copy the file to the journal if invoked from etoys; and 
 subsequently access the journal-entry thereafter.
 
 Bert, we will be grateful if you could provide the code-location for this.
 
 
 
 
 
 b)
 The second issue is the sound not playing.
 
 I ensured that the following packages were installed on my non-XO laptop 
 (Dell-F14-laptop) ::
 
 * gstreamer-plugins-bad
 * gstreamer-plugins-ugly
 * gstreamer-ffmpeg
 * etoys
 * squeak-vm
 * squeak-vm-nonXOplugins
 
 Thereafter, I downloaded the following MPEG file ::
 http://samples.fileformat.info/format/mpeg/sample/567fd6a0e0da4a8e81bdeb870de3b19c/DELTA.MPG?AWSAccessKeyId=0V91BEFA7GM093MEVMG2Signature=zvF6p5NE3Jz3oSKtyw2obyPosDQ%3DExpires=133835
 
 
 and tried playing via Supplies - Object Catalogue - Multimedia - 
 MPEGPlayer. However, I got the same abandon error, with the second-last, 
 and third-last stack-point error as follows ::
 
 #
 primitiveFailed
 Announce that a primitive has failed and there is no appropriate 
 Smalltalk code to run.
 
 self error: 'a primitive has failed'
 
 
 primFileValidMPEG: aPath
 Check to see if the file is valid
 primitive: 'primitiveMPEG3CheckSig' module: 'Mpeg3Plugin'
 self primitiveFailed
 #
 
 
 
 SOLUTION ::
 =
 
 I guess there is still some plugin missing on my Dell laptop.
 But I have gone out of ideas to try.
 
 Bert, we will again be grateful :)
 
 
 
 
 Thanks and Regards,
 Ajay
 
 
 On Sun, May 27, 2012 at 2:10 AM, Rafael Ortiz raf...@activitycentral.com 
 wrote:
 
 
 On Sat, May 26, 2012 at 12:13 PM, Rafael Ortiz raf...@activitycentral.com 
 wrote:
 
 
 On Sat, May 26, 2012 at 7:47 AM, Peter Robinson pbrobin...@gmail.com wrote:
 On Sat, May 26, 2012 at 12:54 PM, Bert Freudenberg b...@freudenbergs.de 
 wrote:
 
  On 25.05.2012, at 22:21, Rafael Ortiz wrote:
 
 
 
  On Thu, May 24, 2012 at 11:34 AM, Rafael Ortiz raf...@activitycentral.com
  wrote:
 
  Hi
 
  While trying to add a journal entry (mp3 file) from etoys-113, i'm getting
  .An error has occurred; you should probably just hit abandon. Sorry
 
  Is this known?
 
  Log attached
 
 
  A clue on what this might be happening and how to solve it, appreciated.
 
  Thanks :)
 
 
  Well, the relevant lines in the error log seem to be these:
 
  DBusError: Traceback (most recent call last):
File /usr/lib/python2.7/site-packages/dbus/service.py, line 702, in
  _message_cb
  retval = candidate_method(self, *args, **keywords)
File /usr/lib/python2.7/site-packages/carquinyol/datastore.py, line 
  355,
  in get_properties
  metadata = self

Re: [Sugar-devel] Etoys mp3 files

[Bert Freudenberg]

On 30.05.2012, at 12:49, Ajay Garg wrote:

 
 
 On Wed, May 30, 2012 at 4:09 PM, Bert Freudenberg b...@freudenbergs.de 
 wrote:
 Did you move the plugin to where the other plugins are, and possibly renamed 
 it to match the other plugins name scheme?
 
 Yes, tried the following variants ::
 
 * /usr/local/lib/libMpeg3Plugin.so
 * /usr/local/lib/Mpeg3Plugin.so
 * /usr/lib/libMpeg3Plugin.so
 * /usr/lib/Mpeg3Plugin.so

Put it in the squeak plugins folder /usr/lib/squeak/...

- Bert -

  
 
 Also, are you sure that DELTA.MPG actually is an mp3 file?
 
 No, this is a MPEG file.
 The same happens with a true mp3 file as well.
 
 
 Regards,
 Ajay 
 
 - Bert -
 
 On 30.05.2012, at 10:53, Ajay Garg wrote:
 
 For brevity, here is the complete stacktrace (picked from shell command 
 line) ::
 
 
 ##
 === SqueakDebug.log START ==
 Error: a primitive has failed
 30 May 2012 2:21 pm
 
 VM: unix - a SmalltalkImage
 Image: etoys4.1 [latest update: #2390]
 
 SecurityManager state:
 Restricted: false
 FileAccess: true
 SocketAccess: true
 Working Dir /home/ajay/Etoys
 Trusted Dir /home/ajay/.etoys/private
 Untrusted Dir /home/ajay/Etoys
 
 MPEGFile class(Object)error:
 Receiver: MPEGFile
 Arguments and temporary variables: 
 aString: 'a primitive has failed'
 Receiver's instance variables: 
 superclass: Object
 methodDict: a MethodDictionary(#audioChannels:-a CompiledMethod 
 (1113) #audioG...etc...
 format: 138
 instanceVariables: #('pathToFile' 'fileBits' 'fileIndex' 
 'endianness')
 organization: ('access' endianness fileHandle fileName 
 getPercentage getTOC:doS...etc...
 subclasses: nil
 name: #MPEGFile
 classPool: a Dictionary(#Registry-nil )
 sharedPools: nil
 environment: a SystemDictionary(lots of globals)
 category: nil
 
 MPEGFile class(Object)primitiveFailed
 Receiver: MPEGFile
 Arguments and temporary variables: 
 
 Receiver's instance variables: 
 superclass: Object
 methodDict: a MethodDictionary(#audioChannels:-a CompiledMethod 
 (1113) #audioG...etc...
 format: 138
 instanceVariables: #('pathToFile' 'fileBits' 'fileIndex' 
 'endianness')
 organization: ('access' endianness fileHandle fileName 
 getPercentage getTOC:doS...etc...
 subclasses: nil
 name: #MPEGFile
 classPool: a Dictionary(#Registry-nil )
 sharedPools: nil
 environment: a SystemDictionary(lots of globals)
 category: nil
 
 MPEGFile classprimFileValidMPEG:
 Receiver: MPEGFile
 Arguments and temporary variables: 
 aPath: '/home/ajay/Desktop/DELTA.MPG'
 Receiver's instance variables: 
 superclass: Object
 methodDict: a MethodDictionary(#audioChannels:-a CompiledMethod 
 (1113) #audioG...etc...
 format: 138
 instanceVariables: #('pathToFile' 'fileBits' 'fileIndex' 
 'endianness')
 organization: ('access' endianness fileHandle fileName 
 getPercentage getTOC:doS...etc...
 subclasses: nil
 name: #MPEGFile
 classPool: a Dictionary(#Registry-nil )
 sharedPools: nil
 environment: a SystemDictionary(lots of globals)
 category: nil
 
 MPEGFile classisFileValidMPEG:
 Receiver: MPEGFile
 Arguments and temporary variables: 
 path: '/home/ajay/Desktop/DELTA.MPG'
 Receiver's instance variables: 
 superclass: Object
 methodDict: a MethodDictionary(#audioChannels:-a CompiledMethod 
 (1113) #audioG...etc...
 format: 138
 instanceVariables: #('pathToFile' 'fileBits' 'fileIndex' 
 'endianness')
 organization: ('access' endianness fileHandle fileName 
 getPercentage getTOC:doS...etc...
 subclasses: nil
 name: #MPEGFile
 classPool: a Dictionary(#Registry-nil )
 sharedPools: nil
 environment: a SystemDictionary(lots of globals)
 category: nil
 
 
 --- The full stack ---
 MPEGFile class(Object)error:
 MPEGFile class(Object)primitiveFailed
 MPEGFile classprimFileValidMPEG:
 MPEGFile classisFileValidMPEG:
  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 MPEGDisplayMorphopenFileNamed:
 MPEGDisplayMorphopenMPEGFile
 SimpleButtonMorphdoButtonAction
 SimpleButtonMorphmouseUp:
 SimpleButtonMorph(Morph)handleMouseUp:
 MouseButtonEventsentTo:
 SimpleButtonMorph(Morph)handleEvent:
 SimpleButtonMorph(Morph)handleFocusEvent:
 [] in HandMorphsendFocusEvent:to:clear: {[ActiveHand := self.  ActiveEvent 
 := anEvent.  result := focusHolder han...]}
 [] in PasteUpMorphbecomeActiveDuring: {[aBlock value]}
 BlockContexton:do

Re: [Sugar-devel] Etoys mp3 files

[Bert Freudenberg]

On 30.05.2012, at 13:55, Ajay Garg wrote:

 Same result.
 
 Following are the locations of candidate files :::
 
 
 [ajay@localhost ~]$ ls -l /usr/lib/squeak/3.10-5/
 -rwxr-xr-x. 1 root root 674862 May 30 17:24 Mpeg3Plugin
 
 

This one should have been sufficient. You're right, it does not work. There is 
a genuine problem.

So I checked. I recompiled the VM after setting DEBUG to 1 in 
unix/vm/sqUnixExternalPrims.c which shows what's happening when Squeak tries to 
load the plugin.

The plugin is missing a few functions, which makes it fail to load. I found one 
C file that is not included when building the plugin.

This likely happened in 2009 when we switched to CMake. Which shows that nobody 
else except kids in UY are using the Mpeg3Plugin ;)

It would be much better if you included a real mp3 player in your OS, and not 
rely on the Squeak one ...

I'm not quite sure what the right fix is, but a workaround is to add 
${src}/plugins/Mpeg3Plugin/Mpeg3Plugin.c to the ${plugin}_sources LIST in 
unix/plugins/Mpeg3Plugin/config.cmake

After adding that line and rebuilding, the plugin works fine in the 4.4.7 VM. I 
did not try in the 3.10 VM but it should work too. 

The MP3 I tried played too fast. Not quite sure why that is, but that's enough 
investigating for me for now ...

(And don't bother with MPEG videos. There are only very few that play in this 
plugin. It's not a general-purpose MPEG video player)

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

Re: [Sugar-devel] [SoaS] Etoys translations

[Bert Freudenberg]

On 29.05.2012, at 17:10, Gonzalo Odiard wrote:

 Until now, Etoys just did its own thing, and that worked fine. But there 
 must be a good reason why you want the mo files in the system default 
 directory. (What is that reason, btw?) So I'm trying to find a way to make 
 it happen. If I know what the constraints are, we surely can find a way to 
 make it fit.
 
 While you are looking at this, check if you can rename the file Sugar.po, 
 because will conflict with the file used by the sugar module.
 
 Gonzalo 

That's why I was suggesting to prefix the mo file names:

 Currently Etoys uses mo files named e.g. Collections.mo, Compression.mo, 
 Connectors.mo, etc. [...] I would propose to rename them to 
 Etoys-Collections.mo, Etoys-Compression.mo, Etoys-Connectors.mo, etc. 


Do you think the po file names need to be prefixed, too? I though I could add 
the prefix when generating the mo files from the source po files.

- Bert -

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

Re: [Sugar-devel] [SoaS] Etoys translations

[Bert Freudenberg]

On 29.05.2012, at 17:10, Gonzalo Odiard wrote:

 Until now, Etoys just did its own thing, and that worked fine. But there 
 must be a good reason why you want the mo files in the system default 
 directory. (What is that reason, btw?) So I'm trying to find a way to make 
 it happen. If I know what the constraints are, we surely can find a way to 
 make it fit.
 
 While you are looking at this, check if you can rename the file Sugar.po, 
 because will conflict with the file used by the sugar module.
 
 Gonzalo 

That's why I was suggesting to prefix the mo file names:

 Currently Etoys uses mo files named e.g. Collections.mo, Compression.mo, 
 Connectors.mo, etc. [...] I would propose to rename them to 
 Etoys-Collections.mo, Etoys-Compression.mo, Etoys-Connectors.mo, etc. 


Do you think the po file names need to be prefixed, too? I though I could add 
the prefix when generating the mo files from the source po files.

- Bert -

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

Re: [Sugar-devel] [SoaS] Etoys translations

[Bert Freudenberg]

On 29.05.2012, at 17:10, Gonzalo Odiard wrote:

 Until now, Etoys just did its own thing, and that worked fine. But there 
 must be a good reason why you want the mo files in the system default 
 directory. (What is that reason, btw?) So I'm trying to find a way to make 
 it happen. If I know what the constraints are, we surely can find a way to 
 make it fit.
 
 While you are looking at this, check if you can rename the file Sugar.po, 
 because will conflict with the file used by the sugar module.
 
 Gonzalo 

That's why I was suggesting to prefix the mo file names:

 Currently Etoys uses mo files named e.g. Collections.mo, Compression.mo, 
 Connectors.mo, etc. [...] I would propose to rename them to 
 Etoys-Collections.mo, Etoys-Compression.mo, Etoys-Connectors.mo, etc. 


Do you think the po file names need to be prefixed, too? I though I could add 
the prefix when generating the mo files from the source po files.

- Bert -

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

Re: [Sugar-devel] Etoys mp3 files

[Bert Freudenberg]

So problem a) is Sugar, problem b) squeak. I'll ignore a). For b):

You do not need gstreamer, but rather Squeak's Mpeg3Plugin which has its own 
decoder. This is not shipped in Fedora due to mp3 licensing concerns. You need 
to copy it from an old UY bundle (there might be a x86 copy in some tracker 
ticket on d.l.o). If need be you can also compile it from a Squeak VM source 
tar ball (likely needed for ARM).

- Bert -

On 29.05.2012, at 22:26, Ajay Garg a...@activitycentral.com wrote:

 Well, there are two different issues ::
 
 a)
 First is the data-store issue.
 
 As seen from the logs, the (mp3) file that was opened, was present in a USB 
 pen drive.
 ANY ENTRY, when accessed via USB-pen-drive, will give this error (i.e. mp3, 
 jpeg, png - any file).
 
 CAUSE ::
 ===
 
 The code in carquinol package, presumes the data-to-be-accessed coming from 
 the journal.
 
 
 
 SOLUTION ::
 ==
 
 As happens with all entries that are accessed from USB pen-drives, these 
 entries too need to be copied first to the journal, to maintain compatability.
 
 
 
 SOLUTION-IMPLEMENTATION-REQUIREMENT ::
 =
 
 The etoys-sugar-code is needed, wherein a flag may be passed to 
 objectchooser, to copy the file to the journal if invoked from etoys; and 
 subsequently access the journal-entry thereafter.
 
 Bert, we will be grateful if you could provide the code-location for this.
 
 
 
 
 
 b)
 The second issue is the sound not playing.
 
 I ensured that the following packages were installed on my non-XO laptop 
 (Dell-F14-laptop) ::
 
 * gstreamer-plugins-bad
 * gstreamer-plugins-ugly
 * gstreamer-ffmpeg
 * etoys
 * squeak-vm
 * squeak-vm-nonXOplugins
 
 Thereafter, I downloaded the following MPEG file ::
 http://samples.fileformat.info/format/mpeg/sample/567fd6a0e0da4a8e81bdeb870de3b19c/DELTA.MPG?AWSAccessKeyId=0V91BEFA7GM093MEVMG2Signature=zvF6p5NE3Jz3oSKtyw2obyPosDQ%3DExpires=133835
 
 
 and tried playing via Supplies - Object Catalogue - Multimedia - 
 MPEGPlayer. However, I got the same abandon error, with the second-last, 
 and third-last stack-point error as follows ::
 
 #
 primitiveFailed
 Announce that a primitive has failed and there is no appropriate 
 Smalltalk code to run.
 
 self error: 'a primitive has failed'
 
 
 primFileValidMPEG: aPath
 Check to see if the file is valid
 primitive: 'primitiveMPEG3CheckSig' module: 'Mpeg3Plugin'
 self primitiveFailed
 #
 
 
 
 SOLUTION ::
 =
 
 I guess there is still some plugin missing on my Dell laptop.
 But I have gone out of ideas to try.
 
 Bert, we will again be grateful :)
 
 
 
 
 Thanks and Regards,
 Ajay
 
 
 On Sun, May 27, 2012 at 2:10 AM, Rafael Ortiz raf...@activitycentral.com 
 wrote:
 
 
 On Sat, May 26, 2012 at 12:13 PM, Rafael Ortiz raf...@activitycentral.com 
 wrote:
 
 
 On Sat, May 26, 2012 at 7:47 AM, Peter Robinson pbrobin...@gmail.com wrote:
 On Sat, May 26, 2012 at 12:54 PM, Bert Freudenberg b...@freudenbergs.de 
 wrote:
 
  On 25.05.2012, at 22:21, Rafael Ortiz wrote:
 
 
 
  On Thu, May 24, 2012 at 11:34 AM, Rafael Ortiz raf...@activitycentral.com
  wrote:
 
  Hi
 
  While trying to add a journal entry (mp3 file) from etoys-113, i'm getting
  .An error has occurred; you should probably just hit abandon. Sorry
 
  Is this known?
 
  Log attached
 
 
  A clue on what this might be happening and how to solve it, appreciated.
 
  Thanks :)
 
 
  Well, the relevant lines in the error log seem to be these:
 
  DBusError: Traceback (most recent call last):
File /usr/lib/python2.7/site-packages/dbus/service.py, line 702, in
  _message_cb
  retval = candidate_method(self, *args, **keywords)
File /usr/lib/python2.7/site-packages/carquinyol/datastore.py, line 355,
  in get_properties
  metadata = self._metadata_store.retrieve(uid)
File /usr/lib/python2.7/site-packages/carquinyol/metadatastore.py, line
  41, in retrieve
  return metadatareader.retrieve(metadata_path, properties)
  IOError: Couldn't open metadata directory
  /home/olpc/.sugar/default/datastore//m//media/Philips/Buenos Muchachos/Se
  Pule La Colmena/2-06 Corazonoro.mp3/metadata
 
  So apparently Etoys tries to access the metadata for the MP3 but the
  datastore fails to find it. Etoys does not handle that case, it relies on
  get_properties() succeeding. Is that wrong?
 
 Being a mp3 do we even have the correct bits installed to be able to
 retrieve that information?
 
 
 In this case what would be the proper bits ?
 
 
  
 Our default builds don't come with the
 ability to play mp3 files so I'm not sure if we can even read the
 metadata.
 
 
 Also realized that the same problem is happening on
 ogg files, so doesn't seem related to codecs.
 
  
 Peter
 ___
 Sugar-devel mailing list
 Sugar-devel

Re: [Sugar-devel] Etoys in RC4 SoaS-v7 does not start when jabber is connected. ( f17 release is imminent )

[Bert Freudenberg]

On 27.05.2012, at 19:41, Thomas C Gilliard wrote:

 On 05/27/2012 05:37 AM, Peter Robinson wrote:
 On Thu, May 24, 2012 at 4:56 PM, Thomas C Gilliard
 satel...@bendbroadband.com  wrote:
 I have been testing the RC4 f17 release of SoaS [1] and I see a problem with
 e-toys:
 If jabber.sugarlabs.org  is connected via a wireless AP, or wired network,
 e-toys will not start:
 
  DBusError: Process /usr/bin/sugar-presence-service exited with status 1
 
 Etoys runs fine if wireless is not logged in and/or wired network is not
 connected. (no jabber connected)
 
 As Etoys is a favorite on the f3 ring and f17 release is imminent, I feel
 that this is an important bug to look at.
 Sorry, it was reported too late. It should have also been reported to
 the soas list.
 I have been reporting this occasional failure, But only realized what was 
 causing this behavior 3 days ago. : (
 
 It is possible to use E-toys but the DBusError created by the starting 
 example is very distracting. See bugs.sugarlabs.org/ticket/3640#comment:1
 
 The start up example seems to require process /usr/bin/sugar-presence-service


SoaS still has the old Etoys version (4.1). Etoys 5 was released along with 
Sugar 0.96. It is more robust wrt presence service failures.

- Bert -

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

Re: [Sugar-devel] Etoys in RC4 SoaS-v7 does not start when jabber is connected. ( f17 release is imminent )

[Bert Freudenberg]

On 28.05.2012, at 15:52, Peter Robinson wrote:

 On Mon, May 28, 2012 at 2:50 PM, Bert Freudenberg b...@freudenbergs.de 
 wrote:
 SoaS still has the old Etoys version (4.1). Etoys 5 was released along with 
 Sugar 0.96. It is more robust wrt presence service failures.
 
 It has issues with translations and the non standard location it installs them


Why is that a problem? Seems to have worked fine so far - and nothing else but 
Etoys is using these translation files.

- Bert -


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

Re: [Sugar-devel] Etoys in RC4 SoaS-v7 does not start when jabber is connected. ( f17 release is imminent )

[Bert Freudenberg]

On 28.05.2012, at 15:52, Peter Robinson wrote:

 On Mon, May 28, 2012 at 2:50 PM, Bert Freudenberg b...@freudenbergs.de 
 wrote:
 SoaS still has the old Etoys version (4.1). Etoys 5 was released along with 
 Sugar 0.96. It is more robust wrt presence service failures.
 
 it also still needs the sugar-presence-service package which has been 
 obsolete for a long
 time.


Etoys 5 is no worse than previous versions in that respect. On the contrary, it 
deals better with presence service deterioration.

Re-implementing the presence service takes time, I'm on my own, can't make it 
happen soon.

- Bert -


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

Re: [Sugar-devel] [SoaS] Etoys in RC4 SoaS-v7 does not start when jabber is connected. ( f17 release is imminent )

[Bert Freudenberg]

On 28.05.2012, at 18:19, Peter Robinson wrote:

 On Mon, May 28, 2012 at 5:05 PM, Walter Bender walter.ben...@gmail.com 
 wrote:
 On Mon, May 28, 2012 at 10:57 AM, Peter Robinson pbrobin...@gmail.com 
 wrote:
 On Mon, May 28, 2012 at 3:30 PM, Bert Freudenberg b...@freudenbergs.de 
 wrote:
 
 On 28.05.2012, at 15:52, Peter Robinson wrote:
 
 On Mon, May 28, 2012 at 2:50 PM, Bert Freudenberg b...@freudenbergs.de 
 wrote:
 SoaS still has the old Etoys version (4.1). Etoys 5 was released along 
 with Sugar 0.96. It is more robust wrt presence service failures.
 
 it also still needs the sugar-presence-service package which has been 
 obsolete for a long
 time.
 
 
 Etoys 5 is no worse than previous versions in that respect. On the 
 contrary, it deals better with presence service deterioration.
 
 Re-implementing the presence service takes time, I'm on my own, can't make 
 it happen soon.
 
 I think it's been over 2 years, I might just drop eToys from the build
 because it always causes random issues.
 
 Peter,
 
 I urge you to not drop Etoys. It is one of the most powerful learning
 tools we offer. Sugar is greatly diminished without it. Are there open
 tickets on these random issues?
 
 Well it would be nice if the developers actively participated and
 tested in the process. We've had these issues on going for as long as
 I can remember and they never get the attention that they need for
 one of the most powerful learning tools we offer and mostly just
 causes me pain.
 
 It's not too late to fix for the core SoaS v7 release so it gives
 people 6 months to actively improve the situation for the next
 release.
 
 Peter


I, too, hope you threaten to drop Etoys just to illustrate your frustration.

What else can we do besides fixing issues and hoping you package the result? 
That's our take on trying to actively improve the situation. 

Again, Etoys 5 starts fine, Etoys 4.1 not. But we cannot really test distro 
stuff if it has not been packaged yet.

Regarding the locale directory layout: I did not find a ticket in any of the 
trackers, neither upstream nor at sugarlabs or olpc. What would make the 
packaging easier for you?

- Bert -

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

Re: [Sugar-devel] [SoaS] Etoys in RC4 SoaS-v7 does not start when jabber is connected. ( f17 release is imminent )

[Bert Freudenberg]

On 28.05.2012, at 19:06, Peter Robinson wrote:

 On Mon, May 28, 2012 at 5:49 PM, Bert Freudenberg b...@freudenbergs.de 
 wrote:
 
 What else can we do besides fixing issues and hoping you package the result? 
 That's our take on trying to actively improve the situation.
 
 Again, Etoys 5 starts fine, Etoys 4.1 not. But we cannot really test distro 
 stuff if it has not been packaged yet.
 
 The last release I remember seeing was an RC (don't remember if it was
 RC1 or 2) and I had issues and never got back to it and if I must have
 missed the final release.

I had assumed you would package even release candidates so they can be tested 
in the distro.

The final release is the last release candidate, Etoys 5.0.2406. I failed to 
send a separate notice for that, sorry.

  Ultimately it would be nice if the
 developers of their Activities checked and tested and emailed the SoaS
 list if they have issues or the new versions have been missed.

Okay. I didn't want to bug you immediately, and after a while forgot.

 We have
 nightly builds right through the dev process and various
 Alpha/Beta/RCs etc in the lead up to final for testing. I can't test
 everything and I'm not fallible and the process we use has clearly
 defined [1] development schedule to know when fixes need to be in by.

I did send the release announcement on March 30th, so that should have been 
fine for the F17 beta.

 Regarding the locale directory layout: I did not find a ticket in any of the 
 trackers, neither upstream nor at sugarlabs or olpc. What would make the 
 packaging easier for you?
 
 To use the same layout that is used by everything else so we can use
 the standard distro tools to deal with them. Probably the best package
 to look at is TurtleArt.

Would a symlink be acceptable? This would make it easier for Etoys to find the 
right system folder.

/usr/share/etoys/locale - ../../locale

(would resolve to /usr/share/locale)

If we prefix all Etoys .mo files then they could be installed to the system 
folder.

- Bert -


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

[Sugar-devel] Etoys translations (was: Etoys in RC4 SoaS-v7 does not start when jabber is connected.)

[Bert Freudenberg]

On 28.05.2012, at 19:54, Peter Robinson wrote:

 symlinks don't work with the Fedora packaging language tools, I prefer
 that as it's what the rest of the sugar stack works with.

The way I imagine it is that the .mo files would be installed in 
/usr/share/locale as all the other packages do, too.

The only question is how to let Etoys know where to go look for its locale 
files. A symlink created by the installation script would be the simplest 
solution IMHO. Otherwise we would have to try to pass the directory as argument 
to etoys in its launcher script which to me seems overly complicated.

 If we prefix all Etoys .mo files then they could be installed to the system 
 folder.
 
 If you use the usual flags as used by all packages for Linux distros
 it means you're standard and it will work with all the various linux
 distro options.
 
 Peter

Not sure what you mean by flags. What I mean by prefixes is this:

Currently Etoys uses mo files named e.g. Collections.mo, Compression.mo, 
Connectors.mo, etc. This works fine because Etoys had the whole LC_MESSAGES 
directory for itself. I would propose to rename them to Etoys-Collections.mo, 
Etoys-Compression.mo, Etoys-Connectors.mo, etc. because if we share the same 
directory with other packages it would be hard to identify which mo files 
belong to Etoys.

- Bert -

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

Re: [Sugar-devel] Etoys mp3 files

[Bert Freudenberg]

On 25.05.2012, at 22:21, Rafael Ortiz wrote:

 
 
 On Thu, May 24, 2012 at 11:34 AM, Rafael Ortiz raf...@activitycentral.com 
 wrote:
 Hi 
 
 While trying to add a journal entry (mp3 file) from etoys-113, i'm getting 
 .An error has occurred; you should probably just hit abandon. Sorry
 
 Is this known?
 
 Log attached
 
 
 A clue on what this might be happening and how to solve it, appreciated.
 
 Thanks :)

Well, the relevant lines in the error log seem to be these:

DBusError: Traceback (most recent call last):
  File /usr/lib/python2.7/site-packages/dbus/service.py, line 702, in 
_message_cb
retval = candidate_method(self, *args, **keywords)
  File /usr/lib/python2.7/site-packages/carquinyol/datastore.py, line 355, in 
get_properties
metadata = self._metadata_store.retrieve(uid)
  File /usr/lib/python2.7/site-packages/carquinyol/metadatastore.py, line 41, 
in retrieve
return metadatareader.retrieve(metadata_path, properties)
IOError: Couldn't open metadata directory 
/home/olpc/.sugar/default/datastore//m//media/Philips/Buenos Muchachos/Se Pule 
La Colmena/2-06 Corazonoro.mp3/metadata

So apparently Etoys tries to access the metadata for the MP3 but the datastore 
fails to find it. Etoys does not handle that case, it relies on 
get_properties() succeeding. Is that wrong?

- Bert -


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

Re: [Sugar-devel] Dr.Geo on XO 1

[Bert Freudenberg]

On 20.05.2012, at 11:00, Sascha Silbe wrote:

 Bert Freudenberg b...@freudenbergs.de writes:
 
 Nope, that was not it. I compiled with -mtune=geode, makes no
 difference.
 
 Make sure to set -march=architecture to something appropriate. -march
 tells gcc what instructions it can use (so anything that doesn't support
 these instructions will fail to run the resulting executable), whereas
 -mtune only tells it to optimise for a certain processor type (but the
 executable will continue to run on other processors as long as they
 support the instruction set specified by -march).

I actually had used -march=pentiumpro -mtune=geode as recommended here:

http://wiki.laptop.org/go/Geode_LX

and even with an additional -O0 it still crashes.

 In gdb I see it's segfaulting inside the GC logic. It's really
 puzzling this only happens on the XO-1 ...
 
 You could try booting an XO-1.5 with mem=256M (append that to boot-file
 in /bootpart/boot/olpc.fth) to simulate the memory pressure of an XO-1.


YES! That reproduces the crash on XO-1.5. Good thinking! :)

I could also reproduce it in a virtual Ubuntu 12 with 768 MB RAM (!) but no 
swap. Top reports:

Mem:766204k total,   601588k used,   164616k free,45624k buffers
Swap:0k total,0k used,0k free,   277024k cached

but DrGeo still crashes.

OTOH, Etoys runs fine using the same Squeak VM on the same system (and on 
XO-1). So I wonder what the new DrGeo does differently ...

- Bert -

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

Re: [Sugar-devel] Dr.Geo on XO 1

[Bert Freudenberg]

On 20.05.2012, at 20:38, Hilaire Fernandes wrote:

 I will give it a shot later these days. These various tries where useful
 to surround the  problem.
 
 Hilaire


I asked on the VM dev list. Dave Lewis had a hunch that possibly Pharo's object 
memory is corrupt:

http://lists.squeak.org/pipermail/vm-dev/2012-May/010652.html

In any case it wouldn't hurt to ask for help on the Pharo list.

- Bert -

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

Re: [Sugar-devel] Dr.Geo on XO 1

[Bert Freudenberg]

Hi Ariel,

there are messages missing from this thread. I did not see the message with 
your trace attachments.

But, are you saying you compiled the 4.4.7 Squeak VM on an old Fedora and it 
still does not work with DrGeo on an XO-1?

- Bert -

On 19.05.2012, at 21:47, Ariel Calzada wrote:

 Hi!
 
 I downloaded it pharo image from 
 http://www.pharo-project.org/pharo-download/release-1-4, and got the same 
 error message. Is there any other test that i can do in order to fix the 
 error?.
 
 Regards,
 Ariel Calzada
 Activity Central
 
 2012/5/19 Hilaire Fernandes hilaire.fernan...@edu.ge.ch
 This VM was used with previous version of DrGeo.
 Is the problem related to the latest stable Sugar and the VM and XO-1?
 I tested DrGeo 11.08 and it worked with this identical set up.
 So It could be related to the Pharo image I used, or all related together.
 It is not easy to track the exact problem and it may take time.
 
 One things to do could be to test latest, virgin, Pharo image 1.4 with
 this same image., so it could clarify the problem
 
 Hilaire
 
 
 
 On 19/05/2012 20:10, Ariel Calzada wrote:
  Hi!
 
  We have made the following tests for XO 1.0:
 
  -- Run squeak binary  strace ./squeak drgeo.image ( Attachment:
  strace-binary.txt )
  -- Run squeak compiled  strace ./squeak drgeo.image ( Attachment:
  strace-src.txt )
 
  Both tests were not successful we got segmentation fault errors, we had
  review the strace logs but we haven't found why this happen.
 
  I hope this helps.
 
  Regards,
  Ariel Calzada
  Activity Central
 
 
  2012/5/16 Hilaire Fernandes hilaire.fernan...@edu.ge.ch
 
  It looks like the SqueakVM I compiled for DrGeo  does not work with X0-1
  last Sugar system, but ok with XO-1.5 last Sugar system.
 
  It will cost me too much to prepare a new VM, I am busy with tablet
  versions of DrGeo.
 
  I invite other group interested to see DrGeo on Sugar, to compiled and
  test a SqueakVM with the latest Sugar version. Idealy one should use the
  COG Squeak VM coming with JITer and extend it to support the --sugar
  application flags.
  The Squeak VM coming with Sugar is an antiquity and slow horse anyway.
 
  Hilaire
 
  --
  Dr. Geo -- http://www.drgeo.eu
 
  ___
  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

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

Re: [Sugar-devel] Dr.Geo on XO 1

[Bert Freudenberg]

The trace is not enlightening.

I'll take a shot in the dark:

I vaguely remember the XO-1's AMD Geode processor lacks some features that 
other x86 CPUs have. Do I remember correctly? If that is so, could you try 
compiling the VM in i386 compatibility mode? I don't recall how to do that, 
it's been too long ago ...

- Bert -

On 19.05.2012, at 23:01, Ariel Calzada wrote:

 Hi Bert!
 
 Yes I compiled 4.4.7 and this doesn't work with drgeo.image, i tested with 
 pharo 1.3 image and it worked. Logs attached.
 
 Regards,
 Ariel Calzada
 Activity Central
 
 On 05/19/2012 03:57 PM, Bert Freudenberg wrote:
 
 Hi Ariel,
 
 there are messages missing from this thread. I did not see the message with 
 your trace attachments.
 
 But, are you saying you compiled the 4.4.7 Squeak VM on an old Fedora and it 
 still does not work with DrGeo on an XO-1?
 
 - Bert -
 
 On 19.05.2012, at 21:47, Ariel Calzada wrote:
 
 Hi!
 
 I downloaded it pharo image from 
 http://www.pharo-project.org/pharo-download/release-1-4, and got the same 
 error message. Is there any other test that i can do in order to fix the 
 error?.
 
 Regards,
 Ariel Calzada
 Activity Central
 
 2012/5/19 Hilaire Fernandes hilaire.fernan...@edu.ge.ch
 This VM was used with previous version of DrGeo.
 Is the problem related to the latest stable Sugar and the VM and XO-1?
 I tested DrGeo 11.08 and it worked with this identical set up.
 So It could be related to the Pharo image I used, or all related together.
 It is not easy to track the exact problem and it may take time.
 
 One things to do could be to test latest, virgin, Pharo image 1.4 with
 this same image., so it could clarify the problem
 
 Hilaire
 
 
 
 On 19/05/2012 20:10, Ariel Calzada wrote:
  Hi!
 
  We have made the following tests for XO 1.0:
 
  -- Run squeak binary  strace ./squeak drgeo.image ( Attachment:
  strace-binary.txt )
  -- Run squeak compiled  strace ./squeak drgeo.image ( Attachment:
  strace-src.txt )
 
  Both tests were not successful we got segmentation fault errors, we had
  review the strace logs but we haven't found why this happen.
 
  I hope this helps.
 
  Regards,
  Ariel Calzada
  Activity Central
 
 
  2012/5/16 Hilaire Fernandes hilaire.fernan...@edu.ge.ch
 
  It looks like the SqueakVM I compiled for DrGeo  does not work with X0-1
  last Sugar system, but ok with XO-1.5 last Sugar system.
 
  It will cost me too much to prepare a new VM, I am busy with tablet
  versions of DrGeo.
 
  I invite other group interested to see DrGeo on Sugar, to compiled and
  test a SqueakVM with the latest Sugar version. Idealy one should use the
  COG Squeak VM coming with JITer and extend it to support the --sugar
  application flags.
  The Squeak VM coming with Sugar is an antiquity and slow horse anyway.
 
  Hilaire
 
  --
  Dr. Geo -- http://www.drgeo.eu
 
  ___
  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
 
 
 strace-binary.txtstrace-src.txt

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

Re: [Sugar-devel] Dr.Geo on XO 1

[Bert Freudenberg]

Nope, that was not it. I compiled with -mtune=geode, makes no difference.

In gdb I see it's segfaulting inside the GC logic. It's really puzzling this 
only happens on the XO-1 ...

- Bert -

On 19.05.2012, at 23:15, Bert Freudenberg wrote:

 The trace is not enlightening.
 
 I'll take a shot in the dark:
 
 I vaguely remember the XO-1's AMD Geode processor lacks some features that 
 other x86 CPUs have. Do I remember correctly? If that is so, could you try 
 compiling the VM in i386 compatibility mode? I don't recall how to do that, 
 it's been too long ago ...
 
 - Bert -
 
 On 19.05.2012, at 23:01, Ariel Calzada wrote:
 
 Hi Bert!
 
 Yes I compiled 4.4.7 and this doesn't work with drgeo.image, i tested with 
 pharo 1.3 image and it worked. Logs attached.
 
 Regards,
 Ariel Calzada
 Activity Central
 
 On 05/19/2012 03:57 PM, Bert Freudenberg wrote:
 
 Hi Ariel,
 
 there are messages missing from this thread. I did not see the message with 
 your trace attachments.
 
 But, are you saying you compiled the 4.4.7 Squeak VM on an old Fedora and 
 it still does not work with DrGeo on an XO-1?
 
 - Bert -
 
 On 19.05.2012, at 21:47, Ariel Calzada wrote:
 
 Hi!
 
 I downloaded it pharo image from 
 http://www.pharo-project.org/pharo-download/release-1-4, and got the same 
 error message. Is there any other test that i can do in order to fix the 
 error?.
 
 Regards,
 Ariel Calzada
 Activity Central
 
 2012/5/19 Hilaire Fernandes hilaire.fernan...@edu.ge.ch
 This VM was used with previous version of DrGeo.
 Is the problem related to the latest stable Sugar and the VM and XO-1?
 I tested DrGeo 11.08 and it worked with this identical set up.
 So It could be related to the Pharo image I used, or all related together.
 It is not easy to track the exact problem and it may take time.
 
 One things to do could be to test latest, virgin, Pharo image 1.4 with
 this same image., so it could clarify the problem
 
 Hilaire
 
 
 
 On 19/05/2012 20:10, Ariel Calzada wrote:
  Hi!
 
  We have made the following tests for XO 1.0:
 
  -- Run squeak binary  strace ./squeak drgeo.image ( Attachment:
  strace-binary.txt )
  -- Run squeak compiled  strace ./squeak drgeo.image ( Attachment:
  strace-src.txt )
 
  Both tests were not successful we got segmentation fault errors, we had
  review the strace logs but we haven't found why this happen.
 
  I hope this helps.
 
  Regards,
  Ariel Calzada
  Activity Central
 
 
  2012/5/16 Hilaire Fernandes hilaire.fernan...@edu.ge.ch
 
  It looks like the SqueakVM I compiled for DrGeo  does not work with X0-1
  last Sugar system, but ok with XO-1.5 last Sugar system.
 
  It will cost me too much to prepare a new VM, I am busy with tablet
  versions of DrGeo.
 
  I invite other group interested to see DrGeo on Sugar, to compiled and
  test a SqueakVM with the latest Sugar version. Idealy one should use the
  COG Squeak VM coming with JITer and extend it to support the --sugar
  application flags.
  The Squeak VM coming with Sugar is an antiquity and slow horse anyway.
 
  Hilaire
 
  --
  Dr. Geo -- http://www.drgeo.eu



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

Re: [Sugar-devel] [support-gang] Clarifications: Help package a 3D activity

[Bert Freudenberg]

On 17.05.2012, at 03:36, Mikus Grinbergs wrote:

 This is not going to work on ARM; the target was said to be XO-1
 Feedback for activity_developer to ensure that it does something
 sensible on ARM, like sorry, your computer is too new for this
 activity
 
 On 05/16/2012 07:42 PM, James Cameron wrote:
 I think Sugar leans toward architecture independence in the .xo files,
 but it's something that could be raised again with Sugar Labs.
 
 It should be feasible to test before you run -- but this Activity includes 
 a binary, and as far as I know ARM machine instructions are not the same as 
 x86 machine instructions -- and including TWO binaries (one for each 
 architecture) leads to .xo bloat.
 
 And, from my limited knowledge (I haven't kept up), the design for Activities 
 does NOT include a way for Activities to __test__ whether dependent RPMs are 
 provided by the runtime environment.  Dependencies have traditionally been 
 addressed by __including__ them in the .xo package -- but that just means 
 *more* architecture-dependent files.
 
 mikus


Executables tend to be small compared to data files. For users, a fat bundle 
containing multiple architectures is arguably simplest. You could use something 
like this:

ARCH=`uname -m`
BIN=$SUGAR_BUNDLE_PATH/bin-$ARCH
exec $BIN/myexecutable

... and have both a bin-i686 and bin-arm7vl directory (and lib dirs if 
needed).

As an example, there is a DrGeo activity bundle that supports both 
architectures (last time I looked, the ARM part included way too many files, 
but it appears to work):
http://people.sugarlabs.org/rafael/UY/
(the proper way here would have been installing a newer Squeak VM in the 
system, but bundling it inside the activity is a good short-term workaround).


- Bert -


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

Re: [Sugar-devel] Running an activity through ssh

[Bert Freudenberg]

On 13.04.2012, at 09:07, Manuel Kaufmann wrote:

 Hello,
 
 I'm trying to run an Activity over ssh -C -X to my XO.
 
 Once I'm logged in, I'm running:
 
 $ sugar-launch org.laptop.AbiWordActivity
 
 But I'm getting this error:
 
 Traceback (most recent call last):
  File /usr/bin/sugar-launch, line 38, in module
proxy = bus.get_object('org.laptop.Shell', '/org/laptop/Shell')
  File /usr/lib/python2.7/site-packages/dbus/bus.py, line 244, in get_object
follow_name_owner_changes=follow_name_owner_changes)
  File /usr/lib/python2.7/site-packages/dbus/proxies.py, line 241, in 
 __init__
self._named_service = conn.activate_name_owner(bus_name)
  File /usr/lib/python2.7/site-packages/dbus/bus.py, line 183, in
 activate_name_owner
self.start_service_by_name(bus_name)
  File /usr/lib/python2.7/site-packages/dbus/bus.py, line 281, in
 start_service_by_name
'su', (bus_name, flags)))
  File /usr/lib/python2.7/site-packages/dbus/connection.py, line
 630, in call_blocking
message, timeout)
 dbus.exceptions.DBusException:
 org.freedesktop.DBus.Error.ServiceUnknown: The name org.laptop.Shell
 was not provided by any .service files
 
 Is there a way to do this?


Probably not.

The immediate problem you ran into is that by logging in remotely, you are not 
in the same DBus session as the running Sugar instance. That could be worked 
around by setting the DBUS_SESSION_BUS_ADDRESS environment variable.

But I doubt this would help you running the activity remotely. Sugar very much 
assumes an activity runs on the same host as the X server, that is, locally.

About the only way to run Sugar remotely is via VNC. But then, why bother? 
VirtualBox works fine. What is the actual problem you want to solve?

- Bert -

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

Re: [Sugar-devel] Just learned about Mistery Meat Navigation

[Bert Freudenberg]

On 29.03.2012, at 14:14, Carl Angiolillo wrote:

  explicit help button that toggles an overlay with help bubbles would be 
  best.
 
 D'oh, good call, totally missed help overlay.
 
  Interesting, this is what Gary pointed in the Simple help system for 
  Sugar thread.
 
 Forgive a stupid question, but I'm not sure where to find the existing Sugar 
 help designs to get context. The sugar labs wiki?
 

3 weeks ago on this list:

http://www.mail-archive.com/iaep@lists.sugarlabs.org/msg13364.html

Would be good to consolidate the discussion into a wiki page though, agreed.

- Bert -

 On Tue, Mar 27, 2012 at 10:43, Bert Freudenberg b...@freudenbergs.de wrote:
 
 
  On 27.03.2012, at 15:24, Manuel Quiñones wrote:
 
   El día 27 de marzo de 2012 08:04, Bert Freudenberg
   b...@freudenbergs.de escribió:
   IMHO, an explicit help button that toggles an overlay with help bubbles 
   would be best. Takes up less space than actual labels. Here's an example:
  
  http://thedigitalstory.com/2012/03/5_tips_for_working_w.html
  
   Interesting, this is what Gary pointed in the Simple help system for 
   Sugar thread.
 
 
  Yes, that, and also combined with your idea of an overlayed help window.
 
  Tapping the help button brings up the bubbles with a short description. But 
  some bubbles also link to a more complete help widget. I'm referring to 
  this screenshot:
 
 http://thedigitalstory.com/2012/03/08/iPhoto_for_iPad.png
 
  Tapping the arrow on the right of these bubbles opens a Help window in the 
  middle of the screen, and jumps to the relevant page. It's organized 
  hierarchically, and articles have hyperlinks to related topics. Plus 
  there's full text search.
 
  - Bert -
 
 
  ___
  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] Just learned about Mistery Meat Navigation

[Bert Freudenberg]

IMHO, an explicit help button that toggles an overlay with help bubbles would 
be best. Takes up less space than actual labels. Here's an example:

http://thedigitalstory.com/2012/03/5_tips_for_working_w.html

- Bert -


On 27.03.2012, at 06:44, Carl Angiolillo wrote:

  However, that is different than the icons you use everyday.
 
 True. The time spent learning iconography is amortized while the pixel costs 
 of the label remain fixed so those text labels that were very helpful at 
 first end up consuming unnecessary real-estate as the kids become experts. 
 However, if the kids become frustrated by confusing buttons* they might not 
 bother becoming experts at all so it's worth keeping an eye on during testing.
 
  on a touch screen ... there's no obvious way to get the text descriptions 
  to pop up.
 
 The method Android uses is to long press on a button to display its label. I 
 doubt this qualifies as obvious judging by the fact that this was slipped 
 quietly into 4.0 and I've never observed anyone using it. Some interfaces 
 (like native OS X toolbars or MS Office products) allow text labels to be 
 turned on and off by the user. I've used time-delay fade-in labels on 
 touchscreens (which were supposed to help novices while not impacting expert 
 use) but they turned out to be too distracting and not helpful in the case of 
 buttons that remain visible all the time. The simplest method might be to 
 bite the bullet, spend the pixels, and add text labels to buttons on 
 touchscreen devices.
 
 Carl
 
 *...e.g., a sound icon shaped like the profile of an internal electronic 
 component or a stop icon shaped like an octagon even in Libya, Zimbabwe, the 
 Bahamas, or Japan.
 
 On Tue, Mar 20, 2012 at 19:37, Bert Freudenberg b...@freudenbergs.de wrote:
 
 On 21.03.2012, at 00:16, C. Scott Ananian wrote:
 
  On Tue, Mar 20, 2012 at 4:47 PM, Gonzalo Odiard gonz...@laptop.org wrote:
  If you find non obvious icons, can report to try to improve.
  May be adults have problems with icons, but kids don't,
  just see a kid playing in any internet site.
 
  These icons become much more problematic on a touch screen, where there's 
  no obvious way to get the text descriptions to pop up.
   --scott
 
 OTOH, on a web site, you just want to get results quickly, and then maybe 
 never visit again. It's not worth learning what the icons mean, since they 
 most likely are unique to that site. That's why using icons like in the video 
 fails.
 
 However, that is different than the icons you use everyday. Those are worth 
 learning. Of course, the learning must be made possible, and hopefully 
 enjoyable. But the gut reaction of I as an adult can't figure it out at 
 first glance, so it must be bad isn't quite appropriate.
 
 - Bert -
 
 ___
 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] Just learned about Mistery Meat Navigation

[Bert Freudenberg]

On 27.03.2012, at 15:24, Manuel Quiñones wrote:

 El día 27 de marzo de 2012 08:04, Bert Freudenberg
 b...@freudenbergs.de escribió:
 IMHO, an explicit help button that toggles an overlay with help bubbles 
 would be best. Takes up less space than actual labels. Here's an example:
 
http://thedigitalstory.com/2012/03/5_tips_for_working_w.html
 
 Interesting, this is what Gary pointed in the Simple help system for Sugar 
 thread.


Yes, that, and also combined with your idea of an overlayed help window. 

Tapping the help button brings up the bubbles with a short description. But 
some bubbles also link to a more complete help widget. I'm referring to this 
screenshot:

http://thedigitalstory.com/2012/03/08/iPhoto_for_iPad.png

Tapping the arrow on the right of these bubbles opens a Help window in the 
middle of the screen, and jumps to the relevant page. It's organized 
hierarchically, and articles have hyperlinks to related topics. Plus there's 
full text search.

- Bert -


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

Re: [Sugar-devel] Just learned about Mistery Meat Navigation

[Bert Freudenberg]

On 21.03.2012, at 00:16, C. Scott Ananian wrote:

 On Tue, Mar 20, 2012 at 4:47 PM, Gonzalo Odiard gonz...@laptop.org wrote:
 If you find non obvious icons, can report to try to improve.
 May be adults have problems with icons, but kids don't,
 just see a kid playing in any internet site.
 
 These icons become much more problematic on a touch screen, where there's no 
 obvious way to get the text descriptions to pop up.
  --scott

OTOH, on a web site, you just want to get results quickly, and then maybe never 
visit again. It's not worth learning what the icons mean, since they most 
likely are unique to that site. That's why using icons like in the video fails.

However, that is different than the icons you use everyday. Those are worth 
learning. Of course, the learning must be made possible, and hopefully 
enjoyable. But the gut reaction of I as an adult can't figure it out at first 
glance, so it must be bad isn't quite appropriate.

- Bert -

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

Re: [Sugar-devel] [PATCH browse] Bring back download functionality using WebKit

[Bert Freudenberg]

On 23.01.2012, at 22:57, Simon Schampijer wrote:

 On 01/23/2012 11:58 PM, Bert Freudenberg wrote:
 This is only tangentially related to the download functionality, but I was 
 wondering if the webkit browser already does better on the identification 
 issue?
 
 http://bugs.sugarlabs.org/ticket/2834
 
 - Bert -
 
 Hi Bert,
 
 we just did land a fix that identifies the Browser with ASLO [1]. Either you 
 change squakland to look for the 'Sugar Labs' string or we need to add the 
 'olpc' string for you. One could argue both ways: we should add back the 
 'olpc' string for backwards compatibility or maybe having people to adapt to 
 the new way for Sugar on any hardware platform.


Changing the server code to look for both should be easy enough. Thanks!

- Bert -


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