Why aren't apps taking advantage of OS X?
It's really annoying me. why aren't apps taking advantage of advanced OS X features such as sheets, native PDF, quartz, etc. I thought all of this was suppose to be free and easy to implement for developers.
If anything I would love for PDF to become the universal file format on OS X. Just think how easy everything would be if a single file was able to be opened in everything and saved in a single format.
Is it harder than they are letting on or are developers lazy?
[ 12-15-2001: Message edited by: applenut ]</p>
If anything I would love for PDF to become the universal file format on OS X. Just think how easy everything would be if a single file was able to be opened in everything and saved in a single format.
Is it harder than they are letting on or are developers lazy?
[ 12-15-2001: Message edited by: applenut ]</p>
Comments
I think the main reason that most of the OS X software isn't particularly taking advantage of OS X's under-the-hood whatnots is that it's just the first round. It's what we've been saying about the initial release of OS X: getting it working first, get it working well second. I think we'll see better understanding and utilization of Os X's technology in future versions of this software.
Also, I think lots of software doesn't need to push the envelope so to speak. Simple-simon apps are legit apps too.
Yes, the advanced features are great, but making the program work correctly in X in the first place is the top priority. Besides, initially many of the advanced features weren't available to Carbon applications...
One app I really would like that behaved like that would be a media file handler where you put a document in on one side and get a transformed document out on the other side. The app in itself did nothing more than paired the document with a tool and perhaps a planning feature or a if-then handler. The tools would be developed for it or tools already existing and providing services for the app. A couple of examples: I tell the app to open a live stream at a certaint time with RealPlayer, record it, encode it as MP3 and place the file in a certaint folder. Or if my phone rang to act as a scriptable answer machine. Or to send a mail with a certaint content to a email adress if I called it on the phone and pressed a code. And it kept all these events on a list.
If only I could download those damn developer tools from Apple (whats wrong with their servers?) I could make a dummy of it in interfaceBuilder.
BTW: Waht is sheets?
I think it's a combination of developer laziness (i.e. not using CoreGraphics text rendering and sheets and X interface elements in MS products) and also the lack of standardization across API's.
Carbon apps, even when programmed as Mach-0 and using all the X-specific tech available to them, at the current time, will not look exactly like Cocoa ones. Non-transparent sheets, services... etc. Also, as a lot of 9 apps use Geneva as their small font, and true X uses Lucida Grande, so many carbon apps won't look right without a major interface overhaul.
The one thing that really peeves me about X is that there is no true interface consistency across anything other than Cocoa Apps. I think, probably, when 9 is nothing but a memory (hopefully by this time next year) we'll be seeing a lot more mach-0, totally redesigned X interfaces, and hopefully Apple will update the carbon spec (now that 9 compatibility can be sacrificed) to make things like transparent, animated sheets, drawers, and CoreGraphics easier for developers to access and implement in their carbon apps.
It seems that originally, Apple wanted carbon to be a "bridge" and more of a temporary API. Now, it seems that Carbon needs to mature very quickly into a true X api that is 100% the equal of Cocoa: right now, it's probably about 90% there, but it still needs spit and polish. On the other hand, Cocoa needs to have some rough edges worked out on its end, too.
Basically, I think that, in about a year, X will be a very different experience altogether. Apps will look like true aqua, everything will be truely pre-emptive, (no more menu calls locking the whole app) and easily distinguishable carbon/cocoa apps will be a distant memory.
[ 12-16-2001: Message edited by: Jonathan ]</p>
[quote]Carbon apps, even when programmed as Mach-0 and using all the X-specific tech available to them, at the current time, will not look exactly like Cocoa ones.<hr></blockquote>
They'll be so close that the difference is negligible. Can you tell if Snapz Pro X is Carbon or Cocoa?
[quote]Non-transparent sheets, services... etc.<hr></blockquote>
Non-transparent sheets are hard to notice, but point taken. Services are available to Carbon. Pretty much the only major GUI element that isn't is the drawer, but that's probably coming soon.
[quote]Also, as a lot of 9 apps use Geneva as their small font, and true X uses Lucida Grande, they won't look right.<hr></blockquote>
Carbon apps can use Lucida. Look at Snapz Pro X. Or Office X's dialogs. Or the PS 7 beta.
[quote]The one thing that really peeves me about X is that there is no true interface consistency across anything other than Cocoa Apps.<hr></blockquote>
Most of the elements that people actually use are available to Carbon, developers just aren't bothering to use them. Ironically, it's some of the biggest apps that have done this the best, like Office X (generally, the palettes and windows have been done pretty well) and even the Photoshop 7 beta.
Another factor is documentation. It's not done, and there's not enough of it. This just takes time. Some of it is developer laziness, some of it isn't. Most of what is necessary is already available in Carbon, though.
The fault probably rests about 90% in developer's hands, 10% in Apple's. 10% being the minor inconstencies in APIs and the utter lack of documentation.
It's also the fact that the apps are coming from so many different sources: you've got classic mac os developers, old next-steppers, now apple-scripters, unix ports, and also people writing new apps in cocoa. I read a quote somewhere that X is truly a chameleon of OS'es... and this is probably responsible (in this early public state) for its minor inconsistencies and the shoddiness of apps.
[ 12-16-2001: Message edited by: Jonathan ]</p>
<strong>I agree with Gorgonzola.. you replied before i edited my post to correct my errors.
The fault probably rests about 90% in developer's hands, 10% in Apple's. 10% being the minor inconstencies in APIs and the utter lack of documentation.
It's also the fact that the apps are coming from so many different sources: you've got classic mac os developers, old next-steppers, now apple-scripters, unix ports, and also people writing new apps in cocoa. I read a quote somewhere that X is truly a chameleon of OS'es... and this is probably responsible (in this early public state) for its minor inconsistencies and the shoddiness of apps.
[ 12-16-2001: Message edited by: Jonathan ]</strong><hr></blockquote>
Fastest cheese-knife on the block.
And yah, I agree with you about the varied backgrounds.
you become lazy
and corrupted
and a little more corrupted
and you start to care less and less... oh shit, i've got an exam tomorrow!
Anders: is what you're talking about what Cocoa does anyway? Seems like Interface and Project Builder encourage code sharing, visual consistency and all the tools the various APIs (including AppleScript now for those translation ideas: can you say "droplet") for the developer.
<strong>The sprightliness of youth... watch when you get to college.
you become lazy
and corrupted
and a little more corrupted
and you start to care less and less... oh shit, i've got an exam tomorrow!</strong><hr></blockquote>
That is so true, man.
I think most of Mac OS X's interface inconsistencies can be attributed to lack of developer experience. People always talk about what a paragon of interface excellence that OS 9 is, but back when System 7 was around I remember a lot of apps with bizarre UI's. Perhaps they weren't as inconsistent as OS X apps are now, but System 7 developers only had one set of APIs to work with.
Applications that use advanced OS X features will soon proliferate and flourish, forcing lazy developers to start using those features if they're to compete.
HMMM! Appleworks has always been available for Windows too... I wonder if that'll continue... if it's cocoa, we know that it _could_ be ported over using the supposedly defunct YellowBox for Windows API...
HMMM!
A full Cocoa rewrite isn't unreasonable. Even AppleWorks 6 is really just the same ClarisWorks that has been with us since the very early 90's. I remember when the entire application and its support files fit on two floppies. All that versions 3 though 5 added were clipart galleries and basic internet features, while 6 was just an interface overhaul. How hard can it be to give us a nifty Cocoa version? Maybe the Omni Group would take it on...
----
If anything I would love for PDF to become the universal file format on OS X. Just think how easy everything would be if a single file was able to be opened in everything and saved in a single format.
----
The problem with PDF is that it is saved as a graphics file. PDF is basically a compressed TIFF. The search functionality therein is provided by Acrobat. When you save a text file in PDF from a print preview, it's about 90K/page. When you use Acrobat Distiller, the same file might be 8K, and it might take 24K as an MS Word file. But, if you save a webpage with several graphics as a PDF it takes up about the same 90 K as well, but only 40K as a MS archive file or 8K as a text file only without graphics.
This makes me think that OSX saves the PDF at 16 or 24 bit depth, whereas the Adobe PDF writer saves it at 8 or 4 bit depth.
Perhaps OSX should allow one to save a file as a 4 or 8 bit PDF. As it is now, a PDF is basically a nice picture with huge color depth. The is great for those of us who work mostly in non-layered graphics files, but for those of us (me) who work mostly in text files, this is very inefficient. I am currently a law student and generate several hundred pages of documents every week. MS Word takes about 16K/page, but the Preview function saves them at about 90-100K/page. After a while, this space starts to add up.
Adobe does not yet provide Distiller for OS X (it works only when booted into OS 9, and does NOT work in Classic mode). Until then, or until Apple licenses the technology from Adobe to allow the OS to make small PDFs from any file, we are probably a long way off....
<strong>As it is now, a PDF is basically a nice picture with huge color depth.</strong><hr></blockquote>
What?? <img src="graemlins/bugeye.gif" border="0" alt="[Skeptical]" /> I'm certainly no expert here, but I am quite sure that this is the opposite of what a PDF really is. I thought PDFs were files that containing vectored data, not bitmapped graphics. Isn't that why Apple made such a big deal about Quartz using PDF technology?
<img src="confused.gif" border="0">
...I'm certainly no expert here, but I am quite sure that this is the opposite of what a PDF really is. I thought PDFs were files that containing vectored data, not bitmapped graphics...<hr></blockquote>
That was certainly my understanding. While PDF's can obviously contain bitmapped data, it is more of a vector-based format.
A. PDF's save all images using Jpeg or Zip compression, not a tiff format.
B. PDF's keep everything vector if possible. If you make a vector drawing in Illustrator & save it as a PDF it will not rasterize it. Rather it will keep it in vectors which is why you can have an 8.5x11 image take up only say 50k or so (varies on depending on image). That'd never happen using a "Tiff" format, unless of course it was like 2 dpi ...
C. PDF's also have the ability to include fonts in the file (again, they do not raster the image!). This is why you can zoom in 1600% on the text document & still have crystal clear fonts, Or do you think that they rastered it at 1152 DPI so that it'd look good when you zoomed in 1600%? Obvoiusly not.
D. Touching on the fonts again, using Acrobat (not reader) you can edit PDF text. This would not be possible if it was one big Tiff image.
Edit:added D
[ 12-18-2001: Message edited by: X704 ]</p>
<strong>I agree with Gorgonzola.. you replied before i edited my post to correct my errors.
The fault probably rests about 90% in developer's hands, 10% in Apple's. 10% being the minor inconstencies in APIs and the utter lack of documentation.
It's also the fact that the apps are coming from so many different sources: you've got classic mac os developers, old next-steppers, now apple-scripters, unix ports, and also people writing new apps in cocoa. I read a quote somewhere that X is truly a chameleon of OS'es... and this is probably responsible (in this early public state) for its minor inconsistencies and the shoddiness of apps.
[ 12-16-2001: Message edited by: Jonathan ]</strong><hr></blockquote>
Good Points. If you were going to develop a NEW app for OSX only, which tools and interfcaces would you use?
Interface Builder, Project Builder, Cocoa and Apple Script Studio? (Objective C or Java). I looked at REALbasic and it looked pretty good for a RAD OO tool for single developer of small apps.