Apple, please fix Cocoa

strobe

Puny Member
I have yet to find a Cocoa app which doesn't drive me up the wall. Clearly there are some implicit Mac HI conventions which have not found their way into the Aqua HI Guidelines. For example:

• When selecting text to the right or down, the trailing hard return (linefeed in UNIX) shouldn't be selected. The Mac behavior of only selecting the trailing linefeed when moving to the next line (or triple-clicking) is by far superior. I nearly never want the trailing linefeed, and when I do I add it after pasting. This problem is only compounded when trying to move selections.

• The delay when trying to drag+drop text makes absolutely no sense. It pisses off not only those who want drag+drop text, but those who do not! Either have it on or off.

• Most Cocoa apps assume a file's path is constant. This logic is opposite of Carbon apps and inferior. When Apple depricated functions using paths long ago it was a huge human interface boon since the user no longer had to keep track of which files were open by what apps. Instead the user could move and rename files/folders/apps willy nilly without doing a census on what files/folders/apps were open. Apple does provide functions in the closed-source version of CoreFoundation to convert POSIX file paths to FSRefs and back, but Cocoa developers aren't using them. They could also use NSDocument for all file I/O, but often they are fetching the file paths from these objects and using them elsewhere in a manner other than temporary. The behavior of commands like "Save" and "Save As..." are based on the implication that file paths are constant or variable.
 
Originally posted by strobe
Apple does provide functions in the closed-source version of CoreFoundation to convert POSIX file paths to FSRefs and back, but Cocoa developers aren't using them. They could also use NSDocument for all file I/O, but often they are fetching the file paths from these objects and using them elsewhere in a manner other than temporary. The behavior of commands like "Save" and "Save As..." are based on the implication that file paths are constant or variable.

And this is where the real problem comes to light: Cocoa is fine, Cocoa coders are not. keep in mind that former Classic programmers are probably mostly sticking to Carbon because it's more like what they're used to, and Unix coders are going to use methods they are used to, so it will be a while before there are lots of good Cocoa programmers (good in the sense that they are completely familiar with using the Cocoa environment and take advantage of ALL its great features). Be patient....within a year or so we should see a lot more Cocoa apps, including Carbon apps being converted to Cocoa.
 
Cocoa is NOT fine! How does one solve these problems while using Cocoa? You don't, instead you have to use non-Cocoa APIs.

This is a definite problem with the Cocoa API
 
Back
Top