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

[NoiseEHC]

Hi!

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

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

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

>
> We probably all agree that it would be awesome to have something  that 
> integrates well with Sugar and works transparently by reusing existing 
> web technologies. I don't think that's easy to achieve though. It has 
> been said in previous discussions that without the close integration 
> between activities and system, Sugar would be just yet another suite 
> of educational applications (and likely not the best of them). I very 
> much agree and I think it's tricky to preserve that while moving to 
> frameworks which are supposed to work everywhere.
>
> We could have started with something more web developer friendly and 
> incrementally integrated it into the native Sugar platform, for 
> example by redesigning the Journal in the way you described, and 
> somehow adapting native activities to the new design. Instead we went 
> for something targeted at the current Sugar developers with the idea 
> of making it incrementally more web friendly.
>
> I have been on the fence on what was the best approach and I still am. 
> Something to consider is that we barely have the resources to maintain 
> the existing native code. I doubt, for example, that we would be able 
> to ship a redesigned Journal. Consider also that the people most 
> involved with this work has all a good knowledge of the Sugar platform 
> but are not really web developers.
>

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

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

So if you already run a node.js server then probably it could host the 
activity's html files and could provide some virtual file GET/POST 
service in
http://localhost/journal/directory.json <- this is for file list
http://localhost/journal/guidcomeshere <- this is for GET/POST files

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

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

Regards,
Andrew