LibAbiwordDiet

From AbiWiki

(Difference between revisions)
Jump to: navigation, search
Maintenance script (Talk)
(Importing text file)
Newer edit →

Revision as of 02:54, 17 October 2007


Contents

Putting Libabiword on a Diet


Scratchpad

Vision for libwrite (the slim libabiword):

Create a powerful but lightweight rich-text widget and infrastructure with a reasonably simple API. It is designed to support a diverse set of applications ranging from source code editor to rich-text viewer supporting all common word processing formats to light-weight word processors. Special features are embeddability of arbitrary content via goffice components and possibly a real-time collaboration infrastructure.

The roadmap below is somewhat outdated, heres some recent stuff that needs to be incorporated.

1 New build system =libabiword-builder=

    • works on all platforms (TODO: embedded conditionals, cocoa)
    • supports plugins in the main tree (TODO port remaining ones)
    • thus can easily be extended to support static linking of plugins.

2 Split libwrite and abiword code, see below. 3 Create =WtView=, a base class for =AbiWidget= with a clean (C/GtkWidget) API. Most additional functionality will be accessible via C++, and likely be exported to python via SWIG.

    • Plugins: =libwrite= can obviously only support filter and canvas plugins. That means the set of plugins must be split into libwrite plugins and abiword plugins. Possibly we need some hack to support stuff like the goffice plugins, which hooks into both, the shell (adding menu entries) and the canvas. Maybe plugins can support 2 initialisation interfaces and thus be useble from both, the abiword binary and the library. An important issue is that libwrite wont try to load plugins itself, but rather offer an API to let the consumer explicitely to that.
    • TODO keybindings
    • TODO popup menus
    • TODO selection handling
    • TODO DnD
    • More TODOs here

4 (if time) Start working on a DOM API

    • Use libxml++ to wrap the PieceTable?
    • Port filters so they use the public DOM API?
    • Would make it possible to write filters in a binding language.
    • Can libxml++ and libxml-python be used on the same in-memory document? Thatd rock for python plugins!

Roadmap

(Will be refined)

  • May 1*: create branch, start work.

Refactoring and build system work. Proposal is to have 2 different libabiword build options: ``--enable-libabiword-compat' (or whatever) that includes the dialog base classes and plugging framework in libabiword (see (3.) below). Plain ``--enable-libabiword' will not include that and thus be able to strip even more, see (4.) below.

1 Split out dialog-involving methods from ap_EditMethods.cpp in a separate file. The full EditMethod array will be put together at run-time. 2 New build system, build libabiword using libtool, and a proper abiword binary. No headers are installed, both lib and binary have to be built from the source tree. 3 (needs discussion) briefly investigate which headers are needed by the abiword binary and the feasibility of installing those headers. Likely well require the source tree for building the abiword binary for the time being.

  • July 1*: finish first part, start the second.

API enhancement. During the second half Ill focus on the public API. This includes things like exposing the model to consumers. Im proposing to have all the public (installed) headers properly written in modern C++ (namespaced, using references where it makes sense, proper use of param- and method constness, possibly exceptions (dont have much experience with C++ exceptions in particular)).

  • August 31*: finish second part.

Statistics

Some abiword codebase statistics, taken using a metric of =grep -r [{};] *.cpp | wc -l=

1 total: 218049 loc 2 "xp" and "unix" sources relevant for the gtk build [1]: 182329 loc 3 "xp" and "unix" sources without xap_UnixDlg_*, ap_UnixDialog_*: 169322 loc ... 93% of (2.) 4 "xp" and "unix" sources without xap_*Dlg_*, ap_*Dialog_*: 160097 loc ... 88% of (2.)

That means 7 loc from a libabiword (rich-text widget only) build. Installation size will decrease even more because auxiliary (glade ...) files are not needed for the widget-only build.

[1] (without "/cocoa/", "/qnx/", "/win/" and "/test/" directories)


Contributors

Personal tools