KHTML is a rendering engine, just like Gecko. It figures out what to do with HTML. Apple had to build that up and then add Safari on top.
OpenOffice is a whole different beast. It has a full blown GUI. And as far as I can tell, one that isn't easily seperated from the code. (I haven't checked in the project in a long time, since there are no new Mac OS X compatible releases for a while, but I'm getting the impression their making massive changes in 2.0 to allow for better "cross-GUI" work.) Still, Apple shouldn't get involved in this project.
Another thing comes to mind. The license on the Gecko code allows you to copy code directly out of it. Apple could possible save some reverse engineering time if OO were like that. (Obviously, check the facts on that as I have not the time, and it's been a while).
And as for OpenDoc. I think the power if there. PDFKit, Web Kit, Core Image, Core Video, Core Data, Image I/O and the other dozens of "really cool stuff" I've seen, allow for an architecture of applications and, really, documents that have immersive content. Whether it will be there now or when it will show up? No idea.
KHTML wasn't the best thing in the world either, but Apple started with it as a base, and worked hard on it and it became Safari.
KHTML was relatively small and clean (that's why they chose KHTML over the more complete Gecko). OpenOffice is the farthest possible thing from small or clean.
An office app pulls many things together. I see Apple going with lots of little open source and Apple proprietary libraries under a common GUI. Far better that than trying to wrangle a massive, self-contained codebase into shape.
If the OpenOffice developers are essentially rewriting OO just to make it cross-platform, what would Apple have to do to make it a robust OS X application?
If the OpenOffice developers are essentially rewriting OO just to make it cross-platform, what would Apple have to do to make it a robust OS X application?
Use the OASIS approved, going to be ISO standard, blessed by the EU, and used in more desktops than there are Apple machines file format in their own apps.
Use the OASIS approved, going to be ISO standard, blessed by the EU, and used in more desktops than there are Apple machines file format in their own apps.
You don't have to convince me to support file format compatibility. I'm more concerned with the other 6 billion lines of never-meant-to-run-on-a-Mac spaghetti code.
Use the OASIS approved, going to be ISO standard, blessed by the EU, and used in more desktops than there are Apple machines file format in their own apps.
They don't need to adopt the code base to do this. In fact they could make the OO file format the native one...the specification is out there (unlike for MS Office).
Interesting... I am not looking into Mac app development anymore since I've been more into web development for the past 4 years...
But it seems pretty easy, with the Cocoa API's for text handling, to write a full blown word processor. Apple could do that pretty fast. But I still see no fit...
I use TextEdit for most of my needs. If I need something better than that, I usually go for InDesign and import the RTF text I typed on TextEdit. It's that simple...
But there's something Apple could do, and the API's for that are all there too:
A PHOTOSHOP KILLER!!
That would be awesome!
Photoshop is getting stale. It's meant to be a "does-it-all" piece of software that is closer to bloatware than anything else. It's like MS Word for graphics. I know it's the de-facto standard, but it's so processor- and memory-hungry that you need a dual G5 to use it decently, even for a web layout!
Apple should write a Photo Studio Pro to match iPhoto, just like Final Cut matches iMovie (I mean, a "pro app" and "iApp" match). With a modular architecture that makes possible for the user to have the right app for his needs.
Just imagine: I don't do web; only print media! OK, you can just disable the web module and you won't have those web palletes, save for web, slices and stuff in your face.
Then I think Apple could go and kill Macromedia as well with a Flash-authoring app. Flash has a terrible interface and all kinds of problems on the Mac. Seems like Macromedia couldn't care less about the Mac platform.
With the knowledge Apple has on its own API's, it should be relatively easy for them to release killer-apps.
Well, I'll add this re: automator. I'm a bit surprised some of this, at least some form of batch processing isn't being put into the Finder and the other respective apps instead. I guess, for that matter, it was a bit curious that Spotlight was given its own result windows rather than simply calling up the Finder. Maybe it's just a first step, or the structure of creating these Automator actions prevents this kind of integration. Anyway, it would be nice, for example, to change the names on a bunch of files in the Finder without having to leave that environment. Seems like a natrual extension of the basic "solo" commands. Maybe the implementation is too complex to shoehorn into these apps? Just curious.
Well, I'll add this re: automator. I'm a bit surprised some of this, at least some form of batch processing isn't being put into the Finder and the other respective apps instead. I guess, for that matter, it was a bit curious that Spotlight was given its own result windows rather than simply calling up the Finder. Maybe it's just a first step, or the structure of creating these Automator actions prevents this kind of integration. Anyway, it would be nice, for example, to change the names on a bunch of files in the Finder without having to leave that environment. Seems like a natrual extension of the basic "solo" commands. Maybe the implementation is too complex to shoehorn into these apps? Just curious.
Why would it belong in Finder? If anything, Apple has offloaded a great deal of Finder's old functionality already (for example, many Apple Events sent to Finder just get forwarded to System Events, an app that runs in the background), and focused on its mission as an interactive file browser.
Any kind of batch work is a different thing altogether, and from reading the AppleScript Users list and lurking in various forums it seems that if you want to do batch processing you want to do batch processing, and the applications involved are subordinated as tools. If you use GraphicConverter for batch work, for instance, it will cheerfully take over the job of moving and renaming and badging files in bulk, just because that's a necessary part of the job you need GC for in the first place.
So I'm not surprised that Automator appears to be one-stop shopping for batch processing in OS X. If the projects you'd like to use Automator for involve file processing, you'd want Automator to be able to process the files, after all.
Just trying to play devil's advocate. That, and trying to get back on the Automator track.
As soon as you start talking about connecting actions among various apps, the Finder integration assumption falls apart. And, after all, that's Automator's real strength and its almost-holy grail quality. I brought it up because I have been asking for the ability to do simple batch changes to file sin the Finder for along time now, things like renaming a bunch of files, which required silly Applescripts and will even now. Automator really goes above and beyond that role, but it's still kinda funny that you can't easily add a suffix to a bunch of files and other rather routine operations. It's just that, I suppose like other oft-requested features for the OS, Apple decided to skip that meal and go for the big game instead.
In reality, I think that the decision to go outside and beyond the Finder speaks volumes about how Apple plans the future role of the Finder. The decision to have Spotlight open its own windows instead of tapping on the shoulder of the Finder reinforces my feeling that the Finder is quietly, slowly being pushed out of the center of the user experience.
Anyone see this as bringing more potential to virus writers? "Check out this bad ass automation script for automator"....
Delete this, send me this, etc...
Just wondering.
AppleScript is a much better avenue for this sort of thing... but there is the problem with both that there is no good way to spread. That is one of the maim reasons why there are no viruses on MacOS X, the security model was better setup to begin with, and most of the routes are turned off my default, or require passwords.
Comments
OpenOffice is a whole different beast. It has a full blown GUI. And as far as I can tell, one that isn't easily seperated from the code. (I haven't checked in the project in a long time, since there are no new Mac OS X compatible releases for a while, but I'm getting the impression their making massive changes in 2.0 to allow for better "cross-GUI" work.) Still, Apple shouldn't get involved in this project.
Another thing comes to mind. The license on the Gecko code allows you to copy code directly out of it. Apple could possible save some reverse engineering time if OO were like that. (Obviously, check the facts on that as I have not the time, and it's been a while).
And as for OpenDoc. I think the power if there. PDFKit, Web Kit, Core Image, Core Video, Core Data, Image I/O and the other dozens of "really cool stuff" I've seen, allow for an architecture of applications and, really, documents that have immersive content. Whether it will be there now or when it will show up? No idea.
Originally posted by FormatC2
KHTML wasn't the best thing in the world either, but Apple started with it as a base, and worked hard on it and it became Safari.
KHTML was relatively small and clean (that's why they chose KHTML over the more complete Gecko). OpenOffice is the farthest possible thing from small or clean.
An office app pulls many things together. I see Apple going with lots of little open source and Apple proprietary libraries under a common GUI. Far better that than trying to wrangle a massive, self-contained codebase into shape.
If the OpenOffice developers are essentially rewriting OO just to make it cross-platform, what would Apple have to do to make it a robust OS X application?
Originally posted by Louzer
Which indicates what they should really do: Dump Aqua and implement a kick-ass build of KDE for Darwin!
5 bonus points for living in a warped fantasy.
Originally posted by Amorph
If the OpenOffice developers are essentially rewriting OO just to make it cross-platform, what would Apple have to do to make it a robust OS X application?
Use the OASIS approved, going to be ISO standard, blessed by the EU, and used in more desktops than there are Apple machines file format in their own apps.
Originally posted by stupider...likeafox
Use the OASIS approved, going to be ISO standard, blessed by the EU, and used in more desktops than there are Apple machines file format in their own apps.
You don't have to convince me to support file format compatibility. I'm more concerned with the other 6 billion lines of never-meant-to-run-on-a-Mac spaghetti code.
Originally posted by stupider...likeafox
Use the OASIS approved, going to be ISO standard, blessed by the EU, and used in more desktops than there are Apple machines file format in their own apps.
They don't need to adopt the code base to do this. In fact they could make the OO file format the native one...the specification is out there (unlike for MS Office).
I don't mind seeing Apple do basically the same thing, competition is good
But it seems pretty easy, with the Cocoa API's for text handling, to write a full blown word processor. Apple could do that pretty fast. But I still see no fit...
I use TextEdit for most of my needs. If I need something better than that, I usually go for InDesign and import the RTF text I typed on TextEdit. It's that simple...
But there's something Apple could do, and the API's for that are all there too:
A PHOTOSHOP KILLER!!
That would be awesome!
Photoshop is getting stale. It's meant to be a "does-it-all" piece of software that is closer to bloatware than anything else. It's like MS Word for graphics. I know it's the de-facto standard, but it's so processor- and memory-hungry that you need a dual G5 to use it decently, even for a web layout!
Apple should write a Photo Studio Pro to match iPhoto, just like Final Cut matches iMovie (I mean, a "pro app" and "iApp" match). With a modular architecture that makes possible for the user to have the right app for his needs.
Just imagine: I don't do web; only print media! OK, you can just disable the web module and you won't have those web palletes, save for web, slices and stuff in your face.
Then I think Apple could go and kill Macromedia as well with a Flash-authoring app. Flash has a terrible interface and all kinds of problems on the Mac. Seems like Macromedia couldn't care less about the Mac platform.
With the knowledge Apple has on its own API's, it should be relatively easy for them to release killer-apps.
Cheers,
_iCeb0x_
Um, but wasn't this thread meant to be about Automator?!
Jimzip
Originally posted by Jimzip
Um, but wasn't this thread meant to be about Automator?!
Kinda shows what Macusers' priorities are, doesn't it?
Now, as for what Apple's priorities are....
Originally posted by Jimzip
Um, but wasn't this thread meant to be about Automator?!
Just look what happens when Apple leaves one its important consumer applications waiting in limbo for nearly four years.
Madness!
Originally posted by Jimzip
Um, but wasn't this thread meant to be about Automator?!
Yes. Automator is cool.
Now back to that Apple office suite/photoshop killer...
Originally posted by BuonRotto
Well, I'll add this re: automator. I'm a bit surprised some of this, at least some form of batch processing isn't being put into the Finder and the other respective apps instead. I guess, for that matter, it was a bit curious that Spotlight was given its own result windows rather than simply calling up the Finder. Maybe it's just a first step, or the structure of creating these Automator actions prevents this kind of integration. Anyway, it would be nice, for example, to change the names on a bunch of files in the Finder without having to leave that environment. Seems like a natrual extension of the basic "solo" commands. Maybe the implementation is too complex to shoehorn into these apps? Just curious.
Why would it belong in Finder? If anything, Apple has offloaded a great deal of Finder's old functionality already (for example, many Apple Events sent to Finder just get forwarded to System Events, an app that runs in the background), and focused on its mission as an interactive file browser.
Any kind of batch work is a different thing altogether, and from reading the AppleScript Users list and lurking in various forums it seems that if you want to do batch processing you want to do batch processing, and the applications involved are subordinated as tools. If you use GraphicConverter for batch work, for instance, it will cheerfully take over the job of moving and renaming and badging files in bulk, just because that's a necessary part of the job you need GC for in the first place.
So I'm not surprised that Automator appears to be one-stop shopping for batch processing in OS X. If the projects you'd like to use Automator for involve file processing, you'd want Automator to be able to process the files, after all.
As soon as you start talking about connecting actions among various apps, the Finder integration assumption falls apart. And, after all, that's Automator's real strength and its almost-holy grail quality. I brought it up because I have been asking for the ability to do simple batch changes to file sin the Finder for along time now, things like renaming a bunch of files, which required silly Applescripts and will even now. Automator really goes above and beyond that role, but it's still kinda funny that you can't easily add a suffix to a bunch of files and other rather routine operations. It's just that, I suppose like other oft-requested features for the OS, Apple decided to skip that meal and go for the big game instead.
In reality, I think that the decision to go outside and beyond the Finder speaks volumes about how Apple plans the future role of the Finder. The decision to have Spotlight open its own windows instead of tapping on the shoulder of the Finder reinforces my feeling that the Finder is quietly, slowly being pushed out of the center of the user experience.
Anyone see this as bringing more potential to virus writers? "Check out this bad ass automation script for automator"....
Delete this, send me this, etc...
Just wondering.
Originally posted by Jay Contonio
Automator....hmmm
Anyone see this as bringing more potential to virus writers? "Check out this bad ass automation script for automator"....
Delete this, send me this, etc...
Just wondering.
AppleScript is a much better avenue for this sort of thing... but there is the problem with both that there is no good way to spread. That is one of the maim reasons why there are no viruses on MacOS X, the security model was better setup to begin with, and most of the routes are turned off my default, or require passwords.
Originally posted by Jay Contonio
Automator....hmmm
Anyone see this as bringing more potential to virus writers? "Check out this bad ass automation script for automator"....
Delete this, send me this, etc...
Just wondering.
This is exactly what I was worried about.
Jimzip