Re: GSoC07: keep dialogs in libabiword?

On Thu, 2007-04-26 at 09:54 -0400, Dominic Lachowicz wrote:
> Hi Rob,
>
> I agree with you, Rob. Ideally, libabiword would contain a model and a
> view that one could build an AbiWord-like application around.
> libabiword would effectively be a rich-text display widget. There
> would be an API to query and set a section's properties, for instance.
> One would then build a dialog that interfaces with the widget and gets
> and sets the section's properties.

agreed++

> I don't see any value in a "libabiwidgets" library.

See below

> And I don't see
> any value in yet another dialog/widget framework.

agreed++

> Truth be told, I
> don't see much value in our existing dialog framework. My hope is that
> in a year or so, we will have a completely standalone rich-text
> widget. One that could sanely be plugged in to a GTK+ window and
> operated on by normal GTK+ operations. No custom-formatted mouse and
> keybindings files. No "map to screen" calls. Just something that looks
> and behaves like a normal GTK+ widget. And let the consumer plug
> his/her own dialogs into it.

That would rock in general.

However, what if people want the rich text widget, and also a way
manage/use styles and be able to modify/construct tables? I suspect that
this will be a _very_ common way consumers will want to use libabiword.

Your solution is: reimplement all style and table dialogs (creating,
deleting, merging, formatting) again.

Imo, this will result in lots of extra (redundant) work, and lots of
bugs most likely.

If one _also_ has a separate abiword-ui library, the consumer could
simply reuse our existing font and table dialogs, ignore the rest, and
be done with it.

I really *really* doubt people will be satisfied with just the bare
libabiword alone. Also I don't see any drawbacks in 'my' approach,
except the additional library maintenance.

Marc
Received on Thu Apr 26 16:46:20 2007