[boost] Re: Re: Re: C++ GUI - another view

From: Andy Little (andy_at_[hidden])
Date: 2004-09-24 07:35:41

"Noah Stein" <noah_at_[hidden]> wrote in message
news:20040923095953.SM01616_at_enki...
> > From: boost-bounces_at_[hidden]
[mailto:boost-bounces_at_[hidden]]
> > On Behalf Of Andy Little
>
> > Yes..As I have touched in in a previous post this should be accessible
> > at  the 'device layer'. OTOH Another way to look at a pixel is as a
> > rectangular box that is *currently*, *on this device*,  (say) 0.25 mm
> > wide and 0.25mm high or whatever, the next layer up.
>
> What does "accessible at the device layer" mean in this context?
> A pixel is a fundamental unit in any graphics context.  I don't think that
> an application programmer should be forced to jump through hoops to get
> at it.

In my current model it is available as (roughly) :

   Canvas c;
    c.viewport.device.extent.x;  // width of device in pixels
    c.viewport.device.physical_size.x; // width in (usually) mm but...
    //The actual units you use are up to you....

    // (implicit conversion from mm to point):
    width::point_comp  current_pixel_width
     = c.viewport.device.physical_size.x / c.viewport.device.extent.x;

    //note: width could be a length typedef or its own type,
    //which I am now thinking about.

> I fully support a unified rasterization model across output devices;

Not quite sure what that means.

> however, I don't think it should be achieved at the expense of the many
> programmers who will not use it because they do not need it.  For the vast
> majority of UI programmers, the look of combo boxes and buttons on 1200
> dpi laser printers is irrelevant.

Hmm... so UI programmers arent at all concerned with explaining the UI  to
the user?
Making the app look as good as possible on a wide range of platforms.
Trying to provide a uniform look and feel.
Avoiding making the user think in terms of pixels.

>  The specification of certain quantities in pixels is necessary.
> When designing a graphics API, supporting high-quality output on a diverse
> set of devices is a large design issue.  Text is very different on a
> monitor  than on a high-res laser printer.  Nice kerning is heavily
affected
>  by the dpi disparities, resulting in a whole host of issues.  One major
issue
> dissimilar line breaking.  Inconsistent line breaks can have an enormous
impact
> on presentation.  At what resolution should kerning occur?  What will
> pay the price: laser printers, monitors, or layout control?

These are the more interesting issues. I have only just started playing
about with units'n guis and havent delved too far into text, fonts and so
on. However text does as you say lead to interesting problems. It will be
interesting to see if it is easier to deal with text via pixels or units of
measure.

> I'm a big fan of types and units.  I just think that pixels should be a
> readily accessible type.

They could be a 'runtime type', which you could interrogate to find the
current size of a pixel in (say) mm.
This would probably be useful in  figuring out what fonts to recommend to
the user in a selection.

> I think it should be the default unit.  Being
> American, there's nothing special about mm's.  I like points more.  Or
> maybe to just get everybody to think about it, the library could default
> to cubits.  ;-)

Well... in  my physical_quantities library you can use cubits if you wish.
If anybody knows what the scaling is between cubits and meters, I'll add it
in :-)

BTW To those interested in the current status of pqs. I am working on the
next distro. But as always I find documentation a heavy slog. But I'm
getting there slowly. Hmm... discussing GUI's is so much more fun ;-)

regards
Andy Little