Re: [Sugar-devel] Have we achieved consensus among activite Sugar developers?

[NoiseEHC]

Sugar Labs has found itself in a position where there is a high degree
of conformity. This tends to create an echo chamber where similar
opinions are respected and encouraged. That can be effective at
building passion and energy, but it tends to crowd out dissenting
opinions and marginalize the people who hold those opinions. These
people can be the most productive members of the community in their
particular areas of interest.

Of all the people who participated in this discussion,
you are the only who is repeating this. Is possible this is only
your personal point of view?



Actually that is my experience as well. But of course I am very biased 
because I write to the mailing list only when I have a differing 
viewpoint and have to say something different than others. Otherwise 
there are usually enough agreeing people that I do not write to the list 
just to agree.
All that told, usually I did not get other than I should not tell others 
what to do or CADT... Maybe it is my fault and I just should not think 
differently. Who knows?



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

[Sugar-devel] native HTML activity

[NoiseEHC]

Hi!

Just to prove that it can be done, I have hacked a little bit more on 
the native HTML activity which can be found here:

https://github.com/NoiseEHC/sugar-webkit-native

I tried to create virtual pages by using WebKit1's or Soap's url 
rewriting callbacks but it turns out that no matter what you do, the 
thing wants to use the data from the TCP stream... So I turned to 
starting a (Soap) HTTP server inside the native activity (on a random 
port) and it works. Now the activity runs from localhost (/activity and 
/web subfolders) and there is a virtual folder called /journal. It has 
only one hacked file, the /journal/journal.html, which has links to all 
the things in the journal. It queries the journal service via DBUS. I 
have to tell you that working with GVariant from C is a real PITA, so I 
did not implement the load/store of the real journal files, but it is 
clearly possible... (Beware, it leaks every possible resources, it is 
just a proof of concept.)


Now, I do not know what is the problem with WebKit1, it seems to work 
for me, and at least it does not crash on an XO-1.75 as WebKit2 does. On 
the other hand I cannot try it on my XO-1.75 as it is not possible 
anymore to install webkitgtk-devel on the machine as I told you last time...


This whole project has the following benefits:
- It is much-much faster than the python one. It does matter on an XO.
- It does not depend on the WebKitGTK python bindings to be maintained, 
it can use all WebKitGTK's features.

- It does not have a dependency on Node.js.
- It does not use WebSocket, which would require using WebKit2...

So now it is your decision whether you use it or not.

Thanks,
Andrew
___
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.

[NoiseEHC]

On 22/10/2013 21:21, Gonzalo Odiard wrote:



So that was my $0.02. Obviously it can be too late to change plans
but who knows. I have uploaded the source anyway so you can use it
if you want.


What I really don't understand is, if is all that easy why not be 
involved and help?
The development of the web activities stuff was done in the open, 
mostly by two developers,

manuq & dnarvaez. Then everyone who wanted help, could do it.
Say now how should be done, is  useless at least.
Talk is easy... as always, the devil is in the details. But you 
already know that,

if not would not talk about "unconstructive criticism"

Gonzalo



You are right. The problem is that my views are exactly the opposite of 
the decided path to take. I do not help developing because I totally 
oppose the current path, meaning that I do not believe that it can work. 
All the easy talk can be useful later *if* they decide to change paths. 
Or it will just remain an interesting viewpoint, but at least I tried.
So while you are right about the "Talk is easy" part as well, I could 
only help developing by finishing the native webkit app (because I 
believe in it), which would be totally wasted (parallel) effort. 
Actually that was the plan but then I run out of time and realized that 
the official project went a different direction anyway.
___
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.

[NoiseEHC]

I have put the ?latest? sources here:
https://github.com/NoiseEHC/sugar-webkit-native
It requires a "yum install webkitgtk3-devel" to be able to compile, 
unfortunately my XO-1.75 says that there are no more mirrors to try 
for mesa and libdrm dependencies so I could not try it under an ARM 
XO... (I did try it some time ago however it just stopped working.)
You may also need to create a test2/bin directory as git does not 
include it...
The code is full of static char buffers which should be fixed and it 
also crashes on an XO when you compile with webkit2gtk...


Ehem, the source should be in a directory called test2 so it matches the 
name in the .info file... That is why it requires a test/bin subdir...

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

[NoiseEHC]

Hi!

Took some time but finally set up my git account...


2 Journal

This is probably the issue we have been most aware of. I've been 
thinking in the per activity datastore direction too and I think it's 
probably the best one. Though as you say that involves UI redesign and 
we would need to figure out compatibility with existing activities. 
(Please share the webkit code, I don't know if I'll have time to hack 
on it but I did think to write something like that at some point, it 
would be interesting to look at it if nothing else).




I have put the ?latest? sources here:
https://github.com/NoiseEHC/sugar-webkit-native
It requires a "yum install webkitgtk3-devel" to be able to compile, 
unfortunately my XO-1.75 says that there are no more mirrors to try for 
mesa and libdrm dependencies so I could not try it under an ARM XO... (I 
did try it some time ago however it just stopped working.)
You may also need to create a test2/bin directory as git does not 
include it...
The code is full of static char buffers which should be fixed and it 
also crashes on an XO when you compile with webkit2gtk...




We probably all agree that it would be awesome to have something  that 
integrates well with Sugar and works transparently by reusing existing 
web technologies. I don't think that's easy to achieve though. It has 
been said in previous discussions that without the close integration 
between activities and system, Sugar would be just yet another suite 
of educational applications (and likely not the best of them). I very 
much agree and I think it's tricky to preserve that while moving to 
frameworks which are supposed to work everywhere.


We could have started with something more web developer friendly and 
incrementally integrated it into the native Sugar platform, for 
example by redesigning the Journal in the way you described, and 
somehow adapting native activities to the new design. Instead we went 
for something targeted at the current Sugar developers with the idea 
of making it incrementally more web friendly.


I have been on the fence on what was the best approach and I still am. 
Something to consider is that we barely have the resources to maintain 
the existing native code. I doubt, for example, that we would be able 
to ship a redesigned Journal. Consider also that the people most 
involved with this work has all a good knowledge of the Sugar platform 
but are not really web developers.




I fail to see why would it be bad if "Sugar would be just yet another 
suite of educational applications". Currently the "close integration 
between activities and system" consist only of 3 DBUS methods, 4 X 
properties, the Journal as a filesystem and the presence service (which 
is desugarized if I remember correctly, you have to use Telepathy 
directly?). In my opinion the single most important thing would be to 
allow developing sugar applications directly in the PC browser (like 
firefox or chrome). If that would work then you could just go to a web 
conference and after giving a presentation about sugar-web you could ask 
the attended crowd to help you in the workshop by converting just 
ONE/person python activity into a web one and you are done with the 
conversion in a day... Obviously it would not make converting 
Write/TurtleArt/Etoys/Scratch easy but at least the rest would be done.


Now, if you go standard web, then you do not need the X properties, 
view-source is built into the browser (DBUS HandleViewSource) and DBUS 
SetActive can be done with "webkitvisibilitychange" event and timers. 
The only remaining thing would be handling the DBUS Invite.
Collaboration would most likely need an OT library which should have a C 
implementation on the XO to have usable speed.
The Journal simply can be implemented by the host application by 
providing either some standard file API implementation (like 
light-swift) or just providing a virtual page with links and POST.

https://github.com/bancek/light-swift

So if you already run a node.js server then probably it could host the 
activity's html files and could provide some virtual file GET/POST 
service in

http://localhost/journal/directory.json <- this is for file list
http://localhost/journal/guidcomeshere <- this is for GET/POST files

My plan was to support http://localhost directly from 
sugar-webkit-native (instead using file:// to be able to OAuth) and 
query/update the journal from there too but it is simpler from node.js 
if you are running it anyways. You can also assume that web developers 
have node.js running on their dev machine or already know how to install 
it. If you forget for a while to have collaboration from web apps then 
the rest can be done in no time IMHO.


So that was my $0.02. Obviously it can be too late to change plans but 
who knows. I have uploaded the source anyway so you can use it if you want.


Regards,
Andrew

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

[NoiseEHC]

On 07/10/2013 18:41, David Farning wrote:

Activity Central supports the recent HTML5 + JS work that is going
into sugar .100. It has the potential to take the OLPC vision to any
device which runs a browser while simultaneously *increasing* the
potential activity *developer* *pool* by several orders of magnitude. This
is an excellent area for community lead research. Activity Central
will be doing activity side work to test the viability of the
framework for client deployments.



No, it won't... It already happened when Bryan Berry moved OLPC Nepal's 
lessons from EToys to Flash, then to HTML5 and there were not any more 
contributors. I mean, there are much more JS developers, so if you pay 
them you can get cheaper talent, but there will be not too much more 
contributors IMHO. The problem is that the current HTML5 work goes into 
a direction which I am not sure that needed by anyone other than 
existing Sugar developers.


It all boils down to this simple question:
If you are a potential contributor wanting to develop some educational 
activity (not a framework but some concrete lesson or stuff usable in a 
lesson!!!) then which one would you use?
1. A HTML5 + JavaScript activity model called Sugar Web Activity, which 
reaches 2-3 million children? (lets call it SWA)
2. A HTML5 + JavaScript activity model called HTML5 + JavaScript, which 
reaches 1 billion children? (lets call it WEB)
I have not seen any compelling reason why would a potential contributor 
(software developer from a developed country who has/likes children) 
choose option 1 instead of 2...


Now I will not give you constructive criticism as that would allow 
answering that "I should not tell others what to do" and it would be 
getting old... Instead here is some nonconstructive criticism:


Some months ago I wanted to create a sample activity to present my point 
but I have run out of time so unfortunately I cannot show it to you. It 
would have been a Google Drive backed game with shared state (so the 
same as a typical shared activity in Sugar) called Scrabble what I try 
to port to SWA. It uses the following things which are trivial to use on 
the WEB but cannot be found in SWA:


1. Sign in. There is no authorization API in SWA so using anything than 
the local journal is problematic. Using Google's OAuth authentication 
from a file:// protocol is impossible so if you want to support existing 
code then you have to serve the activity from http://localhost...

https://developers.google.com/drive/about-auth

2. Datastore. There is no way to access the Google Drive if you cannot 
authenticate. I do not see why would anyone use a new JavaScript lib 
which accesses only the journal when they are already familiar with some 
WEB technology. Like WEBDAV or the OpenStack's SWIFT API.

http://docs.openstack.org/api/openstack-object-storage/1.0/content/storage-object-services.html
Or simply using POST for uploading:
https://developers.google.com/drive/manage-uploads

3. Collaboration. Using the Google Drive Realtime API is dead simple. It 
is the most missing feature from SWA BTW.

https://developers.google.com/drive/realtime/
I have looked at several open source Operational Transformations 
libraries but did not have time to test their performance on an XO...


4. Using WebSockets for simple tasks. The autosaving can be implemented 
by the almost standard "webkitvisibilitychange" event (but you have to 
compile webkit with the appropriate parameters) and standard timers. 
Activity startup is simplified with per activity data store (POST-ing to 
the same server is the default on the WEB). I think it eliminates the 
communication with Sugar so no need for WebSockets...


5. Android port. There already exists a multi-platform technology called 
PhoneGap. It can target 100-200 million children so it can be called 
option 3 if you want... It can become obsolete as HTML5 provides more 
and more of its features though.

http://phonegap.com/

So as I see you either create a framework which mimics Sugar and no web 
developer will use it or create a framework which implements what a web 
developer is already using or at least tries to somehow emulate it. So 
the web developer does not have to modify his/her code and will consider 
porting his/her application for a smaller platform. Of course that would 
require OLPC/Sugarlabs to run free OpenStack/OAuth/OT servers for 
contributors otherwise everybody will go with Google APIs which cannot 
easily be emulated on an XO machine...


But as this discussion already happened and I have already written 
enough now, I just finish here. (In the following link you can replace 
the phrase "Per Activity Data Store" with "Standard WEB Storage" to be 
relevant...)

http://lists.sugarlabs.org/archive/sugar-devel/2010-June/024589.html

Thank you for your attention!
Andrew

ps:
Now to say something constructive as well, some more words about the 
Journal. Recently I was watching one of Walter Bender's talks where he 

Re: [Sugar-devel] somebody deleted gst-plugins-espeak from github?

[NoiseEHC]

Hi!

build worked as it pulled all repos. I thought that it is a connection 
problem because some days ago there was a connection problem. I just 
wanted to archive sugar-build just after pulling all the stuff as I 
really did not want to download ~450 megs again and again as I try 
different configure options for webkitgtk (as cleaning the tree does not 
work...).



Now it fails on fedora18 with this:
* Building gobject-introspection
...
checking for GLIB... no
configure: error: Package requirements (glib-2.0 >= 2.36.0) were not met:

Requested 'glib-2.0 >= 2.36.0' but version of GLib is 2.34.2

Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.

Alternatively, you may set the environment variables GLIB_CFLAGS
and GLIB_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.


So now I gave up building webkitgtk from sugar and will download 
directly from the source and will compile my little activity without sugar.


Thanks anyways,
Andrew


On 02/07/2013 21:12, Daniel Narvaez wrote:
Something else you can try is "git pull". Basically your config is 
stuck to an old version, I'm not sure exactly why. I made improvements 
in that area lately but you won't get them until this is unstuck :)


On Tuesday, 2 July 2013, Daniel Narvaez wrote:

Try to run just "./osbuild" first then pull again?

On Tuesday, 2 July 2013, Noise EHC wrote:

Hi!

For several days I get this, and looking at
https://github.com/sugarlabs/ I cannot see the repository
either...


Log:

[ehc@localhost sugar-build]$ ./osbuild pull

= Pulling =

* Pulling automake
* Pulling glib
* Pulling gobject-introspection
* Pulling pygobject
* Pulling dbus-python
* Pulling gwebsockets
* Pulling node
* Pulling grunt-cli
* Pulling volo
* Pulling karma
* Pulling jshint
* Pulling js-beautify
* Pulling docker
* Pulling flake8
* Pulling sugar-docs
* Pulling sugar-toolkit-gtk3
* Pulling sugar
* Pulling sugar-artwork
* Pulling sugar-datastore
* Pulling gst-plugins-espeak

Command failed: git clone --progress
git://github.com/sugarlabs/gst-plugins-espeak.git

gst-plugins-espeak

fatal: remote error:
  Repository not found.
Cloning into 'gst-plugins-espeak'...
Retrying (attempt 1) in 1 minute


Thanks,
Andrew



-- 
Daniel Narvaez




--
Daniel Narvaez



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

Re: [Sugar-devel] Browse and the move to WebKit

[NoiseEHC]

Unless you are proposing that all of Sugar moves to C as a base; that
may have its merits but is a separate discussion, and not one I'm
going to get involved with. Feel free to start a new thread / Feature
page.



I am not proposing anything. I just showed an option that no one 
considered. I mean that I thought that no one considered... :)


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

Re: [Sugar-devel] Browse and the move to WebKit

[NoiseEHC]

The biggest finding that came from outside this thread is that if
Browse is to move to pygi to access webkit, the Sugar python bits that
it uses must also be gtk3/pygi. No mixing with pygtk2 is possible. So
we have a prerequisite on sugar (or at least parts of it?) being moved
to gtk3/pygi first.



Why do not you implement the new Browse in C/C++?
It would have three advantages:
1. It could reuse an existing WebKit browser's code.
2. It would not depend on incomplete/unmaintained python bindings.
3. It would be fast. At least it would not use 60M of python runtime 
memory per process.
Of course it would require reimplementing some simple toolbar and 
children would not be able to look into the browser's codebase (only 
though the web) but I think it would be an interesting option to 
consider. At least the 3. point could be important enough for the most 
used application in Sugar...

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

Re: [Sugar-devel] [Dextrose] [AC Update] We are what we do.

[NoiseEHC]

"About pane" has a psychological effect, it provides recognition and
maybe a sense of ownership for developers and mantainers. I will
propose it on sugar-devel and the HIG once I've implemented a design.
Also it gives a starting point for eventually getting involved in the
development and improvement of each activity.

The idea of an About dialog (or menu) already came up on sugar-devel,
not long ago. IIRC, Gary Martin was quite opposed to increasing UI
clutter with non-essential information.

Perhaps we could still define a few meta-tags for activity.info and
_not_ display them in the UI at all? They would still be easy to find
for developers.


You can show this info in view source mode and in the journal.

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

Re: [Sugar-devel] Home button in browse - toolbar images

[NoiseEHC]

You could just make the new tab show the home url by default.


On 2010.10.19. 6:15, Bernie Innocenti wrote:

On Tue, 2010-10-19 at 03:01 +0100, Gary Martin wrote:

Alternatively, the "new tab" button could become a small plus on the tab
bar, which could be made visible at all times. For how long would it
remain invisible during a normal session?

Hmmm -1 from me as that would require showing the tab strip at all
times, even if only one tab is in use, making the default UI more
complicated and eating back into canvas space.

But you missed my rhetoric question: "for how long would it remain
invisible during a normal session?".

All UI designers seem to abhor tabs. They call them complicated and
unnecessary, but all users love them, including UI designers themselves!

Ok, but our users are children. Well, have you actually seen a child use
Firefox? Children aren't stupid, they use tabs for browsing just like
adults. Actually even *more* than adults, 'cause they get bored of
waiting for pages to load much sooner. In the real world, after the
first few minutes there will be so many tabs open that they won't fit
horizontally.

Tabbed browsing is the #1 reason why Nepal and other deployments
replaced Browse with the Firefox activity.



1) Just because in your builds you decided to disable the
screen hot corners from triggering the frame doesn't mean
that it is now free space up for grabs ;)

Ouch... Forgot about that. (still, we have way too much space on the
sides. It could fit an entire button.



2) Corners are used by the notification system.

Ok, but those last only a few seconds.



3) Using that space for more buttons does not solve
the feature creep, and spiral towards complexity.

If we were to remove the least useful feature, I'd pick the home
button :-)

Even if we don't add any button, we could use the extra space just to
enlarge the URL bar...



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

Re: [Sugar-devel] Killing activities when memory gets short

[NoiseEHC]

> We used to do that, the problem is that we don't control our platform
> as Google controls Android and you need to make sure that resources
> that need to be specific of each child process aren't shared (dbus and
> X connections, etc).
>
> I'm personally more interested in reducing the amount of resources we
> need to start activities (which is quite insane right now), but
> sharing more of those resources sounds like a good idea to me.
>   

Since I spent quite a bit of time analyzing the Python runtime here is 
my conclusion, maybe it will make wasting all that time less painful.

First, most of the memory consumed by an activity is the process heap. 
While the Python runtime and native libraries are shared among 
processes, the heap is not. Even if you fork processes it will not work 
because reference counting will dirty the shared pages and my instinct 
tells me that just loading a Python source file will reference almost 
all the shared pages because they are mostly used to store already 
loaded modules. What I finally did not do is to actually check the 
hypothesis that most of the heap is filled by strings which are the 
identifiers in the loaded Python modules. My goal was to somehow make 
identifiers constants and just readonly-mmap them into the process 
(replace the pathetic .pyc loading mechanism). Note that my plan was 
just a little subset of the .jar -> .dex converter.

Second, Python has a special memory manager which works with buckets so 
there are separate heaps for different object sizes. Somehow this 
special memory manager is turned off in release mode and it uses the 
standard C heap for some reason. Either it is a bug or just it turned 
out to be faster (more work was put into glibc) I do not know, but 
handling the linked free list can dirty shared pages as well or I am 
just mistaken...

Third, the fact that Python is a dynamic language does not help any 
prefetching or memory sharing. I am not too convicted either that this 
dynamic nature is used at all in the Sugar codebase but you know I 
cannot program in Python and frankly I do not feel the need to learn 
another language. Just now, at my age of 34, I finally gave up and 
learned LISP (more specifically clojure) and I hope that it will be the 
last programming language I will have to learn (other than assembly 
languages of course)... :) Now this point is interesting because if you 
thought that the Dalvik VM could run the Sugar codebase via Jython then 
it just will not work. The Dalvik VM just cannot load .jar files and 
Jython just generates them on the fly because of the dynamic nature of 
Python.

Fourth, moving Python (theoretically) to a GC environment (instead of 
reference counting) also would not work if the GC is compacting because 
it would also dirty the shared pages. So a mark and sweep nonmoving GC 
with separately stored "visited" bits is the only feasible solution. Now 
guess what the Dalvik VM does?
For more info (45 min + questions):
http://www.youtube.com/watch?v=ptjedOZEXPM

So *my* conclusion is that solving this sharing problem is *very* hard. 
I am not sure that simply translating all activities from Python to Java 
would take more time.

Another interesting thing is that meantime the unladen-swallow project 
progresses (just more slowly than planned). Their plan is to make it the 
default Python runtime so if it will happen (I cannot comment on that) 
then the Python VM will use even more memory (though it will be faster) 
so Sugar will be even less interesting on the myriad of low spec cheap 
ARM tablets which will flood the market soon.

I think that is all I can say about this subject so I just finish it here.



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

Re: [Sugar-devel] Killing activities when memory gets short

[NoiseEHC]

