Re: GSoC07: keep dialogs in libabiword?

Hi Rob,

> Martin and also Marc to some extent advocated keeping the dialogs, the
> main argument was that the code/installation size decrease wasn't
> worth the loss of functionality. Hub pointed out that if I thought it
> was too hard to create or modify dialogs I should fix the framework
> instead -- which would be of course a monster project and there's been
> precedent of abandoned dialog migration efforts [2].
>
> My counterarguments were that with a sane "model" interface it would
> be comparatively easy to implement dialogs as a libabiword consumer
> and that -- given an existing language binding -- dialogs could be
> implemented in whatever language. Also there's a number of assumptions
> connected to the way modal/non-modal dialogs work, that might lead to
> problems for apps using multiple abiwidget instances. Finally one has
> to start somewhere, I decided that this starting point/project should
> be a nice standalone rich-text widget, and there's of course the
> possibility to create a "libabiwidgets" at some later point in time.

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.

I don't see any value in a "libabiwidgets" library. And I don't see
any value in yet another dialog/widget framework. 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.

I realize that this is a big undertaking, and that's why a reasonable
migration path is called for. However, I don't see any point in the
migration as an end point. Just a necessary evil on the way to a final
goal.

Best,
Dom
Received on Thu Apr 26 15:53:00 2007