Re: [Sugar-devel] [IAEP] Tech roadmap

[David Farning]

I agree :)

Right now, we are sitting back and seeing what roll OLPC-Australia is
going to play in the ecosystem. The One Education distribution out of
Australia is a combination of Dextrose, Sugar .100 and some custom
patches. My semi-informed guess is that Walter and Rangan (
https://www.laptop.org.au/about ) are going to position One Education
as the successor to OLPC-OS. I hope that we will learn more at about
their plans at basecamp. ( http://olpcbasecamp.blogspot.com/ ) This
would take care or the leading edge on Fedora.

On the Ubuntu side we have a bit of a challenge balancing bleeding
edge and stability. Sugar and Fedora tend to run a bit ahead of Debian
and Ubuntu in library versions. It take a significant amount of effort
to backport the necessary libraries to Ubuntu LTS. For this release we
agreed that the proper balance of innovation and stability was Sugar
.98 on Ubuntu 12.04. The next decision point will be which version of
Sugar to use for the 14.04 release due in the second quarter of 2014.

On Wed, Nov 6, 2013 at 8:05 PM, Daniel Narvaez  wrote:
> Cool stuff.
>
> As for Fedora it would be great to have builds with the latest sugar (stable
> and unstable) releases. I'm not saying to ship those to deployments of
> course, but they would help upstream development, marketing and testing...
> And they would help AC to make the transition to the next sugar release
> smoother.
>
> On 7 November 2013 02:05, David Farning 
> wrote:
>>
>> Please see the link at the bottom left of http://dextrose.ac/platform/
>> for the Sugar on Ubuntu images which Activity Central and Plan Ceibal
>> are jointly developing.
>>
>> For stability it is based on Ubuntu 12.04 and Sugar .98. The testing
>> is done on classmate to meet Plan Ceibal's specifications. I should
>> work equally well on any machine that boots Ubuntu.
>>
>> It is currently is small scale testing by a couple hundred teachers.
>> When the image meets Ceibal's quality standards the pilot will scale
>> to approximately 10,000 units for wider testing.
>>
>> For more information, I have CC Anish Mangal, the project owner (agile
>> speak) and Ruben Rodriguez the lead developer. Ruben has the strongest
>> back ground on the technical issues involved in the port. Anish has
>> the deepest understanding of timelines and objectives.
>>
>> On Wed, Nov 6, 2013 at 9:31 AM, Daniel Narvaez 
>> wrote:
>> > On 6 November 2013 16:20, Manuel Quiñones  wrote:
>> >>
>> >>
>> >> > Classmates are basically just x86 netbooks, I've not tried it as I
>> >> > don't have HW but I don't see any reason they shouldn't work OOTB.
>> >>
>> >> Yep. Sugar is running in classmates out of the box.  In Uruguay for
>> >> example.
>> >
>> >
>> > You mean people are using them in Uruguay deployments? Which distro?
>> >
>> > ___
>> > Sugar-devel mailing list
>> > Sugar-devel@lists.sugarlabs.org
>> > http://lists.sugarlabs.org/listinfo/sugar-devel
>> >
>>
>>
>>
>> --
>> David Farning
>> Activity Central: http://www.activitycentral.com
>
>
>
>
> --
> Daniel Narvaez



-- 
David Farning
Activity Central: http://www.activitycentral.com
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Have we achieved consensus among activite Sugar developers? [ Sugar-devel Digest, Vol 61, Issue 21]

[Sebastian Silva]

El 06/11/13 10:00, Daniel Narvaez escribió:
On 6 November 2013 07:15, Sebastian Silva > wrote:


I too feel the overall attitude within this list has been
dismissive of
non-conforming ideas and individuals, sometimes bluntly. The spanish
speakers, from Xavi who did so much translation, to Homunq who
started (and abandoned) Develop Activity, to Yama whose ideals always
seemed to clash with reality, I miss them. I myself have been often
frustrated, having retreated biting my tongue more than once.

It makes me think of the eastern spiritual ideal of speaking only when
necessary, and then only the truth, and then only with sweet words.

Probably we have all broken that ideal here, and it is not clear
how to
facilitate constructive non-conformism.


I can think of at least a couple of cases where the list could have 
been more welcoming to  non-comforming contributors.


That said I hope this thread doesn't discourage people to get 
involved. Everything can be improved but Sugar is perhaps the most 
welcoming free software community I know of... For good or for bad, 
"sweet words" aren't really what you are normally met by if your ideas 
or patches are not considered high quality enough by the existing 
community.
I realize I chose my wording poorly. I did not mean "this list" but 
"this community".
You have to realize that Sugar community is explicitly more than just a 
Free Software community.
It's Supposed to be an Education Project, it's an ideal, it's more than 
just development, it's a diverse
community of people who believe in the value of collaboration and 
freedom as ways to impact

learning and therefore to change the world.

Therefore we should excersize care in making this a welcoming 
environment not just for developers,
but for any kind of contributors. It may be painstakingly slow, but I 
see the advent of freedom culture
within the educational systems and therefore governments as an 
unstoppable force, and Sugar as

a big part of that.

By the way, you always manage to respond constructively and positively. 
Kudos for that.


Regards,
--
Sebastian
@icarito
R+D SomosAzucar.Org
Sugar Labs Perú
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [IAEP] Tech roadmap

[Daniel Narvaez]

Cool stuff.

As for Fedora it would be great to have builds with the latest sugar
(stable and unstable) releases. I'm not saying to ship those to deployments
of course, but they would help upstream development, marketing and
testing... And they would help AC to make the transition to the next sugar
release smoother.

On 7 November 2013 02:05, David Farning wrote:

> Please see the link at the bottom left of http://dextrose.ac/platform/
> for the Sugar on Ubuntu images which Activity Central and Plan Ceibal
> are jointly developing.
>
> For stability it is based on Ubuntu 12.04 and Sugar .98. The testing
> is done on classmate to meet Plan Ceibal's specifications. I should
> work equally well on any machine that boots Ubuntu.
>
> It is currently is small scale testing by a couple hundred teachers.
> When the image meets Ceibal's quality standards the pilot will scale
> to approximately 10,000 units for wider testing.
>
> For more information, I have CC Anish Mangal, the project owner (agile
> speak) and Ruben Rodriguez the lead developer. Ruben has the strongest
> back ground on the technical issues involved in the port. Anish has
> the deepest understanding of timelines and objectives.
>
> On Wed, Nov 6, 2013 at 9:31 AM, Daniel Narvaez 
> wrote:
> > On 6 November 2013 16:20, Manuel Quiñones  wrote:
> >>
> >>
> >> > Classmates are basically just x86 netbooks, I've not tried it as I
> >> > don't have HW but I don't see any reason they shouldn't work OOTB.
> >>
> >> Yep. Sugar is running in classmates out of the box.  In Uruguay for
> >> example.
> >
> >
> > You mean people are using them in Uruguay deployments? Which distro?
> >
> > ___
> > Sugar-devel mailing list
> > Sugar-devel@lists.sugarlabs.org
> > http://lists.sugarlabs.org/listinfo/sugar-devel
> >
>
>
>
> --
> David Farning
> Activity Central: http://www.activitycentral.com
>



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

Re: [Sugar-devel] My proposals to improve sugar:

[Daniel Narvaez]

On 7 November 2013 02:00, Flavio Danesse  wrote:

> Thanks Daniel , I'll try again.
> I tried on several occasions to contribute in this way, but I see two
> problems :
> Generally not work in ubuntu
>

It's supposed work on Ubuntu. If it doesn't for you post the errors you are
getting and we will get it fixed.


> and has the disadvantage that you can not prove what you do on the xo .
>

I never tested but you should be able to get sugar-build working on the XO
itself. If you give it a try and run into issues let me know. I'm pretty
sure I'll be able to make it work.

>
> The other problem is the time of applying patches , that is, if you get
> excited to make big changes with several days , in the code , you run the
> risk that none of the patches are applied.
>
In my case , I think it would be better to work with someone who has the
> ability to fast track the contributions of code so you can go as you apply
> them or you can send instantly to object to keep moving forward in
> development.
>

Everyone is on the fast track these days! :)

Patches gets feedback pretty quickly. If you are making big changes and are
worried about conflicts, or if you would like some early feedback to know
that patches are going in a good direction,  just post a note here or in
irc. Someone will look at them.

Give it a try. I know this used to be an issue (I run into it myself, I
have a big set of bitrotten patches that never landed completely), but I
don't think it happens anymore these days.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [IAEP] Tech roadmap

[David Farning]

Please see the link at the bottom left of http://dextrose.ac/platform/
for the Sugar on Ubuntu images which Activity Central and Plan Ceibal
are jointly developing.

For stability it is based on Ubuntu 12.04 and Sugar .98. The testing
is done on classmate to meet Plan Ceibal's specifications. I should
work equally well on any machine that boots Ubuntu.

It is currently is small scale testing by a couple hundred teachers.
When the image meets Ceibal's quality standards the pilot will scale
to approximately 10,000 units for wider testing.

For more information, I have CC Anish Mangal, the project owner (agile
speak) and Ruben Rodriguez the lead developer. Ruben has the strongest
back ground on the technical issues involved in the port. Anish has
the deepest understanding of timelines and objectives.

On Wed, Nov 6, 2013 at 9:31 AM, Daniel Narvaez  wrote:
> On 6 November 2013 16:20, Manuel Quiñones  wrote:
>>
>>
>> > Classmates are basically just x86 netbooks, I've not tried it as I
>> > don't have HW but I don't see any reason they shouldn't work OOTB.
>>
>> Yep. Sugar is running in classmates out of the box.  In Uruguay for
>> example.
>
>
> You mean people are using them in Uruguay deployments? Which distro?
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>



-- 
David Farning
Activity Central: http://www.activitycentral.com
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] My proposals to improve sugar:

[Flavio Danesse]

Thanks Daniel , I'll try again.
I tried on several occasions to contribute in this way, but I see two
problems :
Generally not work in ubuntu and has the disadvantage that you can not
prove what you do on the xo .
The other problem is the time of applying patches , that is, if you get
excited to make big changes with several days , in the code , you run the
risk that none of the patches are applied.
In my case , I think it would be better to work with someone who has the
ability to fast track the contributions of code so you can go as you apply
them or you can send instantly to object to keep moving forward in
development.

Walter :
Thanks for the Spanish :)
On the topic of mentoring in the contest , like last year, I prefer not to
participate due to my limited English, if you like the ideas , feel free to
post them for me, I 'd appreciate it.


