411–420 of 495 posts
Earlier quoted context omitted.
"The games at this time were all pretty good. A consumer could go out, buy a game based just on the information printed on the box, and go home and be pretty sure they'd have a good experience." Rose tinted glasses. They still managed to release buggy, downright broken software. It wasn't about quality, it was about control.
You don't achive quality without control
This is only enforceable for tools like CS5 that reverse engineered the app signing process. How could Apple distinguish binaries produced intermediaries like PhoneGap and Appcelerator's Titanium from binaries produced by native Objective C code?
Looking forward to Adobe's response. Going to wager it'll be in the form of a lawsuit, and that the FCC will get involved. Whip out the marshmallows, this should be interesting :)
As much as I dislike this particular move, and Apple's Orwellian control over their platform, bringing this to a lawsuit and getting the FCC involved would be straight-up wrong . Let the market decide this one, Adobe has no legitimate ground whatsoever to force Apple to support it. I would be hugely disappointed to see Adobe pursue this course of action, and would regard it with significantly more contempt than I cur…
Earlier quoted context omitted.
It does make a difference. Linux needs more users, both active and passive. I'm actually surprised how many people that would be the target audience for Linux have come to use OS X instead.
User interface, user interface, quality of hardware, and user interface. "Quality of hardware" boils down to user interface... just at the hardware level. Their UI ability is the secret of Apple's success. Everyone else treats UI and design like an afterthought.
> 3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).
My thought on what they probably meant:
> 3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and code written in C, C++, and Objective-C may compile and directly link only against the Documented APIs (e.g., Applications that link to UnDocumented APIs through an intermediary translation or compatibility layer or tool are prohibited).
I bet what they're trying to do is prevent intermediate tools from allowing people to "whitewash" private API access.
I say this because the interpretation everyone else is seeing in this clause is obviously a horrible position, and I just don't think that's the intent.
Time will tell!
Earlier quoted context omitted.
I honestly wonder what you mean by Alt-Tab being broken? Surely it does switch windows, doesn't it?
The stack doesn't work consistently. In the old days, when you minimised something, it always went to the bottom of the stack. (Except Excel, which had a silent entry in the stack when you had more than one document open. Outlook has been bizarre for a while, too.) In one of the NT4 service packs (I think) this changed so that if something minimised to the status bar (rather than the task bar) it worked differently.…
Earlier quoted context omitted.
They dont want anyone peeing in their pool. They purge the pornspam apps, they purge the rss-reader apps. I personally think this is a good thing, because developing a native iPhone app in C/C++/Objective-C means you will more likely have a vested interest in the iPhone/Mac platform other than to make a quick buck with a flatuence app. At the very least, you're a more dedicated developer.
"At the very least, you're a more dedicated developer" What a rose-tinted way to describe lock-in.
It was more difficult to program for Mac than for DOS. Hell I can make a decent DOS application. But in my younger years doing the same on Mac was way more troublesum.
Ok I havn't programmed Cocoa just done som experiments, made de calculator and currency converter Apple has as tutorial. And yes it simplifies a lot.
But simple programming comes with a cost in quality. Takin the step from DOS programming to program for Apples System 1-MacOS9 was huge. Eventloops, memoryheaps etc etc. Those who know programming had little problems. Those who made hello word apps had huge problems, aka me.
The greater challange there is to programming the greater programs will de creators do.
Basically, they reserve the right to ban any sort of DSL/runtime/engine application architecture. Imagine you are building adventure games (like Money Island). You'd have a game engine and a domain language in which you describe the game. The beauty of this is, you don't have to rewrite the engine every time you finish a story for a game, you just write in your DSL. The same holds for a range of other applications such as travel guides, recipes for cooking... How can you be sure where they draw the line between data and code?
Well, it probably just depends on whether it comes from an Adobe tool or not. Let's see who's next.