Introduction and toolkit abstraction

[Mike Hearn]

> The idea of a middleware library was to fill in the major chunks such as 
> dialog boxes. It is not ideal and not complete, but would prefer a 
> semblence of a solution. Although, with some of the comments from Mike 
> it does seem that there are some technical problems that could prevent 
> it from working.

Don't let me put you off, I was pointing out some of the problems you'd 
encounter. All of them are solvable, though in the end you can't get 
away from the features vs integration tradeoff. If you produce a dialog 
box abstraction, some apps will use it, others won't ... and you have to 
convince library authors to stop using their current toolkits APIs and 
use yours. I don't know how often you'd win that argument, though it 
could certainly be worth a shot. I don't have strong opinions either way 
on whether it's a good idea.

Look at it this way. We've achieved far, far more difficult things in 
the free software community than abstracting a few dialogs boxes before. 
If you think it's the way forward, go for it!

> How do they do this - do they literally have a UI layer for each 
> interface? The problem with this is that it (a) feels like a fudge and 
> (b) would need more development effort. This is not viable for smaller 
> projects.

AbiWord makes smart use of C++ subclassing to get very high code reuse 
while having native UI code for each platform. It's a good technique, 
perhaps one of the best.

AbiWord is a smaller project by all rights, so if they can do it, other
projects can too.

thanks -mike