<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><font face="Helvetica" size="3" style="font: 12.0px Helvetica">> The general problem is, developers want a nice, common API; but users  </font></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><font face="Helvetica" size="3" style="font: 12.0px Helvetica">> want software that integrates nicely into their OS and its particular  </font></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><font face="Helvetica" size="3" style="font: 12.0px Helvetica">> look-and-feel. So either you use cross-platform toolkits, limiting you  </font></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><font face="Helvetica" size="3" style="font: 12.0px Helvetica">> to a common denominator (think AWT), or you make lots of costly  </font></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><font face="Helvetica" size="3" style="font: 12.0px Helvetica">> special solutions to make your users happy.</font></div><div><br></div><div><div>Nice summary of what is commonly thought to be the problem, but I'm not sure you make your case with the examples you cite:</div><div><br></div><div>> On Mac OS X some issues that come to mind are that the menu deviates from most other platforms in not being window-specific, </div><div><br></div><div>Actually, the Mac menu bar _is_ window-specific. It only displays the menu of the application that has the focus. OS X sacrifices a bit of screen real estate for this, but the alternative is to give up screen real estate for every window that has a menu, as in Windows. I'm hard pressed to come up with a justification for the Windows approach. Maybe that's why Windows used such a small font for menus, to save screen area. The only benefit that I can see is that you can see the top-level menu bar items (File, Edit, etc.) for windows that don't have the focus (and presumably are not covered by other windows). Not really very useful information.</div><div><br></div><div><br></div><div>> it prefers window-attached sheets over application-modal dialogs, </div><div><br></div><div>The last time I checked, I couldn't find very many apps that used sheets. In any case, OS X doesn't "prefer" modal sheets over modal windows. I haven't seen anything in Apple's docs that suggests sheets are preferable. And I'm not sure why implementing a modal form as a sheet vs. a window would make much difference in the design of the widgetset.</div><div><br></div><div><br></div><div>> control layout is different everywhere, menu naming/translation deviates, etc.</div><div><br></div><div>Isn't this really up to the app developer, not the widgetset? If you're using absolute postioning of individual controls, are you sure you want what you're implying: that the widgetset moves things around for you?</div><div><br></div><div>Thanks.</div><div><br></div><div>-Phil</div><div><br></div></div>
</body></html>