|
Boost : |
From: Dave Harris (brangdon_at_[hidden])
Date: 2005-10-09 12:45:17
In-Reply-To: <434426EF.5030808_at_[hidden]>
mw8329_at_[hidden] (Martin Wille) wrote (abridged):
> > But you aren't going to draw a PCB on screen with boost.GUI widgets.
>
> Why shouldn't a good GUI library be prepared for that use case?
I think he's saying that the use case would be handled by a different
component of the library.
I'm coming around to the idea that the library should use ints and device
pixels for its core graphics units. Or rather, some fraction of pixels:
probably 100 or 256 units per pixel. All other units eventually get
converted to this. The conversion is dependant on the device, and if a
component needs to be device-independant it uses its own units and defers
conversion until it knows what device it is using.
Many widget calculations won't care what the units are at all. Some sizing
happens top-down. The user drags out a window, the app gives half the
space to one widget and half to the other. It doesn't care what the units
are, it is just dividing by two.
Some sizing happens bottom-up. Often this is driven by text. A button
needs enough room to display the word "Cancel" in 12-point text.
int height = 12 * device.points_to_gu();
Font font( "Arial", height );
int width = font.width( "Cancel" );
I don't think there is any need to force the width to be in absolute
units. Both millimetres and inches would be wrong for someone.
A PCB would be laid out with a CAD app, which would measure in
millimetres. Part of its rendering pipeline would be a conversion from mm
to graphic units.
A dialog editor is a different kind of app. It might measure in points and
have a different conversion. The Microsoft one uses what it calls "dialog
units", which are scaled according to dialog's chosen font, which can in
principle be changed by the end-user.
We don't need to force the dialog editor to use the same internal units as
the CAD app. When they need to communicate, they can use pixels units *
256 a lingua-franc. I do not think the need for a device-independant
linga-franca is compelling enough for it to dominate the core GUI.
-- Dave Harris, Nottingham, UK.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk