Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Safari v80 Leaked?
- Thread starter MacRumors
- Start date
- Sort by reaction score
You can ctrl-click on the forward/back buttons and get a list of the pages. I don't know if thats new or not. I never tried ctrl-click on that button before.
pyrotoaster
macrumors 65816
I spoke too soon. Some sites still have the wrong font. Try using "Lucida Grande."
Edit: Didn't see your post, thanks AppleMatt.
Oh cool I never noticed that, but did you try command clicking (apple button) on the home or back/forward?
As it should. That shoudl be the default in all browsers as it pretty much has been forever.
Maybe Apple finally realized they're mucking up a lot of sites that were designed with defaults in mind.
I realize times isn't the best screen font in the world, but at least it's a serif font. When you design a site to use the default font for the text, then you use san-serif fonts for titles and other elements, Safari became a pain because it now had a san-serif font used for text default, and then whatever san-serif fonts you prescribed in the design for the other fonts. Bad clash in typography right there.
Apple probably wised up. If pages don't appear the same as in Netscape and IE, people will have issues.
Just click and hold for a brief second. That's been there for as long as I can remember. Works pretty much the same as all web browsers.
Re: Help!
You might just have to remove the preferences in Home -> Library -> Preferences for Safari but preserve the bookmarks file. Next time, only download official releases of betas etc...you run the risk of losing everything to untested versions more than those that have been tested.
Did you make a backup of the entire hard disk before installing the pirated version? It is always smart to backup before installing new software in case you run into trouble like this.
You might just have to remove the preferences in Home -> Library -> Preferences for Safari but preserve the bookmarks file. Next time, only download official releases of betas etc...you run the risk of losing everything to untested versions more than those that have been tested.
No. In truth, there's not much wrong or funny with Microsoft's bundling of HTML rendering services with the OS, either. The difference is that Safari still exists as an application on OS X. The code to draw the windows, to handle tabs, to manage bookmarks, all of that is encapsulated as an application. On Windows, that doesn't really exist as an application in the same sense. It's an OS component, analogous to some of the stuff in /System/Library/CoreServices on your Mac. You can't really remove IE from Windows, although you can remove references to it.
What Apple is doing is taking the HTML rendering part of the browser and making it available as a feature of the operating system. This is sensible. After all, styled text rendering code is available as part of the operating system. You don't have to write your own styled text renderer every time you want to use styled text in an application. HTML is basically the same thing.
So, in other words, no. Nothing wrong or funny. Just (no offense, seriously) an incomplete understanding on your part.
Erm. If we really want to talk about defaults, we have to mention the fact that the W3C standard explicitly avoids mention of any default typeface. Unless otherwise specified by the browser, the typeface is the sole domain of the client.
Anybody who assumes 16 point Times is going to be the user's font of choice is making a bad decision. Any page that does not render correctly in a font other than 16 point Times is a poorly designed page.
My personal default font of choice is 14 point Georgia. There's no reason for a page designer to know this, or to care.
Hmm. I don't buy it. If you believe that leaking the software was wrong (which is not a given, but it happens to be my opinion), then you have to believe that using the software is also wrong. It's the fruit-of-the-poisoned-tree idea. Also summed up by the phrase "ill-gotten gains."
It's not clear that if Apple were to "open up their beta programs a good bit" that it would further "honour" its customers. For instance, many customers might be ofended that Apple would offer a product ridden with annoying deficiencies. By improving the product to a certain acceptable level internally, Apple can avoid customer dissatisfaction to some extent. It is conceivable that customers would create an additional burden on Apple's technical support and engineering teams...it's certainly not helpful to receive two thousand bug reports on a well-known issue, and to have to invest time in sorting through all of those reports. And, in what format should those public bug reports be made?
Quality testing is not a function of how many people are doing the testing. It is about having the right number of people doing efficient testing and producing useful results (useful to the engineers, in this case). Apple certainly wouldn't need 2,000 people to tell them that a button doesn't work right...
More to the point, *you* are illegally acquiring and using software that is not at all public. It is the private, protected property of Apple Computer, Inc., and you are not helping the company nor your cause by stealing that software, which you do not have a right to do, and further, discussing details of it and publishing images of it as well, which you also do not have a right to do. It's a good thing you don't work for Apple, and if your posts in this thread (which belie little understanding of Apple, software testing, and respect for protected intellectual property) are any indication, that you probably never will.
Re: No
It was bad that Apple let a script with such a simple mistake in it get out. But the problem does not lie with the installer.
In point of fact, neither Apple's installer nor Vise (shudder) is particularly good at managing software. Installing software is easy; managing it is hard.
The topic is going to appear to go bye-bye for a second, but I'll bring it back. Be patient.
The best software management system I ever used was an SGI tool called "inst." Inst had a graphical interface called Software Manager. Inst maintained a database of installed software, and allowed a privileged user to manipulate that database.
The first thing a software vendor did when making software for IRIX was create an inst package. The inst package included some basic metadata, like the name and version number of the package. It also included information about relationships to other packages: prerequisites, incompatabilites, and so on.
To install a package, you just ran it through inst or through Software Manager. It allowed you to select sub-packages for installation, if you wanted to install X but not Y. Or, more often, it just let you hit the big green button and do a default installation.
But the cooler thing was management. At any time, you could fire up Software Manager (or inst) and see what was installed on your computer at the product, subsystem, or even file level. There were shell tools that let you figure out interesting things, like, "What software product does the file /usr/lib64/libfoo.so belong to?"
You could remove software. Since the inst database knew all about dependencies, it wouldn't let you remove X without also removing all the things that depended on X.
The flexibility and power of inst can't be overestimated. I was able, using inst, to get a bare-bones IRIX operating system installation down under 200 megabytes... and that's for a 64-processor, 64-bit supercomputer! I pulled out stuff like HTML rendering components and OpenGL and cryptographic libraries that this particular single-purpose system simply didn't need, and got it down to the absolute minimum.
I wish OS X had a system like that. Maybe I'll get to work writing one, just as an exercise, and see if Apple's interested in taking the ball and running with it.
The point, of course, is that a system like that would make installing Safari a piece of cake. When you ran the installer you'd see two products listed: Safari and WebKit. The Safari product would install the Safari application in /Applications. The WebKit product would install WebKit in /Library/Frameworks or whatever. Because the system enforces certain rules, WebKit would not be able to overwrite Foundation. Instead, the package would include an updated Foundation. If, after installing the new software, you decided you wanted to revert, you could just open up Software Manager and, assuming you chose to save old versions, click a button to remove the Safari package (including WebKit and Foundation) and revert to the old versions.
*sigh* Those were the good old days.
Okay, look. What happened with the iTunes installer was the result of a poorly written script. It doesn't matter if that script was executed by Apple's installer (good) or a piece of poorly ported junk like Installer Vise. It would have had exactly the same effect.
It was bad that Apple let a script with such a simple mistake in it get out. But the problem does not lie with the installer.
In point of fact, neither Apple's installer nor Vise (shudder) is particularly good at managing software. Installing software is easy; managing it is hard.
The topic is going to appear to go bye-bye for a second, but I'll bring it back. Be patient.
The best software management system I ever used was an SGI tool called "inst." Inst had a graphical interface called Software Manager. Inst maintained a database of installed software, and allowed a privileged user to manipulate that database.
The first thing a software vendor did when making software for IRIX was create an inst package. The inst package included some basic metadata, like the name and version number of the package. It also included information about relationships to other packages: prerequisites, incompatabilites, and so on.
To install a package, you just ran it through inst or through Software Manager. It allowed you to select sub-packages for installation, if you wanted to install X but not Y. Or, more often, it just let you hit the big green button and do a default installation.
But the cooler thing was management. At any time, you could fire up Software Manager (or inst) and see what was installed on your computer at the product, subsystem, or even file level. There were shell tools that let you figure out interesting things, like, "What software product does the file /usr/lib64/libfoo.so belong to?"
You could remove software. Since the inst database knew all about dependencies, it wouldn't let you remove X without also removing all the things that depended on X.
The flexibility and power of inst can't be overestimated. I was able, using inst, to get a bare-bones IRIX operating system installation down under 200 megabytes... and that's for a 64-processor, 64-bit supercomputer! I pulled out stuff like HTML rendering components and OpenGL and cryptographic libraries that this particular single-purpose system simply didn't need, and got it down to the absolute minimum.
I wish OS X had a system like that. Maybe I'll get to work writing one, just as an exercise, and see if Apple's interested in taking the ball and running with it.
The point, of course, is that a system like that would make installing Safari a piece of cake. When you ran the installer you'd see two products listed: Safari and WebKit. The Safari product would install the Safari application in /Applications. The WebKit product would install WebKit in /Library/Frameworks or whatever. Because the system enforces certain rules, WebKit would not be able to overwrite Foundation. Instead, the package would include an updated Foundation. If, after installing the new software, you decided you wanted to revert, you could just open up Software Manager and, assuming you chose to save old versions, click a button to remove the Safari package (including WebKit and Foundation) and revert to the old versions.
*sigh* Those were the good old days.
pyrotoaster
macrumors 65816
Your point is completely valid, as this is really just a matter of opinion. My feeling is that it was stupid for whomever leaked this build to do so, and they probably shouldn't have. I'm not that person though, so I have no problem with getting a little sneak preview at what Apple has in store.
But, like I said, it's a matter of opinion.
pyrotoaster
macrumors 65816
RE: Some Assistance.
Sorry I offended the "Safari Police" on this BBS. Maybe "you don't get" wanting to check out new software, and being as though it's free, it's not as if peolpe are looting.
But maintain your so-called higher moral standing. A simple "No, no help here" would suffice.
Sheesh, it's that type of cavalier attitude that gives Apple it's deserved "elitist" tag. Please, step off the high horse.
So whatever. Keep your Safari beta to yourself.
Sorry I offended the "Safari Police" on this BBS. Maybe "you don't get" wanting to check out new software, and being as though it's free, it's not as if peolpe are looting.
But maintain your so-called higher moral standing. A simple "No, no help here" would suffice.
Sheesh, it's that type of cavalier attitude that gives Apple it's deserved "elitist" tag. Please, step off the high horse.
So whatever. Keep your Safari beta to yourself.
I've been using autotabs for some time now. If you enable debug mode in the current released version it'll add an option under each folder named "Open in Tabs" and it does just that, it opens every single bookmark in that folder in a tab.
Oh? I didn't know that, but its still not the same. I'm obviously not familiar with the program you are talking about but from reading the other posts it would appear that Microsoft is providing a set of APIs to do html rendering, and that rendering is based on IE. That's actually pretty nice, it will make a lot of developer's lives easier.
The difference is that Microsoft owns that underlying code, whereas Apple doesn't own KHTML any more than you or I do. If Apple decides they want to get rid of competitors to safari, they can't take their ball and go home. The improvements that they've made to the code will stay.
With regards to someone's post that if everyone uses the webcore framework it will force web developers to write to the subset of the standard that is supported by the KHTML engine, that's probably true. But when that code belongs to everyone, its sort of a mute point. If there's some portion of the engine that doesn't meet some WC3 standard, anyone with the desire and ability can fix it. And nothing is stopping you from using the mozilla engine if you prefer.
It's all about ownership. And Apple putting work into something that the community owns is a good thing for the community.
