Subject: dialog design cleanup (was Re: XP dialogs)
From: Paul Rohr (paul@abisource.com)
Date: Sun Feb 11 2001 - 13:33:50 CST
At 11:00 AM 2/11/01 -0500, Thomas Fletcher wrote:
>I'd like to chime in here as one of the few people who has actually
>ported AbiWord to another platform (and I've done it twice now).
>
>Bringing the main AbiWord interface up was easy and took no time
>at all.
Cool. That's what we were shooting for.
I hope that when Hub finishes grinding his way through all his compiler
woes, he'll agree, too. From what little I know of the Mac event model, it
might be different enough to require a few tweaks to the XP design.
However, we'll cross that bridge when and if we come to it. (I still have
Jeff's home phone number, if needed.)
>Completing the rest of the work (ie the dialogs) was hell.
Sorry. This is (slightly) my fault. See details below.
>Not because they are necessarily hard to do, in fact, given a
>screenshot of an existing dialog it doesn't take long to whip
>one up on any given platform assuming that you are familiar with
>that platform (this is why we have "platform" maintainers).
Yep. That's the way the current approach should work.
>The problem with the AbiWord dialogs is that each back end is
>managed and implemented differently. Some dialogs have a
>very complete XP implementation so that the GUI really just
>feeds the XP class and vice versa. Others rely on a lot more
>work to be done in the actual platform GUI code. This makes
>impementing the dialogs a real pain.
Yeah, exactly.
Rather than try to design an up-front approach to use for all dialogs, we
made a fairly conscious decision to gain some implementation experience
first. Unfortunately, this has gotten totally out of control.
From the first few ultra-simple dialogs, it just wasn't clear what would be
the cleanest spot to draw the API boundary between XP and platform code.
Thus, the only rule we made was that the maximum amount of dialog behavior
belonged in XP code, thus minimizing the size and scope of the platform
face.
In particular, we started off by letting at least two models compete:
- "bulk copy" paradigm -- platform code uses XP member variables & methods
- "set/gather" paradigm -- lots of little calls from XP down into widgets
Both approaches, when done well, can isolate the "right" amount of code into
XP logic in ways which shouldn't favor any of our platforms. Since we
didn't have consensus that there was only one right way, we did the Linux
thing:
Let various alternatives compete.
Canonize the winner, when it becomes obvious which one that is.
Unfortunately, in this case the competition hasn't been that productive.
Sorry about that.
>I'd be happy if we had a utopian world where you could code the
>dialog in XP land completely. I don't think that it is going
>to happen any time soon, so I'd suggest instead that coming
>up with a consistant set of rules on how to manage the dialogs
>would be more worthwhile.
Yes. We should now have enough experience with the weaknesses of current
implementations to make the call now. (Does anyone envision an upcoming
dialog which is so hellishly complex that our experience to date still isn't
enough?)
This sounds like an excellent, practical, short-term project for someone
who'd like to flex their design muscles -- namely, assess the current XP
dialog implementations to see whether one is now a clear winner that should
be used for all of our existing dialogs. Obvious criteria would include:
- native final look & feel
- clean & compact implementations on each platform
- clear & simple APIs to XP logic controlling behaviors
Any takers?
As one of the original advocates of the "bulk copy" paradigm, I'd probably
advocate switching directly to that. It worked fine for early dialogs up
through the relatively complex Paragraph dialog. But hey, I'll admit that
I'm biased.
Paul
motto -- let many flowers bloom
This archive was generated by hypermail 2b25 : Sun Feb 11 2001 - 17:35:52 CST