<strong>I agree with your thoughts, Amorph, but it makes you wonder why they would (or so the rumor claims) go through the trouble of re-writing it only to replace it with frameworks and services later? I guess that kind of idea must be quite a ways away, if it's even being worked on at all.</strong><hr></blockquote>
First, you rework it just to get rid of the totally custom, really wonky class library that it used for its GUI and event handling, which obviously made porting to OS X a nightmare.
Then, you break it up into frameworks, services and separate applications that depend on them, and reengineer a user interface that sits on top of all of them and gets them to appear to the end user as a single, highly integrated office app.
The great folly that Microsoft has perpetuated is the absurd idea that an app has to be integrated at the code level to seem integrated to the end user. That's absolutely false, and stupid. The two issues are completely orthogonal. Apple is definitely heading in the opposite direction: lots of discrete bits of code working together seamlessly. If they don't get all the way there with AW 7, they'll at least have done enough work to make the totally modular AW 8 take less than 3 years to implement.
So you think they are bundling developing a few frameworks and making one application that brings them all in one place. Is that the main job of interface builder? How are frameworks related to Cocoa nibs, objects and such? Should we assume that these would be closed framworks, that third parties couldn't make use of them? For example, could an application like Create incorporate the presentation module/framework into it, like how it adopts the standard Cocoa word processing module/object class for text?
I've said it before, and I'm not afraid to say it again: OpenDoc.
All this stuff that Apple couldn't get to work the first time around seems to be popping out of the woodwork, albeit through a completely different framework.
Take one little application that does one job incredibly well, bundle it with a bunch of other little applications that do one job each incredibly well, give it a coherent interface and usability model and you get something that isn't a million miles away from the sort of interoperability we're seeing between Mail/Address Book/iCal...
Apple just needs to buy Omnigroup and get it over with. That would give them an upcoming top-flight browser, plus a bunch of neat tools that can be integrated into the next Appleworks. Omnigroup is second only to Apple in making high-quality Cocoa apps.
<strong>Apple just needs to buy Omnigroup and get it over with. That would give them an upcoming top-flight browser, plus a bunch of neat tools that can be integrated into the next Appleworks.</strong><hr></blockquote>
/ahem
Omnigroup doesn't make just apps like OmniWeb and OmniGraffle.
Comments
<strong>I agree with your thoughts, Amorph, but it makes you wonder why they would (or so the rumor claims) go through the trouble of re-writing it only to replace it with frameworks and services later? I guess that kind of idea must be quite a ways away, if it's even being worked on at all.</strong><hr></blockquote>
First, you rework it just to get rid of the totally custom, really wonky class library that it used for its GUI and event handling, which obviously made porting to OS X a nightmare.
Then, you break it up into frameworks, services and separate applications that depend on them, and reengineer a user interface that sits on top of all of them and gets them to appear to the end user as a single, highly integrated office app.
The great folly that Microsoft has perpetuated is the absurd idea that an app has to be integrated at the code level to seem integrated to the end user. That's absolutely false, and stupid. The two issues are completely orthogonal. Apple is definitely heading in the opposite direction: lots of discrete bits of code working together seamlessly. If they don't get all the way there with AW 7, they'll at least have done enough work to make the totally modular AW 8 take less than 3 years to implement.
I hope that makes sense.
So you think they are bundling developing a few frameworks and making one application that brings them all in one place. Is that the main job of interface builder? How are frameworks related to Cocoa nibs, objects and such? Should we assume that these would be closed framworks, that third parties couldn't make use of them? For example, could an application like Create incorporate the presentation module/framework into it, like how it adopts the standard Cocoa word processing module/object class for text?
All this stuff that Apple couldn't get to work the first time around seems to be popping out of the woodwork, albeit through a completely different framework.
Take one little application that does one job incredibly well, bundle it with a bunch of other little applications that do one job each incredibly well, give it a coherent interface and usability model and you get something that isn't a million miles away from the sort of interoperability we're seeing between Mail/Address Book/iCal...
<strong>Apple just needs to buy Omnigroup and get it over with. That would give them an upcoming top-flight browser, plus a bunch of neat tools that can be integrated into the next Appleworks.</strong><hr></blockquote>
/ahem
Omnigroup doesn't make just apps like OmniWeb and OmniGraffle.
They do also consulting.
/ahem