Windows visual guidelines compliance

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Windows visual guidelines compliance

Esteban A. Maringolo-3
Hello,

What should I consider if I want that the windows built using Dolphin
complies with the Visual Guidelines given by Microsoft?

Mainly in term of dialog units (DLU) as measurement, and the support
multiple DPI font resolution.

Does Dolphin natively support this?

Thanks,

--
Esteban


Reply | Threaded
Open this post in threaded view
|

Re: Windows visual guidelines compliance

Steve Alan Waring
Hi Esteban,

> What should I consider if I want that the windows built
> using Dolphin complies with the Visual Guidelines
> given by Microsoft?

Tough question ... do Microsoft ship apps that comply fully with their
own guidelines?

Reading this blog:
<http://blogs.msdn.com/jensenh/archive/2006/03/13/550407.aspx> suggests
that Office 12 will do its own thing as far as themes are concerned. I
am sure that breaks a guideline or two.

> Mainly in term of dialog units (DLU) as measurement,
> and the support multiple DPI font resolution.
> Does Dolphin natively support this?

The short answer is Dolphin does support dpi changes.

The long answer, with a bit of speculation mixed in, is:

I am not exactly sure what DLUs are, but I have always assumed they
solve the same problem as Dolphin's #resolutionScaledBy: system. My
understanding is that Dolphin saves all resources (including dialogs)
layed out in pixels. When a resource is saved, the current dpi is saved
into it (See STBViewProxy>>setView:). When it is loaded, it checks the
saved dpi against the current dpi and gives everything in the view a
chance to scale itself. (See STBViewProxy>>restoreView and the various
definitions of #resolutionScaledBy: ).

It has been a long time since I created a GUI in another environment,
so I am not in a position to compare DLU with Dolphin's
#resolutionScaledBy: ... however I assume like most things, Dolphin
does it better. The nice thing about #resolutionScaledBy: is that you
can implement it yourself where needed, and scale any custom view
widgets or dynamic layout code you have.

FWIW: I believe that due to DPI problems, Vista will report a constant
DPI to all applications unless a function is called which indicates
that the app is DPI aware. I have a machine I test with set to 120 dpi,
and it is amazing how many big name apps don't cope.

One thing the #resolutionScaledBy: system doesn't adjust for is if the
user changes the "Font scheme size" ( as distinct from DPI). FWIW:
Raymond Chan gave a good talk on the two different types of "Large
Fonts" which you can stream online from:
http://microsoft.sitestream.com/PDC05/ ( See "FUN412: Five Things Every
Win32 Developer Should Know").

Personally I think this *may* be more of a problem in D6 than D5,
(although this is 100% speculation as I have not done any deployment
testing in D6 as yet). In D5 (at least in my images), it was common to
have a font set into the DesktopView singleton's font instance variable
when deploying. In D6, it seems much harder for this to happen.
Therefore, D6 is more likely to pick up the user's #iconTitleFont, and
I think (although I am not sure) the #iconTitleFont is one of the fonts
that does change when the user changes the "Font scheme size".

If this sounds confusing, it is, and I am! What I would recommend is to
always test deployed apps. Check them with various dpi settings and
with the various "Font scheme sizes". In the past couple of months
VMWare and Microsoft have made some of their VM products free. So it is
now easy and cheap to do these tests.

Steve