Re: [Sugar-devel] suggestions for additions to platform page

[Tomeu Vizoso]

On Tue, Jan 5, 2010 at 11:54, Daniel Drake  wrote:
> vte (and Python bindings) should be added (Terminal requires this)
> and it should be noted explicitly that python bindings for csound are
> required (Pippy and other activities use these)
>
> What's the process for making such changes? or am I allowed just to use
> common sense for once? :)

The process is having some discussion such as what we are having now.
I'm ok with these changes.

Regards,

Tomeu

-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [ANNOUNCE] Sugar Services

[Tomeu Vizoso]

On Sun, Jan 3, 2010 at 19:12, Aleksey Lim  wrote:
> Happy New Year to all,
>
> http://wiki.sugarlabs.org/go/Activity_Team/Services

I don't think I fully understand your plan with services yet, but when
you feel this is ready to receive feedback from deployments, ask me,
though I haven't had always success with that...

Regards,

Tomeu

> It is the first version Sugar Services infrastructure which is ready
> to test or use in simple cases(see Known Issues[1]).
>
> In short terms it's about adding decentralized method to support
> various activity dependencies. See what Services is[2] and is not[3].
>
>
> There are also guides for:
>
> * activity developers
>  http://wiki.sugarlabs.org/go/Documentation_Team/Services/Activity_Developers_Guide
>
> * service developers
>  http://wiki.sugarlabs.org/go/Documentation_Team/Services/Service_Developers_Guide
>
>
> Examples:
>
> * CartoonBuilder-9
>  http://activities.sugarlabs.org/en-US/sugar/addon/4037
>  uses Toolkit[4] service which provides new toolbar design for 0.82+
>
> * Speak-12
>  http://activities.sugarlabs.org/en-US/sugar/addon/4038
>  uses gst-plugins-espeak[5] service which lets activity use gst plugin
>  instead of executing espeak command on XO-1
>
> In all examples the only change(except bundling 0sugar-launch, since
> saccharin is not part of Sugar Platform) is adding new string to
> activity.info:
>
>   requires = toolkit; gst-plugins-espeak
>
>
> [1] 
> http://wiki.sugarlabs.org/go/Documentation_Team/Services/Activity_Developers_Guide#Known_issue
> [2] http://wiki.sugarlabs.org/go/Activity_Team/Services#Workflows
> [3] 
> http://wiki.sugarlabs.org/go/Activity_Team/Services#What_is_Sugar_Services_not.3F
> [4] http://wiki.sugarlabs.org/go/Activity_Team/Services/Toolkit
> [5] http://git.sugarlabs.org/projects/gst-plugins-espeak
>
> --
> Aleksey
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Please tag tarball releases in git repository, e.g. Sugar 0.87.2

[Tomeu Vizoso]

On Wed, Dec 30, 2009 at 14:04, Jonas Smedegaard  wrote:
> Hi,
>
> Please do remember to tag tarball releases in Git repositories.  Those tags
> are helpful for (some) distributors - like me :-)

Oops, was a problem with the release script, git push failed because I
had some non-uptodate branches and the script didn't pushed the tags.
I'm attaching a patch for Simon to review.

> Concretely Sugar 0.87.2 released december 21st lack a tag about that.

Pushed, thanks!

Regards,

Tomeu

>
> Kind regards,
>
> - Jonas
>
> --
> * Jonas Smedegaard - idealist & Internet-arkitekt
> * Tlf.: +45 40843136  Website: http://dr.jones.dk/
>
>  [x] quote me freely  [ ] ask before reusing  [ ] keep private
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iQIcBAEBCgAGBQJLO0/aAAoJECx8MUbBoAEheicP/37UK0+SUQVbOHL9p1Lc7nVl
> p+K6T3Q3jbhKVymTlGuKIirHpPp4y0FTy/X3kJbtPPAtFHYfcg0v+M5JMGJL9NqS
> gWQCITI1o+4Qd7d22j8FOSwX8hrsGwa6bwFtc1bHG17LRi47ZgNXjb5A/9LuQV00
> 1EIsYUT4uZzEIldtBoRw1iZ4B3/kOdgv2BOHVlc7VxKd0HHSPOSyBOS41cIxIJEQ
> njA+e3HZERc1kKXz5VPNzCGfo4cFfa2D1MDGy1BXp3eU0Yv8vJd7mdq3KVIdne/X
> CpxSONQMMUIgGXIC7UkH1CPy+fXmEaAVkG5gDB7E6Rd35D638rIgFOul7inftQFl
> 9ZNUP8BwBfJmsHewGPrMt9yqbdeq8TuIbRBD1Whpx+4h4cXhHNeqVwK9xgyVYQTG
> U+pxE9h6sZOhOvNmx/XOXp/rK6xDz3yPNOcqhnFqMZjbNJUUtsC9XIr7aUgGU06P
> h/7nycSQFvCPk5FBrI/dhAIgn8nF2ozbLXgpB82AfXGQCfblOxskhuSgQf0YfBy3
> 6k9CeBIxIt0n7wcv86EKH1WXBZ7cC8IQRIqUIkmYzNZyFjPrYr23wBs1hg34w7nx
> ZRSuLMLw92FtUc+x7dRT++C81BlJfRYQLqFik6z1V0GW1xSE7EqMM+YUMmu+Y7TA
> HeaW9o9JqV9qcQIyzGwI
> =hRAp
> -END PGP SIGNATURE-
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning


0001-Push-only-to-master.patch
Description: Binary data
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] File Share Activity

[Tomeu Vizoso]

Hola,

creo que os puede interesar esta actividad, que facilita mucho la
distribucion de contenido y actividades en el aula.

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

Saludos,

Tomeu

On Wed, Dec 30, 2009 at 22:24, Justin Lewis  wrote:
> I have been building a File Share activity and I have just uploaded a
> copy of it to the activities page.
>
> I am looking for testing, feedback, bugs, and any other comments you may have.
>
> It can be found here: http://activities.sugarlabs.org/en-US/sugar/addon/4266
>
> Justin Lewis
> http://people.rit.edu/~jtl1728
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [FEATURE] [DESIGN] Journal Reload a new attempt

[Tomeu Vizoso]

On Sun, Dec 6, 2009 at 03:20, Aleksey Lim  wrote:
> (oops, wrong subject)
>
> Hi all,
>
>
> This post is not about particular feature but about proposed
> to 0.88 features that can be composited to one set.

IMHO, instead of proposing (apparently out of the blue) new features
that change everything including the development and deployment
models, would be better to start from a stated need and then propose
solutions for those.

In the particular case of the Journal, we know from the 0.86 cycle
that the current list widget is not the best we could use. Users are
also demanding a way to select multiple items and perform operations
on them. Sorting has also been requested. Do we really need to decide
on the plugins thing before we solve these simpler issues?

Regards,

Tomeu

> Some of them
> could be implemented in 0.88 partially, some are invasive, some not.
> We lost possibility to push several such features in 0.86 and we have
> a chance to do it once more in 0.88 release cycle. But in my mind,
> start to fix followed issue could be useful even in 0.88.
>
> * Reinforcing the storage metaphor in sugar
>  (w/o loosing dairy component). Since in sugar we have only
>  datastore(existed Journal from users POV) as a data storage(excluding
>  external sources), we have *very* poor instruments to treat sugar
>  object from users POV - user has to face to the whole list of objects
>  from begging(there is not way to keep query - should look like
>  replacement of regular directories), user even can't manually sort
>  Journal objects.
>
>  Could be fixed by:
>  * [5] having sugar "directories" - bookmarks
>  * [6] several views that could provide most useful browsing features
>
> * Having extended storage metaphor, we should save dairy component,
>  so we can start implementing of long discussing Actions feature
>
>  Could be fixed by:
>  * [2] its only a stub, so any ideas are welcome
>
> * Make existed work flows more consistent
>  ("activities vs. objects-that-could-be-treated-as-activities",
>  "activities vs. activity bundles")
>
>  Could be fixed by:
>  * having [5], there is simple behaviour, all sugar objects are
>    accessible from one place but from different views e.g. Hove view
>    is just a special view that contain only "activities"(but could
>    contain other objects too to speed up access) or new Actions view
>    is a "dairy" view
>
> * Encourage activity developers make custom objects views,
>  (having only one object view we either have complicated view or
>  feature less one)
>
>  Could be fixed by:
>  * [1]
>
>
> These features are:
>
> [1] http://wiki.sugarlabs.org/go/Features/Journal_Plugins
>    the name could be confusing but [1] should provide all features that
>    are mentioned here
>
>    How its invasive:
>    * except [7], non of UI should be changed in default sugar distribution
>    * code will be refactored to support plugins API
>
> [2] http://wiki.sugarlabs.org/go/Features/Actions
>    this page just a stub, so who are original initiators (or have ideas)
>    for this feature, please tweak wiki page to cover all workflows
>
>    How its invasive:
>    * the full implementation of this feature could be too invasive for UI
>      and codebase, but we can just initiate this feature in 0.88 and
>      collect users feedback to improve it in 0.90
>
> [3] http://wiki.sugarlabs.org/go/Features/Activity_as_a_regular_Journal_Object
>
>    How its invasive:
>    * adds another confusion when user deletes activity instead of
>      activity objects but having [5], by default, all object sets could
>      not contain activity object except special activity views that can
>      make activity removing more explicit for users
>    * shouldn't be invasive in case of codding
>
> [4] http://wiki.sugarlabs.org/go/Features/Sugar_Bundles
>
>    How its invasive:
>    * codding shouldn't be invasive
>
>
> Summarising above text, I think we can start implementation of these
> features in 0.88 release cycle(but we shouldn't implement the final
> workflows and make only initial steps e.g. in case of Actions). So, what
> community thinks about how such features could be invasive to users
> workflows and codebase and how it could(invasive changes) be reduced.
>
>
> [5] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#Data_model
> [6] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#View_model
> [7] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#UI_Design
>
> --
> Aleksey
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Browse questions for Karma

[Tomeu Vizoso]

On Fri, Jan 1, 2010 at 14:13, Bryan Berry  wrote:
> I am trying to run the Karma lessons using Browse instead of regular
> Firefox. Using Browse will enable me to create sugar bundle for karma that
> doesn't include binaries
> I have tested it on os10 of 0.86
> http://dev.laptop.org/~smparrish/XO-1/builds/OS10/os10.img on the XO.
> This build uses  xulrunner-1.9.1.5. My version of "Conozco a Uruguay"
> doesn't run at all
> http://karma.sugarlabs.org/examples/Conozco-Uruguay
> I can run "Conozco" on my regular laptop w/ Firefox 3.5 which uses
> xulrunner-1.9.1. My understanding was that Browse basically is Firefox. What
> other components make up Browse and which ones distinguish it from regular
> firefox?

Both Browse and Firefox are based on xulrunner. Hulahop is a Gtk+
widget that allows embedding the xulrunner engine and provides some
glue for using PyXPCOM. Browse uses PyXPCOM as Firefox uses XUL and
XBL.

> My first question is, how can I debug web applications running in Browse?

Debug is a bit wide of a term. As a first shot at anticipating what
you want, you could activate the javascript console and use dump()
calls? Those should appear in the activity log file.

https://developer.mozilla.org/en/Debugging_a_XULRunner_Application

> If
> I can't debug on the XO or w/in Sugar, I need someway to replicate nearly
> the exact Firefox environment on my regular laptop.

You mean the exact Browse? You can install F11 on your laptop, or
sugar-jhbuild, Strawberry SoaS should also be very close.

> Also, is there another image besides os10.img that I should try?

I think I heard from Steve about a new image soon.

Regards,

Tomeu

-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] g.sl.o issues for Karma and perhaps other activities

[Tomeu Vizoso]

On Sat, Jan 2, 2010 at 03:50, Bryan Berry  wrote:
> On Sat, Jan 2, 2010 at 6:16 AM, Wade Brainerd  wrote:
>>
>> This sounds like the ideal conditions for Git.
>>
>> Just set up a server at your office using any Git related software you
>> want, like Gitorious or even GitWeb.  Developers set their projects up
>> on your local server, and when they reach some level of stability they
>> create public repositories on git.sugarlabs.org.
>
> I would like to set up gitorious but not sure how difficult this would be
>
>>
>> Do all your development on your local server, and every once a while
>> push the changes over to SL.
>>
>>  git push gitori...@git.sugarlabs.org:myproject/mainline.git
>>
>> If SL people want to make changes, they clone the repository on
>> git.sugarlabs.org and push to it.
>
> We will have about 60 individual repos by April and hopefully several
> hundred by the end of 2010. It will be impractical and error-prone is we
> have to create each repo twice, once on our local server and once on the SL
> server. Is there a way to automate this?

Guess you can cook a cron job quite easily, but I don't see any way
around having only one writeable instance and the others read only,
unless someone wants to take care of resolving conflicts.

Regards,

Tomeu


>
>>
>>  git push gitori...@git.sugarlabs.org:myproject/wadebs-clone.git
>>
>> The SL person lets the author know by email, and the author pulls the
>> changes to their local repository, merges them, and pushes them to
>> your internal server.
>>
>>  git pull gitori...@git.sugarlabs.org:myproject/wadebs-clone.git
>>  .. do merge work
>>  git push usern...@local-git-server:myproject.git
>>
>> Does this help at all?
>>
>> -Wade
>>
>>
>> On Thu, Dec 31, 2009 at 10:37 PM, Bryan Berry  wrote:
>> > I want to discuss some issues for managing Karma lessons on glso. Please
>> > let
>> > it be clear that I am not criticizing the infrastructure team
>> > __at_all__. I
>> > think they are doing a great job. The issues I am encountering have to
>> > do
>> > with underlying tools and some issues specific to developers working in
>> > countries w/ crappy bandwidth, such as Nepal.
>> > Some of the main goals of the Karma Project are to get more developers
>> > in
>> > general involved in creating content for Sugar and to make OLE Nepal's
>> > content development more accessible and open to developers inside and
>> > outside Nepal. We have a full-time team of 7 sw engineers, 3 graphic
>> > designers, and 3 teachers working on content. It would be a crying shame
>> > if
>> > we can't work with the larger community.
>> > One big problem for devs here in Nepal is that international bandwidth
>> > is
>> > both lousy and expensive. Conversely, w/in Kathmandu bandwidth is
>> > relatively
>> > high-speed and cheap. I have up to 2 Mbps w/in Nepal but get around 30
>> > kbps
>> > for a site hosted outside Nepal.
>> > The Karma repos are big and there will soon be many. The main Karma repo
>> > will be 10-15 MB and each individual lesson will be in its own repo,
>> > usually
>> > 2-4 MB. I hope to have about 60 individual karma activities under source
>> > control. That will be easily 200 MB. Transferring files of that size
>> > over
>> > slow international links will really cramp our development cycle. At the
>> > same time we need for the Karma lessons to be easily accessible
>> > internationally.
>> > A working solution will have to start with a server inside Nepal hosting
>> > the
>> > Karma content. OLE Nepal can likely provide the server space. Would it
>> > be
>> > possible for us to set up our own instance of gitorious? My impression
>> > is
>> > that everyone is waiting to move to the gitorious instance but something
>> > is
>> > holding it up. Even if g.sl.o migrates to
>> > gitorious.org how difficult would it be to set up an instance in Nepal.
>> > Or
>> > will it be too hard to set up a gitorious instance and we should just
>> > use
>> > something simple for Karma like cgit?
>> > So say we do set up an instance of gitorious here in Nepal. How could we
>> > make it easy for others outside Nepal to access the code and contribute
>> > back? If you are outside Nepal, downloading from a server in Nepal also
>> > sucks due to the bandwidth issue. Would it be feasible to set up a
>> > read-only
>> > mirror of Nepal's repositories on the Sugar infrastructure?
>> > I would like there to be a writable set of repositories on an
>> > international
>> > server but I can't imagine how the this mirror would sync w/ the Nepal
>> > server without lots of nasty conflicts.
>> > Sugaristas, please let me know what you think
>> > ___
>> > 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 

[Sugar-devel] Fwd: [olpc-nz] Inventing games in python

[Tomeu Vizoso]

-- Forwarded message --
From: Tabitha Roder 
Date: Wed, Dec 30, 2009 at 01:11
Subject: [olpc-nz] Inventing games in python
To: olpc-nz , OLPC Devel
, Support Gangsters 


Useful website: http://inventwithpython.com/
It was recommended by Nat Torkington so worthy of sharing the link.
It has links for downloading Python installer for multiple operating
systems as well as the book as .pdf or web page.

Tabitha

___
olpc-nz mailing list
olpc...@lists.laptop.org
http://lists.laptop.org/listinfo/olpc-nz




-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] undo stack in gtk+

[Tomeu Vizoso]

Interesting thread, given that Undo is important for our learning goals:

http://mail.gnome.org/archives/gtk-devel-list/2009-December/msg00082.html

Regards,

Tomeu

-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Sugar Development

[Tomeu Vizoso]

On Wed, Dec 30, 2009 at 06:33, James Cameron  wrote:
> On Tue, Dec 29, 2009 at 07:40:01AM -0500, Walter Bender wrote:
>> Informally, we have such a list from Peru, which is our largest Sugar
>> deployment. They use a core set of activities and have expressed the
>> desire to see that set (a) reach a level of increased stability; and
>> (b) run reliably on newer versions of Sugar [...]
>
>> Helping track down open tickets with any activities on this list
>> would be of great benefit.
>
> And a polite reminder that there are now at least three places you might
> find tickets ... sugarlabs.org, laptop.org, and launchpad.  ;-)

Not really, every distributor of Sugar has their own tracker. I would
suggest anyone wanting to help with this to focus on only one tracker.

Regards,

Tomeu

-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [Debian-olpc-devel] packaging accessibility tools

[Tomeu Vizoso]

On Tue, Dec 29, 2009 at 19:37, Sascha Silbe
 wrote:
> On Tue, Dec 29, 2009 at 06:49:31PM +0100, Tomeu Vizoso wrote:
>
>> http://slappy.cs.uiuc.edu/fall98/Linux/download.html
>
> xkbset is an alternative CLI (for the AccessX interface) and already
> packaged at least for Debian. Have they considered using that one instead?
> I've given the package you mentioned above a quick look and it's Makefile
> looks horrible from a distro maintainers POV. Besides it doesn't even
> compile anymore, i.e. needs to get patched first.

Hi Esteban, have you considered using xkbset instead?

Thanks,

Tomeu

> CU Sascha
>
> --
> http://sascha.silbe.org/
> http://www.infra-silbe.de/
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iQEcBAEBAgAGBQJLOkxjAAoJELpz82VMF3DaRlIH/jiqA9qKkOeMwhGLIdu6nIiW
> EDr7r0XwPqxs8Vt5UERh8ylPareFMQWwh+d+6doWl9lH4KgUiOHko0yQgzFJKAgK
> 1BT9/99PGksvg7aJm2nBjBARoOCg96ZFTVgXx1kPjU3+HUHUULa0amrVRVoHR8kK
> Eq7JsQOWSiGu6O8crtCFETbsSkgL/8fF7J97gjhN4a5TndPI4aiOA1QM0ZSTwUse
> tL27Ib7w72LxraskmW1pTjeAp9lvWffMRwHTwFNmZOWngmeSZPzzkrGyruwOLVow
> KkZuYm46Q/V8GkoL2NV2UMJu77BSSFeFE0UcxxQ6Ne29iOSdv8Br/SXS0thvN4s=
> =aBSD
> -END PGP SIGNATURE-
>
>



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] packaging accessibility tools

[Tomeu Vizoso]

Hi,

Uruguay is working on adding some accessibility features to Sugar and
they are using some stuff that, though old, is not properly packaged
in any distro I know of:

http://slappy.cs.uiuc.edu/fall98/Linux/download.html

Do we have any volunteers to tackle packaging in their distro of
choice? This seems like a task with specially high karma points.

Thanks,

Tomeu

-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Weekly Fedora Sugar Meetings

[Tomeu Vizoso]

On Mon, Dec 28, 2009 at 22:06, Sebastian Dziallas  wrote:
> Hi all,
>
> you've probably heard the rumor, that SoaS v3 will only ship Fedora
> packages. Now let me tell you this: It's true.
>
> What this means is that we can use a lot of help with packaging all
> kinds of crazy-awesome activities and other stuff for Fedora - which
> will get a Sugar environment with even more and better apps on its turn.
>
> So. Let's get this party started. I'm suggesting weekly meetings
> starting this Thursday, at 1500 UTC, 1000 EST [1].
>
>    Who else is in for this? Drop a note here!

Great idea, will try to attend regularly.

Regards,

Tomeu

> For those who're interested in getting started with contributing to
> Sugar, for example by packaging activities, there will be a Fedora
> Classroom session on January 6 (1500 UTC) in IRC & Gobby [2].
>
> --Sebastian
>
> [1]
> http://www.timeanddate.com/worldclock/fixedtime.html?month=12&day=31&year=2009&hour=15&min=0&sec=0&p1=0
> [2] https://fedoraproject.org/wiki/Classroom
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Accessibility - control panel

[Tomeu Vizoso]

On Mon, Dec 28, 2009 at 20:09, Martin Langhoff
 wrote:
> On Mon, Dec 28, 2009 at 7:02 PM, Esteban Arias
>  wrote:
>> In Uruguay, we have section of control panel: "Accessibility". This item
>> configurate keyboard accessibility options: mouse keys, bounce keys and
>> sticky keys.
>> We develop this on sugar 0.82 and now we begin to update this source code to
>> 0.88.
>
> Given that it is likely that you will deploy 0.84 (before 0.88), it
> might make sense to target both 0.88 and 0.84 :-)

>From what I have seen, most of this functionality should translate
very easily from 0.82 to 0.88 and in-between.

IMHO, this is an awesome feature, Ceibal has several other
accessibility features that I think Sugar must get.

Regards,

Tomeu

-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Sugar Development

[Tomeu Vizoso]

On Sat, Dec 26, 2009 at 22:50, Mark Symmonds
 wrote:
> Hello!
>
> I am a freelance developer and LAMP architect with over twelve years
> experience.  I would like to get involved in the OLPC development
> project where my skills may be of best use.  Please let me know if there
> is anything I can help with.

Wade, do we have a list of orphan activities that people could adopt?
If so, I could ask deployments which are the most important from their
points of view.

Thanks,

Tomeu

> Here are a few of my skill sets which may be beneficial in the Sugar and
> Sugar Activity development effort:
>
> Languages: Python, Ruby, C++ / C, Java, PHP, Perl
> Platforms: Linux (any dist. but primarily Fedora and Ubuntu), Free BSD,
> Windows
>
> Best regards,
> Mark Symmonds
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] Fwd: [Testing] Quick run-through of Activities that launch with build 802

[Tomeu Vizoso]

For activity authors that wish to know if their new versions still run
on 8.2.x, Mikus have given some testing to several activities:


-- Forwarded message --
From: Mikus Grinbergs 
Date: Mon, Dec 28, 2009 at 18:20
Subject: [Testing] Quick run-through of Activities that launch with build 802
To: Testing 


My attention had been on F11 for a number of months.  Had occasion to
check 8.2 again - and wanted to see which Activity versions would run.
My testing was done on build 802, using a G1G1 XO with swap partition.

Note:  I did not actually TEST these Activities - just made sure that
the Activity was initialized to the point where it drew is own screen.

The following list is by sub-directory name (without '.activity'):

> Launched and showed Activity's screen:
>
>   Abalone - 80601
>   Ajedrez - 1           malformed bundle
>   Analyze - 8
>   APRSXO - 14
>   Arithmetic - 1
>   audacity - 1          dependency on back-level library
>   Ayuda-1 - 1           screen not fit
>   BlockHead - 7
>   BlockParty - 7
>   Bounce - 7
>   Breakout - 80601
>   Bridge - 2
>   Browse - 102
>   BundleActivity - 2
>   Calculate - 30
>   CardSort - 4          keep error
>   CartoonBuilder - 6
>   cells - 2
>   Chat - 48
>   chess_computer - 10
>   Clock - 5
>   COBBLE - 3
>   ColorDeducto - 4      no color (press stop twice)
>   Colors - 15
>   Connect - 22
>   ConozcoUruguay - 8
>   Deducto - 4           yes/no truncated  (press stop twice)
>   Develop - 39          keep error
>   Distance - 18
>   Distribute - 1
>   Domino - 7            keep error
>   Doom - 1
>   DOSConsole - 3
>   DrGeoII - 148
>   EatBoom - 2
>   Ecomundo - 2
>   Elements - 1          keep error
>   EPaati - 13
>   ePals - 3
>   Etoys - 99
>   ExecCommand - 1
>   falabracman - 1
>   FiftyTwo - 2
>   Finance - 3
>   Firefox-6 - 6
>   FlipSticks - 3
>   FoodForce2 - 4
>   FreeCell - 1
>   Frotz - 3
>   Geoquiz - 4
>   GetBooks - 5
>   Gmail - 5
>   gpodder - 2
>   HablarConSara - 2
>   HelloMesh - 3
>   Help - 11
>   Helpfr - 5
>   Hop-A-Round - 2
>   idle - 2
>   ImageViewer - 8
>   Implode - 5
>   inarow - 1
>   InfoSlicer - 6
>   IRC - 5
>   iStoa.net - 150
>   JigsawPuzzle - 7
>   JokeMachine - 10
>   Jukebox - 8
>   Jump - 1
>   Kaleidoscope - 12
>   Kandid - 2
>   Karma - 2
>   Labyrinth - 8
>   LearningCenter - 4
>   LeerPendrive - 1
>   License - 4
>   Lines - 1
>   ListenAndSpell - 2
>   Log - 16
>   Mail - 1
>   Map - 7
>   MapStats - 1          keep error
>   Maze - 6
>   Measure - 29          keep error
>   Memorize - 34
>   micropolis - 8
>   Model - 8
>   Moon - 11
>   NewsReader - 24
>   OurMusic - 1          malformed bundle
>   Pacman - 2
>   Paint - 27
>   Panorama - 1
>   Physics - 3
>   Pippy - 35
>   PlayGo - 6
>   Pointillism - 2
>   Poll - 22
>   Pong - 1
>   Read - 56
>   ReadETexts - 17
>   Record - 64
>   RoadMap - 3
>   Ruler - 6             keep error
>   SarynPaint - 1        has java dependency
>   Scratch - 12
>   Screencast - 1
>   Scribble - 2
>   ShowNTell - 2
>   simcity - 5           difficulty closing
>   Skype - 1
>   SliderPuzzle - 8
>   Sliderule - 7         keep error
>   Smile - 2
>   Snow - 1
>   SocialCalcActivity - 1
>   sonata - 11
>   SpaceTag - 1          ?? - did not want to stop
>   Speak - 11
>   SpillDill - 1
>   StackAttack - 80601
>   StarChart - 5
>   StopWatch - 4
>   StoryBuilder - 15
>   sudoku - 10
>   Surf - 106            keep error;  dependency on WebKit and more
>   swordread - 2
>   TabletAreaTest - 1
>   TamTamEdit - 51
>   TamTamJam - 52
>   TamTamMini - 51
>   TamTamSynthLab - 52
>   tangram - 10
>   Terminal - 30
>   Theorie - 8
>   TurtleArt - 81        (needed keyboard input to show first screen)
>   TuxPaint - 2
>   TypingTurtle - 26
>   ucblogo - 4
>   VideoChat - 9
>   ViewSlides - 10
>   VisualMatch - 13      keep error
>   WatchMe - 2
>   Wesnoth - 1452
>   WikipediaEN - 4
>   Wine - 19
>   WirelessGraph - 7
>   Words - 4
>   Write - 60
>   X - 1
>   x2o - 9
>   XaoS - 2
>   xoEditor - 2
>   XOlympics - 1
>
>
> Did not launch properly:
>
>   -- asteroids - 1
>   -- childsplay - 1
>   -- classic - 6
>   -- iabv - 1
>   -- Kuku - 1
>   -- MaMaMediaMenu - 3
>   -- Memosono - 10
>   -- MikMik - 1
>   -- Mimic - 1           ended instead of starting
>   -- MindMap - 1
>   -- MotionCapture - 3
>   -- OurStories - 1
>   -- pydance - 2
>   -- Quiz - 3
>   -- watch-listen - 14
>   -- Xmms - 1


___
Testing mailing list
test...@lists.laptop.org
http://lists.laptop.org/listinfo/testing



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Ticket 8104

[Tomeu Vizoso]

On Wed, Dec 23, 2009 at 17:33, Cecilia Abalde
 wrote:
> Hi,
> I have a question about the patch in ticket 8104.
> to which version of networkmanager was done?

Hi Cecilia,

I'm forwarding our email to the devel mailing list at OLPC because
NetworkManager is a component that belongs to the distro, not to
Sugar. In case of doubt, you are of course welcome to ask here again.

Regards,

Tomeu

> thank you
> regards
>
> Cecilia
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [RELEASE] sugar-0.87.2

[Tomeu Vizoso]

== Source ==

http://download.sugarlabs.org/sources/sucrose/glucose/sugar/sugar-0.87.2.tar.bz2

== News ==

* Name input screen should be deactivable #1497
* Create temporary files for DS in ~/.sugar #1452
* can't connect to WEP shared key networks #1602
* intro screen doesn't unfreeze dcon #1601
* font configuration through gconf #1584
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [Marketing] Ad Design for StackOverflow

[Tomeu Vizoso]

On Mon, Dec 21, 2009 at 15:56, Sean DALY  wrote:
>
> thanks all for these suggestions
>
> I think we can include both a call for motivation (kids education) and 
> competence (python)
>
> I like the idea of Activities as an on-ramp - we certainly want to grow the 
> ASLO ecosystem
>
> my instinct would be to start with education, but may be better to define 
> target as Python devs? Maybe something like this:
>
> 
> Python Developers!
> Develop Activities for the Sugar Learning Platform
> Help children learn with your skills - over 1,000,000 served
> join.sugarlabs.org

In my experience, most people only consider helping when they realize
we are all volunteers and we are filling an important hole that nobody
wants to fill. How could we communicate that succinctly?

Regards,

Tomeu

>
> feedback?
>
> Sean
>
>
>
> On Mon, Dec 21, 2009 at 1:14 AM, John Tierney  wrote:
>>
>>
>> 
>> From: jtis4...@hotmail.com
>> To: jtis4...@hotmail.com
>> Subject: RE: [Marketing] Ad Design for StackOverflow
>> Date: Sun, 20 Dec 2009 19:11:08 -0500
>>
>> Hello All,
>>
>> >Something like "Got Python? Change the world!"? Not sure how much room
>> >we have. Also, developers are a quite heterogeneous bunch when it
>> >comes to motivation, can we target a defined profile?
>>
>> Maybe something like:
>>
>>   "Get Rockin With Python"
>> Join Sugar Labs Developing Communities!!
>>
>>
>>
>>
>>  Help Kids "Learn How to Learn"!!
>> Change The World One Child at a Time!!
>>
>> Best-
>> John Tierney
>>
>> > Date: Sun, 20 Dec 2009 19:31:46 +
>> > From: to...@sugarlabs.org
>> > To: > CC: market...@lists.sugarlabs.org; sugar-devel@lists.sugarlabs.org
>> > Subject: Re: [Marketing] Ad Design for StackOverflow
>> >
>> > On Sun, Dec 20, 2009 at 17:54, Sean DALY  wrote:
>> > > Many thanks Luke, a good catch as developers are difficult to reach
>> > >
>> > > in fact I've been thinking of placing such an ad with the Ad Bard
>> > > network after our December free run for Blueberry is done - they cycle
>> > > ads on dev-oriented sites
>> > >
>> > > Before we ask the designers to work on this, we need to decide what to 
>> > > write
>> > >
>> > > Should we seek Activity, or platform devs?
>> >
>> > Maybe first activities? Makes an easier start. Python or gtk+
>> > experience should be enough.
>> >
>> > > Tomeu, what do you think a developer would react to?
>> >
>> > Something like "Got Python? Change the world!"? Not sure how much room
>> > we have. Also, developers are a quite heterogeneous bunch when it
>> > comes to motivation, can we target a defined profile?
>> >
>> > > e.g.:
>> > > 
>> > > Nonprofit volunteer org seeks talented developers interested in
>> > > improving the lives of Sugar's second million children. Join us!
>> > > 
>> >
>> > Sounds pretty good, a reference to concrete technologies as python and
>> > gtk are may help, because developers tend to group around the
>> > technologies they use and like.
>> >
>> > Regards,
>> >
>> > Tomeu
>> >
>> > > thanks
>> > >
>> > > Sean
>> > >
>> > >
>> > > On Sat, Dec 19, 2009 at 8:44 PM, Luke Faraone  wrote:
>> > >> Hi,
>> > >>
>> > >> StackOverflow, a popular programmer Q/A site, is soliciting adverts from
>> > >> FOSS projects looking for developers.
>> > >>
>> > >> Does anybody have some spare time to whip up a 220px by 220px image?
>> > >>
>> > >> --
>> > >> Luke Faraone
>> > >> http://luke.faraone.cc
>> > >>
>> > >> ___
>> > >> Marketing mailing list
>> > >> market...@lists.sugarlabs.org
>> > >> http://lists.sugarlabs.org/listinfo/marketing
>> > >>
>> > >>
>> > > ___
>> > > Marketing mailing list
>> > > market...@lists.sugarlabs.org
>> > > http://lists.sugarlabs.org/listinfo/marketing
>> > >
>> >
>> >
>> >
>> > --
>> > «Sugar Labs is anyone who participates in improving and using Sugar.
>> > What Sugar Labs does is determined by the participants.» - David
>> > Farning
>> > ___
>> > Marketing mailing list
>> > market...@lists.sugarlabs.org
>> > http://lists.sugarlabs.org/listinfo/marketing
>>
>>
>> ___
>> Marketing mailing list
>> market...@lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/marketing
>>
>



--
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [Marketing] Ad Design for StackOverflow

[Tomeu Vizoso]

On Sun, Dec 20, 2009 at 20:37, Gary C Martin  wrote:
> Hi Tomeu,
>
> On 20 Dec 2009, at 19:31, Tomeu Vizoso wrote:
>
>> On Sun, Dec 20, 2009 at 17:54, Sean DALY  wrote:
>>> Many thanks Luke, a good catch as developers are difficult to reach
>>>
>>> in fact I've been thinking of placing such an ad with the Ad Bard
>>> network after our December free run for Blueberry is done - they cycle
>>> ads on dev-oriented sites
>>>
>>> Before we ask the designers to work on this, we need to decide what to write
>>>
>>> Should we seek Activity, or platform devs?
>>
>> Maybe first activities? Makes an easier start. Python or gtk+
>> experience should be enough.
>>
>>> Tomeu, what do you think a developer would react to?
>>
>> Something like "Got Python? Change the world!"? Not sure how much room
>> we have. Also, developers are a quite heterogeneous bunch when it
>> comes to motivation, can we target a defined profile?
>>
>>> e.g.:
>>> 
>>> Nonprofit volunteer org seeks talented developers interested in
>>> improving the lives of Sugar's second million children. Join us!
>>> 
>>
>> Sounds pretty good, a reference to concrete technologies as python and
>> gtk are may help, because developers tend to group around the
>> technologies they use and like.
>
> Just a FWIW: gtk was a pain word and kept me away from tinkering for some 
> time, "Hey Python, fab; oh hell GTK+,  not another random GUI toolkit to 
> learn."
>
> But then again, I don't really consider myself an OSS developer so am likely 
> an outlier.

Good to know, I'm not sure if OSS people hang around in StackOverflow.

Regards,

Tomeu

> Regards,
> --Gary
>
>> Regards,
>>
>> Tomeu
>>
>>> thanks
>>>
>>> Sean
>>>
>>>
>>> On Sat, Dec 19, 2009 at 8:44 PM, Luke Faraone  wrote:
>>>> Hi,
>>>>
>>>> StackOverflow, a popular programmer Q/A site, is soliciting adverts from
>>>> FOSS projects looking for developers.
>>>>
>>>> Does anybody have some spare time to whip up a 220px by 220px image?
>>>>
>>>> --
>>>> Luke Faraone
>>>> http://luke.faraone.cc
>>>>
>>>> ___
>>>> Marketing mailing list
>>>> market...@lists.sugarlabs.org
>>>> http://lists.sugarlabs.org/listinfo/marketing
>>>>
>>>>
>>> ___
>>> Marketing mailing list
>>> market...@lists.sugarlabs.org
>>> http://lists.sugarlabs.org/listinfo/marketing
>>>
>>
>>
>>
>> --
>> «Sugar Labs is anyone who participates in improving and using Sugar.
>> What Sugar Labs does is determined by the participants.» - David
>> Farning
>> ___
>> Sugar-devel mailing list
>> Sugar-devel@lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [Marketing] Ad Design for StackOverflow

[Tomeu Vizoso]

On Sun, Dec 20, 2009 at 17:54, Sean DALY  wrote:
> Many thanks Luke, a good catch as developers are difficult to reach
>
> in fact I've been thinking of placing such an ad with the Ad Bard
> network after our December free run for Blueberry is done - they cycle
> ads on dev-oriented sites
>
> Before we ask the designers to work on this, we need to decide what to write
>
> Should we seek Activity, or platform devs?

Maybe first activities? Makes an easier start. Python or gtk+
experience should be enough.

> Tomeu, what do you think a developer would react to?

Something like "Got Python? Change the world!"? Not sure how much room
we have. Also, developers are a quite heterogeneous bunch when it
comes to motivation, can we target a defined profile?

> e.g.:
> 
> Nonprofit volunteer org seeks talented developers interested in
> improving the lives of Sugar's second million children. Join us!
> 

Sounds pretty good, a reference to concrete technologies as python and
gtk are may help, because developers tend to group around the
technologies they use and like.

Regards,

Tomeu

> thanks
>
> Sean
>
>
> On Sat, Dec 19, 2009 at 8:44 PM, Luke Faraone  wrote:
>> Hi,
>>
>> StackOverflow, a popular programmer Q/A site, is soliciting adverts from
>> FOSS projects looking for developers.
>>
>> Does anybody have some spare time to whip up a 220px by 220px image?
>>
>> --
>> Luke Faraone
>> http://luke.faraone.cc
>>
>> ___
>> Marketing mailing list
>> market...@lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/marketing
>>
>>
> ___
> Marketing mailing list
> market...@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/marketing
>



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [DESIGN] what looks like an activity developer?

[Tomeu Vizoso]

Looks like this or can we find something more appropriate?

http://activities.sugarlabs.org/img/amo2009/developers/hub-addon-fox.png

Regards,

Tomeu

-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [DESIGN] Re: #1493 UNSP: Keep preferable activities

[Tomeu Vizoso]

What do people think about this?

Thanks,

Tomeu

On Tue, Oct 13, 2009 at 09:46, Sugar Labs Bugs
 wrote:
> #1493: Keep preferable activities
> --+-
>    Reporter:  alsroot                    |          Owner:  tomeu
>        Type:  enhancement                |         Status:  new
>    Priority:  Unspecified by Maintainer  |      Milestone:  0.88
>   Component:  sugar                      |        Version:  0.86.x
>    Severity:  Unspecified                |       Keywords:  r?
> Distribution:  Unspecified                |   Status_field:  Unconfirmed
> --+-
>  How it could be:
>  for activity_id less Journal objects, sugar could store chosen "Resume
>  with" activity and use it for later fast click activation
>
> --
> Ticket URL: 
> Sugar Labs 
> Sugar Labs bug tracking system
>



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [DESIGN] multiple selection in the journal

[Tomeu Vizoso]

On Sun, Dec 20, 2009 at 10:39, Tomeu Vizoso  wrote:
> Hi,
>
> often have heard from the field about the need to select multiple
> entries and delete them. Should we add a checkbox to every entry in
> the list, or allow the user to select with shift-click and ctrl-click?
> Or anything else?

This has been already discussed here, more comments welcome:

http://lists.sugarlabs.org/archive/sugar-devel/2009-November/020630.html

Thanks,

Tomeu

-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [DESIGN] multiple selection in the journal

[Tomeu Vizoso]

Hi,

often have heard from the field about the need to select multiple
entries and delete them. Should we add a checkbox to every entry in
the list, or allow the user to select with shift-click and ctrl-click?
Or anything else?

Thanks,

Tomeu

-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] Fwd: Turtleart and Arduino

[Tomeu Vizoso]

Hola,

creo que oi a alguien en esta lista comentar algo sobre arduino y olpc?

Saludos,

Tomeu


-- Forwarded message --
From: Sayamindu Dasgupta 
Date: Sat, Dec 19, 2009 at 13:00
Subject: [Sugar-devel] Turtleart and Arduino
To: Sugar devel 


Hello everyone,
Over the past few weekends, I have been working on adding Arduino[1]
support to TurtleArt, and you can get the latest code from
http://git.sugarlabs.org/projects/turtleart/repos/arduino-support
If you have an Arduino board lying around, it would be great if you
could test out the code, and let me know if something refuses to work.
Here's a screenshot: http://people.sugarlabs.org/sayamindu/ta_arduino.png
Instructions on how to set up your board, etc are at
http://git.sugarlabs.org/projects/turtleart/repos/arduino-support/blobs/master/README.arduino
Thanks,
Sayamindu


[1] http://www.arduino.cc/

--
Sayamindu Dasgupta
[http://sayamindu.randomink.org/ramblings]
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [FEATURE] Journal Backup && Restore

[Tomeu Vizoso]

On Fri, Dec 18, 2009 at 14:38, crodas  wrote:
> Hello Everybody,
>
> Last year, Daniel Drake, while he was in Paraguay, he wrote a set of
> scripts to perform backups from SugarJournal to Schoolserver and a restore
> script. Everybody can see it:
>
> + http://trac.paraguayeduca.org/browser/scripts/os-modifications
> (diario-*)
> +
> http://trac.paraguayeduca.org/browser/scripts/os-modifications/olpc-session-restore-journal.patch
>
> We have tested creating a backup on XO-1, OS8.2 and restoring the backup
> in the same machine after an OS upgrade (to OS10), and worked perfectly
> fine. That's very good for an automatic OS upgrade.
>
> So, we have questions to the folk:
>
> 1. Is there any similar to this and standar on Sugar?
> 2. If no, Wouldn't be great if we add those scripts to Sugar?
> 3. In any case, I think will be great if we add a new section on the
> Control Panel, to manually force the backup and restore.
>
> Any thoughts?

Right now backup support lives outside sugar:

http://dev.laptop.org/git/users/martin/ds-backup.git/

But I agree with integrating it into sugar or datastore.

Regards,

Tomeu

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



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [DESIGN][FEATURE] 3G modem support

[Tomeu Vizoso]

On Fri, Dec 11, 2009 at 19:36,   wrote:
> It has been discussed before and i have been working on it with Daniel
> Castelo from Uruguay.
>
> This is the link of the formal proposal, I will be updating it soon.
>
> http://wiki.sugarlabs.org/go/Features/3G_Support

I support this feature, has a clear value for our users and the
proposal is solid.

Regards,

Tomeu

-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Technique to extract all records from xapian DB?

[Tomeu Vizoso]

On Wed, Dec 16, 2009 at 20:21, Martin Langhoff
 wrote:
> On Wed, Dec 16, 2009 at 9:46 PM, Tomeu Vizoso  wrote:
>> On Wed, Dec 16, 2009 at 17:48, Martin Langhoff
>>  wrote:
>>> On Fri, Dec 11, 2009 at 2:35 PM, Tomeu Vizoso  wrote:
>>> Yeah. It's a very complex beast that, after following the callstack
>>> hither and yon, only makes a v simple mapping. I've written a 20 line
>>> mini-reader class using xapian directly. Instead of following the DS
>>> code, I used the CLI tools that xapian includes, and it is a trivial
>>> thing. Needs a bit more time but it'll work.
>>
>> Sounds good, if you need later to move to python, we can do something
>> easily if we know the prefixes for each field.
>
> The code is all python using the xapian bindings. I used the CLI tools
> to figure out the data layout...  because I hadn't spotted the mapping
> array you've just given me :-)
>
>> I think it should be stable for the fields we care about, which is a fixed 
>> set:
>>
>> http://git.sugarlabs.org/projects/sugar-datastore/repos/mainline/blobs/sucrose-0.82/src/olpc/datastore/model.py#line379
>
> Will use that and stop guessing. They still have odd prefixes which I
> have to strip out, some do, some don't... the whole thing is rather
> strange. I don't know if I want to know the hysterical raisins behind
> it...

In case you change your mind... ;)

http://xapian.org/docs/quartzdesign.html

Regards,

Tomeu

-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Technique to extract all records from xapian DB?

[Tomeu Vizoso]

On Wed, Dec 16, 2009 at 17:48, Martin Langhoff
 wrote:
> On Fri, Dec 11, 2009 at 2:35 PM, Tomeu Vizoso  wrote:
>> I think it's worth trying, but not sure if worth merging and
>> deploying. 0.82 didn't used directly the python xapian bindings, but
>> some wrapper on top of it that tried to make easier the mapping
>> between keys in the B-tree and metadata values.
>
> Yeah. It's a very complex beast that, after following the callstack
> hither and yon, only makes a v simple mapping. I've written a 20 line
> mini-reader class using xapian directly. Instead of following the DS
> code, I used the CLI tools that xapian includes, and it is a trivial
> thing. Needs a bit more time but it'll work.

Sounds good, if you need later to move to python, we can do something
easily if we know the prefixes for each field.

>> The mapping mentioned before is persisted in index/config inside the DS dir.
>
> Ah, it's not static? The number-field mapping It seems stable to me
> testing it. So the right way is to read that 'config', how do you
> parse it?

I think it should be stable for the fields we care about, which is a fixed set:

http://git.sugarlabs.org/projects/sugar-datastore/repos/mainline/blobs/sucrose-0.82/src/olpc/datastore/model.py#line379

Regards,

Tomeu

> Good that I asked.
>
>
>
> m
> --
>  martin.langh...@gmail.com
>  mar...@laptop.org -- School Server Architect
>  - ask interesting questions
>  - don't get distracted with shiny stuff  - working code first
>  - http://wiki.laptop.org/go/User:Martinlanghoff
>



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Glucose and Frame

[Tomeu Vizoso]

On Tue, Dec 15, 2009 at 16:58, Cilyan Olowen  wrote:
> Thanks for the reply, here is the log and indeed, it seems there is a
> problem with the presence service.
>
> http://pastebin.com/mdac6658

Ok, and what says sugar-presence-service?

Regards,

Tomeu

> 2009/12/15 Tomeu Vizoso :
>> On Tue, Dec 15, 2009 at 16:39, Cilyan Olowen  wrote:
>>> Hello !
>>>
>>> I'm all new in the Sugar community, but I'm very interested in Sugar's
>>> very simple and intuitive interface for my grand parents who are
>>> completely new to computers. As I need a light and very strong system,
>>> I decided to base this on a distrib I know very well : ArchLinux. I
>>> met here another Archer who has almost the same needs and same
>>> interests, and together we decided to package Sugar for ArchLinux.
>>> That's for the background.
>>>
>>> Now the project has a little bit progressed, and I'm ending with
>>> Glucose almost packaged :
>>> hippo-canvas, hulahop, python-xklavier, squeak, sugar, sugar-artwork,
>>> sugar-base, sugar-datastore, sugar-presence-service, sugar-toolkit
>>> (I'm missing etoys and pyabiword). All this is now installed on my
>>> system and I wanted to make a little check of where I was. And
>>> surprise, after launching "sugar" in a console, no Frame ! Metacity is
>>> launched, together with a nice big cursor, but no Frame or Activity
>>> Circle. Same with "sugar-emulator" which opens a nice Xephyr window
>>> with a black screen and the famous cursor inside, but nothing more.
>>> And indeed it seems that the sugar script ends with no error or maybe
>>> forks to the background but I have no trace of it in "ps".
>>>
>>> This leads to the simple question : Do I have a misconfiguration here,
>>> a bug, or am I simply missing a packet ?
>>>
>>> Woo, such a long message for a simple question, yes I know, sorry. But
>>> I needed to introduce myself too to your community ;)
>>
>> Hi Cilyan, welcome.
>>
>> Can you attach ~/.sugar/default/logs/shell.log? There should be some error.
>>
>> Thanks,
>>
>> Tomeu
>>
>>> Regards,
>>>
>>> Cilyan
>>> ___
>>> Sugar-devel mailing list
>>> Sugar-devel@lists.sugarlabs.org
>>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>>
>>
>>
>>
>> --
>> «Sugar Labs is anyone who participates in improving and using Sugar.
>> What Sugar Labs does is determined by the participants.» - David
>> Farning
>>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Glucose and Frame

[Tomeu Vizoso]

On Tue, Dec 15, 2009 at 16:39, Cilyan Olowen  wrote:
> Hello !
>
> I'm all new in the Sugar community, but I'm very interested in Sugar's
> very simple and intuitive interface for my grand parents who are
> completely new to computers. As I need a light and very strong system,
> I decided to base this on a distrib I know very well : ArchLinux. I
> met here another Archer who has almost the same needs and same
> interests, and together we decided to package Sugar for ArchLinux.
> That's for the background.
>
> Now the project has a little bit progressed, and I'm ending with
> Glucose almost packaged :
> hippo-canvas, hulahop, python-xklavier, squeak, sugar, sugar-artwork,
> sugar-base, sugar-datastore, sugar-presence-service, sugar-toolkit
> (I'm missing etoys and pyabiword). All this is now installed on my
> system and I wanted to make a little check of where I was. And
> surprise, after launching "sugar" in a console, no Frame ! Metacity is
> launched, together with a nice big cursor, but no Frame or Activity
> Circle. Same with "sugar-emulator" which opens a nice Xephyr window
> with a black screen and the famous cursor inside, but nothing more.
> And indeed it seems that the sugar script ends with no error or maybe
> forks to the background but I have no trace of it in "ps".
>
> This leads to the simple question : Do I have a misconfiguration here,
> a bug, or am I simply missing a packet ?
>
> Woo, such a long message for a simple question, yes I know, sorry. But
> I needed to introduce myself too to your community ;)

Hi Cilyan, welcome.

Can you attach ~/.sugar/default/logs/shell.log? There should be some error.

Thanks,

Tomeu

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



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [FEATURE] TableView Widget request for inclusion to 0.88

[Tomeu Vizoso]

On Tue, Dec 15, 2009 at 16:33, Aleksey Lim  wrote:
> On Tue, Dec 15, 2009 at 03:28:23PM -0200, Tomeu Vizoso wrote:
>> On Sun, Dec 6, 2009 at 14:53, Aleksey Lim  wrote:
>> > On Sun, Dec 06, 2009 at 02:37:07PM +0100, Simon Schampijer wrote:
>> >> On 11/28/2009 05:00 AM, Aleksey Lim wrote:
>> >> > Hi all,
>> >>
>> >> Hi Aleksey,
>> >>
>> >> thanks for proposing this feature!
>> >>
>> >> > http://wiki.sugarlabs.org/go/Features/TableView_Widget
>> >> >
>> >> > GTK widget to replace gtk.TreeView in Journal.
>> >> >
>> >> > Benefit to Sugar
>> >> >
>> >> > Standard gtk components are not designed to be lazy. Third party
>> >> > widgets, I managed to find, uses scheme with renders(like gtk
>> >> > components), introduced component uses widgets instead(could have
>> >> > performance penalties, I guess, in common case but we don't have many
>> >> > rows in Journal view, so should be ok for us).
>> >>
>> >> Can you elaborate on this? Instead of using the cell renderers to draw
>> >> the data in the tree model we would pack widgets?
>> >
>> > we should just implement Cell class(regular wigdet) and it will be used
>> > for all(visible) cells, see example
>> > http://wiki.sugarlabs.org/go/Features/TableView_Widget#Simple_example_for_SmootTable_widget
>>
>> The API looks very good to me, just one thing: what means 3, 3 here?
>>
>> table = SmoothTable(Cell, 3, 3)
>
> visible_row_count and visible_column_count

Oh, thought the SmoothTable would be able to know which is the visual area?

Regards,

Tomeu

-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [SoaS] Sharing work between XOs/SOAS devices

[Tomeu Vizoso]

On Tue, Dec 15, 2009 at 15:36, Walter Bender  wrote:
> Sugar 0.86 has sharing built into the Journal. But that doesn't help
> you (yet) on your XO machines :(

Paraguay is coming to the rescue :)

http://lists.laptop.org/pipermail/devel/2009-December/026947.html

Regards,

Tomeu

> -walter
>
> On Tue, Dec 15, 2009 at 12:30 PM, Gerald Ardito  
> wrote:
>> Hello all.
>>
>> As our 5th graders are doing more and more work with their XOs, their being
>> able to turn in and share their work products (as opposed to collaborating
>> with others) is becoming more and more important.
>>
>> My temporary solution is having them upload their work (along with
>> reflections, if desired) to Moodle, which I can do because we have an XS
>> implementation. However, this means that if a student has created a Memorize
>> vocabulary game that s/he want to share s/he has to:
>> 1. Create the game.
>> 2. Save it to the Journal
>> 3. Go to Browse
>> 4. Navigate to Moodle
>> 5. Find the right course/right assignment within the course
>> 6. Upload game.
>>
>> S/he pretty much has to do the same thing to download and then play other
>> games. This is certainly workable, but dramatically slows down the momentum
>> of creating games and wanting others to play them.
>>
>> So, I am asking to create/offering to help create an Activity that allows
>> users to share work products easily. I know that Bert was working on
>> something called Distribute, which may be a starting place. It seems to
>> share Journal objects, which seems right.
>>
>> I am happy to work with developers on this. I could create requirements, if
>> need be. Just say the word.
>>
>> I look forward to what comes next.
>>
>> Thanks and best,
>> Gerald
>>
>
>
>
> --
> Walter Bender
> Sugar Labs
> http://www.sugarlabs.org
> ___
> SoaS mailing list
> s...@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/soas
>



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [FEATURE] TableView Widget request for inclusion to 0.88

[Tomeu Vizoso]

On Sun, Dec 6, 2009 at 14:53, Aleksey Lim  wrote:
> On Sun, Dec 06, 2009 at 02:37:07PM +0100, Simon Schampijer wrote:
>> On 11/28/2009 05:00 AM, Aleksey Lim wrote:
>> > Hi all,
>>
>> Hi Aleksey,
>>
>> thanks for proposing this feature!
>>
>> > http://wiki.sugarlabs.org/go/Features/TableView_Widget
>> >
>> > GTK widget to replace gtk.TreeView in Journal.
>> >
>> > Benefit to Sugar
>> >
>> > Standard gtk components are not designed to be lazy. Third party
>> > widgets, I managed to find, uses scheme with renders(like gtk
>> > components), introduced component uses widgets instead(could have
>> > performance penalties, I guess, in common case but we don't have many
>> > rows in Journal view, so should be ok for us).
>>
>> Can you elaborate on this? Instead of using the cell renderers to draw
>> the data in the tree model we would pack widgets?
>
> we should just implement Cell class(regular wigdet) and it will be used
> for all(visible) cells, see example
> http://wiki.sugarlabs.org/go/Features/TableView_Widget#Simple_example_for_SmootTable_widget

The API looks very good to me, just one thing: what means 3, 3 here?

table = SmoothTable(Cell, 3, 3)

>> > Benefits we have for such scheme:
>>
>> Can you describe the benefit for a user? Faster scrolling?
>
> I meant here only developers,
> for users it could have only disadvantages :) if we have many visible
> cells at the same time, but in our case it should be ok, I tested
> thumbs view on XO-1 and didn't see lags

I don't think the overhead of using widgets instead of renderers will
be noticeable given that we render svg icons there.

>> > * coding cells is more useful by using widgets then renders, we can
>> >    reuse our existed custom widgets instead of coding sugarized cell
>> >    renders
>> > * in some cases its hard to sugarize cells theme(we still have
>> >    ugly progress bar for Journal entries), with new widget, we
>> >    use just gtk.ProgressBar
>>
>> Don't we use the gtk.ProgressBar already?
>
> not for TreeView, it uses progress render
>
>> Or do you mean it would just
>> look better?
>
> Our cells will look like other widgets(since cells are the same widgets)
> and we won't have to sugarize renders' theme(e.g. in exsited code, we
> have not fully sugarized pregress renders)
>
>> > There is an ongoing discussion in gnome community about replacing
>> > GtkTreeView, not sure if new widget is ready to use for 0.88 and since
>> > Journal's view widget is pretty simple we can use our own
>> > simple implementation(360 lines of code).
>>
>> Do you have pointers to the GNOME discussion? I found that snippet from
>> someone having the same problem:
>> http://www.mail-archive.com/gtk-app-devel-l...@gnome.org/msg12127.html
>
> Better to ask tomeu, I heard about GNOME discussion from him
> I guess better for us will be switching to GNOME implementation when
> it's ready(for now we can use as simple as possible lazy view implementation
> and imho proposed widgets meet that)

For example this: http://pvanhoof.be/blog/index.php/2009/08/24/as-it-should-be

The GNOME Activity Journal people are also looking for something lik
this but I don't know of any public discussion.

Regards,

Tomeu

>> Do you have written some code already?
>
> The model less widget is fully implemented,
> in case of model, current code has TableView class which uses gtk.TreeModel.
> Exact model scheme will depend on what we will use in Journal
>
> --
> Aleksey
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [FEATURE] [DESIGN] for Journal Plugins feature

[Tomeu Vizoso]

