• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Xcode & Visual C++
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Xcode & Visual C++


  • Subject: Re: Xcode & Visual C++
  • From: David Young <email@hidden>
  • Date: Fri, 6 Jan 2006 15:51:19 -0800

On Jan 6, 2006, at 11:51 AM, Ladd Van Tol wrote:
Because of these, and other problems, it is far faster and easier for me to write a separate Cocoa UI for the Mac version of a product that to try to make the GUI cross-platform. Additionally, the Cocoa UI will look better and perform better than the Qt equivalent.

I'm sure Qt can draw buttons about as reasonably fast as the next UI framework, but whether or not drawing is "emulated" or calling out to native code is somewhat irrelevant so long as it continues to behave differently than applications developed natively for the Mac, be they Carbon or Cocoa applications. I don't think it's a question of technology so much as it's a question of priorities.


My theory is that part what you get when you invest in building a Cocoa or native Carbon application is the attention to detail of someone who's familiar with the Aqua interface. This attention to detail is something that can't be provided by an abstraction layer, it requires someone to actually spend time using the application and changing things so that its interface will fit in well with the rest of the Mac experience. I'm sure that given infinite time, an experienced Mac-first developer could produce a reasonable looking interface using Qt. But, unfortunately, this isn't usually what happens, and while just having someone press "build for Mac OS X" is going to always be the easiest, cheapest solution, quality will always suffer, and you'll get a second-class interface.

Still, for many companies, this is good enough; there's something special enough about their application, or it's trendy enough that people will use it despite the schizophrenic interface. For the others, the initial decision to put cost and convenience ahead of quality isn't one that's easily reversed, and opens the door for companies who choose native technologies to beat them in the marketplace.

(Hey! This thread has very little to do with using Xcode anymore.)

--dave

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


References: 
 >Re: Xcode & Visual C++ (From: David Michael Bryson <email@hidden>)
 >Re: Xcode & Visual C++ (From: Trenton Schulz <email@hidden>)
 >Re: Xcode & Visual C++ (From: Ladd Van Tol <email@hidden>)

  • Prev by Date: Re: Avoiding destructors while still calling atexit handlers
  • Next by Date: i386 build failing...but not selected
  • Previous by thread: Re: Xcode & Visual C++
  • Next by thread: Re: Xcode & Visual C++
  • Index(es):
    • Date
    • Thread