Mailing Lists: Apple Mailing Lists
 Image of Mac OS face in stamp
Re: trapping system wide input events
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: trapping system wide input events

Jim Hagen wrote:
| It's bad enough that we have Carbon apps, IMHO...

I worried:
| Have we not had enough flame wars yet?

Jim Hagen wrote:
| Sorry. I have nothing in particular against Carbon library calls, where
| they work and are used appropriately. I should not have included the
| statement below without being more specific about which apps give me a
| headache. I recognize that almost any business, and many home users,
| would not be able to use OS X without the availability of Carbonized
| applications and the Classic environment, and as such I am very
| thankful for both. Apple has done amazing work on Carbon and Classic,
| and I expect them to get better and better.

I'm relieved. Until the statement about Carbon, you'd seemed like a reasonable, sane person. I'm glad to hear that the statement was but a momentary aberration.


| My distaste for Carbonized applications is based on my experience
| supporting a small number of OS X computers, and is of course nothing
| more than a simple personal opinion. Easily 80% of all problems we've
| seen since migrating to OS X revolve around two major commercial
| applications, both of which are Carbonized apps ( even if they no
| longer run under OS 9, they still make use of Carbon in major ways ).
| They exhibit behaviors and introduce instabilities to the system like
| no other programs. It's hard to tell if it's the applications at fault,
| or the Carbon libraries, or a mixture.

Me, I'd guess the applications, if only on the standard debugging principle that any given bug is more likely to be in the application than in the library.


| As one example, I've never seen
| a Cocoa application show a "Not enough memory" dialog, which is nearly
| common to see in these two Carbon applications...

I can write one for you if you like. :)

If something as routine as that message is in those applications were caused by the Carbon API, I'd expect to see the same problem appear in many other Carbon-based applications. I don't recall seeing much in the way of complaints about that, however. (Asking on the carbon-dev mailing list would probably be instructive.)

Also, blaming Carbon for the failings of two applications--however aggravating those failings are--seems awfully reminiscent of the common novice lament: "my program doesn't work, and I'm sure the bug is in the system", and I'm not used to seeing experienced programmers expressing similar sentiments.


| and what the heck does that mean in OS X, "Not enough memory",
| especially when the behavior is such that you can ( usually ) close
| the dialog and just keep working ?

I think it means "this application has a bug." Memory on OS X is, for most purposes, unlimited (as you clearly know, or you'd not be asking "what the heck does that mean?"). I'd be very surprised if the Carbon Memory Manager doesn't attempt to use as much as it can. (Indeed, I'd be surprised if, at bottom, Cocoa and Carbon don't both rely on malloc to do the actual memory allocation.) That you can ignore the message with no consequences strongly suggests that memory *isn't* actually exhausted, and that the application is simply reporting spurious errors, which is hardly Carbon's fault.


| Clearly it's possible to write a poorly-performing, buggy application
| with any set of tools, so it's very likely that my opinion of
| Carbonized apps has been unfairly prejudiced by exposure to two
| applications which perhaps were ported as quickly as possible without
| getting a decent code review and good QA cycle. I suppose I can think
| of Carbon applications which have never given us trouble,

And it is *precisely* the applications that give you trouble that you're going to notice; the ones that sit there and do what they're supposed to just get taken for granted, whatever API they use.


| anyway, this is way off-topic. Sorry. Glen, please feel free to ignore
| the stuff near "IMHO", that's why people use those silly letters. I'll
| be sure not to mention my feelings about Carbon again on this list.

If *everyone* ignored that stuff, there'd be no problem. Unfortunately, "in my humble opinion" is all too often ironic, with precious little humility involved, so those who use it in its literal sense risk taint by association. Worse, that inconspicuous "H" tends gets overlooked, even when it's *not* ironic.

The point of my post was more to forestall the sort of argument that tends to result from such remarks. There are plenty of Cocoa advocates out there who *don't* seem aware that Cocoa and Carbon are just items in the programmer's toolkit, and who tend to get, shall we say, excessively fervent in their advocacy. (For some reason, the Carbon fans don't seem to get so passionate about it. Or perhaps they're just not as public about it.) For you, the words may have been no more than an overly-hasty aside. For others, they could all too easily become a battle cry. Neither Cocoa nor Carbon is perfect, and a sober, rational consideration of the differences between them is fine (albeit very definitely off-topic here, except perhaps as they relate to doing JNI stuff). But I've had quite enough of the religious wars, and hoped to prevent that one.

Glen Fisher
_______________________________________________
java-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/java-dev
Be sure to read the FAQ http://developer.apple.com/java/faq/ before posting
Do not post admin requests to the list. They will be ignored.
References: 
 >Re: trapping system wide input events (From: Jim Hagen <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2011 Apple Inc. All rights reserved.