[squeak-dev] DPI awareness

Juan Vuletich wrote:
...

 > I also enhanced the (fixed) kerning of the fonts, especially at larger
 > sizes for normal and at all sizes for italics. (Thanks Martin for the
 > suggestions, please check them now).
 >
 > I also added:
 >    Preferences tinyFonts   "For PDAs"
 >    Preferences smallFonts   "For PDAs"
 >    Preferences standardFonts   "For standard displays"
 >    Preferences bigFonts            "For standard displays"
 >    Preferences veryBigFonts      "For hires displays (for example the
 > XO) or for large displays"
 >    Preferences hugeFonts            "For hires displays (for example
 > the XO) or for large displays"
 > These sets the size of fonts (code, lists, buttons, title, etc), the
 > height of the title bar, the height of button rows and the width of
 > scrollbars.
...

Very nice. I like especially the ability to choose fonts from tiny to
huge and have *all* other UI elements resized accordingly. This is the
way to go!

Eventually the work intensive part going this route will be the icons.
But it is necessary, given that the span of DPI resolutions of future
displays will only expand. I just learned that since Windows Vista
Microsoft is "DPI-aware" as they call it. They advocate to write
programs so that they are being able to accommodate to displays and user
preferences over a wide range.

This involves supplying all icons in several sizes and it also requires
developers to keep informing texts short and dialog boxes only scarcely
filled with objects. Otherwise application windows become quickly too
big to fit on the screen.

Just a small calculation: If a user prefers a font with twice the size
of some preinstalled small "standard" and display pixel sizes vary by
only a factor of 2, one would have to support a DPI range of factor 4.
Of course there are disabled users who can only read really huge fonts
like 5 times the standard size and future displays will easily break the
0.1 mm pixel barrier. At the other end they are already nearing 1 mm for
TV/desktop mix mode displays.

Since Vista Windows seems to have the ability to zoom all windows of
selected applications per smoothed bitmap scaling by the graphics card
if the user finds their UI elements too small. Windows transforms mouse
coordinates and otherwise simulates a DPI value different from the
OS-wide chosen one for the whole app.

This is thought as a makeshift for the many older programs out there
that are not DPI-aware. Embarrassingly almost every existing program
falls in that category today, and so, amazingly, I find myself playing
with the idea to upgrade to Windows 7.

Cheers,
Martin

Hi Martin,

Martin Wirblat wrote:
Thanks. I'm glad you like it.

DPI awareness is not the way to do it. And application zoom by the OS is
a low quality workaround. I know what I'm talking about. I specialized
in image and signal processing, did my thesis on those areas, and did
research at my university for several years.

The real solution is to forget about pixels and do real scalable UIs,
like Morphic 3. Take a look at
http://www.jvuletich.org/Morphic3/TheFutureOfTheGUI_01.html and other
entries in my page.

Cheers,
Juan Vuletich

On 23.08.2009, at 11:27, Martin Wirblat wrote:

> Since Vista Windows seems to have the ability to zoom all windows of  
> selected applications per smoothed bitmap scaling by the graphics  
> card if the user finds their UI elements too small. Windows  
> transforms mouse coordinates and otherwise simulates a DPI value  
> different from the OS-wide chosen one for the whole app.


We have that in the Etoys image, too. When you resize the Etoys  
window, all elements are scaled up/down using WarpBlt. Try

http://squeakland.org/content/installers/Etoys-latest-Beta-ToGo.zip

- Bert -

Juan Vuletich wrote:

> DPI awareness is not the way to do it.

This term is more a slogan from Microsoft than a way, but it has its
merits. Most developers are not really aware of the problem.

> And application zoom by the OS is a low quality workaround.

Yes, but most existing programs are in an urgent need for something like
that. They are simply not prepared for modern fine displays.

...

> The real solution is to forget about pixels and do real scalable UIs,
> like Morphic 3. Take a look at
> http://www.jvuletich.org/Morphic3/TheFutureOfTheGUI_01.html and other
> entries in my page.

I know your project. You seem to place emphasis on the coordinate
system. However, for resizing natural pictures or smoothed icons you
will still have to operate directly with pixels. Especially with icons
this is problematic. Perhaps it is better to have a set of sufficient
sizes and choose the best match instead of trying to scale them precisely.

Another part of the equation is the structuring of programs. Only
windows and dialogs that are not overloaded with UI elements and text
can be scaled reasonably. And for that "DPI-awareness" is necessary.

By the way, the biggest obstacle Squeak has IMO for broader visibility,
is its UI library, the current Morphic. All power to brave UI developers!

Cheers,
Martin

2009/8/24 Martin Wirblat <[hidden email]>:
Don't you need "TrueType" (vectorized graphic) icons ?
Aren't icons just some colorful character glyphs ?

Nicolas Cellier wrote:

> Don't you need "TrueType" (vectorized graphic) icons ?
> Aren't icons just some colorful character glyphs ?

Most existing icons are bitmaps, only some have been created as SVG or
some other vector graphics format. Both types generally look different
and some systems can only display bitmapped icons, including Squeak.

Personally I prefer systems or applications with very few and very
simple symbolic icons, so that indeed a TrueType "Symbol" font could be
the primary source for icons. IIRC Squeak used already for some of the
window icons character glyphs, just not scaled.

Regards,
Martin