or Connect
AppleInsider › Forums › Software › Mac OS X › Why aren't apps taking advantage of OS X?
New Posts  All Forums:Forum Nav:

Why aren't apps taking advantage of OS X?

post #1 of 18
Thread Starter 
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>
post #2 of 18
Obviously some developers are lazy, some don't quite grasp what the full potential of the OS is, but I think most are sincerely trying to make their software as good as possible, and OS X can help in that.

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.
post #3 of 18
A principle tenet of OpenSource software design is "release early and release often." Sure the developers could spend extra time tweating their apps to take full advantage of OSX's cool GUI features, or they could release their 1.0 version now and add those features the next time around.

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...
Download BARTsmart BART Widget, the best BART schedule widget for Mac OS X's Dashboard.
Reply
Download BARTsmart BART Widget, the best BART schedule widget for Mac OS X's Dashboard.
Reply
post #4 of 18
What I don´t understand is why applications aren´t build the other way round. Someone (Apple for instance) release a really basic app like rules for how "things" talk to each other and a "room" where they can do it and then other add the "things"/tools that provide services for the application. It could be TextEdit that is nothing more than a very basic word processor with fonts. Then someone add a spell checker, other a graphics manipulation tool aso. I thought that would be the point of sevices and easy to do with object orientated programming.

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 reject your reality and substitute it with my own" - President Bush
Reply
"I reject your reality and substitute it with my own" - President Bush
Reply
post #5 of 18
Sheets are the new, non-modal file save dialogs.


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>
post #6 of 18
Jonathan,

[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.
"If I were a younger man, I would write a history of human stupidity; and I would climb to the top of Mount McCabe and lie down on my back with my history for a pillow; and I would take from the...
Reply
"If I were a younger man, I would write a history of human stupidity; and I would climb to the top of Mount McCabe and lie down on my back with my history for a pillow; and I would take from the...
Reply
post #7 of 18
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 ]</p>
post #8 of 18
[quote]Originally posted by Jonathan:
<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.
"If I were a younger man, I would write a history of human stupidity; and I would climb to the top of Mount McCabe and lie down on my back with my history for a pillow; and I would take from the...
Reply
"If I were a younger man, I would write a history of human stupidity; and I would climb to the top of Mount McCabe and lie down on my back with my history for a pillow; and I would take from the...
Reply
post #9 of 18
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!
post #10 of 18
Very true about coordination issues between different APIs. At least Apple has expressly stated they intend to make the difference in how apps are created irrelevant and unoticable to the end user. Carbon in particular was doing a lot of programming acrobatics in its development right through 10.1, and more smaller changes are being made to have it catch up and even then change as Cocoa does.

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.
post #11 of 18
[quote]Originally posted by Jonathan:
<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.
I'm not going anywhere.
Reply
I'm not going anywhere.
Reply
post #12 of 18
I fear though that Office will be one of the last to do this, as it has no real competition. That is, unless Apple pulls a very large coup on AW7... Maybe the 1+ year delay in its delivery is due to a cocoa rewrite?

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!
post #13 of 18
I really hope that AppleWorks 7 is awesome, after 6 being such a letdown. I won't even mention the carbonised version...

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...
I'm not going anywhere.
Reply
I'm not going anywhere.
Reply
post #14 of 18
Quote:
----
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....
post #15 of 18
[quote]Originally posted by n4mant:
<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">
post #16 of 18
[quote]Originally posted by starfleetX:
...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.
post #17 of 18
Yes our friend n4mant seems to know very little about PDF's <img src="graemlins/bugeye.gif" border="0" alt="[Skeptical]" /> . Here's a few tips for him.

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>
post #18 of 18
[quote]Originally posted by Jonathan:
<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.
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: Mac OS X
AppleInsider › Forums › Software › Mac OS X › Why aren't apps taking advantage of OS X?