Re: GSoC07: keep dialogs in libabiword?

Hi Dom and Rob,
              I hate supplying stop energy and preventing people from
following their passion. In a nutshell the libabiword you are proposing
will be useful for projects like OLPC Write and Develop which are
explicitly designed to not use dialogs. Maybe this will be the big
future of the AbiWord project.

It will not be anything like as useful for a presentation program or any
other application that needs dialogs. While there are many simple
dialogs in AbiWord, there are also many complex ones. Even the simplest
dialogs have embedded knowledge not obvious or needed to consumer
application. Even the fundamental FileOpenSave dialog has all sorts of
embedded tweaks to get everything right. A dialog-less libabiword will
force every consumer application to reinvent all the tweaks for
FileSaveOpen plus every other dialog of interest.

If the Presentation application happens I would not use the new
libabiword for it because I would not want to reinvent all the dialogs.
The stripped down version of Write shipped to test countries was
apparently useful because the kids could get to the features they wanted
via the dialogs accessible from the right click menu.

My point about this is that it is much easier to not use something than
it is write code from scratch. The current dialog framework allows
dialogs to be loaded dynamically as needed. I implemented this for
AbiCollab. The keybindings framework makes it easy to change or not use
features as needed.

Upon reading a later post I see that your real agenda is to improve the
MVC arrangements of AbiWord and that the dialogs prevent this. I'm not
smart enough to see how this will work but I'm perfectly happy if you
two want to work on this as a research project. I'll shutup now after
posting a link to a post by JoelOnSoftware.

http://www.joelonsoftware.com/articles/fog0000000069.html

All the best,

Martin

On Thu, 2007-04-26 at 09:54 -0400, Dominic Lachowicz wrote:
> 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 Fri Apr 27 02:29:11 2007