On Tue, Dec 8, 2009 at 07:05, Simon Schampijer  wrote:
> On 12/07/2009 01:09 PM, Aleksey Lim wrote:
>>
>> On Mon, Dec 07, 2009 at 10:57:01AM +0100, Simon Schampijer wrote:
>>>
>>> On 12/07/2009 05:58 AM, Aleksey Lim wrote:
>>>>
>>>> On Sun, Dec 06, 2009 at 11:56:09PM +, Gary C Martin wrote:
>>>>>
>>>>> On 6 Dec 2009, at 21:19, Tomeu Vizoso wrote:
>>>>>
>>>>>> 2009/11/27 Aleksey Lim:
>>>>>>>
>>>>>>> On Fri, Nov 27, 2009 at 06:13:55AM +, Aleksey Lim wrote:
>>>>>>>>
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> Want to know what people think about Journal Plugins feature[1]
>>>>>>>> and particularly that design team think about UI changes[2] involved
>>>>>>>> in this feature.
>>>>>>>>
>>>>>>>> [1] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#
>>>>>>>> [2] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#UI_changes
>>>>>>>
>>>>>>> I tweaked "Benefit to Sugar" section a bit
>>>>>>>
>>>>>>> * browsing different types of sugar object looks the same in many
>>>>>>> cases (search, tagging etc.). So, keep unified code base and do not 
>>>>>>> split it
>>>>>>> could be useful idea.
>>>>>>> * for now, some activities have similar functionality(browsing
>>>>>>> Journal entries), so having plugins, we will use the same theme for 
>>>>>>> browsing
>>>>>>> features in sugar
>>>>>>> * encourage developers create new view for different purposes(books,
>>>>>>> media etc.)
>>>>>>> * having plugins we don't stick to sugar releases, deployers could
>>>>>>> create/change plugins that support not only last sugar but version 
>>>>>>> which is
>>>>>>> in deployment
>>>>>>> * having bookmarks, users can have fast access to his
>>>>>>> books/media-files/etc in the Journal(and using proper view plugin to 
>>>>>>> browse
>>>>>>> them)
>>>>>>> * shared bookmarks is more powerful and useful method of network
>>>>>>> sharing(in comparing with "Send to" option)
>>>>>>
>>>>>> Can anyway relate these benefits from actual requests from
>>>>>> deployments?
>>>>>>
>>>>>> I think this is something that would be good to do in Sugar at some
>>>>>> point, but I'm not convinced we are yet in the best moment for that.
>>>>>
>>>>>
>>>>> I can't see us finding the right solution for the whole action/object
>>>>> view concept/requirements in the next few months. The Journal_Plugins idea
>>>>> seem rather scary to me at the moment, and has a very broad effect that
>>>>> would need much design work (security, UI confusion, documentation 
>>>>> issues).
>>>>> Now I admit I was hoping we had another shot at including the thumbnail 
>>>>> view
>>>>> for 0.88 (thumbnails would seem to be a genuine improvement for
>>>>> finding/browsing many Journal entry types, and likely the default view for
>>>>> kids)... Perhaps just adding the thumbnail image (if available) to the
>>>>> Journal hover palette could be a low risk improvement we could agree on? 
>>>>> The
>>>>> design intent seems to go way back in Sugar history, so lightly has plenty
>>>>> of supporters.
>>>>
>>>> The core idea of plugins is exactly to avoid situation when we have to
>>>> release fat UI change set, plugins let us decentralize existed scheme
>>>> when entirely sugar design(not only UI) depends on what core team
>>>> thinks. We just provide usable toolset developers cold use to implement
>>>> what they think.
>>>>
>>>> [1] proposes UI changes in [2] but plugins API could be implemented w/o
>>>> any UI changes at all - user will see the same Journal(but it will be
>>>> Journal plugin). The idea is let developers make plugin out of sucrose
>>>> release cycle, yeah developers could do it in pure activities(but see
>>>> 

Re: [Sugar-devel] [IAEP] Future of Zero Sugar

[Tomeu Vizoso]

On Tue, Dec 15, 2009 at 12:19, Bert Freudenberg  wrote:
> On 15.12.2009, at 15:09, Daniel Drake wrote:
>>
>> I believe there are still various well-known 0.86 regressions (over
>> 0.84). For example, Record not working. These regressions are going to
>> be a huge headache to anyone who tries to upgrade, perhaps you could
>> squash a few of those.
>
> Speaking of upgrade headaches, the most significant UI change in 0.84 is 
> resume-by-default, which combined with the still not implemented versioning 
> is possibly unhealthy in deployments. I can see many Journal entries 
> overwritten for good. Has there been any experience with kids used to the 
> 0.82 way who switched to a later Sugar version? And if needed, would it be 
> easy for deployments to revert to not resuming by default?

Good point, reverting would be easy and also adding a setting to
switch it on or off. I can work on it if someone takes the task of
verifying the need.

Regards,

Tomeu


-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [FEATURE] [DESIGN] Frame Panels

[Tomeu Vizoso]

On Mon, Dec 14, 2009 at 17:40, Wade Brainerd  wrote:
> +1 overall.
>
> The one thing that jumps out to me here is the idea that I could
> download frame components from ASLO, like a Clock or a Calendar.  That
> sounds fantastic.

Yes, but what about security? Right now the shell process only
executes code in /usr, executing activities in a separate process.

A possible approach would be to run extensions out-of-process and have
D-Bus APIs, but the memory usage would be pretty high...

> I also like  that activities such as Chat could install frame
> components, and have a proper notification system.

XOIrc emits a notification when a direct message is received, maybe
Chat needs the same? It has been already mentioned that the
notification alert doesn't call the attention enough.

http://www.galago-project.org/specs/notification/0.9/index.html

> A great addition to this feature would be to actually implement the
> freedesktop.org panel protocol, which would help Sugar run  native
> software like pidgin or claws-mail or skype (or nm-panel!).

Looks like GNOME 3 is going to drop those? There's the impression from
desktop developers that the application developers abused that
mechanism.

Regards,

Tomeu

> Regarding extensibility, we would have to clearly define the "roles"
> of the different sides of the screen.  IE the top is for task and view
> switching, the bottom is for information and devices, the left is for
> MIME objects, the right is for collaboration.  Rather than adding a
> panel to top/left/right/bottom, a panel should be added by role.
>
> I agree that all four sides should be independently "stickable".  Also
> would be nice if they could come out separately when the screen edge
> is hovered.
>
> -Wade
>
> On Mon, Dec 14, 2009 at 1:53 PM, Aleksey Lim  wrote:
>> On Mon, Dec 14, 2009 at 01:34:38PM -0500, Eben Eliason wrote:
>>> On Sun, Dec 13, 2009 at 12:42 AM, Aleksey Lim  
>>> wrote:
>>> > Hi all,
>>> >
>>> > At the end Journal Plugins mutated to Frame Panles feature.
>>> > All UI visible changes I wanted to implement in plugins could be done
>>> > via Frame Panle components(the rest of code are shell agnostic).
>>> >
>>> > Frame Panles feature has the same major idea, social context - giving
>>> > non core developers more freedom in case of releasing/supporting theirs
>>> > code, e.g. adding GSM modem support could be implemented not in
>>> > core(thus stuck to sugar version, when previous sugar version users
>>> > can't grab last changes of GSM modem component) but as a standalone
>>> > activity(and deployed as a regular activity).
>>>
>>> Is this an extension of the "device" concept already present? The idea
>>> there was to allow anyone to create devices (in the bottom edge of the
>>> frame) that added extended features (such as text-to-speech,
>>> additional hardware support, dictionaries, etc.). Having a way to
>>> separate these from the core of Sugar, and even add or remove them at
>>> will, would be nice.
>>
>> it was more common proposal, ala GNOME panels
>>
>>>
>>> > == Summary ==
>>> >
>>> > Treat frame as a containers(upper, left, right and bottom) for
>>> > predefined or custom components i.e. having GNOME panels analog in
>>> > sugar.
>>>
>>> I'm a bit confused by this. The panels, clockwise from top, are for
>>> activities, people, devices, and objects (clipboard). Only the bottom
>>> edge is currently thought of as a place for extension. Are you
>>> proposing that all of these would be extensible?
>>
>> yup, e.g. could move any predefined components to panel he wants..
>> i.e. like GNOME panle components
>>
>>> > == Detailed Description ==
>>> >
>>> > The major reason is to let activities like FileShare or Chat special UI
>>> > representation in shell's interface. It could be also useful if user
>>> > wants fast access to some activities like Journal replacements.
>>>
>>> I would raise some caution here. The Frame was specifically designed
>>> as a place for "active" elements to live, and is specifically not a
>>> "launcher." As such, any running activities, current friends,
>>> available devices, etc. appear there. Your description of "fast
>>> access" makes it sound more like a launcher and less like a place of
>>> status.
>>
>> my intention was to have panel components ala GNOME panel launchers(or even
>> menus)
>>
>>> > Any of four panels could be stuck i.e. let user see its components all
>>> > time.
>>>
>>> This is an interesting idea.
>>
>> yup, I'm also strongly for such feature, despite of accepting panels
>> feature
>>
>>> We played with similar concepts early on,
>>> but decided at the time that the Frame as more comprehensible as a
>>> single unit that could be shown and hidden at will. If we break that
>>> paradigm, how do we handle the overlap that a persistent frame edge
>>> would cause? Does the activity window move/shrink in these instances?
>>
>> yup, activity windows should be shrunk e.g. like application in GNOME
>> have less free space for maximization afte

Re: [Sugar-devel] [IAEP] Future of Zero Sugar

[Tomeu Vizoso]

On Tue, Dec 15, 2009 at 04:07, Aleksey Lim  wrote:
> On Tue, Dec 15, 2009 at 10:16:02AM +0545, Bryan Berry wrote:
>> I strongly agree w/ tomeu on this.
>>
>> Making Sugar easier to contribute to isn't anywhere near the top of the list
>> of requested features by our kids and teachers in Nepal.
>>
>> The far and away most requested feature by teachers in Nepal is a mechanism
>> for kids to "turn in homework." I am not talking about invasive testing
>> here. The typical Nepali teacher just wants to know which students out of
>> 50-70 kids are failing to understand basic concepts.
>
> I absolutely agree with such points, but:
>
> * as a 3rd party developer, I don't see such teachers requests listed
>  somewhere on wiki, that let me see what can I do and peek most
>  interesting/suitable-for-my-skils/etc task

I'm painfully aware of this situation and have been spending my
energies on this problem for already a good while. Our colleagues at
Uruguay and Paraguay are already working on upstreaming their
developments, but are also going to work with us in identifying the
most pressing needs in deployments. Have already some ideas about what
to work on, how do you think we should track them?

> * I'm feeling huge discomfort as a developer when I need to package
>  binary blobs to my .xo, w/o instrument which let me unify
>  installing/upgrading process of such non-SP/specific-to-my-activity
>  dependencies

I agree this is a problem, but also think that many activities
shipping binaries don't actually need them. Bindings for libraries can
be written in ctypes, without need to use a .so.

> * I'm feeling less(but still big) discomfort as a developer when I
>  don't have standard method to share my core related changes,
>  for-testing-purposes/to-show-what-I-have-in-mind, well "please, attach
>  my cloned repos, install them" still works but not so attractive for
>  users

What about generating a SoaS (or Trisquel, etc) image with such
changes? This is something that can be done today without so much
trouble.

> * implementing Zero Sugar initiative, in my mind, is providing
>  "fishing-rod" for developers/doers instead of "feeding" users
>  thus has prime priority

I don't see things so black and white. I have been working on this
same problem for a while now (view source key, extensions, etc) and
our users are taking advantage of at least the extensions facility. We
are going to see patches very soon for keybindings, device icons and
control panel sections. And that code can be already deployed without
waiting for upstreaming because of the extensions mechanism.

So _today_ we have empowered users that are deploying shell extensions
without disrupting the rest of the shell, and simultaneously are
working with the community and sharing the fruit of their work.

The technical part has been in place since a year ago, but the trigger
for this to happen has been actually social interaction. There's no
point in making our platform super-hackable if we don't work as well
in the non-technical part of the problem.

Regards,

Tomeu

>> On Tue, Dec 15, 2009 at 12:04 AM, Tomeu Vizoso  wrote:
>>
>> > On Mon, Dec 14, 2009 at 11:25, Benjamin M. Schwartz
>> >  wrote:
>> > > Aleksey Lim wrote:
>> > >> So, I have
>> > >> strong intension to switching development focus from core team,
>> > >> which develops sucrose - glucose(core) and fructose(some core
>> > >> activities) to wide range of developers/doers thus some kind of
>> > >> decentralization of development process.
>> > >
>> > > I agree. I think this has been a central part of the Sugar design
>> > > philosophy from the beginning.  I think your message is very much on the
>> > > right track.
>> >
>> > While I think this is in the spirit of my vision for Sugar, my
>> > experience with how Sugar is being used and deployed _today_ makes it
>> > quite uninteresting and too invasive to consider for the near future.
>> >
>> > The current barriers for people to contribute to Sugar development and
>> > share their work are mostly cultural. We can make the technology a
>> > thousand times easier to modify, but if people still think that they
>> > can be only users, we won't gain anything.
>> >
>> > If we really want more people to realize their power and modify sugar
>> > and share their work, we need to, in order:
>> >
>> > - show how the community can address some of their needs, as perceived by
>> > them,
>> >
>> > - show how they can better address the rest of t

Re: [Sugar-devel] moving some more configuration to gconf (was Re: some efforts that would be really useful for deployments)

[Tomeu Vizoso]

On Tue, Dec 8, 2009 at 06:56, Simon Schampijer  wrote:
> On 12/07/2009 11:39 AM, Mathieu Bridon (bochecha) wrote:
>> On Mon, Dec 7, 2009 at 10:11, Simon Schampijer  wrote:
>>> Yes, I think it makes sense to control settings via gconf - this should
>>> be our standard way.
>>
>> Isn't Gnome thinking about dropping GConf ? (in favor of DCconf as far
>> as I understood)
>>
>> I'd be worried about using a technology that upstream is not certain
>> to go on maintaining :-/
>
> In general I agree. Though, the discussion with moving away from gconf
> has been for a while. It has been now scheduled for 3.0 it looks like.
>
> http://mail.gnome.org/archives/devel-announce-list/2009-November/msg2.html
>
> + dconf (desktop)
>    - agreement it's the way forward
>    - concerns about migration of settings
>    - concerns about the lack of planning for admin tools (pessulus and
>      sabayon)
>    - concerns about the fact that we need stuff in glib but that's not
>      there yet (although we know there's a plan for this)
>    - a massive migration from gconf to dconf would be preferrable
>      (instead of having some modules using gconf and some other modules
>      using dconf). We know it might not be realistic, though.
>    => rejected for this cycle, but pre-approved for the next cycle
>       (assuming glib gets the required API for the next cycle). The
>       additional time should be used for careful planning of the above
>       items.
>    => we encourage developers to look at it and to create gsettings
>       branches for their modules (like devhelp and gedit).
>
> Maybe someone wants to evaluate the current status of dconf, work out
> the pros and cons and present a summary here?

I'm following those discussions and I don't think it's time yet for
any project do ditch gconf for dconf. And when the time comes, it will
be such a minor modification that is not worth our discussion time.

Regards,

Tomeu

-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [IAEP] Future of Zero Sugar

[Tomeu Vizoso]

On Mon, Dec 14, 2009 at 17:01, Aleksey Lim  wrote:
> On Mon, Dec 14, 2009 at 04:19:51PM -0200, Tomeu Vizoso wrote:
>> On Mon, Dec 14, 2009 at 11:25, Benjamin M. Schwartz
>>  wrote:
>> > Aleksey Lim wrote:
>> >> So, I have
>> >> strong intension to switching development focus from core team,
>> >> which develops sucrose - glucose(core) and fructose(some core
>> >> activities) to wide range of developers/doers thus some kind of
>> >> decentralization of development process.
>> >
>> > I agree. I think this has been a central part of the Sugar design
>> > philosophy from the beginning.  I think your message is very much on the
>> > right track.
>>
>> While I think this is in the spirit of my vision for Sugar, my
>> experience with how Sugar is being used and deployed _today_ makes it
>> quite uninteresting and too invasive to consider for the near future.
>>
>> The current barriers for people to contribute to Sugar development and
>> share their work are mostly cultural. We can make the technology a
>> thousand times easier to modify, but if people still think that they
>> can be only users, we won't gain anything.
>>
>> If we really want more people to realize their power and modify sugar
>> and share their work, we need to, in order:
>>
>> - show how the community can address some of their needs, as perceived by 
>> them,
>>
>> - show how they can better address the rest of their needs by working
>> within the community.
>>
>> The rest is just icing on the top, IMHO.
>
> well, thats all true but it doesn't exclude easy to change and easy to
> share possibility of doer's changes e.g. if I want to hack Journal by
> adding wallpaper support(and of course want to expose my changes) the
> worst way that could be is proposing my changes to core team(e.g. think
> about proposing your patches to kernel.org team - maybe exaggerating but
> the same level issue). Having ready to use sugarized 0install
> environment gives developers easy sharing method.

As I said, I agree with your points of view and also agree something
should be done in the path you show. But I also think that presently,
what would bring more users and deployers on board, is by caring of
their more immediate needs.

Regards,

Tomeu

-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [IAEP] Future of Zero Sugar

[Tomeu Vizoso]

On Mon, Dec 14, 2009 at 11:25, Benjamin M. Schwartz
 wrote:
> Aleksey Lim wrote:
>> So, I have
>> strong intension to switching development focus from core team,
>> which develops sucrose - glucose(core) and fructose(some core
>> activities) to wide range of developers/doers thus some kind of
>> decentralization of development process.
>
> I agree. I think this has been a central part of the Sugar design
> philosophy from the beginning.  I think your message is very much on the
> right track.

While I think this is in the spirit of my vision for Sugar, my
experience with how Sugar is being used and deployed _today_ makes it
quite uninteresting and too invasive to consider for the near future.

The current barriers for people to contribute to Sugar development and
share their work are mostly cultural. We can make the technology a
thousand times easier to modify, but if people still think that they
can be only users, we won't gain anything.

If we really want more people to realize their power and modify sugar
and share their work, we need to, in order:

- show how the community can address some of their needs, as perceived by them,

- show how they can better address the rest of their needs by working
within the community.

The rest is just icing on the top, IMHO.

Regards,

Tomeu

> [snip]
>>   * I hope to see many shell forks with implemented features like new
>>     sugar themes(wallpapers support, new icons etc.), Actions view
>>     implementations from non-core development/doers. The benefit they
>>     will have after 0install integration is more useful method to share
>>     these forks - just a regular entity on Activity Library that brings
>>     new shell to user environment
>
> I don't think this part will work as "a regular entity on Activity
> Library", for security reasons.  Any "Activity" that hooks so deeply into
> the shell is no longer safe to run.  It is running with the full authority
> of the user and can violate the user's privacy or interfere with the
> user's actions.  In orders to encourage users to become doers, Sugar is
> designed to make sure that Activities are always safe to run (thanks to
> Bitfrost/Rainbow protections).
>
> I would of course support an effort to "wall off" parts of the shell in a
> secure fashion, but so far almost no work has been done in that direction.
>
> --Ben
>
>
> ___
> IAEP -- It's An Education Project (not a laptop project!)
> i...@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/iaep
>



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [FEATURE] [DESIGN] Frame Panels

[Tomeu Vizoso]

On Sun, Dec 13, 2009 at 03:42, Aleksey Lim  wrote:
> Hi all,
>
> At the end Journal Plugins mutated to Frame Panles feature.
> All UI visible changes I wanted to implement in plugins could be done
> via Frame Panle components(the rest of code are shell agnostic).

I'm having trouble guessing which needs addresses this change. Does
this idea come from any need expressed by our users?

Thanks,

Tomeu

> Frame Panles feature has the same major idea, social context - giving
> non core developers more freedom in case of releasing/supporting theirs
> code, e.g. adding GSM modem support could be implemented not in
> core(thus stuck to sugar version, when previous sugar version users
> can't grab last changes of GSM modem component) but as a standalone
> activity(and deployed as a regular activity).
>
> == Summary ==
>
> Treat frame as a containers(upper, left, right and bottom) for
> predefined or custom components i.e. having GNOME panels analog in
> sugar.
>
> == Detailed Description ==
>
> The major reason is to let activities like FileShare or Chat special UI
> representation in shell's interface. It could be also useful if user
> wants fast access to some activities like Journal replacements.
>
> Any of four panels could be stuck i.e. let user see its components all
> time.
>
> === Predefined components ===
>
> * rings switch
> * activities list
> * clipboard
> * users list
> * sources list
> * network component
> * notification area
>
> == Benefit to Sugar ==
>
> * let users more freedom to organize sugar shell how they want
> * provide to activity developers a way to integrate theirs activities
> * to shell UI(useful for activities that work in background and
> * requires some kind all-time-present indicator in UI)
> * having stable API for panel components, activity developers have more
> * freedom and aren't stuck to core releases e.g. Network
> * activity/component(analog of NM widget in GNOME) could support
> * several sugar releases and previous release sugar users will benefit
> * from last Network component.
> * previous sugar release users will benefit from last updates of
> * predefined components as well
>
> == UI Design ==
>
> * all of four frame panels could be stuck
> * manage components, way to add-new/remove/move components
> * components could have shell level key shortcuts
>
> == User Experience ==
>
> * sugar frame as a regular GNOME panels
>
> --
> Aleksey
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Activity Versioning - Dotted Scheme

[Tomeu Vizoso]

On Sun, Dec 6, 2009 at 01:42, Aleksey Lim  wrote:
> On Wed, Dec 02, 2009 at 04:38:56PM +0100, Bert Freudenberg wrote:
>> On 30.11.2009, at 21:24, Bert Freudenberg wrote:
>> >
>> > On 30.11.2009, at 20:02, Aleksey Lim wrote:
>> >>
>> >> On Mon, Nov 30, 2009 at 07:49:15PM +0100, Simon Schampijer wrote:
>> >>> On 11/30/2009 10:00 AM, Bert Freudenberg wrote:
>>  On 29.11.2009, at 20:50, Simon Schampijer wrote:
>> >
>> >
>> > Well, if an activity will work for an older release is not only
>> > determined by the activity version number. For example, activities that
>> > moved to the new toolbar design are not working for older releases<
>> > 0.86. I don't think we can always avoid breaking backwards 
>> > compatibility.
>> 
>>  But so far we have managed to make is at least *possible* for an 
>>  activity author to have a single activity version run under all Sugar 
>>  versions. This would be the first instance where the author would not 
>>  have that chance.
>> 
>>  I'm pretty sure we can find a scheme that both allows a single activity 
>>  bundle to provide dotted version numbers for new Sugar, but keep 
>>  working in old Sugar.
>> 
>>  E.g., we do not have to re-use the "activity_version" field if that 
>>  breaks the parsing in older versions. It could be a new field named 
>>  "dotted_activity_version" or simply "version" or something else. An 
>>  activity author who cared could then provide both, a decimal and a 
>>  dotted activity version.
>> 
>>  - Bert -
>> >>>
>> >>> Sorry, for the mixup. Yes we could add a way for the dotted version
>> >>> number, and your idea sounds good. How does Bert's idea from above
>> >>> sounds to others?
>> >>
>> >> +1, but maybe use "activity_release"(or so) instead of 
>> >> "dotted_activity_version",
>> >> the full version in 0.88+ will be .?
>> >
>> > That would link the old and new version field - I thought of them as being 
>> > independent. Basically, the old activity_version field would be a like a 
>> > build number, increasing for every build, as we did before. It would be 
>> > optional in Sugar 0.88. The "real" user-visible version number would be 
>> > the dotted one in a different field.
>> >
>> > An activity author who wants to support both could keep incrementing 
>> > activity_version, and assign dotted version numbers independently.
>> >
>> > - Bert -
>>
>> Thinking about this, for Etoys it doesn't really make a difference. We can 
>> as well switch to the dotted-only scheme.
>>
>> So unless other activity authors feel backwards compatibility is needed, 
>> just use whatever is simplest.
>>
>> Is this already written up as a feature? Couldn't find it.
>
> I've created
> http://wiki.sugarlabs.org/go/Features/Dotted_Activity_Versions
> and wrote several options of your proposal(how I understood it)
> in 
> http://wiki.sugarlabs.org/go/Features/Dotted_Activity_Versions#Detailed_Description
>
> Also I pushed it to "Feature Ready for Release Manager" group though
> this feature doesn't meet all requirements(there is no owner, I guess it
> will be trivial to code it) but it let us do not forget about this
> feature.

Thanks a lot for entering the feature page. Do we have any consensus
on which alternative is best?

Regards,

Tomeu

-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Backwards compatible Browse

[Tomeu Vizoso]

On Mon, Nov 30, 2009 at 01:00, Wade Brainerd  wrote:
> I cloned Browse v114 and spent a few hours hacking on backwards
> compatibility.  I added compatibility fallbacks for the toolbars and a
> few other modules.
>
> The repository is here:
> http://git.sugarlabs.org/projects/browse/repos/backwards-compatibility
>
> On OLPC build 8.2.0, the patched Browse v114 starts and basically
> works.  A few features like typeahead find are broken and beyond my
> ability to trivially fix, but someone with more experience hacking
> XPCOM could probably figure it out quickly.
>
> Is there any interest in re-forging the compatibility chain, so that
> the latest Browse will work on old versions of Sugar?

I think there's interest. Have given a look at your modifications and
have these comments:

+# If GConf is not available, automatic server authentication is disabled.
+try:
+import gconf
+except ImportError:
+pass

was automatic server authentication working in any way in 0.82? If so,
I guess we need to fix it (maybe we were using something else than
GConf back then?)

+try:
+client = gconf.client_get_default()
+except NameError:
+return

I would define HAS_GCONF, like you have done with the toolbars.

+if not NEW_TOOLBARS:
+_TOOLBAR_EDIT = 1
+_TOOLBAR_BROWSE = 2

I think we should try to not mix the main code with the compatibility
one. Otherwise the code in activities will get quite more messy and
when we decide to drop some of it we'll have more risk to introduce
regressions.

Nice work,

Tomeu

-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [NEW FEATURE] write to the journal whenever you want

[Tomeu Vizoso]

On Fri, Nov 20, 2009 at 15:49, Walter Bender  wrote:
> On Fri, Nov 20, 2009 at 9:47 AM, Gary C Martin  wrote:
>> Hi Walter,
>>
>> On 19 Nov 2009, at 19:32, Walter Bender wrote:
>>
>>> Many of us love the Naming Alert, but even more seem to despise it.
>>> With this feature, it is invoked from a toolbar button instead of
>>> automatically invoked on quit. It lets the learning take notes
>>> repeatedly and at any time during an activity session.
>>>
>>> See http://wiki.sugarlabs.org/go/Features/Write_to_journal_anytime
>>>
>>> This is a quick hack. We may want to revisit the toolbar integration
>>> and certainly need a better icon :)
>>
>> :-)
>>
>> The first thing that comes to mind is something Journal icon like (but still 
>> distinguishable from the Journal activity icon), the original Journal with 
>> pencil seems a good place to work from (as Eduardo already mentioned).
>>
>>> Comments?
>>
>> Yes, I do like the intent, though I'm not sure we have activity toolbar 
>> space for another new icon. How about the whole dialogues content be placed 
>> in the activity icon secondary toolbar design (I think Simon raised this 
>> once before)? This would also make it non-modal, so you can add notes and 
>> interact with your activity canvas without the 'click the tick' edit cycle. 
>> The secondary toolbar does scale to fit the content height, but you'd need 
>> to be sensitive with the amount of space used as some activities will layout 
>> badly if too much of their canvas space is eaten away. I could try a few 
>> mockups if this approach seems reasonable.
>
> My mock up was just to get the ball rolling on this. It is a
> reasonable fall-back if we cannot get a better solution implemented in
> time for 0.88, but I would love to see more ideas emerge.

I'm a bit wary about quick temporary fixes with big impact in the UI,
because deployments generate materials that get outdated, etc.

I'm pinging Christian and Eben in case they have more ideas about how
to resolve the issue.

About the bug of the values in the activity not being updated by
changes in the journal, I think Simon is already working on it.

Regards,

Tomeu

>> One thing that does seem a shame is that this indicates the Journal UI for 
>> adding details is not easy enough to use. Ideally we would have one single 
>> UI as part of the Journal for entering all entry details (for both code 
>> maintenance and design simplicity reasons). Activities could then providing 
>> a quick way to switch there. When the current original naming dialogue was 
>> first added I was hoping a way would be found to replace the new dialogue by 
>> just switching directly to the existing Journal detail view instead. Perhaps 
>> this should be the design goal (improving Journal integration/use rather 
>> than new separate activity based dialogues).
>
> We could use a bit more structure (esp. in the tags section) and a
> rich-text interface (including images and audio) in the description
> field.)
>
>> Regards,
>> --Gary
>>
>>
>
> -walter
>
> --
> Walter Bender
> Sugar Labs
> http://www.sugarlabs.org
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] File Share Activity

[Tomeu Vizoso]

Would you like for people in Uruguay to test it? 0.84 and later Sugar
releases have file transfer in the journal, but most OLPC machines are
stuck with 0.82 for the time being.

Btw, are you the author of Bundle or is it another Lewis?

http://dev.laptop.org/git/activities/bundleactivity/

Regards,

Tomeu

On Sat, Dec 12, 2009 at 02:30, Justin Lewis  wrote:
> Hey members of sugar-devel,
> Just wanted to let you know that I have been working on a file
> share activity and is now in a testable state.
> It is still under development, but I figured I would share it with
> everyone and see what you all think.
> The activity can be found on on the sugarlabs wiki.
> http://wiki.sugarlabs.org/go/FileShare
> Please feel free to check it out.  Let me know if you have any
> suggestions, bugs or other feedback.
>
>
> Justin Lewis
> http://wiki.sugarlabs.org/go/User:Jlew
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [Feature] activity.info enhancements

[Tomeu Vizoso]

On Fri, Dec 11, 2009 at 17:36, Eben Eliason  wrote:
> On Fri, Dec 11, 2009 at 2:26 PM, Tomeu Vizoso  wrote:
>> On Fri, Dec 11, 2009 at 17:18, Sayamindu Dasgupta  
>> wrote:
>>> On Fri, Dec 11, 2009 at 11:13 PM, Walter Bender  
>>> wrote:
>>>> Summary: It would facilitate the packaging of Sugar activities into
>>>> RPMs and DEBs if there were additional information available in the
>>>> activity.info file.
>>>>
>>>> Details: In walking the process of creating an RPM of one of my
>>>> activities with Sebastian Dziallas, who is doing lots of packaging for
>>>> Fedora and SoaS, we observed that many fields in packages' .spec files
>>>> could readily be pulled from the activity.info file. A few additional
>>>> fields would be necessary, such as the following:
>>>>
>>>>    * a short summary
>>>>    * an URL to the source package
>>>>    * an URL to the activity home page
>>>>    * the required dependencies to run
>>>>
>>>> None of these additional fields are particularly onerous for an
>>>> activity developer to provide and it would enable the creation of a
>>>> script (as part of setup.py/bundlebuilder.py) to do most of the work
>>>> in creating the .spec file. (I assume .deb has similar requirements to
>>>> .rpm). Things are more complex for activities that include binaries
>>>> and the like, but for the most part, we should be able to greatly
>>>> facilitate upstream maintenance of our code while asking little more
>>>> of Sugar developers. None of these additional fields need be required,
>>>> but their inclusion would make things easier. (This is not a new idea,
>>>> but one that seems timely given all the upstream interest in Sugar
>>>> these days.)
>>>>
>>>
>>> It may be interesting to factor in localization (eg: translation of
>>> the description, etc) into this discussion. We already translate parts
>>> of activity.info so it may be trivial to extend the mechanism.
>>> However, it does increase the workload on translators a bit, and we
>>> need to agree on which fields to translate (for example, if we have a
>>> non-UI-visible field called category or tags, it may not make sense to
>>> translate it).
>>
>> I was thinking of displaying these tags in the activity list (or it's
>> already happening, not sure). Also, if we allow searching for those,
>> we would need to do so with the ones in the local language.
>
> I think displaying them in the list might just add visual noise, but
> their primary intent is to allow searching, and as you point out, it's
> critical to have good translations for that to work.

