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://lists.sugarlabs.org/listinfo/sugar-devel
