Re: GSoC07: status update, refactoring feedback request (libabiword diet)

On Wed, 2007-06-06 at 14:56 +0200, Robert Staudinger wrote:
> Hi Dom, Devs,
>
> here's another update on my progress, scroll down if you're only
> interested in giving feedback about future refactoring.
>
> Status update
> -------------
>
> Status for "plain vanilla" abiword build (using libabiword-builder):
> Cocoa: bails at linking stage (any help appreciated!)
> Gtk: works
> Win32: works, tested only cross-compilation on linux / running under mingw
>
> Known to be missing is the "menubutton" option and hildon support for
> the gtk build. I've been in contact with Tomas and Etrunko over how to
> get this fixed and possibly do some cleanup along the way (currently
> it's a mix of XAP_SIMPLE_MENU, XP_SIMPLE_MENU / XAP_SIMPLE_TOOLBAR,
> XP_SIMPLE_TOOLBAR defines and separate layouts in
> ap_Menu_Layouts_Embedded.h / ap_TB_Layouts_Embedded.h).
> Personally i'm in favour of using separate headers for different
> layouts to avoid stepping on other platform's toes.
>
> Apart from compile time options (optional spelling, gucharmap,
> printing) I've been focusing on supporting more plugins in
> libabiword-builder. Currently 11 of 53 plugins are supported, my goal
> is to add support for 3 more each workday (a simple plugin takes about
> 10min).
>
> What occurred to me is that by having abiword and the plugins in a
> single build system it should be rather straight forward to support
> static linking, I'm planning to pursue that in the future.
>
> Refactoring
> -----------
>
> In the recent years it has become pretty clear that we won't do
> another "Abi" application, at least not in the src/af + src/wp way the
> tree is laid out. I'm proposing to work towards a src/lib + src/app
> layout. That means for example that at some point all dialog code
> would in the same directory (e.g. src/app/ap/$platform). Advantages
> are:
> + Buildsystem would be easier, no need to build 2 convenience libs
> e.g. in src/wp/ap/xp, some files there will be needed for libabiword,
> some for the actual application.
> + Tree layout would reflect reality, in which we are working towards a
> standalone library and application that's using it.
> + There's a number of hacks anyways, that circumvents the src/af vs.
> src/wp split (e.g. src/af/ev stuff, which depends on icons in src/wp),
> that would be cleaned up.
>
> What do you think?

Hi Rob,
       I think the only other major application that could ever emerge
from the AbiWord code base is "AbiShow". If such a program does emerge
it will share a LOT of code with with AbiWord from the current src/wp/*
and src/text/* trees.

This new layout will make creating AbiShow much easier.

Other things that are needed are the ability to subclass fp_Page,
fl_DocLayout, fl_DocListener and FV_View (at least) and possibly other
classes in src/text/fmt/.

I agree that the current structure has src/af/xap polluted with explicit
calls to src/wp/ap/* classes and FV_View anyway.

So I'm in favour in principle for post 2.6 development.

Cheers

Martin

> - Rob
Received on Thu Jun 7 02:24:28 2007