Hmm, I was hoping that displaying the tags would help people know what
to search for.

Regards,

Tomeu


> Eben
>
>
>> Regards,
>>
>> Tomeu
>>
>>> It may also be worthwhile to keep some kind of compatibility with the
>>> desktop-entry spec
>>> http://standards.freedesktop.org/desktop-entry-spec/latest/, in case
>>> we add support for standalone activities in the future.
>>>
>>> Thanks,
>>> Sayamindu
>>>
>>>
>>> --
>>> Sayamindu Dasgupta
>>> [http://sayamindu.randomink.org/ramblings]
>>> ___
>>> Sugar-devel mailing list
>>> Sugar-devel@lists.sugarlabs.org
>>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>>
>>
>>
>>
>> --
>> «Sugar Labs is anyone who participates in improving and using Sugar.
>> What Sugar Labs does is determined by the participants.» - David
>> Farning
>> ___
>> Sugar-devel mailing list
>> Sugar-devel@lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>
>



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [Feature] activity.info enhancements

[Tomeu Vizoso]

On Fri, Dec 11, 2009 at 17:18, Sayamindu Dasgupta  wrote:
> On Fri, Dec 11, 2009 at 11:13 PM, Walter Bender  
> wrote:
>> Summary: It would facilitate the packaging of Sugar activities into
>> RPMs and DEBs if there were additional information available in the
>> activity.info file.
>>
>> Details: In walking the process of creating an RPM of one of my
>> activities with Sebastian Dziallas, who is doing lots of packaging for
>> Fedora and SoaS, we observed that many fields in packages' .spec files
>> could readily be pulled from the activity.info file. A few additional
>> fields would be necessary, such as the following:
>>
>>    * a short summary
>>    * an URL to the source package
>>    * an URL to the activity home page
>>    * the required dependencies to run
>>
>> None of these additional fields are particularly onerous for an
>> activity developer to provide and it would enable the creation of a
>> script (as part of setup.py/bundlebuilder.py) to do most of the work
>> in creating the .spec file. (I assume .deb has similar requirements to
>> .rpm). Things are more complex for activities that include binaries
>> and the like, but for the most part, we should be able to greatly
>> facilitate upstream maintenance of our code while asking little more
>> of Sugar developers. None of these additional fields need be required,
>> but their inclusion would make things easier. (This is not a new idea,
>> but one that seems timely given all the upstream interest in Sugar
>> these days.)
>>
>
> It may be interesting to factor in localization (eg: translation of
> the description, etc) into this discussion. We already translate parts
> of activity.info so it may be trivial to extend the mechanism.
> However, it does increase the workload on translators a bit, and we
> need to agree on which fields to translate (for example, if we have a
> non-UI-visible field called category or tags, it may not make sense to
> translate it).

I was thinking of displaying these tags in the activity list (or it's
already happening, not sure). Also, if we allow searching for those,
we would need to do so with the ones in the local language.

Regards,

Tomeu

> It may also be worthwhile to keep some kind of compatibility with the
> desktop-entry spec
> http://standards.freedesktop.org/desktop-entry-spec/latest/, in case
> we add support for standalone activities in the future.
>
> Thanks,
> Sayamindu
>
>
> --
> Sayamindu Dasgupta
> [http://sayamindu.randomink.org/ramblings]
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] resource for understanding git

[Tomeu Vizoso]

Unfortunately, for learning git you need to have some knowledge of its
architecture. This link has helped me understand quite a bit of
things:

http://www.newartisans.com/2008/04/git-from-the-bottom-up.html

Regards,

Tomeu

-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] branches for sugar-base and hulahop

[Tomeu Vizoso]

Hi,

hulahop lacks any branch and sugar-base has only 0.82 and 0.86. Can
the missing branches be created in the points where new development
started?

Thanks,

Tomeu

-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Technique to extract all records from xapian DB?

[Tomeu Vizoso]

On Sun, Dec 6, 2009 at 12:49, Martin Langhoff  wrote:
> I am trying to add minimal support on 0.84 for the old "0.82" format
> in which JE metadata was saved on external disks.
>
> By minimal I mean read-only, fail-safe, and generally with small
> impact on the codebase. I sure don't want to reimplement the old DS
> code
>
> Is there a simple (and cheap) way to read the xapian DB and extract
> all the records, complete?

I think it's worth trying, but not sure if worth merging and
deploying. 0.82 didn't used directly the python xapian bindings, but
some wrapper on top of it that tried to make easier the mapping
between keys in the B-tree and metadata values.

I'm not sure if it would be easier for you to try to read the index
with the basic bindings or by using secore (now called xappy).

The mapping mentioned before is persisted in index/config inside the DS dir.

Regards,

Tomeu

-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] links and commands for supporting development

[Tomeu Vizoso]

More links about what we have covered today:

http://wiki.sugarlabs.org/go/User:Tomeu/CeibalDay2

== Overview of Sugar's architecture ==

http://wiki.sugarlabs.org/go/Development_Team/Release/Modules

http://wiki.sugarlabs.org/go/0.86/Platform_Components

http://wiki.sugarlabs.org/go/Development_Team/Release

http://wiki.sugarlabs.org/go/Development_Team/Architecture

http://people.collabora.co.uk/~danni/telepathy-book/

== Code submission ==

http://wiki.sugarlabs.org/go/Development_Team/Code_Review

http://wiki.sugarlabs.org/go/Development_Team/Code_guidelines

http://www.python.org/dev/peps/pep-0008/

http://wiki.sugarlabs.org/go/Development_Team/Almanac

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

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

== Sugarization of C activities ==

http://wiki.sugarlabs.org/go/Running_Linux_Applications_Under_Sugar

http://git.gnome.org/cgit/gcompris/tree/src/gcompris/gcompris.c?h=gcomprixogoo#n642

http://git.sugarlabs.org/projects/etoys/repos/mainline/blobs/master/etoys-activity#line77

== Forking of rpms ==

http://fedoraproject.org/wiki/Projects/Mock

http://bradthemad.org/tech/notes/patching_rpms.php

http://www.rpm.org/max-rpm/s1-rpm-miscellania-rpm2cpio.html

http://cvs.fedoraproject.org/viewvc/F-11/sugar/sugar.spec?view=markup

http://koji.fedoraproject.org/koji/buildinfo?buildID=144037


Regards,

Tomeu


On Wed, Dec 9, 2009 at 17:20, Tomeu Vizoso  wrote:
> Hi,
>
> have been talking today with developers at the Plan Ceibal and have
> written down a series of links and commands that were discussed. I'm
> sending this to the list in case is useful and in case someone has any
> questions.
>
> Regards,
>
> Tomeu
>
> 
>
> git checkout -b sucrose-0.84 origin/sucrose-0.84
>
> sshfs 
> to...@10.0.0.33:/home/tomeu/sugar-jhbuild/install/lib/python2.6/site-packages/sugar
> sugar
> http://embraceubuntu.com/2005/10/28/how-to-mount-a-remote-ssh-filesystem-using-sshfs/
>
> PermitRootLogin yes
> PasswordAuthentication yes
> PermitEmptyPasswords yes
>
> http://wiki.sugarlabs.org/go/Development_Team/Release
> http://wiki.sugarlabs.org/go/Features
> http://wiki.sugarlabs.org/go/Features/Policy
> http://wiki.sugarlabs.org/go/Development_Team/Code_Review
> http://wiki.sugarlabs.org/go/Development_Team/Code_guidelines
> http://wiki.sugarlabs.org/go/Development_Team/Architecture
> http://wiki.sugarlabs.org/go/0.86/Platform_Components
>
> http://docs.python.org/library/pdb.html
>
> http://winpdb.org/
> http://code.djangoproject.com/wiki/DebuggingDjangoWithWinpdb
>
> import rpdb2
> rpdb2.start_embedded_debugger("any_password")
>
> http://producingoss.com/
>
> --
> «Sugar Labs is anyone who participates in improving and using Sugar.
> What Sugar Labs does is determined by the participants.» - David
> Farning
>



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] links and commands for supporting development

[Tomeu Vizoso]

Hi,

have been talking today with developers at the Plan Ceibal and have
written down a series of links and commands that were discussed. I'm
sending this to the list in case is useful and in case someone has any
questions.

Regards,

Tomeu



git checkout -b sucrose-0.84 origin/sucrose-0.84

sshfs 
to...@10.0.0.33:/home/tomeu/sugar-jhbuild/install/lib/python2.6/site-packages/sugar
sugar
http://embraceubuntu.com/2005/10/28/how-to-mount-a-remote-ssh-filesystem-using-sshfs/

PermitRootLogin yes
PasswordAuthentication yes
PermitEmptyPasswords yes

http://wiki.sugarlabs.org/go/Development_Team/Release
http://wiki.sugarlabs.org/go/Features
http://wiki.sugarlabs.org/go/Features/Policy
http://wiki.sugarlabs.org/go/Development_Team/Code_Review
http://wiki.sugarlabs.org/go/Development_Team/Code_guidelines
http://wiki.sugarlabs.org/go/Development_Team/Architecture
http://wiki.sugarlabs.org/go/0.86/Platform_Components

http://docs.python.org/library/pdb.html

http://winpdb.org/
http://code.djangoproject.com/wiki/DebuggingDjangoWithWinpdb

import rpdb2
rpdb2.start_embedded_debugger("any_password")

http://producingoss.com/

-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [IAEP] [ANNOUNCE] Feature Policy updated

[Tomeu Vizoso]

2009/11/29 Simon Schampijer :
> On 11/27/2009 09:00 PM, Sascha Silbe wrote:
>> On Fri, Nov 27, 2009 at 07:40:26PM +0100, Simon Schampijer wrote:
>>
>>> * Backup up by the community *
>>> The proposer of the feature has to get feedback from the community.
>>> This includes technical feedback, feedback from the deployments etc.
>>> See as well in the last paragraph about which points the community
>>> might care. Of course there will be some different opinions in the
>>> community - in general there should be more YES than NO in the
>>> community for a feature to be able to get into a Sugar release.
>>
>> This puts the burden of interacting with deployments on each individual
>> feature proposer (but away from the core developers, which is a good
>> thing).
>> How is that supposed to happen (getting feedback from deployments)?
>> Writing to iaep? What if nobody replies to those messages (e.g. because
>> it doesn't matter to them either way), will the feature be rejected even
>> if it's a good idea? (*)
>
> Yes, sending an email to sugar-devel - see here the section community
> consensus [1]. So deployments for example interested in the evolution of
> the Sugar platform should read sugar-devel and watch out for the
> [FEATURE] tag. Of course not only deployers are invited to comment.
>
> The idea is to have the submitter of a Feature taking care of getting
> the feedback. He is the one that knows best about the feature. It is
> good practice to interact with the community, too. The release manager
> is just there to make sure the process is done correctly.

I think the deployment team can play a strong role here, but it's
currently in need of re-energizing. In the meantime, I think you can
ask people like Daniel Drake, Martin Langhoff, Caroline, Walter, me,
etc. to proxy that request to others or share whatever we may have
heard about the need in the field. Local labs might also be able to
help here.

There's also a page in the wiki that lists some contacts in
deployments that are active in the community, should be something like
Deployment_Team/Places.

Regards,

Tomeu

>> (*) Obviously "good idea" is quite subjective, but I assume you
>> understand what I mean.
>
> I guess we have to use common sense for that. There are guidelines [2]
> what you should thinks about before proposing a feature. I hope we don't
> see dead ends often. If we do, we can create a board that solves such
> conflicts - like the oversight board (not sure if it is the same board
> or if it has to be a different one).
>
> Regards,
>    Simon
>
> [1]
> http://wiki.sugarlabs.org/go/Features/Policy#Propose_a_feature_for_addition_into_the_release_cycle
> [2]
> http://wiki.sugarlabs.org/go/Features/Policy#Things_you_should_consider_when_proposing_a_feature
> ___
> IAEP -- It's An Education Project (not a laptop project!)
> i...@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/iaep
>



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [FEATURE] Activity as a regular Journal Object request for inclusion to 0.88

[Tomeu Vizoso]

2009/12/3 Aleksey Lim :
> On Thu, Dec 03, 2009 at 12:23:37AM -0500, Eben Eliason wrote:
>> On Tue, Dec 1, 2009 at 5:54 AM, Martin Langhoff
>>  wrote:
>> > On Mon, Nov 30, 2009 at 9:40 PM, Wade Brainerd  wrote:
>> >> When deleting an object from the Journal that is an activity bundle,
>> >> we ought to display an alert with a scary icon.  The alert should
>> >> clearly state that Journal entries will no longer be able to be opened
>> >> until the activity is reinstalled.
>> >
>> > Majority of 6 year old will not understand that.
>>
>> The best way to handle this, I think, is to let kids delete activities
>> but also keep a reference to the source in the form of an update URL
>> or similar, so that fetching the activity automatically when an
>> instance of it is resumed can be done. There's additional UI work
>> there, and we can't guarantee connectivity, etc., but it would help
>> reduce the overhead involved. (I'm not suggesting we shouldn't find
>> ways to make it clearer when a deletion is happening, either, but as
>> noted, the dialog may not work in practice with the target audience.)
>>
>> >> Some of the other operations Aleksey mentioned, like upgrading
>> >> activities, ought to display similar alerts.
>> >
>> > Gentlemen, alerts do not work with young users. We have to just DTRT,
>> > or provide actions that are very clearly different (and even then...).
>>
>> On a more general note, this discussion has many hints of the
>> action/object views that have been tossed around for some time now.
>> This specifically addressed the conflict between the desire to manage
>> all objects and the desire to have the Journal reflect only the
>> actions of the child.
>>
>> In this split, the action view shows actions, which reference one or
>> more objects (activities, people, devices, etc.) This would contain
>> only references to things the children have done themselves. The
>> object view shows objects, which is a more traditional view of
>> everything that's around to be manipulated. Any preinstalled
>> activities would appear in the object view by default, and thus be
>> accessible by kids to copy, share, modify, etc. (and as they do, new
>> actions will be created to record that).
>>
>> Ultimately, the object view would look much like the current Journal
>> view does, and the actions view would be a bit friendlier. One benefit
>> of this is that young kids need only look at the actions view, while
>> those that wanted more control could dig into the objects directly.
>
> Good catch, what about more explicit following "user works all time with
> the same objects but from different views" and add Action view as a
> Journal plugin(and maybe make it default) to [1](technically we need
> addition data to form actions view but for users it could be the same
> (as in objects view) objects but organized to actions.
>
> [1] http://wiki.sugarlabs.org/go/Features/Journal_Plugins

I agree that the split of the journal in an actions and objects view
would help with this and other problems we currently have in the
journal. The GNOME Activity Journal is also going with this.

Regards,

Tomeu


-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] registering/unregistering to XS (was Re: some efforts that would be really useful for deployments)

[Tomeu Vizoso]

2009/11/25 Daniel Drake :
>
> Unregistering from an XSes / registering with multiple XSes
> A hack available here: http://dev.sugarlabs.org/ticket/362
> Still no user-friendly or documented way of doing this.

>From the other day's conversation in #sugar, seemed like the command
line tool was enough for some deployments? Do we still need to add
anything to the UI?

Thanks,

Tomeu

-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [FEATURE] [DESIGN] for Journal Plugins feature

[Tomeu Vizoso]

2009/11/27 Aleksey Lim :
> On Fri, Nov 27, 2009 at 06:13:55AM +, Aleksey Lim wrote:
>> Hi all,
>>
>> Want to know what people think about Journal Plugins feature[1]
>> and particularly that design team think about UI changes[2] involved
>> in this feature.
>>
>> [1] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#
>> [2] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#UI_changes
>
> I tweaked "Benefit to Sugar" section a bit
>
> * browsing different types of sugar object looks the same in many cases 
> (search, tagging etc.). So, keep unified code base and do not split it could 
> be useful idea.
> * for now, some activities have similar functionality(browsing Journal 
> entries), so having plugins, we will use the same theme for browsing features 
> in sugar
> * encourage developers create new view for different purposes(books, media 
> etc.)
> * having plugins we don't stick to sugar releases, deployers could 
> create/change plugins that support not only last sugar but version which is 
> in deployment
> * having bookmarks, users can have fast access to his books/media-files/etc 
> in the Journal(and using proper view plugin to browse them)
> * shared bookmarks is more powerful and useful method of network sharing(in 
> comparing with "Send to" option)

Can anyway relate these benefits from actual requests from deployments?

I think this is something that would be good to do in Sugar at some
point, but I'm not convinced we are yet in the best moment for that.

Regards,

Tomeu

-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] moving some more configuration to gconf (was Re: some efforts that would be really useful for deployments)

[Tomeu Vizoso]

2009/11/25 Daniel Drake :
[snip]
>
> Customizing browse homepage
> The procedure to do this is too complicated for most deployments, and is
> undocumented.
>
> Customizing which activities are in the favourites view by default
> You can do this just by editing a file, but that file is a part of the
> sugar distribution so it will be lost on upgrades.
> There is also no documentation for how to do this, as far as I can see.
>
[snip]
>
> And once we're that far, why do users have to select which network to
> connect to?  This is also a significant classroom challenge. But
> typically in deployments, networks are installed at the same time that
> the sugar systems are made available. It's all controlled by the same
> party. So we could have a way that deployers could make sugar
> automatically connect to specific networks, or something like that.
>
[snip]
>
> http://wiki.sugarlabs.org/go/Features/Font_configuration

It has been suggested that GConf is the way to go here because is
precisely intended to simplify customization of defaults by
deployments.

Everybody agrees with this? Should be a goal? Maybe someone from the
technical teams at .uy or .py would like to lend a hand?

Thanks,

Tomeu

-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] 0.84 maintenance

[Tomeu Vizoso]

2009/12/1 Daniel Drake :
> Hi,
>
> Earlier this year, OLPC began developing a new laptop (XO-1.5) and OLPC
> OS (based on Fedora 11). Sugar-0.84 was hot off the presses at that time
> so even though it may feel a little dated today, it's what we've been
> working with and will soon be shipping in large quantity.
>
> One issue that we've been facing is various regressions since Sugar
> 0.82, some of which have been fixed in Sugar versions later than 0.84
> and some which are still pending. As nobody seems to look after 0.84 any
> more we've been backporting these fixes into a local branch for our OS
> builds.
>
> Now we're going to move to making these changes in the usual sugarlabs
> git repositories (sucrose-0.84 branches) and publishing them as regular
> Sugar releases of the main components. This is an improvement/cleanup to
> our current development processes and will open it up for other people
> to become involved. (we already have our 'offline fork' including about
> 15 patches, but we're not being very organised with our development
> working this way)
>
> So, OLPC will take over maintenance. To start with we'll just be working
> with sugar and sugar-toolkit.
>
> Me and Sayamindu will be taking care of this. There may be exceptions,
> but in general we'll only be taking patches that are already in master.
> We'll focus on fixes, but if there are really important features
> then we'll take them too (ad-hoc networking support is the 1 example we
> have right now).
>
> Of course, we'd love support from those of you who are actively involved
> in Sugar development. In a way it's a bit sad for us to see that 0.84
> maintenance already seems to have been halted, but at the same time it's
> certainly our responsibility to make contributions as well.

Thanks a lot for stepping up and taking these tasks, in my view this
is a big step forward for Sugar.

About the general issue of maintenance of stable releases, I don't
think it has to be so black and white. There's lots of ways to
contribute resources that end up benefiting maintenance of stable
releases:

- take maintenance of whole modules,

- become comaintainers of whole modules,

- take roles in the community that right now are overloaded on
existing maintainers: coordinator of teams such as development, QA,
community, etc.

- help with bug triaging,

- answering questions in the mailing lists and irc channels,

- help with macro-features such as accessibility support, performance,
static bindings, etc (deployments might not care right now, but these
are areas that Sugar must tackle at some point in order to keep
growing),

- keep pinging and summarizing the most important points for deployments,

- and finally, taking maintenance of a stable branch in a module.

I'm not saying the option you have chosen is not the best one in this
circumstances, I just wanted to point out that if more resources are
needed in stable branches, there are still all those ways to keep
improving on this.

> So we'll try and keep the community updated on the issues that we are
> facing, and hopefully you will be interested in helping us out. We'll be
> shipping this to a lot of children. Thanks for the continued
> developments on sugar, but don't forget that
> developing is only a small part of the challenge...!

Yes, thanks for keeping reminding us, for SLs to be a cohesive and
inclusive community, we need a bigger exchange of needs and points of
view.

> Also on this topic - we will certainly run into issues where activities
> themselves progress beyond the Sugar-0.84 platform; if activity authors
> could work to minimize these cases (i.e. keep backwards compatibility,
> remain responsive to bugs) it would help us avoid a huge headache, and
> will help your activities spread to various corners of the globe.

I think this is a current policy of the activity team?

Thanks,

Tomeu

-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] some efforts that would be really useful for deployments

[Tomeu Vizoso]

2009/11/25 Daniel Drake :
> Hi,
>
> After revisiting some of the changes I have made to the software while
> working on deployments I just wanted to post the list again as a
> refresher.

Thanks for doing this, I think it really helps to ping people until
the important stuff gets finally done.

Regards,

Tomeu

