patch - build abiword with sugar-jhbuild

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

patch - build abiword with sugar-jhbuild

Robert Staudinger
On 8/3/06, Marco Pesenti Gritti <[hidden email]> wrote:

[...]

> > BTW, can i check in a patch to sugar.modules that allows building
> > abiword?
>
> Sure, though I *think* access is per module  so you probably don't have
> access to sugar-build.  If you don't just send me a patch and I will
> check it in.

The patch lets you build a basic abiword from Erik's "sugar" branch.
Currently no launcher or activity is installed, will try to get that
into the branch soon.

A few things need pondering
+ spell checking (enchant vs ispell vs "at all")
+ use of gucharmap (vs builtin char map)
+ need of printing support (through gnome-print)
+ plugins like ODT (currently no plugins are built)

Cheers,
Rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sugar-jhbuild-abiword.diff
Type: text/x-patch
Size: 2129 bytes
Desc: not available
Url : http://mailman.laptop.org/pipermail/sugar/attachments/20060804/bd5cfb69/sugar-jhbuild-abiword.bin
Reply | Threaded
Open this post in threaded view
|

Re: patch - build abiword with sugar-jhbuild

Marco Pesenti Gritti
Robert Staudinger wrote:

> On 8/3/06, Marco Pesenti Gritti <[hidden email]> wrote:
>
> [...]
>
>> > BTW, can i check in a patch to sugar.modules that allows building
>> > abiword?
>>
>> Sure, though I *think* access is per module  so you probably don't have
>> access to sugar-build.  If you don't just send me a patch and I will
>> check it in.
>
> The patch lets you build a basic abiword from Erik's "sugar" branch.

Looks like also the addition of evince-olpc is part of the patch for
some reason? Can you remove it so that it applies cleanly?

Thanks,
Marco
Reply | Threaded
Open this post in threaded view
|

Re: patch - build abiword with sugar-jhbuild

Robert Staudinger
On 8/4/06, Marco Pesenti Gritti <[hidden email]> wrote:

[...]

> Looks like also the addition of evince-olpc is part of the patch for
> some reason? Can you remove it so that it applies cleanly?

Lack of git-fu here, sorry.

- Rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sugar-jhbuild-abiword.diff
Type: text/x-patch
Size: 1561 bytes
Desc: not available
Url : http://mailman.laptop.org/pipermail/sugar/attachments/20060805/daedf371/sugar-jhbuild-abiword.bin
Reply | Threaded
Open this post in threaded view
|

Re: patch - build abiword with sugar-jhbuild

Marco Pesenti Gritti
Robert Staudinger wrote:
> On 8/4/06, Marco Pesenti Gritti <[hidden email]> wrote:
>
> [...]
>
>> Looks like also the addition of evince-olpc is part of the patch for
>> some reason? Can you remove it so that it applies cleanly?
>
> Lack of git-fu here, sorry.

Any reason the abiword branch in specified in the rc file rather than
the .modules?

Marco
Reply | Threaded
Open this post in threaded view
|

Re: patch - build abiword with sugar-jhbuild

Marco Pesenti Gritti
Robert Staudinger wrote:

> On 8/5/06, Marco Pesenti Gritti <[hidden email]> wrote:
>> Robert Staudinger wrote:
>> > On 8/4/06, Marco Pesenti Gritti <[hidden email]> wrote:
>> >
>> > [...]
>> >
>> >> Looks like also the addition of evince-olpc is part of the patch for
>> >> some reason? Can you remove it so that it applies cleanly?
>> >
>> > Lack of git-fu here, sorry.
>>
>> Any reason the abiword branch in specified in the rc file rather than
>> the .modules?
>
> No, i'm not too familiar with jhbuild.

Fixed that up and checked in. Let me know if there are probs.

Thanks,
Marco
Reply | Threaded
Open this post in threaded view
|

patch - build abiword with sugar-jhbuild

Christopher Blizzard
In reply to this post by Robert Staudinger
Robert Staudinger wrote:

> On 8/3/06, Marco Pesenti Gritti <[hidden email]> wrote:
>
> [...]
>
>> > BTW, can i check in a patch to sugar.modules that allows building
>> > abiword?
>>
>> Sure, though I *think* access is per module  so you probably don't have
>> access to sugar-build.  If you don't just send me a patch and I will
>> check it in.
>
> The patch lets you build a basic abiword from Erik's "sugar" branch.
> Currently no launcher or activity is installed, will try to get that
> into the branch soon.
>
> A few things need pondering
> + spell checking (enchant vs ispell vs "at all")
> + use of gucharmap (vs builtin char map)
> + need of printing support (through gnome-print)
> + plugins like ODT (currently no plugins are built)
>

So how well does it work in the sugar environment?  If at all?

--Chris
Reply | Threaded
Open this post in threaded view
|

patch - build abiword with sugar-jhbuild

Robert Staudinger
On 8/7/06, Christopher Blizzard <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

patch - build abiword with sugar-jhbuild

Marco Pesenti Gritti
Robert Staudinger wrote:

> On 8/7/06, Christopher Blizzard <[hidden email]> 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.

alt+c for now... The new design will have a visible way to do it...

Marco
Reply | Threaded
Open this post in threaded view
|

patch - build abiword with sugar-jhbuild

Christopher Blizzard
In reply to this post by Robert Staudinger
Robert Staudinger wrote:

> On 8/7/06, Christopher Blizzard <[hidden email]> 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.

--Chris
Reply | Threaded
Open this post in threaded view
|

patch - build abiword with sugar-jhbuild

Robert Staudinger
On 8/8/06, Christopher Blizzard <[hidden email]> wrote:

[...]

> 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.

Yeah, Erik so far did a good job coping with the not-always-so-easy
abiword codebase.

> 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.

Hard facts appreciated ;-)
(as in docs or code to draw some inspiration from)

For everyone who's interested in abi/sugar:
the port can now be launched with a --gtk-socket-id=$foo parameter,
that's what's used for sugar embedding.
If the sugar build is launched without passing of the socket id
abiword launches in a normal window, which is quite handy for
development.

- Rob
Reply | Threaded
Open this post in threaded view
|

patch - build abiword with sugar-jhbuild

Christopher Blizzard
Robert Staudinger wrote:
> Yeah, Erik so far did a good job coping with the not-always-so-easy
> abiword codebase.

How far off the main codebase is it?  Also, what do your on-disk and
memory sizes look like right now?

>> 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.
>
> Hard facts appreciated ;-)
> (as in docs or code to draw some inspiration from)

We'll have something post-worthy either tomorrow or Friday.  We've gone
back and done some pretty large visual changes to the design.  The
underlying principals haven't changed but a some of the interactions
have.  Sorry about sounding vague, we just want to be able to tell a
pretty good story this time instead of just having screenshots.

>
> For everyone who's interested in abi/sugar:
> the port can now be launched with a --gtk-socket-id=$foo parameter,
> that's what's used for sugar embedding.
> If the sugar build is launched without passing of the socket id
> abiword launches in a normal window, which is quite handy for
> development.

Recent builds of sugar (like, from source?) don't use socket embedding
anymore.  We're using a window manager, just like the rest of the
planet.  That makes things a lot easier for guys like you who are
attempting the impossible.

--Chris
Reply | Threaded
Open this post in threaded view
|

patch - build abiword with sugar-jhbuild

msevior@physics.unimelb.edu.au
In reply to this post by Christopher Blizzard
> Robert Staudinger wrote:
>> On 8/7/06, Christopher Blizzard <[hidden email]> 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.

>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?

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.

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

Martin


> --Chris
> _______________________________________________
> Sugar mailing list
> [hidden email]
> http://mailman.laptop.org/mailman/listinfo/sugar
>


Reply | Threaded
Open this post in threaded view
|

patch - build abiword with sugar-jhbuild

Dan Williams-4
On Wed, 2006-08-09 at 22:02 +1000, [hidden email] wrote:

> > Robert Staudinger wrote:
> >> On 8/7/06, Christopher Blizzard <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

patch - build abiword with sugar-jhbuild

Alan Kay
In reply to this post by msevior@physics.unimelb.edu.au
Don't we really want the children to collaborate at higher levels than
individual apps? And to integrate media at a higher level than word
processors, chat UIs, etc.?

Cheers,

Alan

At 05:02 AM 8/9/2006, [hidden email] wrote:

> > Robert Staudinger wrote:
> >> On 8/7/06, Christopher Blizzard <[hidden email]> 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.
>
> >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?
>
>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.
>
>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
>
>Martin
>
>
> > --Chris
> > _______________________________________________
> > Sugar mailing list
> > [hidden email]
> > http://mailman.laptop.org/mailman/listinfo/sugar
> >
>
>
>_______________________________________________
>Sugar mailing list
>[hidden email]
>http://mailman.laptop.org/mailman/listinfo/sugar


Reply | Threaded
Open this post in threaded view
|

patch - build abiword with sugar-jhbuild

Robert Staudinger
In reply to this post by Christopher Blizzard
On 8/9/06, Christopher Blizzard <[hidden email]> wrote:
> Robert Staudinger wrote:
> > Yeah, Erik so far did a good job coping with the not-always-so-easy
> > abiword codebase.
>
> How far off the main codebase is it?  Also, what do your on-disk and
> memory sizes look like right now?

It's very close to the original codebase, only a few UI tweaks as of
now. For on disk size see below, not sure if memory size would be very
significant without a reference document loaded.

This is of course an unoptimised "stock" gtk-only build (as built by
sugar-jhbuild). There might be considerable room for improvement,
depending on which features are required (also i'm not sure who sets
the requirements and when).

Sorry for late reply.
- Rob


Stripped binary:

[robsta@abiword bin]$ ls -l AbiWord-2.6
-rwxr-xr-x  1 robsta robsta 6893576 Aug 16 16:13 AbiWord-2.6

Installed in its own prefix, including translations, glade files ...

[robsta@abiword ~]$ du -bs abi-sugar/
12898019        abi-sugar/
Reply | Threaded
Open this post in threaded view
|

patch - build abiword with sugar-jhbuild

Robert Staudinger
In reply to this post by Alan Kay
On 8/9/06, Alan Kay <[hidden email]> wrote:
> Don't we really want the children to collaborate at higher levels than
> individual apps? And to integrate media at a higher level than word
> processors, chat UIs, etc.?

Alan, quite frankly, your messages are slightly confusing me every now
and then. We want to create a "word processing activity" (in whatever
incarnation) that fits the requirements as good as possible (and time
permitting).
If you have ideas how to improve collaboration we'd certainly be most
interested and also willing to prototype stuff. If the word processing
is just a part in that higher level system we'd like to have it fit
that bill.
Has any work been done yet towards higher level integration? Is there
any writeup, API or code to look at?

Thanks,
Rob
Reply | Threaded
Open this post in threaded view
|

patch - build abiword with sugar-jhbuild

Alan Kay
Hi Robert --

At 07:41 AM 8/16/2006, Robert Staudinger wrote:

>On 8/9/06, Alan Kay <[hidden email]> wrote:
>>Don't we really want the children to collaborate at higher levels than
>>individual apps? And to integrate media at a higher level than word
>>processors, chat UIs, etc.?
>
>Alan, quite frankly, your messages are slightly confusing me every now
>and then. We want to create a "word processing activity" (in whatever
>incarnation) that fits the requirements as good as possible (and time
>permitting).
>If you have ideas how to improve collaboration we'd certainly be most
>interested and also willing to prototype stuff. If the word processing
>is just a part in that higher level system we'd like to have it fit
>that bill.
>Has any work been done yet towards higher level integration? Is there
>any writeup, API or code to look at?

There are several issues here. The first is the integration of media. A
good old model that would be great for children is Hypercard (and to a
lesser extent Logo Microworlds). Hypercard was a mini authoring system for
many kinds of media, including text, pictures, presentations, scripted
applications, etc. A few additions would allow it to also do email, screen
sharing, web pages and wikis, etc. Examples of this in a more modern form
are the Squeak Etoys, which was heavily inspired by the directions
Hypercard was pointing. Several white papers on the educational approach
and the media approach are:
  http://www.squeakland.org/pdf/etoys_n_learning.pdf ,
http://www.squeakland.org/pdf/etoys_n_authoring.pdf .

For many reasons, I think the "integration of media objects in a unified
media approach with scripting" is a better way to go, not just for
children, but for most users. The current alternative is the extreme
stovepiping of separate applications without perfect copying between them:
this leads to a weaker media approach in general and makes things more
difficult than they need to be.

The Squeak Etoys will be included with the $100 laptop, but I have urged
(on this list, in OLPC meetings, to the Ruby folks, and in a keynote at
EuroPython) for something like the Etoys to be done in a more recognizable
open source vernacular (such as Linux + Python). I'm still hoping this will
be done, as it would ensure the strongest integration between media for the
children and the adults who are trying to help them.

The second issue is that of sharing. Again, Squeak Etoys has a number of
methods for deep multiuser collaboration, not just chat but multiple cursor
simultaneous access to shared worlds in both 2D and 3D. I used the 2D
version to give my presentation from Los Angeles to EuroPython at CERN.
Again, I want to urge OLPC to try to deal with the larger issues involved
here, and one of these really requires collaborative sharing of any and all
experiences, not just something specialized to a particular application.
And, again, though this can be done now in Squeak Etoys, I urge OLPC to use
the underlying technological solutions to make a recognizable vernacular
version.

Cheers,

Alan



>Thanks,
>Rob
>_______________________________________________
>Sugar mailing list
>[hidden email]
>http://mailman.laptop.org/mailman/listinfo/sugar