[Sugar-devel] native HTML activity

2013-11-07 Thread 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.

2013-10-22 Thread 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


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http

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

2013-10-22 Thread 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.

2013-10-22 Thread 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.

2013-10-09 Thread 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 
was 

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

2013-07-02 Thread 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
http://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

2011-06-22 Thread 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] Browse and the move to WebKit

2011-06-22 Thread 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] [Dextrose] [AC Update] We are what we do.

2011-03-30 Thread 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

2010-10-19 Thread 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

2010-08-10 Thread 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

2010-08-09 Thread 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

2010-06-24 Thread 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.

2010-06-12 Thread 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.

2010-06-10 Thread 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
bmsch...@fas.harvard.edu 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
 - 

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

2010-06-10 Thread 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] Assessment in Karma

2009-08-30 Thread 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 noise...@freemail.hu:
  

 - 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] Candidate paper cut bugs for a new 8.2.x release?

2009-08-30 Thread 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

2009-08-19 Thread 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

2009-08-10 Thread 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 http://www.olpcnews.com
e-mail: christ...@olpcnews.com mailto: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] Karma IRC meeting - August 11

2009-08-10 Thread 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] [RELEASE] Read 71

2009-08-08 Thread 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

2009-08-05 Thread 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 
Grade_Subject_Lesson Name_Week 
(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 http://www.olpcnews.com
e-mail: christ...@olpcnews.com mailto: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

2009-07-29 Thread 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 http://www.olpcnews.com
e-mail: christ...@olpcnews.com mailto: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

2009-07-29 Thread 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] Book bundles and Read

2009-07-25 Thread 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

2009-07-21 Thread 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

2009-06-16 Thread 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, NoiseEHCnoise...@freemail.hu 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

2009-06-15 Thread 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] Sugar Digest 2009-06-15

2009-06-15 Thread 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

2009-06-15 Thread 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] cool animation w/ all-javascript space invaders

2009-06-05 Thread 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

2009-05-28 Thread 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] Sugar Developer MINUTES

2009-05-25 Thread 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] [SoaS] Announcing Snapshot 2009/05/24

2009-05-25 Thread 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

2009-05-22 Thread 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

2009-05-21 Thread 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

2009-05-21 Thread NoiseEHC

Tomeu Vizoso wrote:

On Thu, May 21, 2009 at 12:40, Bernie Innocenti ber...@codewiz.org 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: long list here. To install 
them, type in your root password: type here.

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

2009-05-20 Thread 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)

2009-04-22 Thread 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
mar...@martindengler.com wrote:
  

Imagine if it actually looked like the demo:
http://www.sugarlabs.org/index.php?template=gallerypage=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] [IAEP] 3D engine uses in a no-nonsense GUI (was: XO Gen 1.5)

2009-04-22 Thread 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] UI mockups for version support in Journal

2009-04-17 Thread 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] Idea for SOC

2009-03-24 Thread 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

2009-03-18 Thread 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