Gracias Daniel, intentaré nuevamente.
Probé en varias oportunidades aportar de esta forma, pero le veo dos
problemas:
Generalmente no funcionaba en ubuntu y tiene el inconveniente de que no
puedes probar lo que haces en la xo.
El otro problema es el tiempo de aplicación de los parches, o sea, si te
entusiasmas a hacer grandes modificaciones que lleven varios dias, en el
código, corres el riesgo de que ninguno de los parches se apliquen.
En mi caso, creo que sería mejor trabajar en conjunto con alguien que tenga
la capacidad de hacer un seguimiento rápido de los aportes de código de
forma que pueda ir aplicándolos a medida que se envian o que pueda poner
objeciones al instante para que no siga avanzando en el desarrollo.

Walter:
Gracias por el español :)
Con respecto al tema de ser mentor en el concurso, al igual que el año
pasado, prefiero no participar debido a mi limitado inglés, si te gustan
las ideas propuestas, sientete en libertad de publicarlas por mi, yo te lo
agradecería.


2013/11/6 Daniel Narvaez 

> 2013/11/7 Flavio Danesse 
>
>> What someone explain a simple way to contribute code to sugar, I'm 5
>> years ago and I have been able to do so (the timers need help).
>>
>
> Did you see these docs
>
> http://developer.sugarlabs.org/dev-environment.md.html
> http://developer.sugarlabs.org/contributing.md.html
>
> Happy to help out, here or in irc, if you run into any issues.
>
>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] My proposals to improve sugar:

[Daniel Narvaez]

2013/11/7 Flavio Danesse 

> What someone explain a simple way to contribute code to sugar, I'm 5 years
> ago and I have been able to do so (the timers need help).
>

Did you see these docs

http://developer.sugarlabs.org/dev-environment.md.html
http://developer.sugarlabs.org/contributing.md.html

Happy to help out, here or in irc, if you run into any issues.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [Sur] My proposals to improve sugar:

[Walter Bender]

2013/11/6 Flavio Danesse :
> My proposals to improve sugar:

Lots of good ideas here, many of which can be explored in Google Code
in. Please create tickets for them and add them to the task list in
the wiki [1]. And please sign up as a mentor!!! (Note that tasks can
be coding, but also UI design, documentation, QA, and research.)

-walter

[1] http://wiki.sugarlabs.org/go/Google_Code_In_2013#Tasks
>
> Change the face, giving more importance to aesthetics, leave the black and
> white, give colorful, add animations, sounds, etc.. . . What is pleasing to
> the user's view and fun to use. Change the geometry of buttons and other
> widgets of sugar to have a delicate design and tasteful.
>
> Remove all the features that make the system seem slow, such as the
> deployment of the menus in the GUI.
>
> Since I do not want to eliminate journal, give it a nicer interface (I like
> the idea I had Gonzalo, that explain it if you want).
> Adding a view of standard directories (could be a target for google code-in,
> see it mentors).
> That does not keep unnecessary things for the journal is truly usable.
>
> What sugar is distributed with the Linux man so users can use it like any
> linux user.
>
> Developers simplify activities, all network interface to develop shared
> activities (As commented, Augustine was doing something about this, maybe I
> can be another target for google code-in).
>
> What someone explain a simple way to contribute code to sugar, I'm 5 years
> ago and I have been able to do so (the timers need help).
>
> Order very personal:
> Remember that some do not speak English (particularly those whose native
> language is Spanish)
>
> Ensure first, support for popular applications, then the other.
>
> Rebuilding the link between development and deployment, taking into account
> that when I talk about deployments I mean users of the system, so that what
> matters is the opinion of teachers and students or users.
>
> Sugar should focus primarily on the opinions of teachers and students, ie
> actual use is given, is the only way to improve it.
>
> We must devise a way of communicating with them, perhaps this could
> materialize in an application that is distributed along with sugar (this
> proposal and did several times).
>
> From my point of view:
> You can not miss a student?
> Internet (social networks)
> Games (funny)
>
> You can not miss a teacher?
> Rapid applications without flaws that allow you to work in class and
> evaluate the tasks performed by their students.
>
> Obviously, the interests of both groups are different, we must find ways to
> meet the expectations of both groups, it is not enough that only one group
> using the system.
>
> On the other hand, those responsible for the deployments what the results
> will be evaluated in the education system, but you need to have to conform
> to users who use the system.
>
> Well, more or less, as I see it.
>
>
> Mis propuestas para mejorar sugar:

Un montón de buenas ideas aquí, muchos de los cuales pueden ser
exploradas en Google Code in.  Por favor, cree entradas para ellos y
añadirlos a la lista de tareas en el wiki [1]. Y por favor regístrese
como mentor! (Tenga en cuenta que las tareas se pueden codificación,
sino también el diseño de interfaz de usuario, documentación, control
de calidad y la investigación.)


[1] http://wiki.sugarlabs.org/go/Google_Code_In_2013 # Tasks
>
> Cambiarle la cara, darle más importancia a la estética, abandonar el blanco
> y negro, darle colorido, agregar animaciones, sonidos, etc . . . Qué sea
> agradable a la vista del usuario y divertido de utilizar. Cambiar la
> geometría de botones y demás widgets de sugar para que tengan un diseño
> delicado y de buen gusto.
>
> Quitar todas las funcionalidades que hacen parecer lento al sistema, como
> por ejemplo el despliegue de los menús en la interfaz gráfica.
>
> Ya que no desean eliminar journal, darle una interfaz más agradable (me
> gusta la idea que tenía Gonzalo, que el la explique si desea).
> Agregarle una vista de directorios estandard (podría ser un objetivo para
> google code-in, veanlo los mentores).
> Que no se guarden cosas innecesarias para que el journal sea realmente
> utilizable.
>
> Qué sugar sea distribuido con el man de linux para que los usuarios puedan
> utilizarlo como cualquier usuario linux.
>
> Simplificarle a los desarrolladores de actividades, toda la interfaz de la
> red para desarrollar actividades compartidas (Según comentaron, Agustín
> estaba haciendo algo sobre este tema, quizas pueda ser otro objetivo para
> google code-in).
>
> Qué alguien me explique una forma sencilla de aportar código a sugar, hace 5
> años que estoy y no he podio hacerlo (los novatos necesitamos ayuda).
>
> Pedido muy personal:
> Recordar que algunos no hablamos inglés (sobre todo aquellos cuya lengua
> madre es el español)
>
> Asegurar primero, el soporte a las aplicaciones más utilizadas, luego a las
> demás.
>
> Reconstruir el vínculo entre desarrollo y despli

[Sugar-devel] My proposals to improve sugar:

[Flavio Danesse]

*My proposals to improve sugar: *

Change the face, giving more importance to aesthetics, leave the black and
white, give colorful, add animations, sounds, etc.. . . What is pleasing to
the user's view and fun to use. Change the geometry of buttons and other
widgets of sugar to have a delicate design and tasteful.

Remove all the features that make the system seem slow, such as the
deployment of the menus in the GUI.

Since I do not want to eliminate journal, give it a nicer interface (I like
the idea I had Gonzalo, that explain it if you want).
Adding a view of standard directories (could be a target for google
code-in, see it mentors).
That does not keep unnecessary things for the journal is truly usable.

What sugar is distributed with the Linux man so users can use it like any
linux user.

Developers simplify activities, all network interface to develop shared
activities (As commented, Augustine was doing something about this, maybe I
can be another target for google code-in).

What someone explain a simple way to contribute code to sugar, I'm 5 years
ago and I have been able to do so (the timers need help).

Order very personal:
Remember that some do not speak English (particularly those whose native
language is Spanish)

Ensure first, support for popular applications, then the other.

Rebuilding the link between development and deployment, taking into account
that when I talk about deployments I mean users of the system, so that what
matters is the opinion of teachers and students or users.

Sugar should focus primarily on the opinions of teachers and students, ie
actual use is given, is the only way to improve it.

We must devise a way of communicating with them, perhaps this could
materialize in an application that is distributed along with sugar (this
proposal and did several times).

>From my point of view:
You can not miss a student?
Internet (social networks)
Games (funny)

You can not miss a teacher?
Rapid applications without flaws that allow you to work in class and
evaluate the tasks performed by their students.

Obviously, the interests of both groups are different, we must find ways to
meet the expectations of both groups, it is not enough that only one group
using the system.

On the other hand, those responsible for the deployments what the results
will be evaluated in the education system, but you need to have to conform
to users who use the system.

Well, more or less, as I see it.


*Mis propuestas para mejorar sugar:*

Cambiarle la cara, darle más importancia a la estética, abandonar el blanco
y negro, darle colorido, agregar animaciones, sonidos, etc . . . Qué sea
agradable a la vista del usuario y divertido de utilizar. Cambiar la
geometría de botones y demás widgets de sugar para que tengan un diseño
delicado y de buen gusto.

Quitar todas las funcionalidades que hacen parecer lento al sistema, como
por ejemplo el despliegue de los menús en la interfaz gráfica.

Ya que no desean eliminar journal, darle una interfaz más agradable (me
gusta la idea que tenía Gonzalo, que el la explique si desea).
Agregarle una vista de directorios estandard (podría ser un objetivo para
google code-in, veanlo los mentores).
Que no se guarden cosas innecesarias para que el journal sea realmente
utilizable.

Qué sugar sea distribuido con el man de linux para que los usuarios puedan
utilizarlo como cualquier usuario linux.

Simplificarle a los desarrolladores de actividades, toda la interfaz de la
red para desarrollar actividades compartidas (Según comentaron, Agustín
estaba haciendo algo sobre este tema, quizas pueda ser otro objetivo para
google code-in).

Qué alguien me explique una forma sencilla de aportar código a sugar, hace
5 años que estoy y no he podio hacerlo (los novatos necesitamos ayuda).

Pedido muy personal:
Recordar que algunos no hablamos inglés (sobre todo aquellos cuya lengua
madre es el español)

Asegurar primero, el soporte a las aplicaciones más utilizadas, luego a las
demás.

Reconstruir el vínculo entre desarrollo y despliegues, tomando en cuenta
que cuando hablo de despliegues me refiero a los usuarios del sistema, de
modo que lo que más importa es la opinión de docentes y alumnos o sea los
usuarios.

Sugar debiera centrar la atención sobre todo en la opinión de docentes y
alumnos, es decir en el uso real que se le da, es la única forma de
mejorarlo.

Hay que idear una forma de comunicación con ellos, quizás esto pueda
materializarse en una aplicación que se distribuya junto a sugar (esta
propuesta ya la hice varias veces).

Desde mi punto de vista:
Que no le puede faltar a un alumno?
Internet (redes sociales)
Juegos (divertidos)

Que no le puede faltar a un docente?
Aplicaciones rápidas, sin fallas que le permitan trabajar en clase y
evaluar las tareas que realizan sus alumnos.

