Re: GSoC07: keep dialogs in libabiword?

Hi Martin,

Thanks for the thoughtful words.

> 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.

That assumes that our consumers want the tweaks in the first place,
which I think is a bit presumptuous. But perhaps not much moreso than
thinking that they wouldn't want them.

> 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.

Importantly, this wouldn't change with this proposal. All that would
change is how the right-click menu materializes, not the end result.

> 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.

I'd disagree with that. Many times, yes, it's easier to work from an
existing base. However, many times, legacy can get in your way.
Instead of aiding you, it's an obstacle. I'd argue that this becomes a
much larger problem at toolkit and language boundaries.

Try looking at it from this angle. You're a consumer of the AbiWord
GTK+ widget and want to write a code editor using it. Ideally, you'd
like to write it in a dynamic language, like Python. You don't want to
have to mess with how AbiWord's keybindings and mouse bindings work.
And you don't want AbiWord's FOSA dialog to show up when you hit
Ctrl+S, because you want to show your own.

So is it easier for this user to:

1) Expect that his GTK+ accelerator's signal invokes his GTK+ callback
function, popping up his GTK+ dialog
or
2) Rewrite AbiWord's keybindings file (perhaps not really knowing
which key combos are already taken by AbiWord). You'd want to disable
about 99% of the existing bindings (code editors have no need for
bold, italics, underline, etc.). Then you would overwrite an AbiWord
edit method in order to plug in a new dialog (which you must write C++
code for, that extends an AbiWord FileOpenSaveAs dialog class) that
ultimately doesn't care about AbiWord's view or piece table, just a
plaintext representation thereof.

This is all what I'd call application logic. The AbiWord widget has
some notion that it is a rich-text editor. But it doesn't know whether
it's being used as a C++ code editor, HTML editor (where you'd
probably want Ctrl+B to insert a literal "<b></b>" around a block of
text), presentation app, or a word processor. And it shouldn't have
to. Its goal is to be helpful while unobtrusive. I believe that it
does this best by being a good model and view, but leaving as much
controller logic to the parent application as is practicable.

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

I could come up with a few dozen good arguments against Joel's opinion
here (and as many in favor of it, of course), but that's beside the
point. No one is advocating rewriting things from scratch. I've
mentioned "incremental transitions toward a goal", not "throw what we
have away and start from scratch", though it may seem like that's what
I said.

My argument is that a lot of our recent work for Hildon, XO, and etc.
has been trying to make a square peg fit rather clumsily into a round
hole. We have a *really good* model and view, in no small part due to
your efforts. I'd like to keep that. From where I sit, it's the
controller that's getting in the way of us fully exploiting these new
market opportunities. I'd like to smooth out some of those rough edges
to make our peg fit into those round holes.

Maybe that means that we keep around an AbiWord UI library, and we
repackage our dialogs and framework in a way that makes sense for
3rd-party consumers. Maybe it means something different. I don't have
the answers yet, but I think that as we experiment and iteratively
develop, we'll get a better idea of what the final product looks like.

It appears that we both have the same basic goal ("an AbiWord control
adaptable to alternate environments"), but different ideas on how to
get there. And that's healthy.

All the best,
Dom
Received on Fri Apr 27 03:53:49 2007