Introduction and toolkit abstraction
m.hearn at signal.QinetiQ.com
Thu Sep 2 11:17:00 EEST 2004
> 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
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.
More information about the xdg