[sugar] patch - build abiword with sugar-jhbuild

[Dan Williams]

On Wed, 2006-08-09 at 22:02 +1000, msevior at physics.unimelb.edu.au wrote:
> > Robert Staudinger wrote:
> >> On 8/7/06, Christopher Blizzard <blizzard at redhat.com> wrote:
> >>
> >> [...]
> >>
> >>> So how well does it work in the sugar environment?  If at all?
> >>
> >> The branch has an initial patch from Erik but that's more about
> >> setting up internals.
> >> It currently looks like that:
> >> http://www.abisource.com/~robsta/tmp/sugar-abi-running.png
> >>
> >> There surely is loads of work to be done. E.g. we need to figure out
> >> how quitting an activity works.
> >>
> >> - Rob
> >
> > Nice, no menus or anything.  Would be great to see that hooked up to the
> > presence stuff so that you could collaborate with others.  We have a
> > decent framework for that.
> >
> > There's also the cool Journal stuff that Bryan and Seth both designed
> > and we're working through.  It would be neat if we could see this hooked
> > up with that as one of our first tests.
> >
> 
> Very interesting indeed. Our peer-to-peer collaboration feature is shaping
> up very nicely. We would like to (eventually) integrate this to the olpc
> avhai peer detection system.
> 
> The idea is that the child hits the collaboartion button and sees a list
> of his friends on the network he can collaborate with.

Ok; from the OLPC side, you _already_ know who you can collaborate with:
everyone you can see.  If Tommy doesn't have your activity, we'd like
him to pull it from you, then join the shared activity.  So when you
want to share you activity, you bring up a buddy window, and you invite
buddies to join your shared activity.  The buddy list (whatever form it
takes) is present in every activity, as is a chat with everyone who is
participating in your shared activity.

We seem to be thinking along the same lines.

> >From our perspectie it is actually easier if there were a C-based API that
> gives this. From my brief snoops through the sugar codebase I see that all
> the peer-to-peer stuff is in python. Are there any plan ot provide  C (or
> C++) wrapper for that?

No, it's actually D-Bus based.  There's a defined D-Bus API for presence
on the wiki, and a slightly less-defined one for activities.  But the
plan was always to have a D-Bus interface that activities could plug
into.  We just like to wrap the D-Bus APIs in Python for simplicity and
convenience :)

So C, C++, Python, mono, Java, perl, or whatever your language of choice
is, you're covered.

> I'll look at the jounraling stuff with interest. We have two options. One
> to write the document to disk upon focus change or to actually record each
> operation on the document model to a journal file. Playing these back
> restores the document. This also makes use of the collaboration code.

The Journal stuff we're talking about is more along the lines of "at
12:15am I started writing a report with Tommy and Jenny".  That report
could certainly be an Abiword-based activity.  We'll likely have to
provide hooks (via a D-Bus API) that activities can call for certain
operations with the journal.  Since we don't have the entire interaction
for the journal defined yet (or even how the UI looks) I don't think we
can make a guess how activities will interact with it.  But the idea of
the journal is a higher-level annotated log of what you're doing and who
you did it with.

One possible journal feature is the ability to look at the state of your
activity yesterday, two weeks ago, or last year.  That means we may roll
stored document versioning into some sort of framework, or we may leave
that up to the activities themselves to sort it out.  But we'd like to
expose the state of a document at given points of time as an integral
part of the journal.

Sugar doesn't care about the on-disk format of the document (yet, if
ever).

> On disk document storage is pretty efficient if we write gzipped abiword
> format. A 9 page document with no images and mild formatting is about 12
> KB

Small size is very important when we start talking about journal
document states.

Dan