Windows L&F Bugs: Part 2
Welcome back to the Windows Look and Feel Show!
In this segment we'll dive right into some of the bugs directly. In this series I won't cover all of the bugs because some of them involve structural changes that didn't directly fix visible bugs. For example, the XPStyle class was significantly changed by adding enum support. Enums let us more closely model Microsoft's UXTheme API and it's list of part constants. Also, I'm only covering bugs that were fixed. There are quite a few bugs which were closed as not reproducible or no longer a bug because they were fixed by another fix or simply can't happen any more because of other code changes under the hood. With that in mind, let's take a look at a few.
In Windows, but not in some other operating systems, you can highlight a disabled menu item. This means when you move the mouse over that item it will have a rollover, though you still cannot select it (because it's disabled). This is especially important for keyboard users because without it the keyboard focus would appear to go off into oblivion when you encounter a disabled menu item. This fix also affects the high-contrast modes which are important for disabled users (who are more likely to be using keyboard only navigation).
While this fix is only for Windows, I implemented it in a way that lets us use it in any Look and Feel by using a defaults property (MenuItem.disabledAreNavigable). In general we try to fix things this way so that future improvements will be easier and safer to implement.
The selected color of the actual check and circle of the checkbox and radiobuttons are off slightly. They should be black instead of gray. Actually, they are foreground color of the component, rather than the darkShadow color. For most themes you won't notice this bug in highcontrast modes like green on black your checkboxes could completely disappear!
Can you see the difference?
This is another minor one, but even the little things matter. The slider thumb of JSliders has a slight rollover effect on XP. Now we support this. (Eventually this will be animated on Vista as well).
We originally removed the focus rectangle on buttons because in Windows you don't have them in toolbar buttons. That's not because the don't have them, however, but because toolbar buttons aren't supposed to be focusable at all. You can't navigate between them with the keyboard, for example. A properly written Swing app won't let the toolbar buttons be focusable either, however some apps do allow it. For the most part this isn't an issue. The problem arises like this: if a user starts tabbing between components and the toolbar buttons get focus then the focus rect will disappear. A toolbar button will have the focus but the user won't be able to see it. We decided that in this case native fidelity would hurt usability so we have reverted to the old behavior and now let toolbar buttons draw their focus rects (if they are focusable). You should still make sure your own toolbars aren't focusable, but if they are then it will look right.
This very subtle bug was caused by converting the alpha channel of certain icons to 1 bit transparency in certain circumstances. It causes slight jaggies on the edges of these icons. By fixing the way we load bitmaps from Windows it fixed this and several other bugs.
notice the jaggies on the 'new folder' icon.
Microsoft doesn't document how they generate grayscale versions of their icons, but it clearly wasn't how we were doing it. The solution was to create a new algorithm that more closely models the grayscale op they do, which is less linear than ours.
Look at the disabled 'up one folder' icon
The cancel button in a native file chooser doesn't have a mnemonic when you hold down the alt key. I don't know why, but it doesn't, and now neither do we.
Well, that's it for this edition. Keep trying out new Mustang builds to see if we've missed anything. Thanks!