[IAEP] sugar, android,... oui? ....ou non!! ...
djhbrown at gmail.com
Thu Sep 13 21:27:51 EDT 2012
> I am curious as to the specific features of Android that David finds
a. i believe it has Google behind it with a large development team, but
it's also open source to encourage new apps from outside (sugar could be
one of those apps, which is what i think Scott has in mind...)
b. i believe it runs on smartphones as well as tablets/netbooks/laptops.
as such, i assume it is lean and mean
c. i can't comment on its own ui as i've never seen it, but i did have a
Sugar Activities able to run in Gnome....
certainly, Edbuntu has a large range of comparable apps
Android compatibility.... sugar->android pathways,
this should be feasible, but it's not what i had in mind; i was thinking of
a (oversimplistic?) model of software as a layer cake like this (regarding
a sugar "activity" as an app):
sys ui app ui (each app has its own ui)
| / \
| / \
user mgt app
os (eg gnome or fedora or android)
so what i was thinking of was making OUI the sys ui. [btw, whereas a sugar
"activity" is a single app (and its record), a OUI "activity" is a named
room (aka folder) containing artifacts (aka files) produced so far with
various tools (aka apps) - the artifacts represent the current state of the
my gutfeel is that journalling is of more interest to teachers (so they can
monitor student output) than to students themselves - an artist is
interested in his canvas, not the strokes he made to get it to that point.
it's only the artist's manager who wants to make sure the nose is to the
the collaboration apis.
i wonder whether the os itself could manage collaboration ( ie multiplex
app ui i/o) rather than requiring a different api for every app?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the IAEP