Obviamente, los intereses de ambos grupos son diferentes, hay que buscar la
manera de cubrir las espectativas de ambos grupos de usuarios, porque no
basta que solo un grupo utilice el sistema.

Por ot

Re: [Sugar-devel] [IAEP] Tech roadmap

[Gonzalo Odiard]

Yeah, is a option.

Gonzalo


On Wed, Nov 6, 2013 at 8:50 PM, Daniel Narvaez  wrote:

> On 7 November 2013 00:37, Gonzalo Odiard  wrote:
>
>>
>> In F18 we can do:
>>   from gi.repository import WebKit2
>>
>> but later crash, not sure where.
>>
>
> Hrm, yeah, I had forgot the exact situation in Fedora 18...
>
> Then I'm afraid the only solid approach I can think of is testing for a
> SUGAR_WEBKIT_VERSION environment variable, set perhaps by a /usr/bin/sugar
> patched by the rpms.
>
> --
> Daniel Narvaez
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [IAEP] Tech roadmap

[Daniel Narvaez]

On 7 November 2013 00:37, Gonzalo Odiard  wrote:

>
> In F18 we can do:
>   from gi.repository import WebKit2
>
> but later crash, not sure where.
>

Hrm, yeah, I had forgot the exact situation in Fedora 18...

Then I'm afraid the only solid approach I can think of is testing for a
SUGAR_WEBKIT_VERSION environment variable, set perhaps by a /usr/bin/sugar
patched by the rpms.

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

Re: [Sugar-devel] [IAEP] Tech roadmap

[Gonzalo Odiard]

In F18 we can do:
  from gi.repository import WebKit2

but later crash, not sure where.

Gonzalo



On Wed, Nov 6, 2013 at 8:20 PM, Daniel Narvaez  wrote:

> On 6 November 2013 18:32, Gonzalo Odiard  wrote:
>
>> >> No. the web-server issue is already solved.
>> >
>> > If we want to support WebKit1, I think we should do it upstream then.
>> I'm
>> > still not thrilled about that but not opposed to it either.
>>
>> Good. We can see what is the better way to do it. May be check the
>> webkit version installed?
>>
>> Just for reference, the changes we did are here:
>>
>>
>> https://github.com/godiard/au1b_rpms/blob/master/sugar-toolkit-gtk3/0001-Adapt-webactivity-to-work-with-webkit1.patch
>>
>
> I think the best way to detect it would be to import WebKit2, if it fails
> fall back to WebKit.
>
> I'm not sure what's the best way to maintain the two different
> implementations though. Maybe two modules with identical interfaces,
> imported "as webview".
>
> So something like this in webactivity.py:
>
> try:
>   from gi.repository import WebKit2
> except ImportError:
>   pass
>
> if WebKit2:
>   from sugar.activity import webkit1view as webview
> else:
>   from sugar.activity import webkit2view as webview
>
> class WebActivity:
>   def __init__(self):
> self._web_view = webview.WebView()
> ...
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [Sur] [IAEP] Sugar oversight board meeting

[Sebastian Silva]

El 06/11/13 17:35, Sean DALY escribió:
On Mon, Nov 4, 2013 at 11:05 PM, Peter Robinson > wrote:


But you have for a long time refused to actually even market SoaS!


That's right, at the time SoaS became an official Fedora spin, Mel and 
Sebastian decided to take over marketing, which included coming up 
with unmarketable names, linking with Fedora announcements, and 
opening a Fedora hosted minisite (the "home" of SoaS), none of which 
was done with any consultation of the SL marketing team.


Please try to include last names, you mean Sebastian Dzallas, original 
developer of "Sugar On A Stick".


Now that we're on the topic... the concept "Sugar On A Stick" has 
several problems.


1.- It suggests it's the only possible Sugar OS on a USB.
2.- It suggests it's not a serious OS to be installed on a computer.
3.- It's impossible to translate.
4.- It suggests it's not regular GNU/Linux, with availability of the 
Myriad other GNU/Linux educational tools.


Regards,
Sebastian Silva
R+D SomosAzúcar
Sugar Labs Perú
@icarito

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

Re: [Sugar-devel] [IAEP] Tech roadmap

[Daniel Narvaez]

On 6 November 2013 18:32, Gonzalo Odiard  wrote:

> >> No. the web-server issue is already solved.
> >
> > If we want to support WebKit1, I think we should do it upstream then. I'm
> > still not thrilled about that but not opposed to it either.
>
> Good. We can see what is the better way to do it. May be check the
> webkit version installed?
>
> Just for reference, the changes we did are here:
>
>
> https://github.com/godiard/au1b_rpms/blob/master/sugar-toolkit-gtk3/0001-Adapt-webactivity-to-work-with-webkit1.patch
>

I think the best way to detect it would be to import WebKit2, if it fails
fall back to WebKit.

I'm not sure what's the best way to maintain the two different
implementations though. Maybe two modules with identical interfaces,
imported "as webview".

So something like this in webactivity.py:

try:
  from gi.repository import WebKit2
except ImportError:
  pass

if WebKit2:
  from sugar.activity import webkit1view as webview
else:
  from sugar.activity import webkit2view as webview

class WebActivity:
  def __init__(self):
self._web_view = webview.WebView()
...
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [IAEP] [Sur] Sugar oversight board meeting

[Sean DALY]

On Mon, Nov 4, 2013 at 11:05 PM, Peter Robinson wrote:

> But you have for a long time refused to actually even market SoaS!


That's right, at the time SoaS became an official Fedora spin, Mel and
Sebastian decided to take over marketing, which included coming up with
unmarketable names, linking with Fedora announcements, and opening a Fedora
hosted minisite (the "home" of SoaS), none of which was done with any
consultation of the SL marketing team.

This wiped out a year and a half of hard work on my part and others who
were successfully building SoaS as the pillar of our marketing strategy,
cf. BBC coverage etc. We had been marketing SoaS as a concept - "Sugar on
OLPC now available on a $5 stick". Mel's approach was to turn SoaS into an
example of how Fedora was well-suited as a technical platform for themed
spins - certainly true, but of no interest to teachers. Unfortunately, key
components for a smooth teacher experience - an up-to-date liveUSB
installer, Sugar branded first-run screens such as Trisquel - became more,
not less difficult to create with the "spin" status.

Of course, this wasn't the only effort by community members to lay claim to
SoaS; a former contributor had even registered a domain name and built a
separate SoaS minisite, hoping to obtain exclusive distribution rights, and
only closed the site under pressure.

In traditional free software projects, engineers make the decisions then
communicate (usually quite late in the process) with their marketers. This
is almost completely ineffective, which is why I wasn't prepared to
contribute time and expertise under those conditions.

The several thousand USD I had contributed to seed the marketing effort
(remember the branded USB sticks?) had allowed us to obtain excellent
results, however as of two years ago I've been unable to continue that
financing for personal reasons.

Looking forward, I myself feel prebuilt VMs with pancake installers for
Windows, OSX and GNU/Linux (including SoaS images cf. [1]) would be our
best bet to offer a Sugar experience to interested teachers. I use a
VirtualBox VM on a Mac when I present Sugar to audiences, and it works very
well, inheriting network connections, fullscreen etc. Of course, the
downside is enormous download images, and I don't underestimate the work
and infrastructure required to keep a matrix of images available.

So yes Peter, I salute your hard work on SoaS; for want of a better
strategy it has even been kept on the SL homepage for three years. However,
for SoaS to aid SL in raising awareness, allowing teachers to overcome the
installation and unfamiliarity barriers, and providing a path to non-OLPC
hardware in a world massively dropping the PC for tablets, additional
teacher-friendly components are necessary and the marketing needs to be
done by marketers.

Sean
Sugar Labs Marketing Coordinator

P.S. I'm quite interested in your proposals concerning ARM boxes; I have
always maintained that a non-OLPC OEM deal would allow us to bypass the
installation barrier. That said, my interest in the Raspberry Pi is from a
marketing standpoint - they have over a million sold, corporate
sponsorships in the UK, wide press coverage, retail distributors, only one
official SD card OS for non-advanced users, and are seeking education
partners to better reach students.

1. http://wiki.sugarlabs.org/go/Sugar_on_a_Stick/Virtual_machines
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] new features for 102 (Walter Bender)

[Gonzalo Odiard]

> Okay. I've seen two other features not described in the feature lists:
> - Backup/Restore journal to an USB key
> - Copy to "Teacher" menu item (grayed).
> Is it related to Australia deployment too ?
>
>
Backup/Restore can be included in 0.102,
at least the implementation storing in a external device.
That was code used in Dextrose, and we ported it to Sugar 0.100

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

Re: [Sugar-devel] new features for 102 (Walter Bender)

[Walter Bender]

On Wed, Nov 6, 2013 at 4:17 PM, Lionel Laské  wrote:
>
>
> 2013/11/6 Gonzalo Odiard 
>>
>>
>> The information is stored inGConf, your backup process can get it an
>> restore it later.
>>
>
> Nice, just seen it in GConf.
>
>>
>>
>> The testing images include the work done for Australia deployment,
>> that is the reason, this and other features proposed by Walter are
>> already included.
>>
>
> Okay. I've seen two other features not described in the feature lists:
> - Backup/Restore journal to an USB key

Not sure what you are asking. Is not there a backup/restore activity?
Is there some specific feature you'd like?

> - Copy to "Teacher" menu item (grayed).
> Is it related to Australia deployment too ?

That is a webservice (See
https://github.com/walterbender/teachershare) that is enabled whenever
an adult (as defined by the age/gender patch) launches Gonzalo's
Journal Share activity.  Not sure it is somethng we want to include
upstream or leave as an option to load on demand. Haven't written it
up yet.

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



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

Re: [Sugar-devel] new features for 102 (Walter Bender)

[Lionel Laské]

2013/11/6 Gonzalo Odiard 

>
> The information is stored inGConf, your backup process can get it an
> restore it later.
>
>
Nice, just seen it in GConf.


>
> The testing images include the work done for Australia deployment,
> that is the reason, this and other features proposed by Walter are
> already included.
>
>
Okay. I've seen two other features not described in the feature lists:
- Backup/Restore journal to an USB key
- Copy to "Teacher" menu item (grayed).
Is it related to Australia deployment too ?

Thanks.

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

Re: [Sugar-devel] [IAEP] Tech roadmap

[nanonano]

/>On 06/11/2013 13:31, Daniel Narvaez wrote://
//>You mean people are using them in Uruguay deployments? Which distro?/
--



In Uruguay we have Classmates II (called "Magallanes") in some High Schools, that comes with Ubuntu 10.01.3 and Sugar 
Sweets Distribution (0.94.1), you can download the image here 
.
(hardware  and Software 
 specifications).


In other High schools the children have XO 1.5, 1.75 or 4.0, and in some kindergardens and schools (1st grade) they have 
OLPC tablets  with Android.




By the way: in High Schools there are very few people who uses Sugar, they normally use the Gnome interface, as in 
primary School, except for a part of the children that still have the XO 1.0 without Gnome.




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

Re: [Sugar-devel] Tech roadmap

[Peter Robinson]

On Wed, Nov 6, 2013 at 7:13 PM, Walter Bender  wrote:
> On Wed, Nov 6, 2013 at 2:10 PM, Daniel Narvaez  wrote:
>> Did you run into any specific issue?
>
> It has been a while, but I had some issues with lack of introspection
> support with some pad stuff... will look again over the weekend.

I would look at the gst 1.2.0 release and see how you get on there,
it's in Fedora 20.

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

Re: [Sugar-devel] Tech roadmap

[Walter Bender]

On Wed, Nov 6, 2013 at 2:10 PM, Daniel Narvaez  wrote:
> Did you run into any specific issue?

It has been a while, but I had some issues with lack of introspection
support with some pad stuff... will look again over the weekend.

-walter

>
> On Wednesday, 6 November 2013, Walter Bender wrote:
>>
>> On Wed, Nov 6, 2013 at 12:35 PM, Gonzalo Odiard 
>> wrote:
>> > Clock, Speak, and part of Memorize use gstreamer just to do text to
>> > speech.
>> > I would like to have tts provided by Sugar as a service, probably using
>> > dbus
>> > and a api in sugar-toolkit-gtk3. That would simplify these activities
>> > and solve
>> > other problems we have, like by example the keep the language names
>> > translated
>> > and updated in every place.
>>
>>
>> I've had a few false starts trying to port Measure to GST 1.0. Once I
>> get that working, Turtle Art will follow (that is why I still haven't
>> released the GTK 3 version of Turtle Art).
>>
>> -walter
>>
>> >
>> > Gonzalo
>> >
>> > On Wed, Nov 6, 2013 at 1:40 PM, Peter Robinson 
>> > wrote:
>> >> On Wed, Nov 6, 2013 at 4:24 PM, Daniel Narvaez 
>> >> wrote:
>> >>> I forgot a note about toolkits
>> >>>
>> >>> * The gtk2 toolkit is deprecated and frozen but it will be supported
>> >>> as long
>> >>> as possible (at some point I guess some dependencies might start
>> >>> disappearing from distributions, making that problematic). The gtk3
>> >>> toolkit
>> >>> is supported, backward API compatibility is guaranteed, it's not going
>> >>> to be
>> >>> deprecated in the foreseable future. The web toolkit is experimental,
>> >>> we
>> >>> provide no API guarantee yet, when it's mature it will be the
>> >>> preferred way
>> >>> to write activities (because of cross platform compatibility).
>> >>
>> >> The other one to add to this list is gstreamer. At the moment we have
>> >> some support for gstreamer 1.0 and some (mostly gtk2) Activities still
>> >> using gstreamer 0.10. The 0.10 release will be disappearing sooner
>> >> rather than later (I wouldn't be surprised if this happened in
>> >> F-21/F-22 time frame). I would love to see us be able to remove the
>> >> dependency on two gst stacks, at the moment at least Clock, Speak,
>> >> Record and Memorise need to be converted from gstreamer-python / gst
>> >> 0.10 to gst 1.0 with Introspection support, whether this requires
>> >> migration to gtk3 at the same time is unknown to me.
>> >>
>> >> Peter
>> >> ___
>> >> IAEP -- It's An Education Project (not a laptop project!)
>> >> i...@lists.sugarlabs.org
>> >> http://lists.sugarlabs.org/listinfo/iaep
>> > ___
>> > Sugar-devel mailing list
>> > Sugar-devel@lists.sugarlabs.org
>> > http://lists.sugarlabs.org/listinfo/sugar-devel
>>
>>
>>
>> --
>> Walter Bender
>> Sugar Labs
>> http://www.sugarlabs.org
>
>
>
> --
> Daniel Narvaez
>



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

Re: [Sugar-devel] Tech roadmap

[Daniel Narvaez]

Did you run into any specific issue?

On Wednesday, 6 November 2013, Walter Bender wrote:

> On Wed, Nov 6, 2013 at 12:35 PM, Gonzalo Odiard 
> >
> wrote:
> > Clock, Speak, and part of Memorize use gstreamer just to do text to
> speech.
> > I would like to have tts provided by Sugar as a service, probably using
> dbus
> > and a api in sugar-toolkit-gtk3. That would simplify these activities
> and solve
> > other problems we have, like by example the keep the language names
> translated
> > and updated in every place.
>
>
> I've had a few false starts trying to port Measure to GST 1.0. Once I
> get that working, Turtle Art will follow (that is why I still haven't
> released the GTK 3 version of Turtle Art).
>
> -walter
>
> >
> > Gonzalo
> >
> > On Wed, Nov 6, 2013 at 1:40 PM, Peter Robinson 
> > >
> wrote:
> >> On Wed, Nov 6, 2013 at 4:24 PM, Daniel Narvaez 
> >> >
> wrote:
> >>> I forgot a note about toolkits
> >>>
> >>> * The gtk2 toolkit is deprecated and frozen but it will be supported
> as long
> >>> as possible (at some point I guess some dependencies might start
> >>> disappearing from distributions, making that problematic). The gtk3
> toolkit
> >>> is supported, backward API compatibility is guaranteed, it's not going
> to be
> >>> deprecated in the foreseable future. The web toolkit is experimental,
> we
> >>> provide no API guarantee yet, when it's mature it will be the
> preferred way
> >>> to write activities (because of cross platform compatibility).
> >>
> >> The other one to add to this list is gstreamer. At the moment we have
> >> some support for gstreamer 1.0 and some (mostly gtk2) Activities still
> >> using gstreamer 0.10. The 0.10 release will be disappearing sooner
> >> rather than later (I wouldn't be surprised if this happened in
> >> F-21/F-22 time frame). I would love to see us be able to remove the
> >> dependency on two gst stacks, at the moment at least Clock, Speak,
> >> Record and Memorise need to be converted from gstreamer-python / gst
> >> 0.10 to gst 1.0 with Introspection support, whether this requires
> >> migration to gtk3 at the same time is unknown to me.
> >>
> >> Peter
> >> ___
> >> IAEP -- It's An Education Project (not a laptop project!)
> >> i...@lists.sugarlabs.org 
> >> http://lists.sugarlabs.org/listinfo/iaep
> > ___
> > Sugar-devel mailing list
> > Sugar-devel@lists.sugarlabs.org 
> > http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
>
> --
> Walter Bender
> Sugar Labs
> http://www.sugarlabs.org
>


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

Re: [Sugar-devel] [IAEP] Tech roadmap

[Walter Bender]

On Wed, Nov 6, 2013 at 12:35 PM, Gonzalo Odiard  wrote:
> Clock, Speak, and part of Memorize use gstreamer just to do text to speech.
> I would like to have tts provided by Sugar as a service, probably using dbus
> and a api in sugar-toolkit-gtk3. That would simplify these activities and 
> solve
> other problems we have, like by example the keep the language names translated
> and updated in every place.


I've had a few false starts trying to port Measure to GST 1.0. Once I
get that working, Turtle Art will follow (that is why I still haven't
released the GTK 3 version of Turtle Art).

-walter

>
> Gonzalo
>
> On Wed, Nov 6, 2013 at 1:40 PM, Peter Robinson  wrote:
>> On Wed, Nov 6, 2013 at 4:24 PM, Daniel Narvaez  wrote:
>>> I forgot a note about toolkits
>>>
>>> * The gtk2 toolkit is deprecated and frozen but it will be supported as long
>>> as possible (at some point I guess some dependencies might start
>>> disappearing from distributions, making that problematic). The gtk3 toolkit
>>> is supported, backward API compatibility is guaranteed, it's not going to be
>>> deprecated in the foreseable future. The web toolkit is experimental, we
>>> provide no API guarantee yet, when it's mature it will be the preferred way
>>> to write activities (because of cross platform compatibility).
>>
>> The other one to add to this list is gstreamer. At the moment we have
>> some support for gstreamer 1.0 and some (mostly gtk2) Activities still
>> using gstreamer 0.10. The 0.10 release will be disappearing sooner
>> rather than later (I wouldn't be surprised if this happened in
>> F-21/F-22 time frame). I would love to see us be able to remove the
>> dependency on two gst stacks, at the moment at least Clock, Speak,
>> Record and Memorise need to be converted from gstreamer-python / gst
>> 0.10 to gst 1.0 with Introspection support, whether this requires
>> migration to gtk3 at the same time is unknown to me.
>>
>> Peter
>> ___
>> IAEP -- It's An Education Project (not a laptop project!)
>> i...@lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/iaep
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel



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

Re: [Sugar-devel] different perspectives

[Sameer Verma]

On Mon, Nov 4, 2013 at 7:50 PM, Sameer Verma  wrote:
> Dear Community,
>
> As I was listening to the interviews of some of the OLPC SF Summit
> attendees, I was amazed at the richness of diversity in perspectives.
> In spite of being a part of this community since July 2007, and trying
> to keep up with all that is OLPC and Sugar, these interviews threw me
> off a bit.
>
> The videos are uploading as I write this. They'll be available at
> https://www.youtube.com/user/olpcsf/videos soon. Bill Stelzer, who
> usually interviews and runs the camera asks people a handful of
> questions. So, here's a little community exercise. Why not ask you all
> the same?
>
> 1) What brought you into the OLPC and/or Sugar project(s)?
>

Back in 2005, most of my research was on the user perspective of free
and open source software. OLPC was promising to be a rich source. I
did not know anything about Sugar, or constructivist learning, or the
fact that these machines were largely for children. I was also looking
for a way to provide Internet access to my family in Bhagmalpur,
India, so my uncle could look up information on farming techniques. I
saw an XO at OSCON 2007 for the first time. Rob Savoye (Gnash) was
showing it around. OLPC laptops sounded a better alternative to
sending old desktops and CRT monitors to Bhagmalpur, so I jumped in. I
wrote to the developer program, and Jim Gettys send me an XO!

> 2) What keeps you going in the OLPC and/or Sugar project(s)?

Initially, it was the excitement of a new thing. Then, I started to
read up on the educational side of it, and got hooked. I also admired
the non-stop ability of the core team to solve difficult problems.
They wouldn't take no for an answer, and came up with novel, yet
objective ways to solve problems. That zeal, combined with my very own
personal barometer in Bhagmalpur kept me plugged (and it still does).
OLPC SF became the fun thing to do/focus on locally. Visiting Jamaica
on my sabbatical leave was the catalyst for getting a deployment going
(now grown to 4 schools). Eventually, I got enough G1G1 XOs to
populate Bhagmalpur with 26 XOs in houses across the village. Bringing
OLPC/Sugar into my teaching, research and service allows me to work on
projects and not simply pursue these projects as a personal interest.

>
> 3) What are the challenges you face in the OLPC and/or Sugar project(s)?
>

Over the years, the teams churn through. Each churn takes away some
ideas, and replace these with newer ideas. The trouble is with things
that get lost between the cycles. Many biases come in with each
developer pool, and not all ideas are vetted thoroughly. There was
always a lot of mystery about how decisions were made at the company,
be it in Cambridge, or at Miami. Not being an employee, I typically
resigned to whatever comes down the mailing list pipeline. I
understand that outsiders getting in the way of business is difficult,
but the OLPC community + company partnership (if there was ever one)
never really sat well with me. As OLPC transitioned from the
Foundation to the Association, the "free and open source" went
neglected. Management really didn't understand the core of why FOSS
was important. They probably saw it as a source of software, but not
as an ongoing ecosystem. FOSS does not have strategic significance it
should at OLPCA.

OLPCF on the other hand, struggled with marketing. I'm not talking
about advertising. I'm talking about getting the ideas out so people
could understand it easily. Telling people about your ideas at their
level of understanding makes a major difference. They couldn't tell
the world how important their work was. It didn't translate to the
outside. I was at PLoS.org last week, and about a third of the
staffers there came up and asked me about what that thing (my XO) was.
At least people in this sphere should have known! There was also the
blanket refusal to work with boutique projects at OLPCF. That led to a
"no room for retail" mentality. Retailing would have helped.

OLPCA on the other hand struggles with strategy. Most of what they do
is operational at best. I realize that it is hard to stay the course
when the hardware and software industries focus so much on particular
combinations (think Android and ARM), but increasingly, the tail is
wagging the dog. Letting sales run an organization doesn't last for
too long :-(

Not being a developer myself, keeping up with Sugar's roadmap has been
difficult. These projects are heavily driven by technology. I am used
to an environment where the end user has a fair bit of say in the
matter, but I never got a good sense of whether Sugar as a project was
really getting good input. It's a difficult balance between listening
to your users and going the Jobs way (users don't know what they
want). I don't perceive these to be transparency issues as much as
translation issues - the ideas in people's heads don't make it to the
other side. This leads to a large variance in understanding different
aspects 

Re: [Sugar-devel] [IAEP] Tech roadmap

[Gonzalo Odiard]

Clock, Speak, and part of Memorize use gstreamer just to do text to speech.
I would like to have tts provided by Sugar as a service, probably using dbus
and a api in sugar-toolkit-gtk3. That would simplify these activities and solve
other problems we have, like by example the keep the language names translated
and updated in every place.

Gonzalo

On Wed, Nov 6, 2013 at 1:40 PM, Peter Robinson  wrote:
> On Wed, Nov 6, 2013 at 4:24 PM, Daniel Narvaez  wrote:
>> I forgot a note about toolkits
>>
>> * The gtk2 toolkit is deprecated and frozen but it will be supported as long
>> as possible (at some point I guess some dependencies might start
>> disappearing from distributions, making that problematic). The gtk3 toolkit
>> is supported, backward API compatibility is guaranteed, it's not going to be
>> deprecated in the foreseable future. The web toolkit is experimental, we
>> provide no API guarantee yet, when it's mature it will be the preferred way
>> to write activities (because of cross platform compatibility).
>
> The other one to add to this list is gstreamer. At the moment we have
> some support for gstreamer 1.0 and some (mostly gtk2) Activities still
> using gstreamer 0.10. The 0.10 release will be disappearing sooner
> rather than later (I wouldn't be surprised if this happened in
> F-21/F-22 time frame). I would love to see us be able to remove the
> dependency on two gst stacks, at the moment at least Clock, Speak,
> Record and Memorise need to be converted from gstreamer-python / gst
> 0.10 to gst 1.0 with Introspection support, whether this requires
> migration to gtk3 at the same time is unknown to me.
>
> Peter
> ___
> IAEP -- It's An Education Project (not a laptop project!)
> i...@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/iaep
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [IAEP] Tech roadmap

[Gonzalo Odiard]

>> No. the web-server issue is already solved.
>
> If we want to support WebKit1, I think we should do it upstream then. I'm
> still not thrilled about that but not opposed to it either.

Good. We can see what is the better way to do it. May be check the
webkit version installed?

Just for reference, the changes we did are here:

https://github.com/godiard/au1b_rpms/blob/master/sugar-toolkit-gtk3/0001-Adapt-webactivity-to-work-with-webkit1.patch

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

Re: [Sugar-devel] [IAEP] Tech roadmap

[Daniel Narvaez]

Gstreamer 0.10 is part of what I'm calling gtk2 toolkit, it's not
completely accurate but we have been using than terminology. So it seems we
are going to run into the issue of gtk2 toolkit pieces disappearing earlier
then I expected.

I think you can move to gst 1.0 only if you already ported to gtk3.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [IAEP] Tech roadmap

[Daniel Narvaez]

On 6 November 2013 17:38, Gonzalo Odiard  wrote:

> On Wed, Nov 6, 2013 at 12:53 PM, Daniel Narvaez 
> wrote:
> >
> > On 6 November 2013 16:45, Gonzalo Odiard  wrote:
> >>
> >> >>
> >> >> In the short term, we don't need backport Webkit2 to F18.
> >> >
> >> > Please elaborate :)
> >> >
> >> > I think developing web activities on two very different platforms
> >> > (WebKit1
> >> > and WebKit2) is a bad idea, it will involve more work (and pain) then
> >> > doing
> >> > some backporting.
> >>
> >> Well, with a little patch in our F18 rpm, I have all the web
> >> activities working ok in webkit1. A important missing feature is the
> >> web inspector, but they work ok.
> >
> >
> > We never solved the document domain issue right (if I remember correctly
> you
> > failed to get a in-activity web server running)?
> >
>
> No. the web-server issue is already solved.
>

If we want to support WebKit1, I think we should do it upstream then. I'm
still not thrilled about that but not opposed to it either.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [IAEP] Tech roadmap

[Peter Robinson]

On Wed, Nov 6, 2013 at 4:24 PM, Daniel Narvaez  wrote:
> I forgot a note about toolkits
>
> * The gtk2 toolkit is deprecated and frozen but it will be supported as long
> as possible (at some point I guess some dependencies might start
> disappearing from distributions, making that problematic). The gtk3 toolkit
> is supported, backward API compatibility is guaranteed, it's not going to be
> deprecated in the foreseable future. The web toolkit is experimental, we
> provide no API guarantee yet, when it's mature it will be the preferred way
> to write activities (because of cross platform compatibility).

The other one to add to this list is gstreamer. At the moment we have
some support for gstreamer 1.0 and some (mostly gtk2) Activities still
using gstreamer 0.10. The 0.10 release will be disappearing sooner
rather than later (I wouldn't be surprised if this happened in
F-21/F-22 time frame). I would love to see us be able to remove the
dependency on two gst stacks, at the moment at least Clock, Speak,
Record and Memorise need to be converted from gstreamer-python / gst
0.10 to gst 1.0 with Introspection support, whether this requires
migration to gtk3 at the same time is unknown to me.

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

Re: [Sugar-devel] [IAEP] Tech roadmap

[Gonzalo Odiard]

On Wed, Nov 6, 2013 at 12:53 PM, Daniel Narvaez  wrote:
>
> On 6 November 2013 16:45, Gonzalo Odiard  wrote:
>>
>> >>
>> >> In the short term, we don't need backport Webkit2 to F18.
>> >
>> > Please elaborate :)
>> >
>> > I think developing web activities on two very different platforms
>> > (WebKit1
>> > and WebKit2) is a bad idea, it will involve more work (and pain) then
>> > doing
>> > some backporting.
>>
>> Well, with a little patch in our F18 rpm, I have all the web
>> activities working ok in webkit1. A important missing feature is the
>> web inspector, but they work ok.
>
>
> We never solved the document domain issue right (if I remember correctly you
> failed to get a in-activity web server running)?
>

No. the web-server issue is already solved.


> Current web activities are super simple but as they become more complex I
> think we will run into issues, domain being just one example. I'd rather not
> have to figure out WebKit1 *and* WebKit2 solutions every time that happens.
>

I hope we find the way to keep it simple :)

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

Re: [Sugar-devel] Tech roadmap

[Daniel Narvaez]

I forgot a note about toolkits

* The gtk2 toolkit is deprecated and frozen but it will be supported as
long as possible (at some point I guess some dependencies might start
disappearing from distributions, making that problematic). The gtk3 toolkit
is supported, backward API compatibility is guaranteed, it's not going to
be deprecated in the foreseable future. The web toolkit is experimental, we
provide no API guarantee yet, when it's mature it will be the preferred way
to write activities (because of cross platform compatibility).
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [IAEP] Tech roadmap

[Daniel Narvaez]

On 6 November 2013 16:45, Gonzalo Odiard  wrote:

> >>
> >> In the short term, we don't need backport Webkit2 to F18.
> >
> > Please elaborate :)
> >
> > I think developing web activities on two very different platforms
> (WebKit1
> > and WebKit2) is a bad idea, it will involve more work (and pain) then
> doing
> > some backporting.
>
> Well, with a little patch in our F18 rpm, I have all the web
> activities working ok in webkit1. A important missing feature is the
> web inspector, but they work ok.
>

We never solved the document domain issue right (if I remember correctly
you failed to get a in-activity web server running)?

Current web activities are super simple but as they become more complex I
think we will run into issues, domain being just one example. I'd rather
not have to figure out WebKit1 *and* WebKit2 solutions every time that
happens.


> I was looking at compile the webkit rpm from F19 in F18, but had many
> dependencies. I didn't explore other alternatives.
>

Yeah, we might need to rebuild a few other deps. As soon as I have a bit of
time I plan to look into doing these rebuilds in an automated way using
COPR.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [IAEP] Tech roadmap

[Gonzalo Odiard]

>>
>> In the short term, we don't need backport Webkit2 to F18.
>
> Please elaborate :)
>
> I think developing web activities on two very different platforms (WebKit1
> and WebKit2) is a bad idea, it will involve more work (and pain) then doing
> some backporting.

Well, with a little patch in our F18 rpm, I have all the web
activities working ok in webkit1. A important missing feature is the
web inspector, but they work ok.

I was looking at compile the webkit rpm from F19 in F18, but had many
dependencies. I didn't explore other alternatives.