> I have not had enough time to do the appropriate master-level QA on
> these, or to get them running on the latest Sugar versions. I hope that
> some people will consider taking on these tasks.
>
> Some of the items here are far from trivial and will require design and
> thought to fix properly. Some of the items below are not purely sugar
> tasks. But at the same time they are really big items for sugar
> deployments. (Just to throw in some opinion here too, I feel that all
> deployments would benefit from more time being spent working on
> deployment technologies and realities at the system level -- Sugar 0.82
> reached a point where the biggest problems you find in the field are far
> outside of the UI/activities level, now we have to attack the others)
>
>
>
> Customizing browse homepage
> The procedure to do this is too complicated for most deployments, and is
> undocumented.
>
> Customizing which activities are in the favourites view by default
> You can do this just by editing a file, but that file is a part of the
> sugar distribution so it will be lost on upgrades.
> There is also no documentation for how to do this, as far as I can see.
>
> Automatic activity upgrading
> Activity updating is too difficult for young children to understand and
> is very hard to coordinate across a classroom.
> This one I have never had time to hack a fix into place.
> Also the "You should upgrade your activities" notice needs to die.
>
> Unregistering from an XSes / registering with multiple XSes
> A hack available here: http://dev.sugarlabs.org/ticket/362
> Still no user-friendly or documented way of doing this.
>
> Full journal restore, and backup control
> http://dev.laptop.org/ticket/9250
> We still don't have a good way of browsing backups or restoring multiple
> files (e.g. the whole journal) in 1 go.
>
> Another constant headache is with translations. How do you roll out new
> translations for old software? The best we have right now is language
> packs but they install files which conflict with both system packages
> and activity bundles. And they are difficult for deployments because you
> need Linux skills to execute them.
>
> Registration is a real headache in classrooms right now. It's just a bit
> of an alien concept for new computer users. And it's so difficult. If
> you try to register before connecting then a bug somewhere means that
> you can't even complete a successful registration after connecting --
> you have to restart sugar. And then after you do register you have to
> restart sugar for it to take effect.
> http://dev.sugarlabs.org/ticket/1151
>
> But why do we force users through the pains of registering at all? We
> control all the technical bits, lets automate it to hunt down the
> specific school server and register.
> http://dev.sugarlabs.org/ticket/1152
>
> And once we're that far, why do users have to select which network to
> connect to?  This is also a significant classroom challenge. But
> typically in deployments, networks are installed at the same time that
> the sugar systems are made available. It's all controlled by the same
> party. So we could have a way that deployers could make sugar
> automatically connect to specific networks, or something like that.
>
> During activity update, only download the parts that have changed
> http://dev.sugarlabs.org/ticket/1499
>
>
> And speaking now from a "Sugar implementor" standpoint, here are 2 fully
> specced features which have yet too see much attention:
>
> http://wiki.sugarlabs.org/go/Features/Font_configuration
> http://wiki.sugarlabs.org/go/Features/Content_support
>
>
>
> Any takers? :)
>
> Daniel
>
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] translation updates (was Re: some efforts that would be really useful for deployments)

[Tomeu Vizoso]

2009/11/25 Daniel Drake :
>
> Another constant headache is with translations. How do you roll out new
> translations for old software? The best we have right now is language
> packs but they install files which conflict with both system packages
> and activity bundles. And they are difficult for deployments because you
> need Linux skills to execute them.

I guess that we don't have this problem for software packaged in rpms?

For activities, once we get major/minor version numbers, may be easier
to spin new stable releases with updated translations?

If we still need to decouple the translations from the release
process, then I guess Sayamindu's proposal is the way to go.

Regards,

Tomeu

-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [DESIGN] activity upgrading (was Re: some efforts that would be really useful for deployments)

[Tomeu Vizoso]

2009/11/25 Daniel Drake :
>
[snip]
>
> Automatic activity upgrading
> Activity updating is too difficult for young children to understand and
> is very hard to coordinate across a classroom.
> This one I have never had time to hack a fix into place.
> Also the "You should upgrade your activities" notice needs to die.

Any ideas about the best user experience for users updating their activities?

Lots of people have been complaining about this. I know we discussed
it in the past but cannot remember the conclusion, if any.

Thanks,

Tomeu

-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Fructose - What is it? What should it be?

[Tomeu Vizoso]

2009/11/27 Gary C Martin :
> Hi Tomeu,
>
> On 26 Nov 2009, at 12:41, Tomeu Vizoso wrote:
>
>> On Tue, Nov 24, 2009 at 17:44, Simon Schampijer  wrote:
>>> On 11/24/2009 03:18 PM, Aleksey Lim wrote:
>>>> On Tue, Nov 24, 2009 at 02:57:16PM +0100, Simon Schampijer wrote:
>>>>> Hi,
>>>>>
>>>>> this came up several times now. People where wondering what Fructose is.
>>>>>   From the definition it is:
>>>>>
>>>>> The Sugar developers will need some example set of activities with which
>>>>> to demonstrate Sugar. This set is Fructose. The packages in Fructose
>>>>> should be selected to make the resulting environment as impressive as
>>>>> possible for a potential client or user. Packages should therefore be
>>>>> stable, polished, and exercise the widest possible range of features.
>>>>> Fructose may also serve as an example for people constructing their own
>>>>> Activity sets. [1]
>>>>>
>>>>> The current list of activities can be found at [2].
>>>>>
>>>>> The fructose activities follow the Sucrose development cycle (0.84,
>>>>> 0.86...). This means they follow the freezes, provide source tarballs,
>>>>> need a present maintainer etc. The duties are described at [3]. The
>>>>> activity gets noted in release notes, possibly more attention by the
>>>>> localization teams as revenue.
>>>>>
>>>>> In the end their are downsides and upsides to be part of Fructose. There
>>>>> were some arguing, that only system dependent activities should be part
>>>>> of it (e.g. Browse with the dependency on hulahop).
>>>>>
>>>>> There were some discussions that we would loose the show case activities
>>>>> when an activity would not be part of Fructose anymore. This comes down
>>>>> to packaging, as for rpm packaging one needs to provide the source
>>>>> tarballs and need to follow certain rules. Some distributors may ship
>>>>> the .xo bunles at one point, otherwise probably won't, so it is a good
>>>>> habit to do the source releases.
>>>>>
>>>>> Anyhow, this is a bit of the background. Let's think how we can move
>>>>> forward on this topic. We should do it quickly, to be able to keep the
>>>>> work on 0.88 going.
>>>>
>>>> In my mind, the best thing we can do is making clear definition:
>>>>
>>>> 1)  we have core with strong release cycle
>>>>      * glucose(and its dependencies)
>>>>      * sugar platform(additional dependencies)
>>>>      (core)
>>>>
>>>> 2)  various sugar activities
>>>>      (the rest of development community)
>>>>
>>>> 3)  sugar users
>>>>      (the rest of community)
>>>>
>>>> Relations between 1) and 2) totally depends on sugar release cycles.
>>>> Activity developers decide what release cycles they can/should/will 
>>>> support.
>>>> For activities like Browse it will several activities versions per SP
>>>> release. Most activities will support several SP release.
>>>>
>>>> Relations between 2) and 3) is task for various deployment methods.
>>>> Since fructose makes sense mostly for users, its content should totally
>>>> depends on deployers not core. So I can't see the 4rd place for fructose,
>>>> only as a part of 2).
>>>
>>> So far, I conclude, that Fructose as we have it today is outdated. The
>>> tarball issue could be solved with adding for example a field to ASLO,
>>> to be able to upload a tarball too, when doing a release. As I think
>>> where to upload a tarball was one big issue back in the days. The
>>> packaging (rpm, xo, deb) and how you install/upgrade, where you install
>>> (system vs user space) is then up to the deployer. As the tarball is
>>> available, that should work out nicely.
>>>
>>> Activities that rest coupled to the Sucrose release would be Browse and
>>> Etoys as they have strong platform dependencies.
>>
>> I think hulahop is more mature now and won't change as much in the
>> future. Also Python allows us to do lots of tricks to keep backwards
>> compatibility, but it all takes time developing and testing. Browse
>> may be now in the same situation as Read.
>>
>> I don't th

Re: [Sugar-devel] configuring Socksproxy for Jabber Server on the XO-1 or XO-1.5

[Tomeu Vizoso]

2009/11/19 Manusheel Gupta :
> On Thu, Nov 19, 2009 at 7:41 PM, Tomeu Vizoso  wrote:
>>
>> 2009/11/18 Manusheel Gupta :
>> > We did try to search around but have not been able to make much progress 
>> > towards configuring socks proxy on the XOs. Are you aware if someone would 
>> > have tried this
>> > before?
>>
>> Just to be sure, you want to tell the presence service to connect to a
>> ejabberd server through SOCKS?
>
>
> Yes. Establishing this communication is useful for working with activities 
> using non-https protocols like XMPP ( e.g. - Chat activity). We are trying to 
> explore a variety of possibilities and scenarios, and build the basic 
> infrastructure before moving towards the development of activities like Video 
> Talk, VOIP service etc.

Hi, got any luck on this?

Regards,

Tomeu

>> > On a separate note, https-proxy works well for all data oriented 
>> > connections using https protocol. Foxyproxy is another interesting Mozilla 
>> > plug-in we are looking forward to explore.
>>
>> And with this you mean that you have managed to tell Browse to use a
>> SOCKS server to access web pages?
>>
>
> Yes, exactly.
>
> Thank you Tomeu.
>
> Manu
>
>
>
>
>>
>> Thanks,
>>
>> Tomeu
>>
>> > Copying Morgan on the thread.
>> >
>> > Regards,
>> >
>> > Manu
>> >
>> >
>> >
>> >
>> >
>> >
>> > On Wed, Nov 18, 2009 at 11:44 PM, Tomeu Vizoso  wrote:
>> >>
>> >> 2009/11/15 Manusheel Gupta :
>> >> > Dear all,
>> >> >
>> >> > Do we have documentation somewhere on the steps involved in configuring 
>> >> > socksproxy for jabber server on the XO-1 or XO-1.5? Please let us know.
>> >>
>> >> Hi Manu,
>> >>
>> >> have you done any progress on this since then?
>> >>
>> >> Thanks,
>> >>
>> >> Tomeu
>> >>
>> >> > Thank you.
>> >> >
>> >> > Regards,
>> >> >
>> >> > Manu
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> «Sugar Labs is anyone who participates in improving and using Sugar.
>> >> What Sugar Labs does is determined by the participants.» - David
>> >> Farning
>> >
>> >
>>
>>
>>
>> --
>> «Sugar Labs is anyone who participates in improving and using Sugar.
>> What Sugar Labs does is determined by the participants.» - David
>> Farning
>
>



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Removing Log and Terminal from favorites view

[Tomeu Vizoso]

On Fri, Dec 4, 2009 at 11:21, Simon Schampijer  wrote:
> On 12/04/2009 12:15 PM, Daniel Drake wrote:
>> Hi,
>>
>> For the OLPC builds we're removing Log and Terminal from the default
>> favorites view. Is there any interest in making this change in upstream
>> sugar too?
>>
>> The reasons being that these activities are confusing/useless for young
>> children, but are left discoverable in the list view for older users as
>> well as other people who end up working on more technical tasks with the
>> laptops.
>>
>> Daniel
>
> +1 Sounds good to me.

I'm ok with that, but I think that the favorites file in the sugar
tarball should be considered an example, and nothing that packagers
and deployers should accept as-is.

Regards,

Tomeu

-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] adding 3G devices support to sugar

[Tomeu Vizoso]

On Thu, Dec 3, 2009 at 18:44, Martin Abente  wrote:
> Today i finished the systray device icon. (but i still need the icon
> graphic... any artist around?)

What would be a good symbol? A GSM base station?

http://www.mobilecomms-technology.com/projects/india_gsm/images/img1.jpg

> So, now we have
>
> 1. Store settings with gconf
> 2. Configuring settings at control panel (thanks to Daniel Castelo)
> 3. Systray device icon fully working
> 4. Gsm connections management
>
> I still need to clean stuff on 1,3,4

Congratulations!

Tomeu

> Saludos,
>
> On Wed, 2 Dec 2009 10:43:51 -0200, Daniel Castelo
>  wrote:
>> In Uruguay we need "USB_SERIAL_OPTION" for 3G Modems.
>> Martin, I could test your work using 3G Modems.
>> I could help programming the control panel and the device icon too.
>>
>>
>> On Wed, Dec 2, 2009 at 10:31 AM, Martin Langhoff
>> wrote:
>>
>>> On Wed, Dec 2, 2009 at 3:04 AM, Martin Abente
> 
>>> wrote:
>>> > I have successfully extended jarabe/model/network.py, so we can
>>> > load-in a gsm connection, tested it with my app (gsmbridge) and it
>>> > works, tomorow ill clean up the code, add the control panel and the
>>> > device icon part.
>>>
>>> Cool. Can you give us a list of kernel modules that will work with
>>> this, so we can look at building them for the XO1/1.5 kernels? They'll
>>> probably be split off in a separate rpm, but easily installable.
>>>
>>> cheers,
>>>
>>>
>>> m
>>> --
>>>  martin.langh...@gmail.com
>>>  mar...@laptop.org -- School Server Architect
>>>  - ask interesting questions
>>>  - don't get distracted with shiny stuff  - working code first
>>>  - http://wiki.laptop.org/go/User:Martinlanghoff
>>>
>>
>



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] adding 3G devices support to sugar

[Tomeu Vizoso]

Hi all,

have heard about progress from the different people involved in this
effort, but it's being a bit hard to track who is doing what and where
the problems are.

Could you write a small note in this thread saying what the status
are, plans going forward and any problems you are finding?

As with most FOSS work, there isn't a single person who has all the
knowledge required, so 1-to-1 conversations aren't particularly
effective.

If the existing forums are not appropriate enough, please tell and we
can discuss alternatives.

Thanks,

Tomeu

-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [RELEASE] sugar-presence-service-0.87.1

[Tomeu Vizoso]

== Source ==

http://download.sugarlabs.org/sources/sucrose/glucose/sugar-presence-service/sugar-presence-service-0.87.1.tar.bz2
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [RELEASE] sugar-0.87.1

[Tomeu Vizoso]

== Source ==

http://download.sugarlabs.org/sources/sucrose/glucose/sugar/sugar-0.87.1.tar.bz2

== News ==

* Several Access Points with the same essid #330
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [DESIGN] CMDA/GSM/3G Modem Support in Sugar

[Tomeu Vizoso]

On Fri, Nov 27, 2009 at 12:48, Daniel Castelo
 wrote:
> We are thinking in add CMDA/GSM/3G Modems Support in Sugar. We want to
> discuss the best interface to allow user configure and use this type of
> connections.

Awesome!

> The basical idea that we managed is to have an option in control panel to
> allow users to setup the connection, and a device icon in the bottom frame
> where users could connect and disconnect it.
> If is possible when the SO detect the new device, sugar could show the
> device icon and a shortcut to setup it.

Yes, that's easily doable.

> The fields that user should configure are:  Tel Number, User Name and
> Password (which more?)
> We should discuss if we will allow configure many conections or just one.

I would vote for just one as a start. Or will the users in your
deployment need to configure more than one?

Regards,

Tomeu

> Opinions, Contributions?
>
>
>
>
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] maintenance of 0.84 branches

[Tomeu Vizoso]

On Thu, Nov 26, 2009 at 13:43, Daniel Drake  wrote:
> On Thu, 2009-11-26 at 09:53 +, Daniel Drake wrote:
>> On Thu, 2009-11-26 at 09:45 +0000, Tomeu Vizoso wrote:
>> > We'll need that they make explicit which modules want to take
>> > maintenance of and then each current maintainer should agree or
>> > disagree.
>>
>> All of glucose, I guess. Right now we only have patches for
>> sugar-toolkit and sugar.
>
> Actually, we'd rather only take over maintenance where it has stopped.
> So for sugar and sugar-toolkit at least that seems necessary.

I'm the maintainer of sugar and I'm fine with it. Simon maintains sugar-toolkit.

As I think you have already commit access, please add yourselves to
sugar/MAINTAINERS and update
http://wiki.sugarlabs.org/go/Development_Team/Release/Modules#sugar .

> If
> existing maintainers of other components are able to continue taking new
> patches (from master) and translations and publishing releases then we'd
> rather leave the job to them.

Mind that it's not just a matter of a module or branch being
"maintained" or not. It's more about the person officially responsible
for that having time to attend all the requests or not.

There are many ways to increase the resources available for the
maintenance tasks of a module: being a co-maintainer, taking
maintenance of another module maintained by the maintainer, helping
with bug triaging, replying to questions posted in the mailing list,
fixing bugs in that module, helping with attracting more contributors,
and a long etc.

Regards,

Tomeu

-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [ANNOUNCE] development team meeting thursday at 14.00 UTC

[Tomeu Vizoso]

And here are the logs:

http://meeting.sugarlabs.org/sugar-meeting.minutes.20091126_0919.html
http://meeting.sugarlabs.org/sugar-meeting.log.20091126_0919.html

Regards,

Tomeu

On Thu, Nov 26, 2009 at 09:15, Simon Schampijer  wrote:
> On 11/24/2009 06:27 PM, Tomeu Vizoso wrote:
>> Hi,
>>
>> the development team is going to meet next thursday to discuss this
>> particular moment in the
>> 0.88 release cycle, please add topics here:
>>
>> http://wiki.sugarlabs.org/go/Development_Team/Meetings#Upcoming_Meetings
>>
>> See you then,
>>
>> Tomeu
>
> Developers, interested in 0.88 please join in. What we will have a look
> at is our roadmap and the feature process. If you have questions about
> it - best is to ask now!
>
> http://wiki.sugarlabs.org/go/0.88/Roadmap#Schedule
>
> http://wiki.sugarlabs.org/go/Features/Policy
>
> Thanks,
>    Simon
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Record rewrite -- was Re: [SoaS] SoaS v2 approaching RC state

[Tomeu Vizoso]

On Thu, Nov 26, 2009 at 14:41, Aleksey Lim  wrote:
> On Wed, Nov 25, 2009 at 12:25:12AM +, Aleksey Lim wrote:
>> On Tue, Nov 24, 2009 at 11:51:55PM +, Peter Robinson wrote:
>> > On Tue, Nov 24, 2009 at 9:13 PM, Sebastian Dziallas  
>> > wrote:
>> > > Hi all,
>> > >
>> > > with the next SoaS release coming up really soon (final image is
>> > > supposed to be composed this weekend, release date is Dec 8), there's a
>> > > new snapshot ready for you. It includes a lot of fixes and smaller
>> > > adjustments. It's currently only available as a general .iso build,
>> > > others will presumably follow later. You can get it from here:
>> > >
>> > > http://download.sugarlabs.org/soas/snapshots/2/soas06.iso
>> > >
>> > > Let us know how it goes and help us debugging and fixing the remaining
>> > > bugs here: https://bugs.launchpad.net/soas/+bugs
>> > >
>> > > A last note, if anybody knows what's wrong with Record, Cairo and F12,
>> >
>> > Who is the maintainer of Record? It would be a pity to ship BB without
>> > that working as its one off the Activities that kids seem to love.
>> > What's the issue with Cairo?
>>
>> last time /me patched Record.. and looks like it doesn't work in 0.86
>> for a long time, so its the right moment to fix 0.86 issues then
>
> Sorry, I'm a bit stuck with it, my plans were to rewrite Record-65
> and make lightweight Record:
>
> * w/o collaboration feature as it was designed in existed Record
>  * it just share records, I'm planing to do the same on Journal level
>  * it just doesn't work well(especially for big files)
> * w/o gtk.Windows that represent Record's controls, only widgets
> * using more robust gst scheme
>
> I decide to use camerabin[1] gst plugin which is a good option for
> Record but it doesn't work(stop w/ gst errors on recording) any help
> from people who are aware of such gst and video recording stuff is
> appreciated.
>
> [1] 
> http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-bad-plugins/html/gst-plugins-bad-plugins-camerabin.html

Maybe Daniel Siegel of Cheese fame can give some insight on that?
Added him to CC

Regards,

Tomeu

-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] .swf files visualization and bundling

[Tomeu Vizoso]

On Tue, Nov 24, 2009 at 11:02, Wade Brainerd  wrote:
> Good question - the SWF author would have to manually add support for
> sharing to the activity.  I believe Gnash has DBus bindings, so that
> might be a possibility.  If there is interested by at least one SWF
> author, I could add support in the SWF framework for collaboration.

The DBus plugin is just a stub for now and I think it would take lots
of work to get it working. What I would suggest instead is a plugin
that provided a simple API for collaboration. I have done some
experiments in this area and will be happy to share my experience.

Regards,

Tomeu

> Unless, Sugar had some sort of "automatic collaboration", using VNC or
> the like, which didn't require custom programming in each activity,
>
> -Wade
>
> On Mon, Nov 23, 2009 at 11:08 PM, roshan karki  wrote:
>> nice, work.
>> I can see that the activity can be shared as well. But unlike other shared
>> activities I can't see any relation between two shared Cabeza activity.
>> Though shared both activity are playing independently. Is it intentional ?
>> What kind of work needs to be done so that a swf based activity can also be
>> shared like 'write' activity ?
>>
>> On Tue, Nov 24, 2009 at 4:10 AM, Rafael Enrique Ortiz Guerrero
>>  wrote:
>>>
>>> Hi Wadeb and Tim
>>>
>>> Thanks for the suggestions.
>>>
>>> I followed  eatboom skeleton and i got a working initial activity.
>>>
>>>
>>> http://people.sugarlabs.org/rafael/Cabeza.activity.xo
>>>
>>> obvioulsy i borrowed eatbom.svg (this mail is only for reporting the
>>> advance :))
>>>
>>>
>>>
>>> Great work Wade!.
>>>
>>>
>>>
>>> Rafael Ortiz
>>>
>>>
>>>
>>> On Sun, Nov 22, 2009 at 7:44 AM, Wade Brainerd  wrote:
>>> > Hey Rafael,
>>> >
>>> > Check out http://git.sugarlabs.org/projects/eatboom/repos/wadebs-clone.
>>> >  That project provides a template for making .SWF files into proper
>>> > Sugar activities.
>>> > The bundle is also available on ASLO here:
>>> > http://activities.sugarlabs.org/en-US/sugar/addon/4225
>>> >
>>> > EatBoom is pretty simplistic, but I'm working on porting a more
>>> > advanced example.
>>> >
>>> > Let me know if you need any assistance with this.
>>> >
>>> > -Wade
>>> >
>>> > On Sun, Nov 22, 2009 at 2:11 AM, Rafael Enrique Ortiz Guerrero
>>> >  wrote:
>>> >> Hi.
>>> >>
>>> >> I have some educational content .swf files that i wish to visualize
>>> >> inside Sugar and also making a content bundle for them.
>>> >>
>>> >> What is the present way of doing so (both making the bundle and
>>> >> visualizing .swf files) ?, we have not talked in a while about content
>>> >> bundles at least that i remember ;), so please direct me to past
>>> >> conversations or links about it.
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> Cheers and thanks in advance for your help.
>>> >> Rafael Ortiz
>>> >> ___
>>> >> 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
>



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Fructose - What is it? What should it be?

[Tomeu Vizoso]

On Tue, Nov 24, 2009 at 17:44, Simon Schampijer  wrote:
> On 11/24/2009 03:18 PM, Aleksey Lim wrote:
>> On Tue, Nov 24, 2009 at 02:57:16PM +0100, Simon Schampijer wrote:
>>> Hi,
>>>
>>> this came up several times now. People where wondering what Fructose is.
>>>   From the definition it is:
>>>
>>> The Sugar developers will need some example set of activities with which
>>> to demonstrate Sugar. This set is Fructose. The packages in Fructose
>>> should be selected to make the resulting environment as impressive as
>>> possible for a potential client or user. Packages should therefore be
>>> stable, polished, and exercise the widest possible range of features.
>>> Fructose may also serve as an example for people constructing their own
>>> Activity sets. [1]
>>>
>>> The current list of activities can be found at [2].
>>>
>>> The fructose activities follow the Sucrose development cycle (0.84,
>>> 0.86...). This means they follow the freezes, provide source tarballs,
>>> need a present maintainer etc. The duties are described at [3]. The
>>> activity gets noted in release notes, possibly more attention by the
>>> localization teams as revenue.
>>>
>>> In the end their are downsides and upsides to be part of Fructose. There
>>> were some arguing, that only system dependent activities should be part
>>> of it (e.g. Browse with the dependency on hulahop).
>>>
>>> There were some discussions that we would loose the show case activities
>>> when an activity would not be part of Fructose anymore. This comes down
>>> to packaging, as for rpm packaging one needs to provide the source
>>> tarballs and need to follow certain rules. Some distributors may ship
>>> the .xo bunles at one point, otherwise probably won't, so it is a good
>>> habit to do the source releases.
>>>
>>> Anyhow, this is a bit of the background. Let's think how we can move
>>> forward on this topic. We should do it quickly, to be able to keep the
>>> work on 0.88 going.
>>
>> In my mind, the best thing we can do is making clear definition:
>>
>> 1)  we have core with strong release cycle
>>      * glucose(and its dependencies)
>>      * sugar platform(additional dependencies)
>>      (core)
>>
>> 2)  various sugar activities
>>      (the rest of development community)
>>
>> 3)  sugar users
>>      (the rest of community)
>>
>> Relations between 1) and 2) totally depends on sugar release cycles.
>> Activity developers decide what release cycles they can/should/will support.
>> For activities like Browse it will several activities versions per SP
>> release. Most activities will support several SP release.
>>
>> Relations between 2) and 3) is task for various deployment methods.
>> Since fructose makes sense mostly for users, its content should totally
>> depends on deployers not core. So I can't see the 4rd place for fructose,
>> only as a part of 2).
>
> So far, I conclude, that Fructose as we have it today is outdated. The
> tarball issue could be solved with adding for example a field to ASLO,
> to be able to upload a tarball too, when doing a release. As I think
> where to upload a tarball was one big issue back in the days. The
> packaging (rpm, xo, deb) and how you install/upgrade, where you install
> (system vs user space) is then up to the deployer. As the tarball is
> available, that should work out nicely.
>
> Activities that rest coupled to the Sucrose release would be Browse and
> Etoys as they have strong platform dependencies.

I think hulahop is more mature now and won't change as much in the
future. Also Python allows us to do lots of tricks to keep backwards
compatibility, but it all takes time developing and testing. Browse
may be now in the same situation as Read.

I don't think the problem is that Browse depends too much in hulahop,
but that the only help the maintainer has with regard to this issue is
when people complaint that the last released Browse is not working in
the release they are running.

With some more manpower I think we could surmount these issues.

Regards,

Tomeu

> Of course, activity authors are encouraged to follow the Sucrose release
> cycle, the point is: they don't have to. As Walter stated there is some
> benefit. Keeps you focused etc.
>
> More thoughts?
>    Simon
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] GSM/CDMA Modems support (part II)

[Tomeu Vizoso]

On Wed, Nov 25, 2009 at 14:47, Daniel Drake  wrote:
> On Wed, 2009-11-25 at 09:36 -0500, Martin Abente wrote:
>> Would a patch that extends the allowed connection types be accepted in the
>> 0.84 branch (that will be shipped with F11) ?
>
> Depends on the patch, but in general one requirement I've been putting
> on patches for OLPCs 0.84 fork is that the patches must already be in
> sugar master. So this should be your first port of call...

I'll be happy to work with Martin (and whoever else) on this. From
looking at http://trac.paraguayeduca.org/browser/nmbridge , Paraguay
Educa has already the required skills to do a great work there.

Regards,

Tomeu

-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Ooo4Kids in several languages - how to let it appear on aslo?

[Tomeu Vizoso]

On Thu, Nov 26, 2009 at 09:48, Tomeu Vizoso  wrote:
> Hi Bastien,
>
> On Thu, Nov 26, 2009 at 09:27, Bastien  wrote:
>> Dear all,
>>
>> I just uploaded Ooo4Kids 0.5.1 on aslo:
>>  http://activities.sugarlabs.org/fr/sugar/addon/4241
>>
>> There is an spanish version here:
>>  http://download.ooo4kids.org/es/descargar-ooo4kids-xo-intel
>>
>> How to host this spanish version on aslo?  Should I make another
>> activity, or is it possible to upload several "branches"?
>>
>> Thanks for any hint!
>
> Has the OOo4Kids team considered using gettext or similar so can ship
> a single bundle containing several localizations?

Eric has told me in #sugar that the reason for this is because each
locale takes about 100MB when compressed. If it's not feasible to make
the locales smaller, then I would recommend creating different
activities, with different activity ids.

Regards,

Tomeu

-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Ooo4Kids in several languages - how to let it appear on aslo?

[Tomeu Vizoso]

Hi Bastien,

On Thu, Nov 26, 2009 at 09:27, Bastien  wrote:
> Dear all,
>
> I just uploaded Ooo4Kids 0.5.1 on aslo:
>  http://activities.sugarlabs.org/fr/sugar/addon/4241
>
> There is an spanish version here:
>  http://download.ooo4kids.org/es/descargar-ooo4kids-xo-intel
>
> How to host this spanish version on aslo?  Should I make another
> activity, or is it possible to upload several "branches"?
>
> Thanks for any hint!

Has the OOo4Kids team considered using gettext or similar so can ship
a single bundle containing several localizations?

Regards,

Tomeu

-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] maintenance of 0.84 branches

[Tomeu Vizoso]

Hi,

Daniel Drake and Sayamindu Dasgupta have offered to take maintenance
of the 0.84 branches of some modules in glucose and fructose.

I'm happy about this because apart from their technical capabilities,
they are working for OLPC's deployments so can know better what their
needs are.

Any concerns about it?

We'll need that they make explicit which modules want to take
maintenance of and then each current maintainer should agree or
disagree.

Regards,

Tomeu

-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [ANNOUNCE] development team meeting thursday at 14.00 UTC

[Tomeu Vizoso]

Hi,

the development team is going to meet next thursday to discuss this
particular moment in the
0.88 release cycle, please add topics here:

http://wiki.sugarlabs.org/go/Development_Team/Meetings#Upcoming_Meetings

See you then,

Tomeu

--
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Non sugar activities on ASLO

[Tomeu Vizoso]

On Mon, Nov 23, 2009 at 17:30, Aleksey Lim  wrote:
> On Mon, Nov 23, 2009 at 01:23:22PM +, Aleksey Lim wrote:
>> Hi all,
>>
>> Non sugar activities we (could)have on ASLO:
>>
>> ++  programs with high sugar integration(journal etc.)
>> +   programs that start smooth in sugar environment(sugarised screen mode 
>> etc.)
>
> btw "sugarizing" programs only by fixing window issues and bundling
> blobs to .xo could be also wrong way to go, better to have universal
> method to run non-sugar programs w/o troubles with
> non-fullsreen/dialogs/etc windows.

Is there any serious problem other than the launcher not appearing in
the home view? About the launcher issue, we could support .desktop
files.

Regards,

Tomeu

> Does someone have any idea.. maybe special "desktop" mode to run
> non-sugar applications, fullscreen top window which is represented by
> one item in activity tray(or special icon in sugar frame).
>
> --
> Aleksey
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] adding 3G support to Sugar (was Re: Sugarizing an application)

[Tomeu Vizoso]

On Fri, Nov 20, 2009 at 14:55, Daniel Castelo
 wrote:
> Yes, we managed this possibility. In this case I need to study (and I need
> support) to know how implement it according to the sugar architecture, and
> discuss which is the best dialog to configure and use this connection.

It's great to hear that. Starting with the user experience, what if we
have a control panel section where the 3G account is setup and a
device icon in the bottom frame that allows the user to connect and
disconnect?

Regards,

Tomeu

> On Thu, Nov 19, 2009 at 12:11 PM, Tomeu Vizoso  wrote:
>>
>> 2009/11/12 Daniel Castelo :
>> > In a short term we are thinking in develop an activity to interact with
>> > wwdial. In the future we are planning to test Sugar 0.8x and Network 
>> > Manager
>> > 0.7, and change our activity to interact with networkmanager. We should
>> > investigate the way to interact with networkmanager (a set of APIs or
>> > something like that).
>>
>> Have you considered adding support for modems in the Sugar shell
>> instead of coding a new activity? That would be more in line with
>> Sugar's user experience.
>>
>> Regards,
>>
>> Tomeu
>>
>> > Regards.
>> > Daniel
>> >
>> > On Fri, Nov 6, 2009 at 11:03 AM, Tomeu Vizoso 
>> > wrote:
>> >>
>> >> On Thu, Nov 5, 2009 at 16:51, Daniel Castelo
>> >>  wrote:
>> >> > I forgot to say you something important: !!!  thanks for your help!!!
>> >>
>> >> Welcome, how did you got this working?
>> >>
>> >> Thanks,
>> >>
>> >> Tomeu
>> >>
>> >> > On Mon, Oct 26, 2009 at 5:44 PM, Dan Williams 
>> >> > wrote:
>> >> >>
>> >> >> On Sun, 2009-10-25 at 09:39 +0100, Tomeu Vizoso wrote:
>> >> >> > On Wed, Oct 21, 2009 at 21:07, Dan Williams 
>> >> >> > wrote:
>> >> >> > > On Wed, 2009-10-21 at 13:46 +0100, Tomeu Vizoso wrote:
>> >> >> > >> On Wed, Oct 21, 2009 at 13:41, Daniel Castelo
>> >> >> > >>  wrote:
>> >> >> > >> > Sorry, just a distraction.
>> >> >> > >> > Is the image that we use in Uruguay, and doesn't have the
>> >> >> > >> > root
>> >> >> > >> > access
>> >> >> > >> > available.
>> >> >> > >> > Network manager supports connections with a modem 3g?
>> >> >> > >>
>> >> >> > >> Current versions of NetworkManager do, but if it's the image
>> >> >> > >> now used
>> >> >> > >> in Uruguay (based in Fedora 9), then it may be too old.
>> >> >> > >
>> >> >> > > What version of NM ships on those?  NM 0.6x like we originally
>> >> >> > > shipped
>> >> >> > > in the images in 2007/2008?  Or were Simon and Daniel able to
>> >> >> > > update
>> >> >> > > them to NM 0.7.x?
>> >> >> >
>> >> >> > This is F9 with NM 0.6.5-0.12.svn3246.olpc3 . I think NM 0.7
>> >> >> > support
>> >> >> > was added to Sugar 0.84 which hasn't gone into an official OLPC
>> >> >> > image
>> >> >> > yet.
>> >> >>
>> >> >> Ok, only NM 0.7.x and later support 3G.  So it looks like they will
>> >> >> have
>> >> >> to wait for an official image, or install the NM 0.7.x ones by hand.
>> >> >>
>> >> >> Dan
>> >> >>
>> >> >> > Regards,
>> >> >> >
>> >> >> > Tomeu
>> >> >> >
>> >> >> > > Dan
>> >> >> > >
>> >> >> > >> I'm CC'ing Dan Williams who is the main author of NM in case he
>> >> >> > >> can
>> >> >> > >> suggest you a way forward.
>> >> >> > >>
>> >> >> > >> Regards and good luck,
>> >> >> > >>
>> >> >> > >> Tomeu
>> >> >> > >>
>> >> >> > >> > Thanks for your help
>> >> >> > >> >
>> >> >> > >> >

[Sugar-devel] sugar-toolkit and sugar-base branched for 0.86

[Tomeu Vizoso]

Hi,

have just created the sucrose-0.86 branch in sugar-toolkit and
sugar-base. Development for 0.86 will happen in sucrose-0.86 and for
0.88 in master.

Regards,

Tomeu

-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] abiword collaboration in soas 2 (was Fwd: [Bug 491466] abiword's collaboration won't work in the Sugar environment)

[Tomeu Vizoso]

Hi,

could someone confirm that we are using libabiword from the fedora
repo and that collaboration works in the F12-based SoaS?

Thanks,

Tomeu

-- Forwarded message --
From:  
Date: Fri, Nov 20, 2009 at 11:44
Subject: [Bug 491466] abiword's collaboration won't work in the Sugar
environment
To: to...@sugarlabs.org


Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=491466





--- Comment #11 from Peter Robinson   2009-11-20
05:44:56 EDT ---
Is this now fixed?

--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You reported the bug.



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Rationale behind the JSON -> CJSON switch in Sugar codebase?

[Tomeu Vizoso]

On Fri, Nov 20, 2009 at 02:34, James Cameron  wrote:
> On Thu, Nov 19, 2009 at 03:11:07PM +0100, Tomeu Vizoso wrote:
>> 2009/11/13 Jonas Smedegaard :
>> > Generally, I recommend Sugarlabs to document clearly in source of
>> > the various components (e.g. in an INSTALL file) which versions of
>> > Python the code is expected to work against, and which version has
>> > been extensively tested.
>>
>> We have http://wiki.sugarlabs.org/go/0.86/Platform_Components for
>> that, maybe we can point to that page in the INSTALL files of all
>> Sugar modules?
>
> I'm releaser of pptp and pptpd, and if I referred to Wiki pages for
> build instructions, dependencies or test results external to my source
> repository or tarball, I'm sure I'd get a few raised eyebrows or
> complaints.
>
> Is there a reason why you don't want to have these dependencies or known
> test results in the source?  If they are not available at the time of
> release, that's a good reason.  In which case saying that in INSTALL is
> also a good idea.

No, I would like to do anything that help packagers do their job. It's
just that the Sugar module maintainers are generally people who have
accumulated too many functions and making them keep those files
updated with the wiki just increases the burden on them.

But of course, anyone can open tickets with patches, as a reminder and
as a way of facilitate their work.

Regards,

Tomeu

-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Python 2.6 for 0.88 (was: Re: Rationale behind the JSON -> CJSON switch in Sugar codebase?)

[Tomeu Vizoso]

On Thu, Nov 19, 2009 at 16:24, Sascha Silbe
 wrote:
> On Thu, Nov 19, 2009 at 03:11:05PM +0100, Tomeu Vizoso wrote:
>
>>> Unfortunately not all distros ship Python 2.6 yet, most notably Debian.
>>> So we need to at least fall back to simplejson for those.
>>
>> Sounds good to me, so maybe we can ask for a minimum of 2.6 for 0.88?
>
> As mentioned Debian still doesn't include 2.6 even in unstable, so AFAICS it
> probably won't get into squeeze. Debian is going to continue with the (more
> or less) regular 2 year release cycle after squeeze, so we're going to be
> stuck with 2.5 for quite a while. I don't particularly like that, but can't
> do anything about it.
>
> Is there anything in 2.6 that's
> a) very useful for Sugar but
> b) doesn't have an easy enough fallback?

Generally, easy fallbacks can be found, the problem is cluttering the
source with those.

Regards,

Tomeu

> CU Sascha
>
> --
> http://sascha.silbe.org/
> http://www.infra-silbe.de/
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iQEcBAEBAgAGBQJLBWNGAAoJELpz82VMF3DavGAH/2tyAi7mnF+bO1X5SK6ZS06a
> oSd4hzLFZk+YoXtJZpBEeWnBGvuBk0sPYIRQb3P86zut7L6W6KLyaF8CHdHzEdYc
> Y0D1c3t5Fl81rZWFBcbS9rEdWd+zlCaCAptk5EoWFkbzr93TIz3faBBCOExkyrI4
> p4micC8ueAikfmhkA4w48OJLAcDti9A0i+t0DnDqzwdKs2gqJQ8kaRLwQSmimUMA
> L/dkmvey44KbXc10+ULXfxblX4jG/GAMYqHftXFLvm8VB8MV/pL/cA0krG3iygwh
> qYyyds70KGevpHhzPPxcdu1zFxzju/WGikFaAJ9zkg6dUQwB3zKSOBDxXbC0r5Y=
> =op7Y
> -END PGP SIGNATURE-
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Rationale behind the JSON -> CJSON switch in Sugar codebase?

[Tomeu Vizoso]

On Thu, Nov 19, 2009 at 15:53, Jonas Smedegaard  wrote:
> On Thu, Nov 19, 2009 at 03:11:05PM +0100, Tomeu Vizoso wrote:
>>
>> 2009/11/13 Sascha Silbe :
>>>
>>> On Fri, Nov 13, 2009 at 10:12:11AM +, Daniel Drake wrote:
>>>
>>>>> As Tomeu mentions, Python 2.6 reduces the cjson/json performance
>>>>> advantage.
>>>>
>>>> OK, didn't see this. Yes, using python standard library seems like the
>>>> way to go.
>>>
>>> Unfortunately not all distros ship Python 2.6 yet, most notably Debian.
>>> So we need to at least fall back to simplejson for those.
>>
>> Sounds good to me, so maybe we can ask for a minimum of 2.6 for 0.88? How
>> well that plays with Debian and its derivatives?
>
> I recommend you to not tune into specific needs of Debian or other
> particular distros, but aim generally at the FLOSS world.
>
> Generally, the faster you tighten the requirements, the more do you
> discourage the use of long-term supported systems.  Which is bad for
> deployers, especially those with few resources!
>
> So please include fallbacks when using features available only in newer
> backend libraries.  Not to play nice with Debian, but to play nice with
> "slow movers".

I see the value in playing nice with "slow movers" but there's also a
cost to be paid by both upstream and other distros, so if we can get a
better idea of what we actually gain, we can better find the sweetest
spot between old and recent dependencies.

Regards,

Tomeu

>
>  - Jonas
>
> --
> * Jonas Smedegaard - idealist & Internet-arkitekt
> * Tlf.: +45 40843136  Website: http://dr.jones.dk/
>
>  [x] quote me freely  [ ] ask before reusing  [ ] keep private
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iQIcBAEBCgAGBQJLBVvTAAoJECx8MUbBoAEhsisQAJKJPFTsWJZpbuwx0TiNAMm8
> t6ruywDn9rBz+g82qX6I9TS6QLQM6orbYsG8Sr9qLHIBT99zFPKvOS3mPxxZ+E67
> SCC9eLMeNHgfqkQdmH3tc0anSYirdsJtAMBJFQ28FNJ0LsnEd0dkqRlnr0NpVCPC
> Fv0tSz2X5M7J/+ZntBpkjbKCXmlGvPbGN7K6maegYgDFrEbUJHOQDg9GRlNURqfv
> 7QWRQ8ugDwc1J4dpkm+Wv+hAGOJMN1bri8z86+I+6MLMVu2E/G7782dnE3la2r7P
> JqNoZ0LJhOXFtex5Z+eYdrusyuHL6tvyG3Rq9QW9E9EIxsknzvvcNOvjcyVye8vV
> /xd1hqmQfuliYhZgTf0y9uZXHqiQC38vY9+DsDx1qIUoM0wli3TPpR90eWJbWuam
> EwbNBTvN9SeRCiQlZ4zOLqArBkzTBm/hgFdcEyLknZNzeYzrxEvXMZMcAC3ELTO8
> 1qugKtaoQPHWga9+mqVWHQaIKYirgg5C2pvon5JpPgd4p/Hm8jn61TkDsEJh+k07
> pzELul5atea+RxJ6N8wekJ7uk9fzKdigP07W9X+v7ED0eqeLiQsBzUwWJFb44zp1
> YwYDAbHrY/YQ+Gv5q3BBQ11miJ5FGkwS0bQeHRlTaHjnXTgfKQTGWiOa9hnDB3fh
> MdATnKjuBe0GtpH2wMry
> =sWVX
> -END PGP SIGNATURE-
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] configuring Socksproxy for Jabber Server on the XO-1 or XO-1.5

[Tomeu Vizoso]

2009/11/18 Manusheel Gupta :
> Hi Tomeu,
>
> We did try to search around but have not been able to make much progress 
> towards configuring socks proxy on the XOs. Are you aware if someone would 
> have tried this
> before?

Just to be sure, you want to tell the presence service to connect to a
ejabberd server through SOCKS?

> On a separate note, https-proxy works well for all data oriented connections 
> using https protocol. Foxyproxy is another interesting Mozilla plug-in we are 
> looking forward to explore.

And with this you mean that you have managed to tell Browse to use a
SOCKS server to access web pages?

Thanks,

Tomeu

> Copying Morgan on the thread.
>
> Regards,
>
> Manu
>
>
>
>
>
>
> On Wed, Nov 18, 2009 at 11:44 PM, Tomeu Vizoso  wrote:
>>
>> 2009/11/15 Manusheel Gupta :
>> > Dear all,
>> >
>> > Do we have documentation somewhere on the steps involved in configuring 
>> > socksproxy for jabber server on the XO-1 or XO-1.5? Please let us know.
>>
>> Hi Manu,
>>
>> have you done any progress on this since then?
>>
>> Thanks,
>>
>> Tomeu
>>
>> > Thank you.
>> >
>> > Regards,
>> >
>> > Manu
>> >
>> >
>>
>>
>>
>> --
>> «Sugar Labs is anyone who participates in improving and using Sugar.
>> What Sugar Labs does is determined by the participants.» - David
>> Farning
>
>



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Sugarizing an application

[Tomeu Vizoso]

2009/11/12 Daniel Castelo :
> In a short term we are thinking in develop an activity to interact with 
> wwdial. In the future we are planning to test Sugar 0.8x and Network Manager 
> 0.7, and change our activity to interact with networkmanager. We should 
> investigate the way to interact with networkmanager (a set of APIs or 
> something like that).

Have you considered adding support for modems in the Sugar shell
instead of coding a new activity? That would be more in line with
Sugar's user experience.

Regards,

Tomeu

> Regards.
> Daniel
>
> On Fri, Nov 6, 2009 at 11:03 AM, Tomeu Vizoso  wrote:
>>
>> On Thu, Nov 5, 2009 at 16:51, Daniel Castelo
>>  wrote:
>> > I forgot to say you something important: !!!  thanks for your help!!!
>>
>> Welcome, how did you got this working?
>>
>> Thanks,
>>
>> Tomeu
>>
>> > On Mon, Oct 26, 2009 at 5:44 PM, Dan Williams  wrote:
>> >>
>> >> On Sun, 2009-10-25 at 09:39 +0100, Tomeu Vizoso wrote:
>> >> > On Wed, Oct 21, 2009 at 21:07, Dan Williams  wrote:
>> >> > > On Wed, 2009-10-21 at 13:46 +0100, Tomeu Vizoso wrote:
>> >> > >> On Wed, Oct 21, 2009 at 13:41, Daniel Castelo
>> >> > >>  wrote:
>> >> > >> > Sorry, just a distraction.
>> >> > >> > Is the image that we use in Uruguay, and doesn't have the root
>> >> > >> > access
>> >> > >> > available.
>> >> > >> > Network manager supports connections with a modem 3g?
>> >> > >>
>> >> > >> Current versions of NetworkManager do, but if it's the image now used
>> >> > >> in Uruguay (based in Fedora 9), then it may be too old.
>> >> > >
>> >> > > What version of NM ships on those?  NM 0.6x like we originally shipped
>> >> > > in the images in 2007/2008?  Or were Simon and Daniel able to update
>> >> > > them to NM 0.7.x?
>> >> >
>> >> > This is F9 with NM 0.6.5-0.12.svn3246.olpc3 . I think NM 0.7 support
>> >> > was added to Sugar 0.84 which hasn't gone into an official OLPC image
>> >> > yet.
>> >>
>> >> Ok, only NM 0.7.x and later support 3G.  So it looks like they will have
>> >> to wait for an official image, or install the NM 0.7.x ones by hand.
>> >>
>> >> Dan
>> >>
>> >> > Regards,
>> >> >
>> >> > Tomeu
>> >> >
>> >> > > Dan
>> >> > >
>> >> > >> I'm CC'ing Dan Williams who is the main author of NM in case he can
>> >> > >> suggest you a way forward.
>> >> > >>
>> >> > >> Regards and good luck,
>> >> > >>
>> >> > >> Tomeu
>> >> > >>
>> >> > >> > Thanks for your help
>> >> > >> >
>> >> > >> >
>> >> > >> > On Wed, Oct 21, 2009 at 10:26 AM, Tomeu Vizoso
>> >> > >> >  wrote:
>> >> > >> >>
>> >> > >> >> On Wed, Oct 21, 2009 at 13:22, Daniel Castelo
>> >> > >> >>  wrote:
>> >> > >> >> > OLPC release 9 (Joyride).  is enough?
>> >> > >> >>
>> >> > >> >> Sorry, not sure to what image that may correspond. Can you tell me
>> >> > >> >> how
>> >> > >> >> that image can be acquired? Depending on the configuration, root
>> >> > >> >> access may be available or not.
>> >> > >> >>
>> >> > >> >> But James' suggestion is good, if you can do it via
>> >> > >> >> NetworkManager,
>> >> > >> >> then you can work around the root limitation.
>> >> > >> >>
>> >> > >> >> Also, please don't drop the mailing list from the email recipients
>> >> > >> >> (do
>> >> > >> >> "reply all" instead of just replying to me).
>> >> > >> >>
>> >> > >> >> Regards,
>> >> > >> >>
>> >> > >> >> Tomeu
>> >> > >> >>
>> >> > >> >> > On Wed, Oct 21, 2009 at 10

Re: [Sugar-devel] Rationale behind the JSON -> CJSON switch in Sugar codebase?

[Tomeu Vizoso]

2009/11/13 Jonas Smedegaard :
> On Fri, Nov 13, 2009 at 01:10:35PM +0100, Sascha Silbe wrote:
>>
>> On Fri, Nov 13, 2009 at 10:12:11AM +, Daniel Drake wrote:
>>
 As Tomeu mentions, Python 2.6 reduces the cjson/json performance advantage.
>>>
>>> OK, didn't see this. Yes, using python standard library seems like the way 
>>> to go.
>>
>> Unfortunately not all distros ship Python 2.6 yet, most notably Debian. So 
>> we need to at least fall back to simplejson for those.
>
> Generally, I recommend Sugarlabs to document clearly in source of the various 
> components (e.g. in an INSTALL file) which versions of Python the code is 
> expected to work against, and which version has been extensively tested.

We have http://wiki.sugarlabs.org/go/0.86/Platform_Components for
that, maybe we can point to that page in the INSTALL files of all
Sugar modules?

> One thing is that Debian do not currently ship Python 2.6 as default version 
> of Python.  Another is that we ship multiple versions concurrently, and 
> attempt[1] to allow users to choose at runtime.
>
> Currently I package Sugar packages with the assumption that they all work 
> with Python 2.5 and newer - but it would sure be better if you explicitly 
> stated which version were a) believed working and b) actually tested.

2.5 is all we have required to date, AFAIK.

> ...or that you provide refression tests, so that distributors can 
> automatically discover if some odd setup suddently stop working at a "minor" 
> Sugar update.

We really need that, though I think that we should first get a more
normal ratio of maintainers per module before we raise the
expectations of packagers.

Regards,

Tomeu

>
>  - Jonas
>
> [1] it is often difficult to package for multiple Python releases, so some 
> package maintainers choose the easier approach of only packaging for whatever 
> is the default version (which allows Ubuntu to switvh to their often newer 
> default version with a simple rebuild of same packaging, but does not allow 
> users at runtime to switch to a different version for that Python module - 
> and all dependent modules).
>
> --
> * Jonas Smedegaard - idealist & Internet-arkitekt
> * Tlf.: +45 40843136  Website: http://dr.jones.dk/
>
>  [x] quote me freely  [ ] ask before reusing  [ ] keep private
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iQIcBAEBCgAGBQJK/WJvAAoJECx8MUbBoAEht5MP/jMSQ7WlDVmxbVjOQmje6jpd
> 08y+EulLZ3HnM0f+HrIDlxqXjFrdjam3dn6gBaLYx6OdZ6rAwLiZtpAUtcE2LLp4
> i5ykvuCOSiePVPCRY7PpaskGNy7s8lgc3mrGSz9mOyQageqjOa+mVhrVL4joHLL0
> vqK1Y/jBl2IzKEcYGZnlTn5y5ZK42OXSwzpGPiDcn9i0sco2+tuLz/4PEeVZKy2q
> k/SIFXtgMXl1RRsR6QuIg4zwVeZopQnvCMxdjrLdXH+OfjHOv1TvTzkZF24iH9/p
> SYS8ZrtvPbCDgShgo3G4NIYj+MMbcXp9rT9bH6Z70nyKavO5SzPI/UAonB7LgNkZ
> ZBoq5mz1ZXNqhb7kW/D1nz9t33PPikBQ+Fnuy4JUZFBYKx9UueBHxueMoCw/cm5D
> BjNFUhfQD6vCfH5g4MzXgQ0TvSmW4bJLfvJpRIF0DnLQSl6nileiO1RV2li+Oiix
> itM5yHJlY4DbhZpKYw38AWNGVDZSv/+4+8aLs6lfr3PGMGj47Vqok/ENftkqBY0x
> 2bmekjv0+391LzOkKTqRfptAMBl4rswR7aZjEiuqfiWYK7XtPKPOUJXT9ELV82fK
> suyuGVmlBVeeFif1ATzx++pjjDaEovXAXAh25wHBfnAAg97rdyuJBfUFX11j97Z2
> jgt7n4LsnbtSumeTxjQo
> =w3U6
> -END PGP SIGNATURE-
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Rationale behind the JSON -> CJSON switch in Sugar codebase?

[Tomeu Vizoso]

2009/11/13 Sascha Silbe :
> On Fri, Nov 13, 2009 at 10:12:11AM +, Daniel Drake wrote:
>
>>> As Tomeu mentions, Python 2.6 reduces the cjson/json performance advantage.
>>
>> OK, didn't see this. Yes, using python standard library seems like the
>> way to go.
>
> Unfortunately not all distros ship Python 2.6 yet, most notably Debian. So we 
> need to at least fall back to simplejson for those.

Sounds good to me, so maybe we can ask for a minimum of 2.6 for 0.88?
How well that plays with Debian and its derivatives?

Regards,

Tomeu

> CU Sascha
>
> --
> http://sascha.silbe.org/
> http://www.infra-silbe.de/
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iQEcBAEBAgAGBQJK/Uy7AAoJELpz82VMF3DaVrgH/3eITIQpsTw69cnj17uNtp3s
> H68eBr/0MNUig0SxbT5pHfHoWshykYr0xet/5O/SqmWfBrv43VG1pGee1bqHEDOq
> /+8lGF0WRjOYWMFhtld5g8TEhT9mnDzrdqYVi9NqXSEszF5qyovRI8h6IbxNiT3M
> rlKOUWPmFDroOOKloqoMh5Z1ChxltGECXeblSs7mX6S6CUf4awM4xuljMyfB4WLP
> 597Oeqz33F7iQqdVhnhUoAavf/hM7NV3LNRulD3uLDfDjHrCZejrel1YXV4ZFw3G
> dQhKs6MunV0YAhIhZbAA8PGZT58xgWDoYB1qWTBFtW5cGjYJmbiYP41JC1dwq1c=
> =8WBF
> -END PGP SIGNATURE-
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [Bugs] #1447 NORM: Display a message when an activity fails to start

[Tomeu Vizoso]

2009/11/4 Gary C Martin :
> Hi Wade,
>
> Just wanted to ping on this; have been running with your 0001-Notify-
> shell-when-activity-process-terminates.patch and 0001-Added-Close-
> button-to-activity-launcher-rewrote-lay.patch applied to sugar-jhbuild
> for the last ~4 days, and it has been working very well. Some of quick
> comments:
>
> - On just one occasion (have not been able to reproducible) I saw the
> 'Stop' button briefly display before the activity successfully launched.
>
> - I'm trying to find a different error message ' failed to
> start.' now that 'Stop' is the button text. My mind keeps grating
> against the dilemma of stopping something that never actually
> started :-)
>
> - The pulse pause feels a little long, perhaps 1 or 1.5 sec would be
> long enough. I really need to try and get this patch on XO-1 HW and
> see what the launch time savings are like (I'm sure even a 1:1 ratio
> of animation to pause should save us a couple of 2 seconds in many
> cases).
>
> - What ever the final pulse animation timing/pause ends up at
> (assuming we see some XO-1 load improvement) it should also be used
> for the other pulsing animations as well (activity tray activity icons
> when launching, corner notification effects).
>
> Again, fab work! It really makes activity developing test cycle much
> more friendly :-)

So, do we have a positive vote from the design team on this? Wonder
what would be the best way to get some feedback from the field, is
there already a screencast we can pass around?

Thanks,

Tomeu

> Regards,
> --Gary
>
> On 31 Oct 2009, at 02:06, Sugar Labs Bugs wrote:
>
>> #1447: Display a message when an activity fails to start
>> 
>> +---
>>    Reporter:  wadeb        |          Owner:  wadeb
>>        Type:  enhancement  |         Status:  accepted
>>    Priority:  Normal       |      Milestone:  0.88
>>   Component:  sugar        |        Version:  Git as of bugdate
>>    Severity:  Unspecified  |       Keywords:
>> Distribution:  Unspecified  |   Status_field:  Unconfirmed
>> 
>> +---
>>
>> Comment(by wadeb):
>>
>> I posted a brand new patch for Sugar.
>>
>>  * Improves the layout so the icon doesn't move when the error appears
>>  * Uses Stop as suggested by Gary
>>  * Delays for a few seconds between pulses to give the user
>> something to
>> count and potentially improve performance.
>>
>> --
>> Ticket URL: 
>> Sugar Labs 
>> Sugar Labs bug tracking system
>> ___
>> Bugs mailing list
>> b...@lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/bugs
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Generating pot file for I18N

[Tomeu Vizoso]

2009/11/9 Henning Bredel :
> Sorry, for replying myself.
>
> On Sun, 2009-11-08 at 16:54 +0100, Henning Bredel wrote:
>> I debugged the code and it seems that bundlebuilder.py is only
>> collecting filenames instead of taking possible relative paths
>> of each file within a submodule.
>
> I meant subpackage of course! All modules within their own sub-
> package aren't recognized.
>
> I'm not sure, if structuring an activity in subpackages are a
> common way in developing activities. Anyway, these subpackages
> mean to be plugin modules extending the actual activity. Would
> it be a better way to structure that in eggs? (Just read about
> that and I thought, this could be a cleaner separation of all
> the code).
>
> What do you think about that?

I think using submodules for better organizing of code is a good idea
and would be surprised if other activities weren't doing that already.
I'm CC'ing this email to more relevant mailing lists in the hope that
you'll get a better reply.

Regards,

Tomeu

-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] configuring Socksproxy for Jabber Server on the XO-1 or XO-1.5

[Tomeu Vizoso]

2009/11/15 Manusheel Gupta :
> Dear all,
>
> Do we have documentation somewhere on the steps involved in configuring 
> socksproxy for jabber server on the XO-1 or XO-1.5? Please let us know.

Hi Manu,

have you done any progress on this since then?

Thanks,

Tomeu

> Thank you.
>
> Regards,
>
> Manu
>
>



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] build for xo-1 fails

[Tomeu Vizoso]

Hi Bert,

can you give more details of what you are trying to accomplish?

Thanks,

Tomeu

2009/11/14 Bert Desmet :
> Hi,
>
>        I'm trying to build the newest image for the XO-1, but the build
>        always
>        fails with the message: Error creating Live CD :  Unable to
>        downlad from
>        repo: cannot retrieve repository metadate (repomd.xml) for
>        repository:
>        olpc. please verify its path and try again.
>
>        Retrieving
>        
> http://ftp.ps.pl/pub/Linux/fedora-linux/releases/11/Everything/i386/os/repodata/repomd.xml
>  ...OK
>        Retrieving
>        
> http://ultra.linux.cz/MIRRORS/fedora.redhat.com/linux/updates/11/i386/repodata/repomd.xml
>  ...OK
>        Retrieving
>        
> http://ftp.heanet.ie/pub/fedora/linux/updates/testing/11/i386/repodata/repomd.xml
>  ...OK
>        Retrieving
>        
> http://fr2.rpmfind.net/linux/fedora/updates/testing/11/i386/repodata/b882789fb82a1c14adef91e43c8bab2ada872c62b409b1e6ba84de6f488b011e-primary.sqlite.bz2
>  ...OK
>        /usr/lib/python2.6/site-packages/imgcreate/errors.py:45:
>        DeprecationWarning: BaseException.message has been deprecated as
>        of
>        Python 2.6
>          return unicode(self.message)
>        Error creating Live CD : Unable to download from repo : Cannot
>        retrieve
>        repository metadata (repomd.xml) for repository: olpc. Please
>        verify its
>        path and try again
>
>
>        what should I use as path then?
>
>        regards,
>        Bert
>
>
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Testing changes (was Re: RFC: Kill the delayed menus for good)

[Tomeu Vizoso]

2009/11/5 Edward Cherlin :
> We need at least one more hat (in addition to those described below),
> which I am willing to put on. Somebody needs to coordinate field
> testing and feedback, so that we have data to make decisions from, or
> we can get appropriate data when they are not yet available.
>
> It is not enough to have a coordinator, of course. We must have
> populations of users (various ages, various countries, in some cases
> various disabilities) approved for testing (at least by themselves, by
> their teachers, and by any administrators with responsibility for
> them). We must have people willing and able to install, de-install,
> and monitor changes. We must have a place to put raw data and results.
> We may occasionally need a tool built. We seem to have no shortage of
> ideas, or even patches, but I am willing to hear more on that point.
> There is more, but that would be sufficient for getting started.
>
> If the developers are willing to get their part organized, I will take
> this question to  iaep and grassroots, and to management, and see
> whether we can get covered at the user end or anything else that
> people think of. Oh, yes. Experiment designers and the like from Ed
> schools.

Having someone coordinating this area would be of great help, but I'm
worried about forgetting that perfect is the enemy of good. As
starters, I think we just need to get some opinions from deployers,
developers, testers and UI designers and make sure that any technical
decision (such as pushing code) is made after taking into account that
feedback.

Once we have this working, we can start thinking about how to make the
feedback we get from those groups more relevant and of more quality.

Regards,

Tomeu

> I'm delighted to see these discussions making progress. I have long
> detested the unfolding hover menus. Keep it up, but please don't take
> any of it personally.
>
> On Sat, Oct 17, 2009 at 10:44, C. Scott Ananian  wrote:
>> On Sat, Oct 17, 2009 at 2:15 PM, Michael Stone  wrote:
 ps. I've found the discussion of ideas here much more interesting than
 the finger-pointing.
>>>
>>> Understandable; thanks for providing this feedback. Are there specific
>>> ideas that have come up in this thread other than the one that Wade
>>> supplied that you have found particularly thought-provoking?
>>
>> In general, revisiting the "why" and attempts to discover different
>> solutions which achieve the original goals.  Like Martin Dengler, I
>> find myself convinced all over again when I revisit the original
>> motivation.  Real world feedback indicates, however, that the current
>> behavior frustrates some users, despite "best laid plans".  It's
>> obviously time to return to the "why" and come up with different ways
>> to accomplish those goals.  (Discussion which is simply "I want X"
>> without a consideration of how this relates to the design goals is
>> much less interesting -- I won't say useless, but it begs for someone
>> to contextualize it and provide the missing rationale before it fits
>> well into the conversation I would like to be having.)
>>
 Attempts to shift responsibility (it's my patch,
 YOU have to prove that it's wrong -vs- it's my design, YOU have to
 prove that it's wrong) are productive/necessary to some degree, but a
 family matter you guys should take out back somewhere to hash out.
>>>
>>> Do you have a recommendation on where "out back" would be? Some other
>>> mailing list? Private conversation?
>>
>> If it's a truely personal matter, private email (or some physical
>> location where you can sit down together for a beer).  If it's about
>> hashing out a philosophy of participation, then mixing it together
>> with discussion of UI changes is not helping either conversation
>> progress.  Sometimes you can't do two things at once, but you can do
>> them separately.
>>
>>> I understand you to be saying that we should be listening to people with
>>> the experience necessary to have informed opinions. Is this a fair
>>> summary of your position?
>>
>> Not necessarily.  My position is that there's an interesting UI
>> discussion largely buried in this thread.  There's also a
>> community/contribution/patch-approval conversation which I don't have
>> any strong opinion on.  Finally, there's a meta-topic revealing some
>> splits within the community which I do have some thoughts on.
>>
>> I am currently working on a(nother) strongly design-oriented
>> "bottom-up" UI, and it has reminded me that such development *can*
>> work.  Having a strongly coherent "user story" and regular feedback
>> from those users *is* really important. That said, unfiltered user
>> opinions are often short-sighted.  You really do need a "designer"
>> role: some group of people who can keep the overall goals in mind and
>> maintain overall direction.  Some problems need evangelism, some
>> problems need design fixes, some problems are unexpected/unresolved,
>> some problems are "won't fix" (propo

Re: [Sugar-devel] Rationale behind the JSON -> CJSON switch in Sugar codebase?

[Tomeu Vizoso]

On Fri, Nov 13, 2009 at 12:01, Daniel Drake  wrote:
> On Fri, 2009-11-13 at 11:50 +0100, Tomeu Vizoso wrote:
>> For past stable releases, deployers are the ones who should know best.
>> If you are talking about 0.82, then we should go back to use
>> simplejson. If this is 0.84 on F11, then we can use what python 2.6
>> provides.
>
> 0.82 doesn't have this bug - we're talking about an 0.84 regression
> introduced by the post-0.82 switch to cjson, right?

Sorry I'm not following this issue close enough.

> If I'm going to maintain 0.84 further then the a requirement for
> anything included should be that it is already included in git master.
> So I'd still like your input on this, please, since we also want to fix
> in current/future releases :)

Sure, just attach a patch and mark the ticket with r?, I also
appreciate if people ping me whenever I lag behind review.

Thanks,

Tomeu

-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Rationale behind the JSON -> CJSON switch in Sugar codebase?

[Tomeu Vizoso]

2009/11/12 Lucian Branescu :
> The json module (simplejson) has only the parser written in C, so it's
> still slower overall than cjson. Not by a lot, but measurable.

Well, we don't really care about overall slowness, but only if it's
fast enough for our actual use of it. In this case, we only care about
fast parsing of small json files in 0.82.

Regards,

Tomeu

> 2009/11/12 Martin Langhoff :
>> On Thu, Nov 12, 2009 at 4:59 PM, Martin Langhoff
>>  wrote:
>>> Then maybe yes, I am seeing a bug in cjson that parses 'foo\/bar' 
>>> incorrectly.
>>
>> Confirmed. In a python session:
>>
> json.loads('"foo\/bar"')
>> u'foo/bar'    <== correct
> cjson.decode('"foo\/bar"')
>> 'foo\\/bar'   <== incorrect
>>
>>
>>
>> m
>> --
>>  martin.langh...@gmail.com
>>  mar...@laptop.org -- School Server Architect
>>  - ask interesting questions
>>  - don't get distracted with shiny stuff  - working code first
>>  - http://wiki.laptop.org/go/User:Martinlanghoff
>> ___
>> Sugar-devel mailing list
>> Sugar-devel@lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>
>



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Rationale behind the JSON -> CJSON switch in Sugar codebase?

[Tomeu Vizoso]

2009/11/13 Martin Langhoff :
> On Thu, Nov 12, 2009 at 4:40 PM, Tomeu Vizoso  wrote:
>> Right now just using the json module in python 2.6 may be best as the
>> parser is a C module (AFAIR).
>>
>> Is because of a bug in cjson why those files aren't being parsed?
>
> Re-reading this -- and given that yes, it's a bug in the cjson parser
> -- probably a revert is the sanest thing to do.
>
> Do you agree?

For past stable releases, deployers are the ones who should know best.
If you are talking about 0.82, then we should go back to use
simplejson. If this is 0.84 on F11, then we can use what python 2.6
provides.

Daniel has taken over maintenance of 0.84 so it's him to decide. And
if someone would like to take maintenance of the 0.82 branch (someone
from a deployment?), then the better.

Regards,

Tomeu

-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel