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

From: John Torjo (john.lists_at_[hidden])
Date: 2004-09-24 11:57:57

Andy Little wrote:

> "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

For fonts, won't you use a wrapper over existing OS-primitives?

Best,
John

-- 
John Torjo
-- john_at_[hidden]
Contributing editor, C/C++ Users Journal
-- "Win32 GUI Generics" -- generics & GUI do mix, after all
-- http://www.torjo.com/win32gui/
-- v1.4 - save_dlg - true binding of your data to UI controls!
    + easily add validation rules (win32gui/examples/smart_dlg)