From: David Turner (dkturner_at_[hidden])
Date: 2004-03-03 23:36:21
> From: boost-bounces_at_[hidden]
> [mailto:boost-bounces_at_[hidden]] On Behalf Of Beman Dawes
> At 12:35 PM 3/3/2004, David Turner wrote:
> >Yes, I agree. As things stand, I use pixels to specify the
> padding >around windows and between grid elements.
> Everything else is auto-sized >and arranged. I think if the
> implementation provides reasonable >defaults for padding,
> etc., then there will be no practical problems.
> Maybe, maybe not. I've been burned a number of times in the
> past by pixel
> defaults for padding, line widths, etc. The defaults were
> reasonable based
> on the most common hardware. But some of my customers paid
> the money for
> much higher resolution hardware, and the defaults were not
> good there.
> Meanwhile another customer did an in-vehicle system with a
> very lo-res
> display. Same software. But because the hardware was so
> different, the
> usual defaults were useless. Might have been OK if the defaults were
> somehow tied to the particular device.
Well, yes, that's what I meant. Presumably different hardware implies
different back-end library.
What seems clear to me at this point is that there should be a mechanism
to allow other libraries to modify or extend the implementation on a
particular platform. My idea is this: there is currently a shared
header file for each platform that basically defines the implementation
class. What if that header were available by including, say,
<gui/platform.hpp>? It would then be possible, at least on a
platform-by-platform basis, to extend the implementation with new
For example, somebody might write an OpenGL widget that interoperates
with the GUI library. It would have to be ported to each target
platform, but then that's not much worse than the current state of
affairs :-). At least there would be an existing framework to hook
into, which would be reasonably similar on the different platforms.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk