Re: wxWin vs. AbiSource framework

Leonard Rosenthol (leonardr@lazerware.com)
Mon, 8 Nov 1999 10:31:52 -0500


At 9:49 PM -0600 11/7/99, Jeff Hostetler wrote:
>On Sun, 07 Nov 1999, Leonard Rosenthol wrote:
> > Actually, you will find that most/all frameworks used by
> > commercial software developers achieve both 1 and 2 - and in fact,
> > those are the two most important goals.
>
>Cool. I stand corrected. ... Can you
>name any (GPL or LGPL or commercial) names that we might
>investigate further or that you would recommend to a friend (or
>recommend to avoid) ?

I've spent a bunch of time looking at the open source
frameworks for a while, at least those that are MacOS and Windows (my
primary platforms) and the two that I like the best are wxWin and
Whisper (<http://www.halcyon.com/www3/jesjones/Whisper/Home.html>).

Architectureally, Whisper is great! It was actually designed
from the bottom up with thought given to exactly how things should
work in the framework. It uses a lot of modern compiler features
(STL, string, etc.) as well as standards (Unicode, XML, etc.). So
although the underlying framework is in great shape, including
abstractions all the way up to the widget level - not all the widgets
and UI elements that one would want from an app like AbiWord are
there (eg. no toolbars, or list widgets).

wxWin has the prize for "most stuff implemented", and it also
works on X, GTK, and even Python ;). It's been used in a number of
real life applications and so a lot of the UI elements and such are
all there - but the underpinnings in many cases are weak and not well
designed, or at least not consistantly designed.

>Cool. Is this a proprietary (in-house developed) package of Adobe
>or was there a third-party supplier?

AFAIK, almost all of the frameworks that I know of that are
being use by the larger commercial houses (Microsoft, Adobe, Apple,
Macromedia, etc.) were all developed in house. The two exceptions
are that Corel is using WINE for moving their software to Linux (and
maybe for their new Mac stuff too), and a small company that has a
nice package for license. I don't have a link for it, but I'll try
find out what the status of it is.

> > You now have enough experience and example
> > dialogs & widgets to sit down and design higher level "wrapper"
> > classes for all this stuff. Do it NOW before you get further and
> > further down the platform-centric path...
>
>yes, we do. And part of me wants to "take a year off" and do that.

I don't think you need to "take a year off". I think that
you could do it in pieces. Pick a dialog that has at least a few
different element types in it, and start working on moving it into a
single set of XP code that manages that window, widgets, etc. Once
you get it done for one dialog, you can move to others - and if you
don't move to others - no big deal they will still work but at least
you'll have started something.

>But I think the right thing to do is to continue on as we are and
>finish 1.0 with a respectable feature set. THEN as it gains critical
>acceptance in the user community, we can pause and DECIDE how to proceed.

That's certainly an option - just make sure you put this
stuff on the schedule for 1.x or for the other apps or it won't
happen. Too many times infrastructure will fall before
features/timelines/etc, esp when it's not pre-scheduled in.

>It might be the wrong thing to do from an engineering point of view, but
>it's the right thing to do from a product point of view.

If you were trying to get a product to market to SELL and
make $$ from - I could understand that. But as an open source
developer, who isn't selling anything, is that still a valid approach?

LDR

----------------------------------------------------------------------------
You've got a SmartFriend in Pennsylvania
----------------------------------------------------------------------------
Leonard Rosenthol Internet: leonardr@lazerware.com
America Online: MACgician
Web Site: <http://www.lazerware.com/>
FTP Site: <ftp://ftp.lazerware.com/>
PGP Fingerprint: C76E 0497 C459 182D 0C6B AB6B CA10 B4DF 8067 5E65



This archive was generated by hypermail 1.03b2.