What should be the default value for a dialog padding? 8px 10px?
The Windows UX guidelines tell you to use a 7 DLU padding all the way around on a dialog.
A Dialog Unit (DLU) is based on the average size of a character. It's defined so that the "average" character is 4 DLUs wide by 8 DLUs high.
The size of an average character changes depending on the font, the font size, and the dpi that the user is currently running. This means that DLUs are not a constant between machines, or between users on the same machine.
Different fonts have different aspect ratios. This ends up meaning that the size in pixels of a DLU will be different in the horizontal and vertical directions.
Looking at this particular size (dialog padding of 7 dlus):
Segoe UI 9pt, 96dpi Tahoma 8pt, 96dpi
dlus px py px py
==================================================
1x1 1.75 1.875 1.250 1.625
4x8 7 15 6 13 Definition of DLU: Average character=4x8
7x7 12.25 13.125 8.75 11.375 Dialog box margin - all sides (7)
So if the user is running Segoe UI 9pt at 96 dpi (the Windows Vista and 7 default), you want a top and bottom margin of 13px, and a left and right margin of 12px.
If the user is running Tahoma 9pt at 96dpi (the Windows 2000 and XP default), you want a top and bottom margin of 11px and a left and right margin of 9px.
Other common sizes:
MS Sans Serif, 8pt, 96dpi (Windows 9x default)
Tahoma 8pt, 96dpi (Windows 2000/XP default)
Tahoma 8pt, 120dpi (Windows 2000/XP large fonts)
Segoe UI 9pt, 96dpi (Windows Vista/7 default)
Segoe UI 9pt, 120 dpi (Windows Vista large fonts default, Windows 7 high-dpi default)
Segoe UI 11pt, 96 dpi (what i run at work)
Segoe UI 9pt, 137 dpi (what i run at home)
And this is why creating user interfaces is hard. It's hard to get it right, and most developers would rather just stick their head in the sand and pretend users didn't have font preferences, or change their dpi setting.
And the fact that the question was asked 4 months ago, and then abandoned, seems to confirm that developers don't want to hear the hard answers.
This depends on the platform and its respective design guidelines.
On Windows it's 7 DLU or 11 px:
Dialog box margins: 7 DLU on all sides or 11 pixels on all sides
—Windows User Experience Interaction Guidelines
In Mac OS X, Apple doesn't mandate a specific size of the dialog padding, but instead only recommends
Equal margins on both sides and the bottom edge of the window (the window in Figure 16-4 uses a 20-pixel margin in these areas).
—Apple Human Interface Guidelines
For GNOME it's 12 px:
Leave a 12-pixel border between the edge of the window and the nearest controls.
—GNOME Human Interface Guidelines 2.2
Consistent across your app.
Related
A picture is worth a thousand words, so:
I use DwmExtendFrameIntoClientArea(this.Handle, AeroMargins); Where AeroMargins is a structure with Left, Right, Top, and Bottom properties. It works fine on Vista, Windows 7, and Windows 8 and 8.1.
However on Windows 10, there is a change in the window background where Left and Right margins end. It's exactly the same code that produces different results on Windows 10. Some colors (that you can pick in Settings, Personalization, Colors) are less obvious than others, but all show this defect. Has anything changed in Windows 10 that the old DWM code is not valid anymore?
I'm using the classic DrawString method to output text in a WinForms app. A typical call look like this:
g.DrawString(text, font, brush, new Rectangle(x, y, width, height), stringFormat);
If stringFormat.Trimming equals StringTrimming.EllipsisCharacter, the text suddenly "jumps" 1 pixel up if it is clipped and the rectangle of the same left/top/height is used:
This happens for many standards fonts like MS Sans Serif or Courier New, but does not happen for others like Segoe UI. And what is more strange, we can avoid this effect if we specify StringFormatFlags.DirectionRightToLeft for stringFormat.FormatFlags.
Is it a known issue of GDI+, and is there a workaround for that?
P.S. Tested all this in Win 8.1 Pro 64-bit, in an app compiled for .NET 4.0.
I made my first WPF app and brought it to work to use. My work computer's monitor is a maximum of 1680 x 1050, 96 dpi, Win 7 system, whereas my home computer is 1920 x 1080p, 96 dpi, Win 7.
The app doesn't display correctly on the work computer. Text is cluttered and 'doesn't fit' where it should, etc (the problem seems to be with the font sizing, only). I'm reading that I did just about everything wrong in regards to making the app support multiple resolutions, so I certainly have some reworking to do.
The odd thing is the work computer appears incorrectly at all lower resolutions, whereas my home computer appears correctly at all lower resolutions, including 1680 x 1050 - meaning I can't duplicate the problem on the computer I am working on the app on.
Here is the font I am using since that seems to be where the problem may lie:
<Setter Property="FontFamily" Value="Linux Libertine G"/>
What other factors could be affecting the appearance of my app besides resolution?
I've got a C# 3.0 Windows Forms app built with VS2008 (previously ported from C# 1.1) that looks fine on a WinXP 32bit PC but has jacked proportions on Win7 64bit laptop.
I'm finding references to the lack of support on Win7 for Tahoma 8, which the app uses. Do I need to redesign my dialog using Tahoma 9 to get it to display well on all 3 OSes?
Here are my initial measurements (cm) of a group box containing radio buttons and a button:
OS, Resolution, GroupBox HxW, RadioButton HxW
XP, 1024 x 768, 7.5 x 6.75, 0.75 x 4.4
7, 1024 x 768, 6.8 x 6.3, 0.8 x 5.0
7, 1680 x 1050, 4.9 x 4.5, 0.55 x 3.5
The problem is basically that on the different OS's, the group box has its proportions changed differently than the radios it contains, such that radios and labels that fit fine in the group box in XP run out of bounds (both x & y axis) on 7. Similarly, the text on the button grew more than the button. This happens even when I dial down the 7 box's resolution to match the XP box. The GroupBox's font is larger than that of the radios, but even when I made them equal I saw no improvement.
I think it has something to do with the fact that the application was originally created with an older version of C# and then ported. I say this because I just created a new (empty) Windows forms project using VS2008, and for every control in my app that isn't displaying correctly on win7, when I copy that control to the new app and run it on win7 it resizes correctly. There must be some high level property in the app that the controls are inheriting.
What causes this and what can I do about it?
Thanks in advance.
The main form's 'AutoScaleMode' was set to 'Font'. Setting it to 'DPI' fixed it (although that created other problems due to the code not anticipating being resized on startup...null refs, but I can deal with those).
Tergiver gets double credit for pointing me to the form's property sheet and for me taking this long to notice the obvious property :)
Does anyone know what measurement units are used by Silverlight/WFP? For example, if I create a new button and set its height to 150, is that 150 pixels? points? millimeters?
I design all of my applications in Adobe Illustrator before proceeding to code, and although I try and set everything to the dimensions in my Illustrator file, the Silverlight application is usually larger.
Although in theory, 1 unit in WPF is 1/96th of an inch, that's frequently not the case in practice.
It's usually true when printing. But it's rarely true on screen. The reason for this is that Windows almost always knows the true resolution of a printer, but almost never knows the true resolution of a screen.
For example, I have three screens attached to my computer. Windows thinks that they all have a resolution of 96 pixels per inch. Actually they don't. Two of them have a resolution of 101 pixels per inch, and one has a resolution of 94 pixels per inch. (Why? Because Windows has no way of working the true resolutions out for itself, and I haven't told it. The fiction that they all have the same pixel size is close to the truth, and turns out to be a convenient fiction.)
So when I create, say, a Rectangle in WPF with Width and Height both set to 96, the size of the Rectangle actually depends on which screen it appears on. Windows thinks that all 3 screens have a resolution of 96 pixels per inch, and so it'll render the rectangle as being 96 pixels tall and wide no matter which screen it appears on. That'll make it appear 0.95 inches tall on two of the screens, and 1.02 inches tall on the third.
So in practice, that means that units in WPF on my computer here are either 1/100th of an inch, or 1/94th of an inch in practice. (I.e., in practice, the size of 1 unit in WPF is exactly the size of 1 pixel on my particular setup, no matter how big the pixels happen to be.)
I could change that. I could reconfigure Windows - I could tell it the actual resolution of all 3 screens, in which case the nominal and actual WPF unit sizes would coincide. Or I could lie - I could claim that I have 200 pixel per inch screens, in which case everything would be massive...
The basic problem here is that there is no standard way for the computer to discover the true size of the physical pixels on the screen, and very few people bother to set it up by hand. (And in fact you can cause problems by configuring it 'correctly', because a lot of software doesn't behave correctly when you do.) So the majority of Windows computers don't report physical pixel sizes correctly to WPF - they can't because they don't know.
Consequently, there's no reliable answer to the question - 1 unit in WPF could be pretty much anything on screen. (In practice, most of the time, it turns out to be 1 pixel, simply because if you don't tell Windows anything else, it defaults to assuming that your screens have pixels that are 1/96th of an inch tall, which is the same as 1 WPF unit. And for most desktop screens, that's actually quite likely to be a good guess. But this isn't universal. On systems configured with what used to be called 'large fonts' for example, you'll find a different nominal screen resolution, and 1 WPF unit will correspond to slightly more than 1 physical pixel - about 1.2 in fact.)
With printers, it's all much more predictable. Printers are invariably able to report their resolutions correctly. So if you print something that's 96 WPF units high, you can be confident that it will be 1 inch high.
MSDN's documentation states that the FrameworkElement.Height property (for Silverlight) refers to:
The height, in pixels, of the object
However, for WPF it refers to:
a device-independent unit (1/96th inch) measurement
So, to answer your question... pixels for Silverlight, device-independent units for WPF.
The documentation refers to Pixels, however these are Pixels where there are 96 such pixels per inch. A line of Width 96 when display on a 120 DPI display will be 120 actual device pixels. Similarly such a line drawn on a printer output which has 600 DPI will be 600 pixels long.
They are Device Independent Units.
You can find more detailed explanations here.