> Sugar has a similar mechanism. From the Low-level Activity API docs:
>
> org.laptop.Activity.SetActive(b: active)
> Activate or passivate an activity. This is sent when switching activities, 
> there is only one active activity at a time, all others are passive. A 
> passive activity must immediately release resources like sound, camera etc. 
> Also it should prepare for being killed without warning at any time in the 
> future (see OOM) by auto-saving to the datastore.
>
> The issue is that it's hard to estimate how many Sugar activities actually do 
> this, because until now they usually have not been killed (*). Might be an 
> interesting test - just randomly kill activities from Terminal and see if 
> they resume correctly ... 
>
> Maybe "good" activities could "volunteer" to be shut down first. Or "bad" 
> activities would have to "beg" to live a little longer. Might just take an 
> entry in the activity.info file.
>   

It will not work, because the application startup time is horrible on 
the XO. The Dalvik VM goes a lng way to have fast application 
startup and to share most of the memory among applications (the Zygote 
process does this). Actually that was the exact thing I tried to do with 
the Python VM. Just at the exact time when I started to hack Python I 
have seen the Google I/O video about the Dalvik VM and thought that 
duplicating that work would have been a waste of time. So if you wanna 
fix the Python VM, good luck, but you know it is already been coded... 
:) Without fast activity startup, killing activities will be a horrible 
user experience. Maybe not that bad as a totally unresponsive XO though.


> (*) Apple seems to have foreseen this "developer psychology" issue and 
> actually killed all apps in the first three iterations of its iOS. So apps 
> had to implement this state saving if the user was to be able to continue 
> after leaving an app. Would be interesting to know how many Android apps 
> actually implement it.
>   

All of them. If an Android application does not implement it correctly 
then there will be big problems while switching apps and while 
navigating among application screens.

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

Re: [Sugar-devel] Keep confusion -- round N+1

[NoiseEHC]

> After making tests [1] in deployments for "start new" 
> vs. "resume" we concluded that the way activity starting works on the 
> iPhone would probably work well in Sugar, too [2].
>   

Hehe, this is exactly the thing you would get with per-activity 
datastores. Guess what, Android does this too. :) Not to mention that an 
object chooser for pictures could be totally different from an object 
chooser for ftp sessions for example.

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

Re: [Sugar-devel] Hypothetical sugar-0.90 material, draft 1.

[NoiseEHC]

> Besides, the assumption that VCS-style deltas will work well with the
> binary files stored by most Sugar activities is... wishful at best.
>
> A design working in real-world scenarios would probably require ad-hoc
> deltifiers for each file format, making it very complex, slow and
> fragile.
>
> Whether a generic versioned filesystem could ever become feasible,
> remains a fascinating research subject for the next decade.
>
> Perhaps we could slightly enhance the current datastore design to store
> full copies of each version without any attempt to deltify them. This is
> also how git started.
>
>   

Actually these are the exact same problems that could be solved much 
better with some kind of per activity DS (not the Android one, which 
would be a little bit overkill). I mean that even making or not making 
deltas is dependent on the object the activity stores and the deltifier 
is also activity object dependent. Also the single file or multi files 
thing is activity dependent and so on. So you can implement every 
possible feature in a global glorified DS but I personally do not think 
that you will reach a really usable general DS ever.

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

Re: [Sugar-devel] Hypothetical sugar-0.90 material, draft 1.

[NoiseEHC]

> You are not explaining why this will happen, so this point is moot.
>
>   

The reason is that it seems that it is impossible to do. I just 
extrapolated historical data.

> So we're indexing the data "automatically", but we still don't have a
> datastore? Please explain how that would work.
>
>   

The Search activity's data is the generated index.


> And we want users to have to start other applications to find there
> stuff *why*? From what I can tell, the trend in the mobile space has
> been to unify searching across formats, a la the iOS's Spotlight.
>
>   

Exactly. Launch Pictures to handle pictures and launch Write to handle 
documents. You can have unified search across formats just not unified 
object handling (display, delete, etc).


> You'll be breaking backwards compatibility with every previous Sugar
> version (from what I can tell by your description), and rather than
> requring us to rewrite the Journal every so often in Sugar, each
> activity maintainer will have to rewrite it themselves.
>
>   

Now here is the interesting part. You already break compatibility.


> If there is shared code between these activities (since most cases
> involve similar models of data storage) we'll have to patch each
> individually, rather than a shared library.
>
>   

That is the point, to not have shared DS code other than some library 
what would be included in every activity which would provide some data 
to search or other activities. Most activities will not have such data. 
The few activities which would have such DS could be updated 
individually without breaking compatibility. They could be developed 
individually *when* *the* *need* *arises*.


Now all that said, the Android model is overkill. Something much-much 
simpler could work IMHO.

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

Re: [Sugar-devel] Hypothetical sugar-0.90 material, draft 1.

[NoiseEHC]

It seems that I cannot stop myself killing some kittens:

As I see the problem is that the DS wants to solve a lot of problems in 
a general way. I think that this is simply impossible. A lot of 
companies tried to create some general storage abstraction other that 
files, but all of them failed (even M$ tried that for decades...). My 
prophecy is that you will fail as well.


Another way to solve those problems would be to have every activity have 
its own journal with its own user interface.
The activity then could use plain files for storage or an SQLite 
database or just append a text file. The point is that the storage would 
be activity specific, with activity dependent optimizations if necessary.
The activity would also show a list of existing documents/objects when 
started and have a New... button to start a fresh one. It would also 
eliminate the troubled activity start mechanic from the activity ring. 
Of course SUGAR should have some very good library support to enable 
creating the default DS user interface in several lines of code. Of 
course for activities which does not save objects this would be optional.


Now because the DS storage would be scattered between activities, they 
should have to implement a backup/restore API, lets call it BackupAgent:

http://developer.android.com/guide/topics/data/backup.html
A simple activity could just mention in the MANIFEST that it has a data 
directory to be backed up and that would be all.


Of course the user should be able to use full text search so there 
should be a either a central index or the activities should implement a 
search API, lets call it SearchRecentSuggestionsProvider:

http://developer.android.com/guide/topics/search/adding-recent-query-suggestions.html
Of course SUGAR should have library support to ease creating this search 
functionality.


Now to allow activities to share data they should implement some API to 
be able to provide content to other activities, lets call it 
ContentProvider:

http://developer.android.com/guide/topics/providers/content-providers.html
Of course a flag in the MANIFEST could just allow SUGAR to index the 
data automatically.


It would need some primitive OLE (Object Linking and Embedding) 
capability which is currently missing from SUGAR, lets call it 
AppWidgetProvider:

http://developer.android.com/guide/topics/appwidgets/index.html

The remaining piece would be a dead simple Journal which would just list 
the recently launched activities.


Now why would it be cool?
1. Searching among contacts, mp3 albums and picture bundles can be 
totally different from the end user perspective.

2. It can be efficient, does not need copying large amounts of data.
3. Activities could be launched from GNOME.
4. It could be backwards compatible (if the APIs are set in stone).
5. The "DS" code (the library) could be developed when there is a need 
in an activity, there is no need to redesign the whole thing over and 
over again.

6. And I am sure that I could find some more...

Why it is just a pipe dream?
1. Python does not have anything like the DALVIK virtual machine so 
every Python process consumes a lot of memory. Because of this, 
implementing the above infrastructure would consume all available RAM 
and so would not work. Of course the DS part could be C++ code as well 
but unfortunately children could not look at the source.

2. It is already implemented so why bother?


Now, you should not take this message too seriously but you could 
seriously consider a per activity DS if you have some free time.




Martin Langhoff wrote:

On Thu, Jun 10, 2010 at 1:41 PM, Benjamin M. Schwartz
 wrote:
  

 - Reworking the datastore... while I welcome efforts in a new
datastore... _every Sugar release has a new DS implementation_ and
they get little testing and I've seen extremely light thinking about
what is _actually_ needed.
  

That's a very polite way of saying that you disagree with the extensive
thinking that's been done about datastore design and implementation for



No. _It says exactly what it says_. People have been thinking lots
about the fun part of the problem, thinking superficially about what
they'll have fun implementing. Not about the complete problem space.
Not about what hits users. Not about what we need for a saner
implementation.

  

even just a list of use cases that you believe have been
overlooked.



Ah...

 - ENOSPC?
 - Backwards compatibility? (Horrendously broken ATM on 0.84 -- I have
a bad patch for that...)
 - Integration with GNOME? (for those "dual desktop" OS builds)
 - Some reasonable degree of atomicity?
 - Sensible backup/restore?
 - Smarter handling of "bundle" filetypes...
= so together with the Journal, it can expose the many images or
videos in a 'Record'
= so the Record "file format" gets untangled
 - Re-thinking of the Journal / Datastore interactions to access the
normal filesystem so that Gnome's ~/Documents directory can be browsed
 - Working gracefully

[Sugar-devel] [Karma] animation package

[NoiseEHC]

Have you tried this?
http://webdemos.sourceforge.net/CAKE/

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

Re: [Sugar-devel] Candidate "paper cut" bugs for a new 8.2.x release?

[NoiseEHC]

Hi!

I do not know what was the conclusion about this _completely 
hypothetical_ case but does fixing the Geode VGA driver match the "paper 
cut" criteria?


Since I am porting (very slowly since 2 months ago I did not know 
anything at all about the Linux boot process for example) Android to the 
XO-1 there were some display errors. Android uses FBIOPUT_VSCREENINFO to 
flip (and not blit!!!) between two frames in video memory and without a 
patched Geode FB driver it causes a very awful flicker since the Geode 
FB driver turns off the video output then sets params then turns on the 
video output. Similar flicker can be seen on the XO when Sugar wakes up 
from a frozen DCON so possibly my fix would be applicable here as well.


If fixing the driver is desirable then probably I could fix the other 
Geode driver bug, the video overlay fuckup during wakeup. My little 
question is this: does anybody know how and where the sleep happens? Is 
the video output turned off in the FB or the X driver? Is the FB driver 
used at all when the X driver takes control?


ps:
The attached file is not a patch but a VERY ugly "fix" for trying... :) 
Of course I will create a normal patch which can be pushed upstream but 
only if it is needed...


Martin Langhoff wrote:

In the _completely hypothetical_ case that I had some time and chance
to spin a 8.2.x release aimed at fixing the "paper cuts"[1] and
low-risk bugs that hinder XO-1 deployability _today_ in the field -
have *you* got any candidates? Tell me about them :-)

I am specially hoping to round up bugs that have patches that have
been tested in the field. So low low risk stuff that makes life easier
and better for those that really matter: kids and teachers in the
field.

No promises for now, but I sure want to find a way to do this.
Daniel's piled up a few good patches I am aware of, but I am sure
there are more (from him and others).

cheers,



martin
1 - https://wiki.ubuntu.com/PaperCut
  




geode_fix.tar.gz
Description: application/gzip
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Assessment in Karma

[NoiseEHC]

Okay, a little holiday happened with me and then had to read through 
100+ olpc emails and then realized that there is a spam filter on my 
email which blocked sugar emails since july so it took some time to 
catch up but here I am... :)


Martin Langhoff wrote:

2009/8/19 NoiseEHC :
  

 - Automatic assessment is snake oil, Bryan is well intentioned but
deeply wrong. See the earlier email at
http://www.mail-archive.com/sugar-devel@lists.sugarlabs.org/msg05584.html
  

Or you are wrong.



I may well be wrong, but to explore that you will have to talk about
what I am stating :-)
  

So I was wrong too... :)

We could rephrase it as

 - Computer-based automatic assessment / grading is only passably
accurate for a tiny *tiny* subset of relevant human skills.
  
I am 98% sure that automatic grading (if you mean assessment == grading 
here) is absolutely not possible at all. (And it is a different issue 
that as far as I know grading in class 1-4 is totally pointless and 
harms children.) Most of the problems are that those tests which would 
in theory differentiate children in a 1-5 grade scale are high stake 
tests which are inherently unreliable.

 - However, it's very spectacular, and people are drawn to it... so
much that they are drawn to it even when it *clearly does not work*
for the skill being tested. It's so easy (for the teacher) and so
flashy, that people use it regardless of whether it works.

I say this after 9 years of work in the field -- I have seen
interactive SCORM objects, Moodle quizzes & lessons, HotPotatoes
activities, LAMS assessments, lots of other standalone assessment
tools. Have worked with teachers, watching their use.

What did I see? See the 2 points above.

There is a 3rd part... because these tools are cool, easy to use, they
do a lot of damage. In large part because they replace the "I don't
know how my students are doing" with "hey, I have all these scores are
numbers... nevermind they are inaccurate and only cover about 3% of
what these kids should know".

So an inaccurate view of a tiny slice of the skillset -- but hey, we
have a number representing what this kid knows! Let's use it! The link
that follows is from the Asttle project, which I was briefly involved
in several years ago:

  http://www.tki.org.nz/r/governance/consider/steps/analyse_e.php

Even worse, the Asttle project promotes the idea that you can get a
form of 'dashboard' of what kids know. Looks like an airplane
dashboard, lots of dials, full of inaccurate data _about a tiny
subset_ of what matters.

  
I can feel your pain (especially seeing the Asttle project) so thanks 
for the warning!

What more interesting is that there is some research in Hungary [1] about
the prerequisites of learning certain skills which are based on each other.



Sure, that is interesting. Now how amenable to computer-grading are
those skills? What automated computer tests can assess them with a
decent accuracy?
  
It is not about computer-grading at all!!! It is about well tested 
low-stake tests (children must reach 80-90%) which can reliably measure 
whether a child for example reached finishing or optimal level in 
reading (I am talking only about basic skills). If a child does not 
reach those levels then no matter how constructivist your education 
policy is in the higher grades (4-8) because this children simply will 
not be able to gain any information from books. Currently teachers can 
only deduce missing basic skills from the simple fact that the children 
fail biology or geography tests (because they cannot read reliably) and 
nobody tests reading skills continuously. The computerized assessment 
cannot be worst than that can it?
  

... Automatizing at
least some of those tests are probably the biggest thing since sliced bread
in education in my humble opinion

Are any of those tests "automatizable"? With what accuracy? If it
turns out some can be computer assessed... _how do we keep the
non-automatizable tests in the map_? Teachers forget them
*immediately*.

  
If the school decides to run this little research then I will let you 
know about the "automatizabledness" of the relevant tests, I promise! :)
And I am sorry but I will not be able to solve those other social 
problems (non-automatizable tests) with computers that is sure...


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

Re: [Sugar-devel] Assessment in Karma

[NoiseEHC]

>  - Automatic assessment is snake oil, Bryan is well intentioned but
> deeply wrong. See the earlier email at
> http://www.mail-archive.com/sugar-devel@lists.sugarlabs.org/msg05584.html
>   
Or you are wrong. Since you did not define exactly what you have meant 
by assessment in your message, I assume that you were talking about 
something like automatic grading or creativity assessment versus 
something mechanical and mind-numbingly trivial. (Any other assumption 
makes your message meaningless in my eyes but correct me if I am 
wrong...)  Now I will not talk about that you have just presented us a 
false dichotomy since it is not too interesting (and can be that I just 
have misunderstand and misrepresented what you have been said).

What more interesting is that there is some research in Hungary [1] 
about the prerequisites of learning certain skills which are based on 
each other. (So for example reading fast - whole word reading - requires 
to be able to read words letter by letter which requires reading out 
certain letter combinations which requires knowing the letters which 
requires differentiating vowels and so on... Since I do not know these 
things in English I did not try to be precise in this example.) The 
point of this research is that it is clear now that if a child does not 
reach a certain threshold in those skills then he cannot progress in 
other skills (these are the critical skills).
Here lies the bane of the Hungarian education system that children go to 
school at the age of 6 and they can be +-2 year apart in mental and 
physical development. So some children are like 8 year olds and some are 
like 4 years olds. Unfortunately this mental/physical difference is 
usually totally different across subjects so for example if a child is 
totally lame in writing (because he cannot control his small muscles 
adequately) but is an ace in math then it is normal and repeating the 
class is not an option. In Hungary (and probably a lot of other 
countries) the problem is that teaching these basic skills goes 
according to the national curriculum and there are no tests which 
measure them so if a child is left behind then game over for him. For 
example if he cannot reach optimal or finishing level in reading then he 
will not learn from books normally since he cannot read fast enough. 
Because teaching of reading skills stops at grade 3 or so these children 
leave the elementary school at advanced, beginner or sometimes 
preparatory level (40% of people in Hungary!!!) and they grow into 
functionally illiterate adults who cannot learn anything from books or 
read newspapers (or watch films with subtitles so they cannot learn 
languages in that way).
Now there are some good news that there exist tests which can measure 
the level in those basic skills and these are low stake tests. Usually 
optimal level means >90% and finishing level is >80% (in some skills 
these are around 80% and 60% respectively). The problem is that 
measuring those takes a LOT of time and energy and no teacher wants to 
do that. Automatizing at least some of those tests are probably the 
biggest thing since sliced bread in education in my humble opinion.

So it will not help teachers giving a mark at all because you know ALL 
the children should pass those tests sooner or later. Of course it will 
not measure creativity either. What it should do is to measure some 
mechanical and mind-numbingly trivial skills what are not measured 
without computers because it is mind-numbingly boring for a teacher. Now 
the questions is: which basic skills can be measured with a computer and 
which cannot? Calling assessment snake oil because it cannot give marks 
automatically is at least strange to me...

[1]
http://www.staff.u-szeged.hu/~nagyjozs/#res

ps:
As the subject becomes more advanced it becomes much more painfully 
obvious that my native language is not English. I am sorry for that.

ps2:
Of course this is not the most important aspect of OLPC but giving these 
assessment tools to children in Ghana probably cannot hurt can it?

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

Re: [Sugar-devel] Karma IRC meeting - August 11

[NoiseEHC]

> Mmm, I'm not sure how realistic it is for people to be interested in 
> providing that kind of data... But I could be wrong.
>

When I was visiting my elementary school there was a biology teacher who 
took teaching biology very seriously. Computer technology was in its 
infancy at that time so he used an overhead projector and has drawn a 
lot of slides (plastic foils) with colored markers. It could have taken 
a LOT of time to draw all those materials and because copying plastic 
slides was (and probably is) very expensive he could not even share it 
with other teachers. What is clear to me that at least in his mind the 
materials were much higher quality than the books we used in class 
otherwise he would not have been working with them so much.
Now my feeling is that approximately 1% of the teachers can be like my 
biology teacher. Also approximately 5-10% of the teachers would spend 
5-10 minutes per day to fix learning materials (like fixing spelling, 
fixing examples kids did not understood in that day, etc). Even in small 
countries like Nepal this 1% can be more manpower you have in OLPC 
Nepal. Not using their helping potential is not too wise, I think that 
if you make contributing easy then people will start doing it.
Of course this is just my speculation.

> Having said that I certainly believe that such a feature would be 
> overkill at this point, there's a bunch of much higher priority tasks 
> that we need to tackle before and it's important not to lose focus of 
> our main goals.

Now that is what I agree with 100%. However at least planning for the 
future cannot be a waste of time (unless it takes more time than can be 
saved later). So probably the following two things would be enough 
preparation:
1. Do not use fancy lesson plans (like pdf or formatting) so creating 
some some wiki -> karma converter will be possible. Then you will be 
able to crowd source.
2. Do not wire questions/examples into the karma lesson. (It is mostly 
done because of internationalization issues.) It is only relevant for 
text only or mostly text only lessons because Karma is for programmers 
and the potential contributors will be teachers and nonprogrammer people 
cannot modify the code via a wiki I think that is obvious. They also 
will not be able to draw via a wiki.
I think that you should consider at least the 1. point since it is 
basically "do not do anything"... :)

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

Re: [Sugar-devel] Karma IRC meeting - August 11

[NoiseEHC]

Hi!

It could be a little bit off topic and can be totally irrelevant because 
of the difference between education systems, but have you considered a 
possibility to generate lesson plans, examples and questions from a wiki?
I mean that it is a lot of work to create a coherent lesson structure 
but after that filling it with simple data (examples and questions) can 
be crowd sourced. Handling hundreds of participants each only adding 
several sentences can be best handled with a wiki is not it?
(It can be that it is just my fantasy and does not fit the group 
dynamics or the lesson structure you have in Nepal but what is your 
opinion?)



Christoph Derndorfer wrote:

Hi all,

here's a preliminary agenda for tomorrow's IRC meeting on 
#sugar-meeting: http://wiki.sugarlabs.org/go/Karma:Meeting_11_Aug_2009


Time permitting OLE Nepal's Roxan (in CC) will also be joining us at 
some point so we can discuss his involvement regarding the teacher's 
note and lesson plan.


Here are some early notes regarding the teacher's note and lesson plan:

* in html
* images allowed (even encouraged?)
* a lesson can potentially have multiple lesson plans
** for different languages
** for different learners
** for the lesson / exercise / game part of the unit
* lesson plans should contain an introduction which gives a very brief 
overview (1~2 sentences) of what exactly the lesson will teach the pupils
** this information can be used to identify interesting lessons in a 
given library

* should be easy to navigate
** e.g. question of whether very long documents should be split into 
several pages for on-screen (target 1024x768) consumption

** should also look half-decent when printed
* templates should be provided

Cheers,
Christoph

--
Christoph Derndorfer
co-editor, olpcnews
url: www.olpcnews.com 
e-mail: christ...@olpcnews.com 


___
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] [RELEASE] Read 71

[NoiseEHC]

> Holding buttons does not work in current stable builds (both 8.2.x and
> F11 based) due to a bug in Xorg (XkbSetDetectableAutoRepeat() does not
> seem to work correctly). That's why there is a major crisis of button
> real estate in ebook mode right now :-)
> Thanks,
> Sayamindu
>   
I told you that it will hard :)
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [RELEASE] Read 71