>
>>
>> In the long term,
>> we need find a solution to move to a newer Fedora in the XOs, maybe 20 or
>> 21.
>
>
> Yes, ideally. I just don't see this happening in the short time and I'm
> worried it might not happen at all, given the kind of work that seems to be
> involved. It would be awesome to be proven wrong...
>
> Until that happens though I think we need to be able to get the latest sugar
> (and it's dependencies) on a XO.
>

Agreed, not easy, but needed in the long run. IN fact other of your proposals,
like use wayland will need it

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

Re: [Sugar-devel] [IAEP] Tech roadmap

[Manuel Quiñones]

2013/11/6 Daniel Narvaez :
> On 6 November 2013 16:20, Manuel Quiñones  wrote:
>>
>>
>> > Classmates are basically just x86 netbooks, I've not tried it as I
>> > don't have HW but I don't see any reason they shouldn't work OOTB.
>>
>> Yep. Sugar is running in classmates out of the box.  In Uruguay for
>> example.
>
>
> You mean people are using them in Uruguay deployments? Which distro?

I don't know the details.  Maybe Flavio knows.

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

Re: [Sugar-devel] [IAEP] Tech roadmap

[Peter Robinson]

On Wed, Nov 6, 2013 at 3:30 PM, Daniel Narvaez  wrote:
> Are classmates somehow available to developers? It sounds like making images
> (or whatever) for them might be a pretty good idea.

You should be able to use the SoaS images on them straight up, there's
an installer option. If it's aimed at a deployment it might be easier
to use olpc-os-builder or a kickstart to automate the installation.

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

Re: [Sugar-devel] [IAEP] Tech roadmap

[Daniel Narvaez]

On 6 November 2013 16:20, Manuel Quiñones  wrote:

>
> > Classmates are basically just x86 netbooks, I've not tried it as I
> > don't have HW but I don't see any reason they shouldn't work OOTB.
>
> Yep. Sugar is running in classmates out of the box.  In Uruguay for
> example.
>

You mean people are using them in Uruguay deployments? Which distro?
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [IAEP] Tech roadmap

[Daniel Narvaez]

Are classmates somehow available to developers? It sounds like making
images (or whatever) for them might be a pretty good idea.


On 6 November 2013 16:25, Gonzalo Odiard  wrote:

> Yes, but we never provided a easy way to install in classmates,
> or tried to approach hardware manufactures to propose them to invest on
> that.
>
> Gonzalo
>
> On Wed, Nov 6, 2013 at 12:20 PM, Manuel Quiñones  wrote:
> > 2013/11/6 Peter Robinson :
> >> On Wed, Nov 6, 2013 at 3:12 PM, Gonzalo Odiard 
> wrote:
> >>> On Wed, Nov 6, 2013 at 11:49 AM, Daniel Narvaez 
> wrote:
>  Hello,
> 
>  I think Sugar Labs needs to express a clear, realistic technology
> roadmap.
>  For example, we have been talking a lot about Sugar on Android,
> mixing a lot
>  of different things under that name. We need to clarify what that
> really is.
> 
>  Here are my thoughts, inspired by the oversight board meeting thread.
> 
>  * Wait and see what happens with the XO. Support existing deployments
> by
>  producing images with the most recent Sugar release. Stick to a
> Fedora 18
>  base system, the work to upgrade is highly non trivial. Provide
> custom rpms
>  for the sugar modules and a few dependencies, most importantly
> Webkit, which
>  is required by web activities.
> >>>
> >>> In the short term, we don't need backport Webkit2 to F18. In the long
> term,
> >>> we need find a solution to move to a newer Fedora in the XOs, maybe 20
> or 21.
> >>>
>  * Ensure web activities run well in web browsers. This will cover
> Android
>  and other non-Linux systems.
>  * Reuse the work done by OLPC on Fedora to get Sugar running nicely
> on one
>  or two ARM boards (Beagle board black and Cubox-i seems to be the
> best we
>  could pick at the moment). Talk to the manufacturers to get publicity
> on the
>  images we produce and devices for the developers.
> >>>
> >>> Maybe not only ARM hardware. At least in South America, many places
> >>> are using Classmates in educative projects. I know talks between OLPC
> >>> and Intel were difficult in the past, but is a different world now.
> >>
> >> Classmates are basically just x86 netbooks, I've not tried it as I
> >> don't have HW but I don't see any reason they shouldn't work OOTB.
> >
> > Yep. Sugar is running in classmates out of the box.  In Uruguay for
> example.
> >
> > --
> > .. manuq ..
>



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

Re: [Sugar-devel] [IAEP] Tech roadmap

[Daniel Narvaez]

On 6 November 2013 16:12, Gonzalo Odiard  wrote:

> > * Wait and see what happens with the XO. Support existing deployments by
> > producing images with the most recent Sugar release. Stick to a Fedora 18
> > base system, the work to upgrade is highly non trivial. Provide custom
> rpms
> > for the sugar modules and a few dependencies, most importantly Webkit,
> which
> > is required by web activities.
>
> In the short term, we don't need backport Webkit2 to F18.


Please elaborate :)

I think developing web activities on two very different platforms (WebKit1
and WebKit2) is a bad idea, it will involve more work (and pain) then doing
some backporting.


> In the long term,
> we need find a solution to move to a newer Fedora in the XOs, maybe 20 or
> 21.
>

Yes, ideally. I just don't see this happening in the short time and I'm
worried it might not happen at all, given the kind of work that seems to be
involved. It would be awesome to be proven wrong...

Until that happens though I think we need to be able to get the latest
sugar (and it's dependencies) on a XO.

> * Ensure web activities run well in web browsers. This will cover Android
> > and other non-Linux systems.
> > * Reuse the work done by OLPC on Fedora to get Sugar running nicely on
> one
> > or two ARM boards (Beagle board black and Cubox-i seems to be the best we
> > could pick at the moment). Talk to the manufacturers to get publicity on
> the
> > images we produce and devices for the developers.
>
> Maybe not only ARM hardware. At least in South America, many places
> are using Classmates in educative projects. I know talks between OLPC
> and Intel were difficult in the past, but is a different world now.


Yes! I think it would be good to research Intel hardware. After all they
are using this wonderful secure boot stuff (sigh) instead of locking the
OS, which would make things much easier...
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [IAEP] Tech roadmap

[Gonzalo Odiard]

Yes, but we never provided a easy way to install in classmates,
or tried to approach hardware manufactures to propose them to invest on that.

Gonzalo

On Wed, Nov 6, 2013 at 12:20 PM, Manuel Quiñones  wrote:
> 2013/11/6 Peter Robinson :
>> On Wed, Nov 6, 2013 at 3:12 PM, Gonzalo Odiard  wrote:
>>> On Wed, Nov 6, 2013 at 11:49 AM, Daniel Narvaez  wrote:
 Hello,

 I think Sugar Labs needs to express a clear, realistic technology roadmap.
 For example, we have been talking a lot about Sugar on Android, mixing a 
 lot
 of different things under that name. We need to clarify what that really 
 is.

 Here are my thoughts, inspired by the oversight board meeting thread.

 * Wait and see what happens with the XO. Support existing deployments by
 producing images with the most recent Sugar release. Stick to a Fedora 18
 base system, the work to upgrade is highly non trivial. Provide custom rpms
 for the sugar modules and a few dependencies, most importantly Webkit, 
 which
 is required by web activities.
>>>
>>> In the short term, we don't need backport Webkit2 to F18. In the long term,
>>> we need find a solution to move to a newer Fedora in the XOs, maybe 20 or 
>>> 21.
>>>
 * Ensure web activities run well in web browsers. This will cover Android
 and other non-Linux systems.
 * Reuse the work done by OLPC on Fedora to get Sugar running nicely on one
 or two ARM boards (Beagle board black and Cubox-i seems to be the best we
 could pick at the moment). Talk to the manufacturers to get publicity on 
 the
 images we produce and devices for the developers.
>>>
>>> Maybe not only ARM hardware. At least in South America, many places
>>> are using Classmates in educative projects. I know talks between OLPC
>>> and Intel were difficult in the past, but is a different world now.
>>
>> Classmates are basically just x86 netbooks, I've not tried it as I
>> don't have HW but I don't see any reason they shouldn't work OOTB.
>
> Yep. Sugar is running in classmates out of the box.  In Uruguay for example.
>
> --
> .. manuq ..
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Putting a little of order in the Features wiki pages

[Walter Bender]

great work Gonzalo.

-walter

On Wed, Nov 6, 2013 at 10:01 AM, Gonzalo Odiard  wrote:
> The Category Feature used to have all the Features we worked in all
> the history of Sugar, and was really difficult know what was done,
> what was a proposal, what was pending and so.
>
>  Trying to solve that, I moved the Features already landed to
> FeatureLanded category:
>
> http://wiki.sugarlabs.org/go/Category:FeatureLanded
>
> (in dark days, look how much this community did)
>
> also, moved to a Category FeatureObsoleted, features no longer applicable
>
> http://wiki.sugarlabs.org/go/Category:FeatureObsoleted
>
> and the pages with the list of features for every release to FeatureList
>
> http://wiki.sugarlabs.org/go/Category:FeatureList
>
> Now, in the page Feature, we "only" have 59 wiki pages, with work
> proposed or in development (before was more than 100).
>
> http://wiki.sugarlabs.org/go/Category:Feature
>
> Some of they are already in the 0.102 page
> http://wiki.sugarlabs.org/go/0.102/Feature_List
>
> Gonzalo
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel



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

Re: [Sugar-devel] [IAEP] Tech roadmap

[Manuel Quiñones]

2013/11/6 Peter Robinson :
> On Wed, Nov 6, 2013 at 3:12 PM, Gonzalo Odiard  wrote:
>> On Wed, Nov 6, 2013 at 11:49 AM, Daniel Narvaez  wrote:
>>> Hello,
>>>
>>> I think Sugar Labs needs to express a clear, realistic technology roadmap.
>>> For example, we have been talking a lot about Sugar on Android, mixing a lot
>>> of different things under that name. We need to clarify what that really is.
>>>
>>> Here are my thoughts, inspired by the oversight board meeting thread.
>>>
>>> * Wait and see what happens with the XO. Support existing deployments by
>>> producing images with the most recent Sugar release. Stick to a Fedora 18
>>> base system, the work to upgrade is highly non trivial. Provide custom rpms
>>> for the sugar modules and a few dependencies, most importantly Webkit, which
>>> is required by web activities.
>>
>> In the short term, we don't need backport Webkit2 to F18. In the long term,
>> we need find a solution to move to a newer Fedora in the XOs, maybe 20 or 21.
>>
>>> * Ensure web activities run well in web browsers. This will cover Android
>>> and other non-Linux systems.
>>> * Reuse the work done by OLPC on Fedora to get Sugar running nicely on one
>>> or two ARM boards (Beagle board black and Cubox-i seems to be the best we
>>> could pick at the moment). Talk to the manufacturers to get publicity on the
>>> images we produce and devices for the developers.
>>
>> Maybe not only ARM hardware. At least in South America, many places
>> are using Classmates in educative projects. I know talks between OLPC
>> and Intel were difficult in the past, but is a different world now.
>
> Classmates are basically just x86 netbooks, I've not tried it as I
> don't have HW but I don't see any reason they shouldn't work OOTB.

Yep. Sugar is running in classmates out of the box.  In Uruguay for example.

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

Re: [Sugar-devel] Activity Central's Sugar related priorities.

[Daniel Narvaez]

On 22 October 2013 21:41, NoiseEHC  wrote:

>  You are right. The problem is that my views are exactly the opposite of
> the decided path to take.
>

I don't think that's true.

I'm one of the three developers involved in the web activities work and I
like many of your ideas. Manuel in his reply appeared to be interested too.
I have the feeling that if you look into it some more you might see the
paths are not that different. But even if you really think we got it all
wrong , I'd say we have been mostly researching so far... there is
certainly space to fix the direction.

Please get involved. Post your thoughts (constructive or not) when we
discuss topics we have been researching (I'd say we did that for any non
trivial topic so far). Make proposals, send patches.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [IAEP] Tech roadmap

[Peter Robinson]

On Wed, Nov 6, 2013 at 3:12 PM, Gonzalo Odiard  wrote:
> On Wed, Nov 6, 2013 at 11:49 AM, Daniel Narvaez  wrote:
>> Hello,
>>
>> I think Sugar Labs needs to express a clear, realistic technology roadmap.
>> For example, we have been talking a lot about Sugar on Android, mixing a lot
>> of different things under that name. We need to clarify what that really is.
>>
>> Here are my thoughts, inspired by the oversight board meeting thread.
>>
>> * Wait and see what happens with the XO. Support existing deployments by
>> producing images with the most recent Sugar release. Stick to a Fedora 18
>> base system, the work to upgrade is highly non trivial. Provide custom rpms
>> for the sugar modules and a few dependencies, most importantly Webkit, which
>> is required by web activities.
>
> In the short term, we don't need backport Webkit2 to F18. In the long term,
> we need find a solution to move to a newer Fedora in the XOs, maybe 20 or 21.
>
>> * Ensure web activities run well in web browsers. This will cover Android
>> and other non-Linux systems.
>> * Reuse the work done by OLPC on Fedora to get Sugar running nicely on one
>> or two ARM boards (Beagle board black and Cubox-i seems to be the best we
>> could pick at the moment). Talk to the manufacturers to get publicity on the
>> images we produce and devices for the developers.
>
> Maybe not only ARM hardware. At least in South America, many places
> are using Classmates in educative projects. I know talks between OLPC
> and Intel were difficult in the past, but is a different world now.

Classmates are basically just x86 netbooks, I've not tried it as I
don't have HW but I don't see any reason they shouldn't work OOTB.

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

Re: [Sugar-devel] [IAEP] Tech roadmap

[Gonzalo Odiard]

On Wed, Nov 6, 2013 at 11:49 AM, Daniel Narvaez  wrote:
> Hello,
>
> I think Sugar Labs needs to express a clear, realistic technology roadmap.
> For example, we have been talking a lot about Sugar on Android, mixing a lot
> of different things under that name. We need to clarify what that really is.
>
> Here are my thoughts, inspired by the oversight board meeting thread.
>
> * Wait and see what happens with the XO. Support existing deployments by
> producing images with the most recent Sugar release. Stick to a Fedora 18
> base system, the work to upgrade is highly non trivial. Provide custom rpms
> for the sugar modules and a few dependencies, most importantly Webkit, which
> is required by web activities.

In the short term, we don't need backport Webkit2 to F18. In the long term,
we need find a solution to move to a newer Fedora in the XOs, maybe 20 or 21.

> * Ensure web activities run well in web browsers. This will cover Android
> and other non-Linux systems.
> * Reuse the work done by OLPC on Fedora to get Sugar running nicely on one
> or two ARM boards (Beagle board black and Cubox-i seems to be the best we
> could pick at the moment). Talk to the manufacturers to get publicity on the
> images we produce and devices for the developers.

Maybe not only ARM hardware. At least in South America, many places
are using Classmates in educative projects. I know talks between OLPC
and Intel were difficult in the past, but is a different world now.

> * Work with deployments to see if there are "complete" hardware solutions
> (Chromebooks for example) they could use. In the case of locked devices they
> might have the where-with-all to load custom software.
> * Migrate from X to  Wayland or support it in parallel (depending on the
> performance of non accellerated Wayland). GNOME is doing most of the work,
> but we will need the rework the window management bits. This will allow us
> to run on Android drivers with libhybris, which should help with hardware
> support.
>
> As you might have noticed there is no Sugar on Android, other than for
> drivers support and web activities running in a web browser. I don't think
> going beyhond those gives us any real advantage.
>
> Just my $0.02
>
> --
> Daniel Narvaez
>

Gonzalo

> ___
> IAEP -- It's An Education Project (not a laptop project!)
> i...@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/iaep
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] Putting a little of order in the Features wiki pages

