Slashdot Mirror
Apple Releases Safari 1.2 and Java 1.4.2
smithk writes "Apple has released Safari 1.2 and Java 1.4.2. Panther owners only. Some new features of Safari include full keyboard access for navigation, download resume, support for LiveConnect, and support for personal certificate authentication. Also, web site compatibility has been improved." Available, as usual, via Software Update.
Finally apple is doing something about speeding Safari up. I don't know about everyone else, but anytime i opened more than 5 tabs in 1.1, my whole machine would slow to a crawl. Already I can tell a huge performance increase with 1.2!
They don't really have that much choice in this case. There were a lot of fixes to Core Graphics and other frameworks of Panther (little things like text not rendering properly). I don't think it's at all realistic for Apple to back-port those fixes to Jaguar. And without them, Safari 1.1 and 1.2 would look terrible.
What the hell is LiveConnect?
Balderdash. The delays were mostly due to Apple abandoning NuKernel/Copland in favor of Mach-O, and also due to introducing a sub-layer based on BSD. These have nothing to do with programming APIs. Also, you need to understand that much of Carbon is based on concepts that never existed under the classic Mac Toolbox, like Carbon Events.
But since 1997 the plan has and continues to be OS X Cocoa which will benefit everyone.
Then explain Apple's continued support for QuickTime... the QuickTime API's are heavily dependant upon conventions introduced during the Mac Toolbox era. OS X also exposes BSD/POSIX, Java and X-Windows APIs for application development, all of which are orthagonal to Cocoa. Even AppleScript Studio relegates Cocoa to the sidelines as "glue." Importantly, Carbon is the best way to get procedural-level programming support under native OS X APIs. Procedural conventions tend to be easier to work with than object-oriented designs when targeting for cross-platform development, especially when trying to write code that targets both Windows and Macs. (Though one can argue this is as much a fault of Microsoft's design than OOP's limitations.)
Based on past discussions I've had and read, the advocacy that Cocoa seems to get arises from a confusion between Carbon/Cocoa and CFM/MachO. A Carbon application linked using MachO is just as much a native OS X citizen as a Cocoa app would be. Under the hood, parts of Cocoa are implemented as wrappers to Carbon functionality, and vice versa.
Those who complain about affect & effect on
Everybody's got their favorite pet peeve and this one is mine. It's obvious now that the Grand Puba in charge of features has decided that thou shalt only only navigate via the toolbar. This omission remains despite the fact that every other browser on earth provides this feature and it is used by a majority of web surfers. My wife won't use it due to this inexplicable omission. She just gives me an incredulous look and exclaims "what do you mean there's no back and forward when I click? This thing sucks". Safari is my main browser and I like it a lot, but this is a major shortcoming in my book.
When it comes to application features, I'm often able to understand the reasoning behind a particular implementation even if I don't personally like it. But, for the life of me, I can't think of one good reason to leave this feature out.
Can anyone enlighten me on the advantages of always having to mouse to the upper left-hand corner to go to the previous page? Am I missing something? I know I can do it from the keyboard, but I often like to kick back and just use the mouse.
BTW, the update is nice. Faster. Renders some sites that previously were unreadable and/or unusable. I love the minimum font size feature and being able to tab through page items.
Why not for 10.2? OK, Framework... Framework can't be updated too? I mean, I flamed enough but nobody tells the exact reason. I am really curious.
BTW, to people standing in line to shout "Don't be cheapo, buy Panther", yes I bought, the upgrade. It works on my G5... I still get mad/confused about this kind of policy.
I don't get it, why Apple does such thing hurts its image? Really curious as end user only, no kidding...
This release didn't fix my pet peeve with Safari: being able to tab through all form elements. Having to click on checkboxes, radio buttons, drop-down selection boxes, etc, is a huge pain when you're testing complicated forms for web applications, especially when every other browser tabs through every element type. I was hoping the this Safari update would address that issue.
If they improved web site compatibility, they most likely changed the rendering engine KHTML. Does anyone know? The changes will have to be given back to the KHTML developers, since it is LGPLed. I know the Apple developers did that before, and I must say that this is a great example for a working open source license!
This sig is stolen from someone who had a much better idea than I had.
I won't debate Copland or Taligent. That was exhausted back in 1997 during the merger.
Apple has Politically maneuvered themselves to make sure as many popular APIs are available for OS X, to build a user base.
Does that mean these APIs won't get folded into ObjC equivalents?
The wrapping of ObjC to Carbon and vice versa is analogous to the Java Bridge between ObjC and Java NeXT developed during the WebObjects transition from ObjC to Java.
The decision to focus ObjC on the desktop and not on the AppServer has been one that bit Apple in the ass and they know it.
The advantages were removed from their products.
This is all from one who had to support WOF and Openstep.
Exposing APIs that market segments have wanted is a smart maneuver.
MVC Paradigm is at the very core of OS X. Linking to MachO was necessary because the OS was slow when all the Carbon/BlueBox/Classic layers were added.
Over time you will see OS X improve due to more Cocoa integration (new Finder being one example) and moreso. The latest Dev examples should show you how much the underpinnings of Cocoa are in Carbon now.
No one is saying ObjC is better than C++ or vice versa.
POSIX Compliance is necessary if one wants to work within the Federal Markets. And that's smart since the Feds have deep pocketbooks.
There were tons of APIs at Apple and NeXT that still aren't nailed down but are slowly morphing into a coherent structure that we'll all benefit from.
The biggest complaint people have about Objective-C is the syntax. Those complaints come from folks who haven't even scratched Cocoa's surface.
The corporations who whined won back in 1998--Adobe, Microsoft, Quark, Macromedia and a few others demanded Carbon.
Now that Microsoft is focused on .NET and C# don't think Apple hasn't noticed and don't think each revision comes with more and more Cocoa Examples for Developers to learn and leverage.
Its quite clear the folks in Engineering were smart enough to take the best of all their APIs and are broadening them under a common umbrella.
Let's just see exactly what happens by OS XI.
For now Apple has done a fine job abstracting its APIs enough to make Carbon a First Class Citizen in most senses due to duplicating efforts and coding time just so that the OS doesn't slow down. Since ObjC is only a superset of C it and interoperates with C++ you'd think people would welcome the advantages it offers when needed?
IANAAD: I am not an Apple developer.
Cocoa, Carbon, etc. aren't really orthogonal. Cocoa relies on BSD, Mach and Carbon. Carbon relies on Cocoa, BSD, and Mach. The reliance is decreasing, if you look at how menus work you'll see a good example.
Think of Carbon and Cocoa as just two ways to access the (mostly) same UI elements. The only difference is that it's a real pain in the ass to write anything in Carbon. I've written a few things in Carbon and a few in Cocoa. Programming in Cocoa is beautiful and fast, at least for something that was wedged sideways into C. And Cocoa's got a lot more thread safety than Carbon. Look at the Carbon docs, tons of functions either must be called by the main thread or aren't reentrant. I think people writing Mach-O apps in Carbon are either lazy, stubborn, or masochists. I write Carbon, but only when I need compatability with the systems of yore.
It took Apple time to put both Carbon and Cocoa in OS X. Cocoa ran on Mach already, but Apple wanted UI elements from Carbon. So in the beginning, they changed Cocoa so that it looked and felt like a Mac, and the changed Carbon so that it ran on systems that used real virtual memory.
Gotta love real virtual memory.
By the way, NeXT did support POSIX, but that required a specific support contract, so no it did not support POSIX, out-of-the-box but for Fed clients who demanded it we put it in.
I was there at Apple when the decisions were made.
Steve was asked by Fred Anderson what would it take to have you come back as CEO, because Gil is ignoring your advice and we are afraid with only 3 months of money left the company will fold?
Steve wanted an interim title and the opportunity to build a new board of directors.
He then made a decision to settle the Microsoft dispute and bury the hatchet, once and for all. That came down to private meetings.
Avie, Bertrand Serlet and others were holding high level meetings with third party developers as I've hinted at to convince them to use Cocoa and they informed them that would set them back years and there had to be a better way.
Back to Engineering and several weeks of brainstorming the teams decided to take the massive amounts of Procedural APIs and wittle it down to a reasonble number that they could then leverage the bulk of the legacy support and mesh them, over time with the future direction of Application Development grounded in Objective-C's Foundation and AppKit APIs.
CoreFoundation was born along with countless other APIs for cross pollination.
Gil Amelio saw the power of Cocoa and like anyone who hasn't developed much just thought it could Presto! change everything overnight. He was more than happy to dump the past and launch into the future with a new set of APIs that had nearly a decade of development already invested in them--Openstep.
No one at NeXT was thrilled with Java--they got it almost right is what the usual comments were up to "If only Sun would ever 'get' objects."
Java tries to be the best of both C++ and ObjC and misses on both but gee like any language if you don't get broad adoption it is perceived as being an inferior choice.
No one from the NeXT encampment has ever "wanted" to port Apps using Procedural APIs, unless you count the Quartz group which wrote Quartz and they wrote WindowServer.app in C. Just ask Andrew Barnes or Peter Graffanino how many lines of C are in Quartz or how many were in Openstep's WindowServer.app.
The languages used within OS X are chosen when it makes the most sense both technically and politically.
BeOS died because its founder's arrogance was greater than the technologies the company could offer Apple. The man wanted > $100Million and a top spot back at Apple. He was concerned about himself, first and foremost. The cost of NeXT exactly paid off the debts NeXT owed to Canon and other investors. Steve made nothing out of the deal and was reluctant to even come onboard, hence his original role as a consultant. He was concerned that the 300 plus NeXT employees were still gainfully employed and that our stock options would be honored, which they were.
The best day I remember was when Steve cancelled Sabbaticals and all those that were hanging around for their 3 month Sabbaticals all quit and stated the only reason they were here was for the 3 free months of pay. As I stated earlier Apple only had 3 months of money and paying for 1/3 of the Corporate Staff to sit on their rears and have a long vacation just wasn't gonna cut it.
Smart Politics, Outstanding Vision, Compassion for the Company as a whole and other attributes is what makes Steven P. Jobs the best person and only person that could have and has save Apple Computer Inc, from oblivion.
Fred Anderson is right up there, in my book, as one of the most able and intelligent executives I as a peon got to talk with and work for.
Apple just keeps getting stronger and stronger and if I recall thats what we want from Her.Go out and get yourself a Microsoft 5-button (w/scroll wheel) mouse. The forth button goes back (you don't evven have to configure it) and the 5th goes forward. It improves your web browsing experience like, eighteen fold. Best 30 bucks or so you could spend on your mac.
c-hack.com |
Previously, if you dragged an image from the browser to the desktop (or wherever), it would download it AGAIN.
Yes, nonsensical, but there was a way around that, and still is for those who don't upgrade.
Just open the image in a new window and use Save As.
The annoying jumping around that happens when reloading a previously scrolled page.
Agreed. But even more; some sites seem to put S into a tizzy (/. is one). No matter that you click to move on, S will continue to load (forever) and only precious minutes later recognise the new click.
If on the other hand you stop the current load and click again, S will do nothing. Check your location bar, and you'll see the next URL which you clicked for but where you never arrived. The trick here is to click Refresh instead.
Another beauty: if you muck with the location bar's contents and hit Refresh, S gets lost. There is no internal representation for your current location; it seems the only storage for this is your location bar, which is eminently editable.
And if you're waiting for a heavy image to load, does the user really think Safari is faster it if doesn't show a single pixel until it can WHAM! put it all there at once? If the dimensions are known, why not do it a bit at a time like Camino? For it's a lot easier to make up your mind whether you want to wait out the complete download or not.
Finally, the 'no man's land' in the lower right hand corner can easily get double scroll bar arrows. This will not happen that often on broadband, but on dialup from a hotel it's very annoying. The technique Cocoa normally does (as evidenced by their table view) is to put a dummy control in these unused areas, but the S team, albeit aware of this cosmetic bug from the get-go, have still not taken the time to fix it.
This version of Safari is starting to show signs of work on forms and controls. When you press the return key in a form the Submit button now lights up for a second, a subtle indicator to reinforce that the form was actually submitted. On the CSS front, font size specifiers now work in form buttons, but not typeface or weight. When they get form control color-specifiers working that'll be pretty nifty.
-- thinkyhead software and media
I found the tip in the original posting at: http://www.floppymoose.com/