[NoiseEHC]

So accessing the frame in ebook mode - is probably not something you do in
your ebook workflow (at least on an olpc without touchpad support).




Correct - and dedicating a frame button on the tablet mode is probably
something I would not do (we don't have too many buttons accessible in
tablet mode)
  
Incorrect. Since I use the XO-1 for reading ebooks while traveling with 
public transport regurarly, I can clearly see the need for not only 
frame support but for handling the laptop from the keyboard even in 
ebook mode. What important is that volume/brightness level and 
magnification (and anything activity specific) should be available from 
ebook mode at least via some menu (and no submenus please).
You should not dedicate a full button to this menu, probably holding the 
rotate screen button for 1 sec is the correct method activating this 
menu (which would take over cursor keys and the 4 game buttons), and 
while the menu is on screen, pressing the rotate screen button would 
hide it. (It also requires to activate screen rotation when the rotate 
screen button is released, not when it is pressed. Also it could have 
some delay so pressing 3 times fast in a row would rotate to the other 
direction, no need to reflow and redraw the screen 3 times.)


See, developing this functionality will be hard (because Sugar does not 
have framework support for it) and probably you have some better things 
to do now but at least putting this functionality on the roadmap would 
be cool.


ps:
Note that the Frame is an usability problem what is evident if you want 
to use it via the keyboard (and will be even more problematic when the 
XO will have touchscreen support). Of course it is only my humble 
opinion and we all know how much opinions worth :)


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

Re: [Sugar-devel] Karma's Chakra - 2 views on lessons

[NoiseEHC]

Now that is strange...
In Hungary there is a document called NATIONAL CORE CURRICULUM (NCC). In 
contains only the goals what the schools must meet at the end of the 
year (in fact it only defines those goals in periods of 2 years), and it 
only has an advised number of hours per week per subject. It is up to 
the school to define a Local Curriculum (LC) which contains the lesson 
structure. Of course the teacher defining this Local Curriculum is 
constrained not only by the NCC but also by the fact that there are only 
approximately 3 books for every subject in a given grade (the school 
decides which books must be bought by parents at the beginning of every 
grade) and the kids have nationwide tests to take. So in the end the LCs 
do not differ too much but giving a date for a lesson is practically 
impossible.


I do not know what other school systems are you aware of but probably 
getting info from around the world would be wise. (Of course if you need 
this feature in Nepal then obviously you will code it so it should not 
withhold nor delay you.)


NCC abridged version in English:
http://www.okm.gov.hu/main.php?folderID=137&articleID=6994&ctag=articlelist&iid=1

ps:
I am not a teacher but my ex-girlfriend who graduated as a teacher (just 
works something else) told me just this and reading the NCC I had the 
same understanding. In the end I am only 98% sure that this is the 
situation in Hungary so I will ask somebody about it.




Christoph Derndorfer wrote:

Andras,

in basically every school system I'm aware of it's not the teacher 
that decides what material is taught and when it's taught but rather a 
well-defined national curriculum.


Hence what OLE Nepal currently does with their E-Paath learning 
activities is to create specific interactive lesson content that 
aligns very closely with the Nepali curriculum, the associated school 
books and weeks when the material is to be taught. This is definitely 
a major use-case for something such as a library of Karma lessons, 
hence I want to support it in Karma's Chakra.


However national curricula obviously differ from country to country hence available lessons will be re-mixed in 
different ways to support these specific requirements. That's where 
the idea to put that meta-data into the locale/ directories comes from.


At the same time I also think it makes sense to support a more generic view 
where all lessons for a specific Grade and Subject (or, as already mentioned 
above, only per Subject) are presented in a simple list.

I hope that answers your questions.

Cheers,
Christoph

2009/8/5 NoiseEHC mailto:noise...@freemail.hu>>

Exactly what is the problem that this solution wants to solve? I
mean that is not the teacher who selects from the lessons
depending on her personal lesson plan? (Of course we could provide
a default lesson plan but in the end it is up to the teacher what
she wants to teach and in what order.)
So is it important at all to select from a predetermined date or
country specific grade?
Can it be that I do not understand at all how those lessons would
be used in the classroom? Or is this mega bundle (what bundles a
lot of lessons from different subjects) solves the deployability
problem and creates a selection problem?

Christoph Derndorfer wrote:

Hi all,

I spent some time toying around with Chakra in the past 24 hours.
As a preliminary result I have concluded that we should initially
support two different "views" of the available lessons.

(1) What I call "E-Paath" style (see the
attached chakra_epaath_s.jpg) as it follows E-Paath's current
flow in terms of choosing Grade - Subject - Week before being
presented with an overview of the available lessons.
(2) "List" style (see the attached chakra_list_s.jpg) which is a
simple list of lessons available for that Grade and Subject (of
course one could make it even simpler by listing all lessons for
a given Subject, regardless of Grade)

(Please ignore the lack of reasonable design and color choices in
these screenshots;-)

Now the question is how to generate these Chakras for a given set
of lessons (which are stored in sub-folders)...

In general the issue is that with the currently proposed Karma
bundle layout (http://wiki.sugarlabs.org/go/Karma/Bundle_layout)
the only information we have about a lesson is it's name. This is
of course too little data to create a nice Chakra with Grade and
Subject choices. Subsequently I believe that we should find a way
to include some additional information with lessons.

The way that OLE Nepal currently handles it during E-Paath
development is that lessons are stored in sub-folders named
___
(e.g. 6_English_RajuAndTheWolf_1). Based on that information a
support scripts then builds the Flash menu struct

Re: [Sugar-devel] Karma's Chakra - 2 views on lessons

[NoiseEHC]

Exactly what is the problem that this solution wants to solve? I mean 
that is not the teacher who selects from the lessons depending on her 
personal lesson plan? (Of course we could provide a default lesson plan 
but in the end it is up to the teacher what she wants to teach and in 
what order.)
So is it important at all to select from a predetermined date or country 
specific grade?
Can it be that I do not understand at all how those lessons would be 
used in the classroom? Or is this mega bundle (what bundles a lot of 
lessons from different subjects) solves the deployability problem and 
creates a selection problem?


Christoph Derndorfer wrote:

Hi all,

I spent some time toying around with Chakra in the past 24 hours. As a 
preliminary result I have concluded that we should initially support 
two different "views" of the available lessons.


(1) What I call "E-Paath" style (see the attached chakra_epaath_s.jpg) 
as it follows E-Paath's current flow in terms of choosing Grade - 
Subject - Week before being presented with an overview of the 
available lessons.
(2) "List" style (see the attached chakra_list_s.jpg) which is a 
simple list of lessons available for that Grade and Subject (of course 
one could make it even simpler by listing all lessons for a given 
Subject, regardless of Grade)


(Please ignore the lack of reasonable design and color choices in 
these screenshots;-)


Now the question is how to generate these Chakras for a given set of 
lessons (which are stored in sub-folders)...


In general the issue is that with the currently proposed Karma bundle 
layout (http://wiki.sugarlabs.org/go/Karma/Bundle_layout) the only 
information we have about a lesson is it's name. This is of course too 
little data to create a nice Chakra with Grade and Subject choices. 
Subsequently I believe that we should find a way to include some 
additional information with lessons.


The way that OLE Nepal currently handles it during E-Paath development 
is that lessons are stored in sub-folders named 
___ 
(e.g. 6_English_RajuAndTheWolf_1). Based on that information a support 
scripts then builds the Flash menu structure.


Now I was thinking that one approach could be to include some sort of 
.info file in each lesson that contains the information. While Subject 
probably will be fairly consistent between various countries the Grade 
information is highly country-specific and could be put into the 
respective .po files for each locale.


What do you think, does that approach make sense? What are other 
possible solutions to deal with this?


As always, all comments, feedback and suggestions are much appreciated.

Thanks,
Christoph

--
Christoph Derndorfer
co-editor, olpcnews
url: www.olpcnews.com 
e-mail: christ...@olpcnews.com 










___
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] Assessment in Karma

[NoiseEHC]

ps:
I intend to use Karma for interactive curriculum development for
reasons Bryan Berry talked about a lot.



Awesome! How can we involve you more? is it time to for us to open a
mailing list specific to karma?  like  sugar-ka...@l.s.o ?

u can find christoph, myself, and the ole nepal team on #olenepal or
#sugar Mon-Fri  03:00 -- 11:00 GMT (day time hours in Nepal)
  
The whole point of this project is that this school developed a 
curriculum that works. The plan is to use the inevitable transition to 
digital learning materials to push this working curriculum onto other 
schools. However it is not my project but the research school's project 
so until they decide that they start this project I cannot do anything 
education related since I am just a coder. I will talk with the 
headmaster in August next time so then I will be able to tell you 
something more concrete.


What I see is that in order to win the curriculum battle the following 
things must be met:
1. It has to be cheaper than paper books so parents will want it. As it 
seems the XO is already cheaper (200$/4years = 50$/year what is already 
spent on paper books).
2. It has to be wanted by children. The XO 1.5 (or maybe the ChromeOS or 
Android based smartbooks, we will see next year) will be able to run 
flash/youtube/web so it is OK.
3. It has to be wanted by teachers. So it has to ease teaching. Like 
automatic assessment.
4. It has to be developed on the cheap. Like reusing the skill set of 
thousands of existing web developers.
So it seems to me that it will not be much different than what you are 
doing in Nepal so we will have the same problems what you had and will 
need the same tools what you use...



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

Re: [Sugar-devel] Assessment in Karma

[NoiseEHC]

In June I was talking with the headmaster of a school which does 
education research. There are two things from that discussion that seems 
relevant for this question:


1. Karma could measure the time it takes to finish a task in a compound 
exercise. If it is statistically relevant then it could give some hint 
to the teacher which parts of the curriculum are hard for the given 
child. If I will be able to persuade the headmaster then there will be 
research (hard data) which hopefully will find out whether this 
measurement is meaningful or pointless.


2. There is a VERY HARD to develop exercise model where the child can 
follow multiple paths to the solution. In this case the possible choices 
the child can follow makes a graph with most of the leaves ending with 
"does not compute". If this exercise model proves to be useful (which 
will be determined in the mentioned research) then Karma should store 
the way the child solved the exercise and not only the end result. So 
what I wanted to say is that it is possible that the wrong steps can 
give more informations to the teacher about the knowledge of the child 
than the fact whether the child was able to solve the exercise or not.
Because the 2. point can be a little bit hard to understand, here is an 
example:
The problem is this: "If we used A amount of paint to fully paint a 
little picture with sides B and C, how much paint do we need to fully 
paint a room with sides D, E and height F?"
This is an exercise with 3 steps. The child has to calculate the area of 
the picture (P=BxC) and the walls' (W=(D+E)*F*2) and has to calculate A/P*W.
Now the graph looks something like this: from the beginning the child 
can calculate either area or can do something like B*E which "does not 
compute". If he has P and W then he can do either A/P or W/P then either 
A/P*W or W/P*A respectively. In every step the program should 
graphically show what the child just have calculated (what can be 
impossible if he uses D*E*F*B for example).


Now I do not insist that you develop this 2. point since it is a HUGE 
task (and needs some research to know whether it really help children 
understand complex relationships) but moving Karma into this direction 
(just a little bit) would help a lot if the headmaster would decide to 
do this research. In this case we will translate the resulting exercises 
to English, probably you will be interested in that.


ps:
I intend to use Karma for interactive curriculum development for reasons 
Bryan Berry talked about a lot.


ps2:
By research I mean "try out with kids while somebody from the University 
measures the outcome".



Christoph Derndorfer wrote:
As previously mentioned by Bryan in his "Automated Assessment is the 
Killer App" blog post 
(http://karmaproject.wordpress.com/2009/07/06/assessment-is-the-killer-app/) 
student assessment is an important component of Karma.


While toying around with the lesson UI I realized that the assessment 
area is still very much an empty space (which kinda reminds me of the 
group view in Sugar;-) as we haven't really discussed how it should 
look, what kind of data will be kept (which is of course heavily 
dependent on the type of lesson), how the data will be stored, etc. To 
keep the efforts required to do that in check I think that it might 
make sense to start by offering a handful of templates - both on the 
UI and storage backend side of things - to fit the most common 
use-cases in terms of different lesson types (e.g.inserted words into 
sentences, doing calculations, etc.)


Now I was wondering whether anyone here had specific suggestions on 
how to address this or pointers to how other e-learning solutions 
(regardless of whether stand-alone applications or Web based) solve 
this interesting challenge.


Thanks in advance,
Christoph

--
Christoph Derndorfer
co-editor, olpcnews
url: www.olpcnews.com 
e-mail: christ...@olpcnews.com 


___
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] Book bundles and Read

[NoiseEHC]

A possible solution for 2.

The catalog file should be a .html file with file:// links to the USB drive.
If the kid opens the .html file in Browse and clicks on the link then it 
will be copied to the Journal and opened in Read.
The .html file can have pictures.
The only criterium is that the links shall point to /media/BOOKS/bah.pdf 
where the USB drive's label is fixed.


Jim Simmons wrote:
> All,
>
> In my own emails when I refer to "content bundles" I am not referring
> to anything that Sugar Labs has proposed as a standard.  I was just
> thinking about how to deal with the Children's Book Library project,
> how would I deal with the problem of distributing 2,000 books to
> children without access to the Internet or even a local web server,
> knowing the limitations of the Journal Activity as it exists in .82.
> I came up with the idea of:
>
> 1). PDF books stored in zip files along with gif files representing
> their book covers plus a catalog file.
>
> 2). An Activity, possibly an enhancement to Get Internet Archive Books
> that would browse this catalog file and create a user interface
> allowing the books to be browsed and copied to the Journal one at a
> time.
>
> I suggested that the catalog file be in Dublin Core format because
> that seems to be trendy but truthfully I'd be happy with a catalog of
> delimited lines like this:
>
> The Innocents Abroad|Mark Twain (Samuel Clemens)|Travel, Humor|innocents
>
> where "innocents.pdf" is the name of the PDF and "innocents.gif" is
> the cover page image.
>
> I've been a professional programmer for over thirty years so my method
> tends to be:
>
> 1).  What do we have?
>
> 2).  What do we want to do with it?
>
> 3).  What is the simplest (not necessarily the most generally useful)
> way to get there?
>
> I certainly can understand the value of a good standard approach to
> this kind of problem but I wasn't trying to propose one.
>
> James Simmons
> ___
> 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] need a better name for starting page of karma than "MenuStage"

