3 ms·

Our opinions on this specific issue: http://www.alertdebugging.com/2009/11/04/mockingbird-cappuccino-and-what-really-matters/ http://www.alertdebugging.com/2009

• alextgordon 16y ago
  I did read that and I think you're missing a key distinction. Custom controls aren't wrong. There's a very limited number of native controls, but a seemingly infinite number of ways to display and interact with data. So all but the most simple of apps are going to require custom controls. Some apps take this further and replace every control in the application with custom one. Notably Logic/Aperture, Final Cut, a great deal of iPhone apps and all games. Done well, this can give a sense of context to the user (especially important in games) and make it look cool. What I object to is requiring a full replacement of native controls because the application was written using Cappuccino. This is arbitrary: there's no reason why a temperature converter app written in Cappuccino should look any different to the exact same app written in Cocoa. There's no benefit of context to the user - the toolkit used is merely an implementation detail. Meanwhile, what would be minor design irritations in a single app are magnified to become major design flaws when they affect all Cappuccino apps. I'm not going to pick on specific things since it's beta software, but if you're going to replace everything, you've got to be absolutely sure it's implemented immaculately. Otherwise overall usability is going to suffer. It seems it would be easier to go with native controls and avoid the fuss.