[Gonzalo Odiard]

The Category Feature used to have all the Features we worked in all
the history of Sugar, and was really difficult know what was done,
what was a proposal, what was pending and so.

 Trying to solve that, I moved the Features already landed to
FeatureLanded category:

http://wiki.sugarlabs.org/go/Category:FeatureLanded

(in dark days, look how much this community did)

also, moved to a Category FeatureObsoleted, features no longer applicable

http://wiki.sugarlabs.org/go/Category:FeatureObsoleted

and the pages with the list of features for every release to FeatureList

http://wiki.sugarlabs.org/go/Category:FeatureList

Now, in the page Feature, we "only" have 59 wiki pages, with work
proposed or in development (before was more than 100).

http://wiki.sugarlabs.org/go/Category:Feature

Some of they are already in the 0.102 page
http://wiki.sugarlabs.org/go/0.102/Feature_List

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

Re: [Sugar-devel] Have we achieved consensus among activite Sugar developers? [ Sugar-devel Digest, Vol 61, Issue 21]

[Daniel Narvaez]

On 6 November 2013 07:15, Sebastian Silva  wrote:

> El 06/11/13 00:40, Yioryos Asprobounitis escribió:
>
>> Looking at the archives of this list you can find several cases (some
>> recent)
>> of "non-conforming" contributors that are not contributing anymore,
>> supporting the
>> "high conformity" hypothesis.
>>
> I too feel the overall attitude within this list has been dismissive of
> non-conforming ideas and individuals, sometimes bluntly. The spanish
> speakers, from Xavi who did so much translation, to Homunq who
> started (and abandoned) Develop Activity, to Yama whose ideals always
> seemed to clash with reality, I miss them. I myself have been often
> frustrated, having retreated biting my tongue more than once.
>
> It makes me think of the eastern spiritual ideal of speaking only when
> necessary, and then only the truth, and then only with sweet words.
>
> Probably we have all broken that ideal here, and it is not clear how to
> facilitate constructive non-conformism.
>

I can think of at least a couple of cases where the list could have been
more welcoming to  non-comforming contributors.

That said I hope this thread doesn't discourage people to get involved.
Everything can be improved but Sugar is perhaps the most welcoming free
software community I know of... For good or for bad, "sweet words" aren't
really what you are normally met by if your ideas or patches are not
considered high quality enough by the existing community.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] Tech roadmap

[Daniel Narvaez]

Hello,

I think Sugar Labs needs to express a clear, realistic technology roadmap.
For example, we have been talking a lot about Sugar on Android, mixing a
lot of different things under that name. We need to clarify what that
really is.

Here are my thoughts, inspired by the oversight board meeting thread.

* Wait and see what happens with the XO. Support existing deployments by
producing images with the most recent Sugar release. Stick to a Fedora 18
base system, the work to upgrade is highly non trivial. Provide custom rpms
for the sugar modules and a few dependencies, most importantly Webkit,
which is required by web activities.
* Ensure web activities run well in web browsers. This will cover Android
and other non-Linux systems.
* Reuse the work done by OLPC on Fedora to get Sugar running nicely on one
or two ARM boards (Beagle board black and Cubox-i seems to be the best we
could pick at the moment). Talk to the manufacturers to get publicity on
the images we produce and devices for the developers.
* Work with deployments to see if there are "complete" hardware solutions
(Chromebooks for example) they could use. In the case of locked devices
they might have the where-with-all to load custom software.
* Migrate from X to  Wayland or support it in parallel (depending on the
performance of non accellerated Wayland). GNOME is doing most of the work,
but we will need the rework the window management bits. This will allow us
to run on Android drivers with libhybris, which should help with hardware
support.

As you might have noticed there is no Sugar on Android, other than for
drivers support and web activities running in a web browser. I don't think
going beyhond those gives us any real advantage.

Just my $0.02

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

Re: [Sugar-devel] new feature for 102: Launch Limits

[Daniel Narvaez]

If there is any possible future use case for it, yes. Otherwise imo it's
just confusing. Single instance vs multiple instance application is a well
known concept. I have never heard of double or triple instance applications
though :)

On 6 November 2013 14:43, Gonzalo Odiard  wrote:

> I can't think now a example, but a integer is more future proof.
>
> Gonzalo
>
> On Wed, Nov 6, 2013 at 10:29 AM, Daniel Narvaez 
> wrote:
> > Is it useful for maximum_instances to be different from 1? Otherwise I
> tend
> > to think a single_instance boolean would make more sense and allow a
> better
> > alert.
> >
> >
> > On 5 November 2013 18:53, Walter Bender  wrote:
> >>
> >> I wrote up a page for a proposed enhancement to set limit to open
> >> activities and open instances [1].
> >>
> >> Summary:
> >>
> >> At the request of OLPC AU (in an effort to reduce OOM freezes) this
> >> patch uses gconf to set a maximum number of open activities. An alert
> >> is shown if the user tries to launch more activities than the maximum
> >> asking them to close an activity before opening a new one. If
> >> maximum_number_of_open_activites is not set or == 0, then there is no
> >> maximum limit applied.
> >>
> >> Further, Some activities don't behave well if more than one instance
> >> is open (e.g., SL #4554). This patch sets a limit on the number open
> >> instances of an activity based on a new field in activity.info:
> >> maximum_instances.
> >>
> >> If and only if the maximum_instances field is present in
> >> activity.info, is it used to set the limit of open instances.
> >>
> >>
> >> thanks for your consideration.
> >>
> >> -walter
> >>
> >>
> >> [1] http://wiki.sugarlabs.org/go/Features/LaunchLimits
> >>
> >> --
> >> Walter Bender
> >> Sugar Labs
> >> http://www.sugarlabs.org
> >> ___
> >> Sugar-devel mailing list
> >> Sugar-devel@lists.sugarlabs.org
> >> http://lists.sugarlabs.org/listinfo/sugar-devel
> >
> >
> >
> >
> > --
> > Daniel Narvaez
> >
> > ___
> > Sugar-devel mailing list
> > Sugar-devel@lists.sugarlabs.org
> > http://lists.sugarlabs.org/listinfo/sugar-devel
> >
>



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

Re: [Sugar-devel] new feature for 102: Launch Limits

[Gonzalo Odiard]

I can't think now a example, but a integer is more future proof.

Gonzalo

On Wed, Nov 6, 2013 at 10:29 AM, Daniel Narvaez  wrote:
> Is it useful for maximum_instances to be different from 1? Otherwise I tend
> to think a single_instance boolean would make more sense and allow a better
> alert.
>
>
> On 5 November 2013 18:53, Walter Bender  wrote:
>>
>> I wrote up a page for a proposed enhancement to set limit to open
>> activities and open instances [1].
>>
>> Summary:
>>
>> At the request of OLPC AU (in an effort to reduce OOM freezes) this
>> patch uses gconf to set a maximum number of open activities. An alert
>> is shown if the user tries to launch more activities than the maximum
>> asking them to close an activity before opening a new one. If
>> maximum_number_of_open_activites is not set or == 0, then there is no
>> maximum limit applied.
>>
>> Further, Some activities don't behave well if more than one instance
>> is open (e.g., SL #4554). This patch sets a limit on the number open
>> instances of an activity based on a new field in activity.info:
>> maximum_instances.
>>
>> If and only if the maximum_instances field is present in
>> activity.info, is it used to set the limit of open instances.
>>
>>
>> thanks for your consideration.
>>
>> -walter
>>
>>
>> [1] http://wiki.sugarlabs.org/go/Features/LaunchLimits
>>
>> --
>> Walter Bender
>> Sugar Labs
>> http://www.sugarlabs.org
>> ___
>> Sugar-devel mailing list
>> Sugar-devel@lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
>
>
> --
> Daniel Narvaez
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] new feature for 102: Launch Limits

[Daniel Narvaez]

Is it useful for maximum_instances to be different from 1? Otherwise I tend
to think a single_instance boolean would make more sense and allow a better
alert.


On 5 November 2013 18:53, Walter Bender  wrote:

> I wrote up a page for a proposed enhancement to set limit to open
> activities and open instances [1].
>
> Summary:
>
> At the request of OLPC AU (in an effort to reduce OOM freezes) this
> patch uses gconf to set a maximum number of open activities. An alert
> is shown if the user tries to launch more activities than the maximum
> asking them to close an activity before opening a new one. If
> maximum_number_of_open_activites is not set or == 0, then there is no
> maximum limit applied.
>
> Further, Some activities don't behave well if more than one instance
> is open (e.g., SL #4554). This patch sets a limit on the number open
> instances of an activity based on a new field in activity.info:
> maximum_instances.
>
> If and only if the maximum_instances field is present in
> activity.info, is it used to set the limit of open instances.
>
>
> thanks for your consideration.
>
> -walter
>
>
> [1] http://wiki.sugarlabs.org/go/Features/LaunchLimits
>
> --
> Walter Bender
> Sugar Labs
> http://www.sugarlabs.org
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>



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

Re: [Sugar-devel] new feature proposal for 102: sharing favorites

[Daniel Narvaez]

I'm not quit convinced about the implementation, this really feels like
something that should be stored in gconf/gsettings rather than using a dbus
method. Might be a good idea to use gsettings directly here because it's
basically a list of lists and the details of how you store those might
differ between the two systems, making migration complicated.


On 5 November 2013 19:51, Walter Bender  wrote:

> I've written up a new feature description to enable updating favorires
> through a dbus service [1].
>
> Summary
>
> Since multiple homeviews landed in Sugar 100, it would be nice to
> enable user-space updates to the homeviews. This requires a new dbus
> service. The idea is that Sugar activities, e.g. ShareFavorites [2],
> could share favorites without requiring a reboot. So, for example, a
> teacher could share a desktop specific to a lesson plan.
>
> thank you for your consideration.
>
> -walter
>
>
> [1] http://wiki.sugarlabs.org/go/Features/UpdateFavorites
> [2] http://wiki.sugarlabs.org/go/Activities/ShareFavorites
> --
> Walter Bender
> Sugar Labs
> http://www.sugarlabs.org
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>



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

Re: [Sugar-devel] new feature for 102: honor maximum_participants

[Daniel Narvaez]

Yes, could even be considered a bug fix.


On 5 November 2013 19:16, Walter Bender  wrote:

> I wrote up a page for a proposed enhancement to honor the maximum
> participants field [1]
>
> Summary
>
> At the request of OLPC AU, we'd like to honor the maximum_participants
> limit. Right now that limit is only used to determine whether or not
> an activity can be shared, but not the number of users who can join.
> This feature would inform users trying to join an activity that has
> already reached its maximum that the maximum number of sharers has
> been reached.
>
> If and only if the maximum_participant field is set is it used to set
> the limit of joiners.
>
> thanks for your consideration.
>
> -walter
>
>
> [1] http://wiki.sugarlabs.org/go/Features/JoinLimits
> --
> Walter Bender
> Sugar Labs
> http://www.sugarlabs.org
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>



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

Re: [Sugar-devel] new feature for 102: Launch Limits

[Daniel Narvaez]

Make sense to me. Btw I would really like to get design team on all the
proposal you posted.


On 5 November 2013 18:53, Walter Bender  wrote:

> I wrote up a page for a proposed enhancement to set limit to open
> activities and open instances [1].
>
> Summary:
>
> At the request of OLPC AU (in an effort to reduce OOM freezes) this
> patch uses gconf to set a maximum number of open activities. An alert
> is shown if the user tries to launch more activities than the maximum
> asking them to close an activity before opening a new one. If
> maximum_number_of_open_activites is not set or == 0, then there is no
> maximum limit applied.
>
> Further, Some activities don't behave well if more than one instance
> is open (e.g., SL #4554). This patch sets a limit on the number open
> instances of an activity based on a new field in activity.info:
> maximum_instances.
>
> If and only if the maximum_instances field is present in
> activity.info, is it used to set the limit of open instances.
>
>
> thanks for your consideration.
>
> -walter
>
>
> [1] http://wiki.sugarlabs.org/go/Features/LaunchLimits
>
> --
> Walter Bender
> Sugar Labs
> http://www.sugarlabs.org
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>



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

Re: [Sugar-devel] new features for 102

[Daniel Narvaez]

This make sense to me. Simple, provedly useful feature.


On 5 November 2013 18:18, Walter Bender  wrote:

> I wrote up a page for a proposed enhancement to the About Me section
> of the control panel [1].
>
> Summary:
>
> OLPC Australia uses gender and age as part of their program analysis.
> They also use age to modify the behavior of some activities, e.g., the
> robot in the Speak activity takes on the age of the user. The proposed
> feature is to modify the About Me CP section and the initial intro
> pages to include widgets for selecting gender and age.
>
> thanks for your consideration.
>
> -walter
>
>
> [1] http://wiki.sugarlabs.org/go/Features/AboutMe
>
> --
> Walter Bender
> Sugar Labs
> http://www.sugarlabs.org
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>



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

Re: [Sugar-devel] new features for 102 (Walter Bender)

[Gonzalo Odiard]

On Wed, Nov 6, 2013 at 6:49 AM, Lionel Laské  wrote:
>
>
> Hi Walter,
>
> Nice feature.
> Two questions:
> - It could be nice to include gender informations (and nickname too) in
> backups. At OLPC France (guess like at lot of other deployments) we
> developed a backup process that get datastore contents, gnome desktop
> contents and write a file name "nickname" with the XO informations,

The information is stored inGConf, your backup process can get it an
restore it later.

> - It seems that this feature is already include in the 0.100 Testing version
> (http://wiki.sugarlabs.org/go/0.100/Testing). Gender/age is asked at first
> boot.
> Is it a 0.100 feature too ?
>

The testing images include the work done for Australia deployment,
that is the reason, this and other features proposed by Walter are
already included.

Gonzalo


> Best regards from France.
>
>  Lionel.
>
>
>
> 2013/11/5 
>>
>> Date: Tue, 5 Nov 2013 12:18:42 -0500
>> From: Walter Bender 
>> To: Sugar-dev Devel 
>> Subject: [Sugar-devel] new features for 102
>> Message-ID:
>>
>> 
>> Content-Type: text/plain; charset=ISO-8859-1
>>
>> I wrote up a page for a proposed enhancement to the About Me section
>> of the control panel [1].
>>
>> Summary:
>>
>> OLPC Australia uses gender and age as part of their program analysis.
>> They also use age to modify the behavior of some activities, e.g., the
>> robot in the Speak activity takes on the age of the user. The proposed
>> feature is to modify the About Me CP section and the initial intro
>> pages to include widgets for selecting gender and age.
>>
>> thanks for your consideration.
>>
>> -walter
>>
>>
>> [1] http://wiki.sugarlabs.org/go/Features/AboutMe
>>
>> --
>> 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-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] new features for 102 (Walter Bender)

[Lionel Laské]

Hi Walter,

Nice feature.
Two questions:
- It could be nice to include gender informations (and nickname too) in
backups. At OLPC France (guess like at lot of other deployments) we
developed a backup process that get datastore contents, gnome desktop
contents and write a file name "nickname" with the XO informations,
- It seems that this feature is already include in the 0.100 Testing
version (http://wiki.sugarlabs.org/go/0.100/Testing). Gender/age is asked
at first boot.
Is it a 0.100 feature too ?

Best regards from France.

 Lionel.



2013/11/5 

> Date: Tue, 5 Nov 2013 12:18:42 -0500
> From: Walter Bender 
> To: Sugar-dev Devel 
> Subject: [Sugar-devel] new features for 102
> Message-ID:
> <
> cadf7c8sg81h7nzvekivczh4a5noyke80mido2y_pjgy07hf...@mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> I wrote up a page for a proposed enhancement to the About Me section
> of the control panel [1].
>
> Summary:
>
> OLPC Australia uses gender and age as part of their program analysis.
> They also use age to modify the behavior of some activities, e.g., the
> robot in the Speak activity takes on the age of the user. The proposed
> feature is to modify the About Me CP section and the initial intro
> pages to include widgets for selecting gender and age.
>
> thanks for your consideration.
>
> -walter
>
>
> [1] http://wiki.sugarlabs.org/go/Features/AboutMe
>
> --
> Walter Bender
> Sugar Labs
> http://www.sugarlabs.org
>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel