libabiword (Re: [sugar] A few more toolbar buttons for AbiWord?)

On 11/20/06, Ivan Krstić <krstic@solarsail.hcs.harvard.edu> wrote:

[...]

> Now for production plans: I'd like to ship AbiWord without an editing
> mode, supporting instead viewing, copy to clipboard, and possibly Save
> As Crossmark. This would let us retain the ability to view the
> unfortunately popular closed .doc files, while moving new document
> creation into the notebook where it logically fits.
>
> That said, the rich editing UI that we're developing for the notebook is
> Javascript-based, and thus isn't usable by regular GTK apps. This is
> where you, the AbiWord folks, come in. If you can shrink Abi to an
> embeddable GTK widget that speaks Crossmark, that would rock a whole
> lot, because it would let us do rich text everywhere -- file
> descriptions, e-mails, general annotations, you name it. We could
> encourage application developers to make almost every textbox where it
> makes any sense be an Abi textbox.
>
> And that's where I think we have a great place for Abi on the OLPC
> desktop. So if this sounds interesting, I wouldn't focus too much on the
> standalone Abi app; I'd love to see you folks shell out the widget, and
> have us integrate it right away.

Hi everyone,

we've been talking about a library version of abiword (that we used to
call libabiword) yesterday in #abiword. There's even some older code
of questionable quality in a branch of our cvs repository towards that
end.

Anyways, I'd like to propose the following way forward:

1) Get bare bones AbiWord build as a shared library (no dialogs, no
templates ...). I'd like to call that "libabicanvas" or something like
that to clearly differentiate from the previous attempt. (we should be
able to use stuff from the old libabiword branch for that)

2) Create an AbiCanvas gtk widget using a similar approach as the
hildon port, i.e. implementing a chrome-less AP_UnixCanvasFrameImpl
class. The widget itself should probably wrap AP_UnixFrame or an
AP_UnixCanvasFrame subclass that implements required extra
functionality.

3) Create python bindings. For the AbiCanvas widget we'll of course
build on pygtk but if advanced functionality should be exported (e.g.
access to the document instance) things might not be as straight
forward. However, it seems we have pygtk, boost::python and swig savvy
developers on the team.

4) Once all that is done (may take a while) we should be able to get a
standalone abiword/sugar port that's not using the GtkSocket hack
almost for free.

That said, we're seeing an increased number of interested hackers due
to our olpc involvement, it would be great to take advantage of that.

Enthusiastic and motivated,
Rob
Received on Tue Nov 21 09:59:49 2006