[NoiseEHC]

Could you please name those items in English?
I suggest this because probably Karma is one of the most important 
things from an educational viewpoint because it will allow developing 
curriculum in a totally open way. I mean it will allow teachers to avoid 
locking teaching materials even into Sugar so no matter what will happen 
10 years from now, will Android or ChromeOS (os something totally 
unpredicted OS) take off, or will Sugar spread to hundreds of millions 
of machines, or will Windows dominate in on portable machines or 
whatever, the curriculum will still be usable because there will be some 
browser in the future that is sure. So most likely most of the 
programmers developing curricula will use Karma so it would be wise to 
name things that will be understandable for the widest international 
audience.
Just name it as "table of contents" or "directory".

Bryan Berry wrote:
> what should we call menustage? it is a horrible name. it is just not
> descriptive:
>
> http://www.pustakalaya.org/external-content/static/epaath/MenuStage.html
>
> I don't want to call it the "frame" because that word already has a
> meaning w/in sugar.
>
> i also don't want to call it anything w/ a religious connotation since
> karma is named after Rabi _karma_charya and not for the religious
> concept.
>
> Words that come to mind are
>
> mandala -- which literally means circle in Nepali but sometimes has a
> religious connotation (ugh)
> dhoka -- this means "gate" in Nepali. I like dhoka but everyone outside
> of Nepal will mispell it
>
> I  like mandala the best so far . . .
>
>
>   

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

Re: [Sugar-devel] Sugar Digest 2009-06-15

[NoiseEHC]

I think you do not get what is so "special" with Android.

1. They killed the braindamaged X driver model and put the driver where 
it belongs, the kernel. Just like Windows NT and OS-X already did. 
Finally it is fast and really supports hardware acceleration! Did I 
mention that it has redraw profiling tools?

2. Python is already available on Android:
http://www.damonkohler.com/2008/12/python-on-android.html

The "porting" is not about running Python Sugar on Android but to 
implement the parts missing from Android in java.
a. Activities store their data into a per activity file area and an 
SQLite instance. A common data publishing interface should be defined. 
The Journal should became just an aggregation.
b. There is no peer to peer networking. I should be written. 802.11s 
will be dropped in XO 1.5 anyway.
c. There is no common document format defined to share data between 
activities. Work is already happening on this one.

d. There is no printing support. Hmmm, I have heard this before.
So IMHO the job would not be to port Python since the lame Python VM 
would be just as lame on ARM. If you really want to port things then 
here is the thing:

http://arstechnica.com/open-source/news/2009/05/canonical-developers-aim-to-make-android-apps-run-on-ubuntu.ars

Of course this is just the (easier) technical side. The people side is a 
totally different beast.


Currently, as I see, both OLPC and Sugar developers spend a massive 
amount of time fighting platform problems when the solution is already 
available. This time could have been spent on learning activities. 
Desktop application compatibility does not exist on the XO so probably 
it would not be a deal breaker. The next big thing which will be 
reimplemented is touch screen support in XO-2. I hope that the result 
will be just as usable than the next Android GUI for smartbooks which 
will be tested for years by then.


Of course it will not happen overnight but can it be that this is the 
most future proof investment? Is not the goal putting education into 
children's hand rather than reimplementing the desktop paradigm over and 
over again when there is an alternative backed by Google, the ARM 
vendors and millions of $?


Elena of Valhalla wrote:

On Mon, Jun 15, 2009 at 11:33 PM, NoiseEHC wrote:
  

The real deal is that Android will be pushed by all the carriers and ARM
vendors. In my humble opinion it will be the dominant phone OS in the
future with even more hardware support



the good thing is that android is based on the linux kernel, so most
of this hardware support will be available to every linux system; the
only significant exception will probably be the graphics subsystem,
where google's work will stop at the framebuffer, while a standard
linux system may need X.

  

(just try out the Android SDK, it
is multi platform with an emulator). Jumping to this massive smartbook
bandwagon could push the OLPC idea further without any hardware development.



It is probably feasible to jump on the smartbook bandwagon even
without a full port to Android: a proof of concept port of sugar to
ARM is already available from the work of Bernie Innocenti in
OpenEmbedded, and in my free time I'm trying to update it to 0.84;
another (untested?) port is available in debian, where the sugar
packages are built for every supported arch, including ARM and other
embedded ones.

Installing such systems on an android phone is generally feasible,
requiring skills broadly comparable to those needed to jailbreak an
iphone; of course deployment will need support / permission from
whoever is going to sell the hardware, to be able to preinstall
gnu/linux + sugar instead of the standard system.

  


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

Re: [Sugar-devel] Sugar Digest 2009-06-15

[NoiseEHC]

> There is a project doing a bit of that, http://code.google.com/p/jythonroid/
> Jython just got a new compiler though, it should be possible to retarget it.
>
> Google seems to love Python, maybe they will help? Perhaps OLPC could
> get them to at least say whether they're working on it?
>   
http://code.google.com/p/unladen-swallow/

It is Google's Python plan. Unfortunately it is not about reducing 
memory consumption, it is for servers.
The problem with the Sugar path is that it has no hardware vendor 
backing. Android has.
The new 1.5 XO makes the memory pressure bearable with 1G of memory just 
it also has no hardware vendor backing (in the sense of at least 10 
million units per year category).

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

Re: [Sugar-devel] Sugar Digest 2009-06-15

[NoiseEHC]

> My major concern against porting to Android is that Java is a horrible
> language, even with the nice Android libs. Google have said that they
> will add more languages, though.
>   
Yes, java sucks. IMHO it does not matter though since mostly activities 
consists of <1000 lines of code.
> A more long term solution would be using PyPy, since it has
> significantly lower memory usage and better optimisation prospects.
> Switching to PyBank for bindings should also help.
>   
Or retargeting Python to the DEX format.

The real deal is that Android will be pushed by all the carriers and ARM 
vendors. In my humble opinion it will be the dominant phone OS in the 
future with even more hardware support (just try out the Android SDK, it 
is multi platform with an emulator). Jumping to this massive smartbook 
bandwagon could push the OLPC idea further without any hardware development.

ps:
If you did not see the video then the current plan is to sell those 
smartbooks for 0$ via G3 phone carrier subsidy. It can became a HUGE market.

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

Re: [Sugar-devel] Sugar Digest 2009-06-15

[NoiseEHC]

> Technologically the phone and the computer are quickly converging.
> They are just coming at the problem from different points of view.
> Phones focus on power consumption and size.  Netbooks focus on screen
> size and general use computing.
>
> If the new ARM technology is as good inside devices as it is on paper
> the convergence is going to happen sooner than many of us expect it.
>   
If you look at the Nvidia Tegra video made by Charbax then it is clear 
that it will converge next year.
Google and the ARM companies pushed millions of $ into quick web 
browsing and hardware accelerated video and flash (something even Bryan 
Berry defines as the future of educational software development).
Android implements the following things (the next version will support 
smartbooks):
1. Its Dalvik VM works in very limited resource environments. It is 
something Negroponte talked about but nothing happened (with Python 
memory comsumption), Google did not talk about it just fixed it.
2. The applications are separated like in Rainbow. OLPC will even loose 
Rainbow with the transitioning to stock Fedora.
3. There is an usable programming environment targeting Android. I can 
debug programs from Eclipse running on Windows!!!
4. All the activities on Android can be used by the cursor keys only (so 
they ARE easy to handle). Something Sugar lacks even now.
5. There is a massive army of programmers targeting Android.
It is only my really humble opinion, but could that be that probably the 
most sane way would be porting the relevant parts of Sugar to the 
Android platform and ditching the rest?

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

Re: [Sugar-devel] cool animation w/ all-javascript space invaders

[NoiseEHC]

Bryan Berry wrote:
> http://static.boundvariable.com/space-invaders/
>
> does most of the animation that we need using raphaeljs, which uses svg
> and not canvas http://www.raphaeljs.com
>
>   
Have you tried it on an XO? I just had this "experience". Seems to me 
that we will not do animation with js ever...

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

Re: [Sugar-devel] [IAEP] Journal criticism

[NoiseEHC]

There are 3 different ideas when we are talking about Journal vs 
Directories:
1. Whether we are limiting the user to use exactly one filtering 
category for his/her documents (and lets call them Files and the filter 
the Files' Directory) or we allow multiple filters (and call them Tags).
2. Whether we are showing the user a open/save dialog which has a 
Directory tree and File list or we just ask for a name and some tags for 
save and let the user filter open.

3. Whether the document store is a filesystem or a database.

so remembering these points, answers are inlined:

Albert Cahalan wrote:

In graphical environments alone, directories are over 25 years old.
Since 8 is less than a third of that, there is only one safe bet.

It'd be way more than 25 years, except that we didn't even have
graphical environments much beyond that. Directories go back
about 40 years. 8 years is just another 20%.
  


I am sure that 100 years ago when the car was invented, because humanity 
has been used horses for 5000 years and the next 100 years is only 2% of 
that, people predicted that we will still ride horses now



This isn't the "Microsoft Windows XP Service Pack 2" feature set.
This is a concept that is pretty fundamental in computing.
It crosses platforms, it's in our network protocols, and it's even
required for all the programming languages that implement Sugar.

  


Having a filesystem does not conflict with that the user will never ever 
see one (3. is a differ idea than 2.).



The following things unfortunately cannot be done with a flat filesystem
view:
1. Revision based view.
2. Tagging.



First, I think you didn't mean "flat". That's the Journal.
Second, both flat and tree systems can handle that.
  


I meant flat filesystem so I have written exactly that. I meant a 
filesystem which can be drawn on a 2D surface in a tree (where the files 
are leafs). Contrast it to a multidimensional "filesystem" where a File 
can have multiple Directories and which stores all the versions. See I 
do not want to argue over semantics so if we will have some system which 
can handle this multidimensional storage then we can call it a 
filesystem if you insist. After all a filesystem is just a database 
which maps names to disc block numbers (and the canceled WinFS was 
marketed as a filesystem after all). What is sure that this future 
"filesystem" will have a completely different access semantics that for 
example ext2.



It is a totally different problem that the current Journal barely implements
those things but dropping it in favor of "time-tested" solutions is a
mistake IMHO. (Note that no filesystem solves those problems I have
mentioned.)



No filesystem should! It looks like GNOME 3.0 will get you those
features on top of a plain old UNIX-style filesystem tree though,
without making the filesystem incompatible with both software
and humans.
  


Have you noticed that as the world evolved, filesystems gained 
unimaginable capabilities like resource forks, extended attributes, 
access control lists, transactions?
Is your point that we should drop the Journal just to be compatible with 
those softwares that possibly no child will ever use?


I would vote to make the Journal more usable rather than trying to stop 
the world.


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

Re: [Sugar-devel] [IAEP] Journal criticism

[NoiseEHC]

I think it's very important if we want to keep pushing Sugar that we
distinguish between design decisions and bugs and unimplemented
features. If we bring down good design ideas not by themselves but
because of its implementation status, we risk ending up with nothing
that brings new value compared to existing desktops.



You say that like it would be a bad thing. The existing desktops
are at least time-tested. Learning to deal with the common features
of modern desktop systems is very valuable for children.
  


This relies on the assumption that 8 years from now when children grow 
up we will still use directories. I do not dare to predict the future so 
I will leave it to you... :)


The following things unfortunately cannot be done with a flat filesystem 
view:

1. Revision based view.
2. Tagging.
Of course, these views could be shown as a tree-like structure but it 
does not necessary mean that a filesystem should be the underlying storage.


It is a totally different problem that the current Journal barely 
implements those things but dropping it in favor of "time-tested" 
solutions is a mistake IMHO. (Note that no filesystem solves those 
problems I have mentioned.)
Another different problem is that Sugar should have a compatibility mode 
for example for USB drives but it will be implemented as I know so 
talking about that is moot.


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

Re: [Sugar-devel] [SoaS] Announcing Snapshot 2009/05/24

[NoiseEHC]

I have tried the appliance image on VirtualBox.

On the registration form it crashed with some python? error (will look 
the exact error if it is not a well known bug). It could be caused that 
I clicked more than once to the Next button.
After that I only have an "Automatic login" user to choose from.
It asked for my XO username correctly.

Speak does not work, the sound output is garbage, changing languages 
kills the sound completely (but it does find the audio output).

Browse has the same bug as in soas2-20090416.vmdk:
1. Go to Sugarlabs page (not the default page in Browse but sugarlabs.org)
2. Click on "Activities"
3. It will open the page in a popup window (what is different that using 
the default page in Browse)
4. Download an activity (I used Speak repeatedly)
5. There is no download notification and when you switch to Journal you 
can see that the download never finishes.
Probably the notification at the end of download crashes.

Sebastian Dziallas wrote:
> Hi folks,
>
> after a short break, there's a new snapshot ready for you. It 
> incorporates the latest packages from the upcoming F11 release, as well 
> the Colors activity. Please report any bugs or issues you encounter and 
> list them appropriately for the soas_linuxtag milestone in trac, if needed.
>
> Our roadmap is located here: 
> http://wiki.sugarlabs.org/go/Sugar_on_a_Stick/Roadmap
>
> The current list of bugs for the RC can be found here: 
> http://www.tinyurl.com/soas-rc-tickets
>
> The image can be downloaded from here: 
> http://download.sugarlabs.org/soas/snapshots/2/Soas2-200905241902.iso
>
> The appliance image has been made available here: 
> http://download.sugarlabs.org/soas/appliances/soas2-20090524.zip
>
> Thanks and happy testing! :)
> --Sebastian
> ___
> 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] Sugar Developer MINUTES

[NoiseEHC]

>
> I hope this anwers your question,
>Simon
>
>

Unfortunately it does not. What I wanted to know whether I will be able 
to use the latest Sugar on my XO-1 ever. It boots the kernel with 802 so 
it is a working Linux distribution. If somehow I copy the latest Sugar 
over the old Sugar (0.82 I think) will it work? If it does not work then 
will anybody port it? What I see is that OLPC has very few developers so 
probably this porting work will be out of question but will Sugar people 
make any effort or would it be just wasting their time where the XO-1.5 
is almost finished?

ps:
If overwriting the old Sugar works on an XO-1 then an unzippable 
"distribution" what could be applied to 802 would be just fine...
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Sugar Developer MINUTES

[NoiseEHC]

Are there any plans to port Sugar to the XO-1 or will it be the job of 
OLPC so it will be effectively abandoned?

Simon Schampijer wrote:
> Attendees: Tomeu, Aleksey, Walter, Sayamindu, Simon
>
> Retrospect: We have been brainstorming on the Goals of the 0.86 release. 
> The Output can be seen at 
> http://wiki.sugarlabs.org/go/Development_Team/Release/Roadmap/0.86 Feel 
> free to add items you feel important to the roadmap - have in mind that 
> it is a short release cycle and therefore we have only a certain amount 
> of things we can do.
>
> Prospect: Next week we will iter over the points and find owners for the 
> them. The time to propose items ends the 5th of June after the 
> developers meeting in two weeks. By then each feature item needs a 
> concrete plan. Examples: http://wiki.sugarlabs.org/go/Activities/Library 
> or https://fedoraproject.org/wiki/Features/DeviceKit
>
> See you next week - a reminder will be send out.
>
> Regards,
> Simon
>
> PS: The schedule have been updated as well: 
> http://wiki.sugarlabs.org/go/Development_Team/Release/Roadmap/0.86#Schedule
> ___
> 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] Simplifying sugar-jhbuild

[NoiseEHC]

Tomeu Vizoso wrote:

On Thu, May 21, 2009 at 12:40, Bernie Innocenti  wrote:
  

On 05/20/09 23:29, NoiseEHC wrote:


When I tried jhbuild what I found strange that it does not detect the
Linux distro so I had to manually enter commands as it was specified on
the wiki. Can we get rid of that? (I have no idea how to detect the
distro or how to automate that just to let you know this fact...)
  

You mean for installing dependencies?  This requires root privileges, so
jhbuild can't do it on its own.

Besides, we used to have some distro-specific dependency check in the
past, but I someone (marcopg?) ripped it off, probably because it was a
pita to maintain.



Wasn't ripped off, but improved, we check for system dependencies in
the supported platforms like this:

./sugar-jhbuild depscheck

This will tell you which packages to install with yum/apt-get/etc.

How can we make this more obvious?

Regards,

Tomeu


  
For example by autodetecting the Linux distro, it could create a full 
command line. Of course, if it could be automated then it should just 
say something:
"The following dependencies are missing: . To install 
them, type in your root password: ".

Of course if it would be a lot of work you should not waste your time in it.
And why shall I run jhbuild 3 times anyway? It could have a default 
option when it does an "update" then "depscheck" and then a "build"...


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

Re: [Sugar-devel] Simplifying sugar-jhbuild

[NoiseEHC]

Bernie Innocenti wrote:

On 05/20/09 23:29, NoiseEHC wrote:
  

When I tried jhbuild what I found strange that it does not detect the
Linux distro so I had to manually enter commands as it was specified on
the wiki. Can we get rid of that? (I have no idea how to detect the
distro or how to automate that just to let you know this fact...)



You mean for installing dependencies?  This requires root privileges, so
jhbuild can't do it on its own.

Besides, we used to have some distro-specific dependency check in the
past, but I someone (marcopg?) ripped it off, probably because it was a
pita to maintain.

  

I am talking about this:
http://wiki.sugarlabs.org/go/Development_Team/Jhbuild/Fedora
As I told I do not know how difficult can it be to automate so if it 
would be a lot of work then of course you should not put too much work 
into it.
BTW text like "the dependency check will fail if you don't have a 
DISPLAY set" does not mean too much for Windows people like me (I did 
manage to google the answer so it was not a question).


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

Re: [Sugar-devel] Simplifying sugar-jhbuild

[NoiseEHC]

Bernie Innocenti wrote:
> Today I've kick-started a newbie on building Sugar to fix a small bug
> and submit his first patch.
>
> It was just painful.  jhbuild has plenty of rough corners and we could
> easily make things easier with a few changes:
>
> 1) Stop checking out random unstable versions of external projects.
> They break very often, and we cannot fix them.  Let's instead upgrade
> manually every once in a while after some testing.
>
> 2) Do not build C modules that is already available (and recent enough)
> in popular distros.  Specifically: abiword, matchbox, hippocanvas...
>
> 3) Let's move etoys away from the base set of components: the repository
> is often offline, building it breaks very often, and it takes a lot of
> time.  You don't need it in order to test Sugar, the same way you don't
> need TamTam and TurtleArt.
>
> 4) We could check for prerequisites before starting the build.  Some
> configure scripts are stupid enough to fail tests silently and proceed
> anyway using "no" as a command name in make :-)
>
> If there's consensus on implementing one or more of these points, I can
> provide patches (or just go on and commit them).
>
>   
When I tried jhbuild what I found strange that it does not detect the 
Linux distro so I had to manually enter commands as it was specified on 
the wiki. Can we get rid of that? (I have no idea how to detect the 
distro or how to automate that just to let you know this fact...)

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

Re: [Sugar-devel] [IAEP] 3D engine uses in a no-nonsense GUI (was: XO Gen 1.5)

[NoiseEHC]

> Actually, GNOME 3.0 is moving into that direction (requiring OpenGL):
> http://lwn.net/Articles/327845/
>
>   
Hehe, seems like that I have just invented Clutter... :)
More seriously, it seems that Sugar just runs ahead of Gnome and 
reinvents almost everything which will be created by Gnome people (or 
will not be created since that article was just a plan). Do you feel 
comfortable that your efforts will not go into Gnome 3.0, or is there 
something I do not know about?
Journal = GNOME Zeitgeist
Karma = Clutter minus the OpenGL acceleration
Sugar = "social desktop"
etc

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

Re: [Sugar-devel] [IAEP] 3D engine uses in a no-nonsense GUI (was: XO Gen 1.5)

[NoiseEHC]

I think most of those effects can be just as easily be done by the 2D 
engine (like what the Geode has). Of course it would need a LOT of 
coding, like killing the stupid X driver model with the X server 
process, using a compositing windows manager, rewriting GTK+ to use some 
form of retained rendering mode (like a super optimized Cairo library 
with some scene manager functionality) and finally fixing all of those 
GTK applications which became buggy because of this rendering change. Oh 
yeah, almost forgotten that moving to OpenGL would need just the same 
amount of work.
So not only would it chew trough the XO 1.5's battery like crazy but it 
would not run on the XO 1.0 so does it really worth that effort?


Martin Langhoff wrote:

On Tue, Apr 21, 2009 at 1:42 PM, Martin Dengler
 wrote:
  

Imagine if it actually looked like the demo:
http://www.sugarlabs.org/index.php?template=gallery&page=media_01



Exactly my thoughts. There are a couple of things we have to be
mindful of as we step into the wild 3D world...

 - memory footprint -- those smooth transitions count on having
various full-screen buffers, one for each screen you might want to
slide smoothly into.

 - batery burn -- the OpenGL API was originally designed for high end
workstations, and has some battery-depleting features such as a hi-res
timer event that triggers all the time and prevents sleep

The iPhone uses these smooth UI tricks (to a fantastic effect), and
its battery life is a fraction of every other phone -- I'd say that
the 3D niceness is part of the reason why.

cheers,



m
  


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

Re: [Sugar-devel] UI mockups for version support in Journal

[NoiseEHC]

> Every help on the UI side welcome.
What I do not get is why there is that navigation bar under the toolbar? 
It consumes a lot of space and has just that one button which was on the 
toolbar before. (I just checked the last SoaS image so it appeared in 
0.84 I guess). Also the old layout shows a back button which looks like 
the one in Browse for the same purpose as in Browse.
It is clearly a bad design IMHO.


ps:
Just booted my XO and 801 has this navigation bar (I do not remember it 
from ~760). So either way can we get rid of it?

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

Re: [Sugar-devel] GSoC idea: Chart/graph-making activity

[NoiseEHC]

Wade Brainerd wrote:
> This whole thing brings to mind something that I've been curious about 
> for awhile.
> What's the "recommended" way to transfer data between activities? 
> Say, I record some data in Measure and want to import it into Chart.  
> Or I generate some data in Finance and want to import it into Chart.
> Is the Clipboard the way to do it?  IE, should we support specialize 
> "copy as text/csv" (or whatever) and "paste text/csv" in our activities?
> Same goes for transferring of pictures.  If I take a picture in Record 
> and want to paint over it in Colors!, is Copy in Record and then Paste 
> in Colors! the way to go, or should I have Colors! open the Record 
> Journal entry?
Me too!

I have just recently read this pdf which is about recommending IT for 
science education and promoting the usage of office suites (mostly 
spreadsheets / word processors / databases / paint programs) for education.
http://www.concord.org/publications/detail/itsme-98.html

They effectively recommend that for a student to have meaningful reports 
or presentations the programs have to support inserting pictures and 
spreadsheets into text documents.

So my question is: What is the "official" plan to support something like 
OLE or KPart or Bonobo? Personally I hope that the plan is not to 
support them but who thought out the perfect user story for data 
exchange? My issue is that how to import models from something like 
Paint into my educational application which teaches kids how to defend 
the planet in case of an alien invasion...
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Idea for SOC

[NoiseEHC]

Since my name was called:
> I think this would be a very nice feature to have.  However, I do not
> think it is very likely to happen.
>
> 99.9% of Sugar users use Sugar on an OLPC XO-1 (maybe even more).  In
> general, Sugar is designed to target low-powered devices.  Blender will
> not be usable on these computers, because they do not have enough disk
> space, enough memory, or any hardware 3D acceleration.
>   
As far as I know Blender was ported to the XO but somehow it was not 
hyped too much. Probably it was slow (but wireframe mode should have 
been OK) and the small XO screen is not too well suited for that UI I 
guess. The main problem could have been that probably they had to use 
Mesa3D and it provides approximately 1-2 frame/sec "speed" as my test 
showed. You should ask them how that stuff turned out.
> Some people (like NoiseEHC) have discussed writing a fast, simple 3D
> library for low-powered devices like the XO, but this has not happened
> yet, so 3D development is not likely to work well.
>   
Yeah, I tried to design this 3D library before I had a real XO and my 
design tried to utilize the Geode documentation which turned out to be a 
little bit "sparse"... So after I got an XO and realized that I had to 
scrap all my designs I turned to existing software rendering libraries 
(I have tried almost all of them).
The conclusion is that writing a 3D app is a lot of work so probably 
just porting an existing app is the most sane. The best way of providing 
software rendering support for an existing application is probably to 
port a software OpenGL renderer to the Geode. Unfortunately it is a LOT 
of work so when I tried it (the winner was the OGL ES software renderer 
for the ARM by the way - formerly it was called Vincent 3D) I did not 
finish before my free time ran out last year. The problem with all of 
this is that I do not see too many education programs for children which 
_really_ need 3D.
If you take this route then at least use this and do not reinvent the wheel:
https://gna.org/projects/softwire/
> If you can demonstrate a 3D modeling program that runs in this limited
> hardware, then people will be more interested, but without such a
> demonstration I think it this project is unlikely to be accepted.
>   
Just to be a little bit negative I have another problem with 3D design 
software is that probably children will not be able to handle them. What 
little research I did in this area showed me that something like this is 
the most likely to be used (browsing the remnants of the site is 
recommended to everybody, good research there):
http://web.archive.org/web/20071016055856/http://www-ui.is.s.u-tokyo.ac.jp/~takeo/java/smoothteddy/index.html
It is java so good luck! :(

So my (uneducated) opinion is that only some voxel models could probably 
be drawn and painted by small children. I can imagine a program which 
offers a set of templates like human/horse/dragon which have animations 
like two legged walking/four legged walking/walking and flying and then 
children could modify (like widen the legs or drawing horns) and paint 
those skeletons. My big-big problem is that currently I do not see any 
sound educational activities which would really need 3D figures to 
animate. Of course I would like to be proven wrong.
BTW if somebody could post a video on YouTube which shows children using 
the Story Builder or Cartoon Builder on the XO I would be very happy.

HTH!

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

Re: [Sugar-devel] idea for GSoC project

[NoiseEHC]

Hehe, the mentioned activity spreads the myth that elephants cannot swim.
See:
http://www.youtube.com/watch?v=HpD40ewOyC4

Bryan Berry wrote:
> The GSoC mentee could recreate one of OLE Nepal's existing flash
> activity with javascript + html5. You can access some of our flash
> activities here:
> http://www.pustakalaya.org/external-content/static/epaath/E-Paath-2.activity/activity/Activity/MenuStage.html
>   

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

Re: [Sugar-devel] OS/X11 support for XO-1 hardware?

[NoiseEHC]

If you need it for some game then here is how to do it: attached.

A little question to Jordan Crouse or anybody else who can answer.
Here Jodran told me that the Geode can do XV flipping:
http://lists.laptop.org/pipermail/devel/2007-May/005208.html
It can be that he either did not reflect to that one part of my message 
or I am just too stupid to make it work. So what I do not see in the XV 
documentation is how to allocate two xvideo frames and flip between 
them? What this code currently does is allocating one frame and doing 
XvShmPutImage. Because its speed depends on the size of the xvideo frame 
I think it does blittting (copying) and not flipping (switching).

So how to do flipping?

ps:
Actually I would need 3 frames for triple buffering but I would be happy 
even with 2 frames.



Chris Marshall wrote:

With the spin-off of Sugar development to sugarlabs,
it is nice to see the development continued.

However, it seems that the OLPC layoffs and refocus
has scuttled the work to complete some OS and system
software support for the XO-1 hardware features.

For example, I have been waiting for the video scaler
support to allow for adjustable display resolutions on
the XO.  Among other things, it would allow programs
that don't understand a 1200x900 but only 6x4" display
to work at a more usable resolution where the graphic
elements and text/fonts are consistent and visible to
the naked eye...  It would allow for much improved
video performance since you could play back a 320x240
video on the full screen at considerable CPU savings.

I had thought this capability would be coming with
the Fedora 10 move in 9.1.0.  With that release now
scuttled, I'm wondering more generally, are these
pieces being picked up anywhere?

Would it make sense to have an 8.2.2 release involving
the move to Fedora 10 but pretty much the same as
8.2.1 otherwise?

--Chris
___
Devel mailing list
de...@lists.laptop.org
http://lists.laptop.org/listinfo/devel


  




xvscale2.tar
Description: Binary data
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel