Kirill Grouchnikov's Blog

The default look and feel breaks visual compatibility in Mustang

One of the requirements imposed on the default Ocean theme was to Not Break Stuff. So now adjustments were made to the l&f which would have broken existing applications; the sizing of widgets is the same and everything should just work out of the box; it's just the skin of that l&f that's different (and, I think you'll agree, better) (quoting Chet's original post).

Here are the screenshots of the same exact application under Tiger 5.0_08 and Mustang 6.0_b98:

Digging in the code of the MetalLookAndFeel locates this suspicious entry:

   "PasswordField.echoChar", (char)0x2022,

which appears to be the result of fixing this bug. So, somebody suggested making this change for Metal as well, and now the default echo char is 2 pixels wider...

Don't be alarmed if one of your forms will become a little garbled :)

Comments

• For having worked with the Swing team, I am sure that such a decision has not been taken lightly. If you read the bug report, you'll see that they mention changing the echo character this in the Metal look and feel as well, and they say there's been a discussion that lead to this decision. Now, instead of being just an ass, maybe could you simply ask the reasons for this decision or even file another bug report. You are talking about a weekly build of Mustang for [whatever fits your beliefs]'s sake!

  Posted by: gfx on September 08, 2006 at 05:22 PM

• Romain,
  We are far beyond simple weekly builds. Build b98 that i mentioned is a freeze build for defect fixes (see Mark's blog for details). So, for all practical purposes we are talking about RC. And talking about "ask the reasons" - this is exactly what i'm doing with this entry. By the way, i just reread the bug report and they say that the discussion was about which character will replace asterisk (25CF or 2022) and not whether the additional two pixels per echo character will break existing layouts.

  Posted by: kirillcool on September 08, 2006 at 05:34 PM

• I'm happy this change crept in. It's shameful that anyone would write a GUI that depended on the pixel precision of the echo character in password fields.

  Posted by: goron on September 08, 2006 at 10:03 PM

• And I'm happy the change crept in. Not breaking things is a poor excuse for not ever modernizing.
  

  Posted by: sumitkishore on September 08, 2006 at 11:02 PM

• I couldn't care less myself since Ocean (and Metal for that matter) isn't the best looking Equidae out there. It's just the old Swing promise being scheduled to be broken in a few weeks.

  Posted by: kirillcool on September 08, 2006 at 11:35 PM

• 
  Hi Kirill. I'll try to provide some of the answers. First, to clear up when this was changed, I'll point out that it was in build 74. Note that we didn't take this decision lightly. Also note that this change was made as a bug fix completely separate from the Ocean theme implementation, and should not be taken as breaking the Ocean design goal.

  
  The reason we made this change is simple: From the very beginning, our internal design spec for Metal called for a bullet echo character. I do not know why it wasn't implemented that way. One of the things we figured out as part of investigating doing this for Windows was how to use the correct echo character, without clobbering what a user may explicitly set. Once this was figured out, it simply made sense to finally fix Metal and Ocean too. I think you'll agree that it looks nicer than *.

  
  I'd like to clear something up with regards to your suggestion that it could break layout of existing applications. This change only affects JPasswordFields that are initially constructed with content, as the content then dictates the size. In most cases, however, one would either create an empty password field, or a password field with a number of rows specified. This change does not affect either of these two cases. As such, I expect very few real-world layouts to be affected. Thanks!
  

  Posted by: shan_man on September 26, 2006 at 06:36 AM

This work is licensed under a Creative Commons License.