The what?;-) We are talking about Macs here, after all.
When I use an SDI UI I have to click on some other browser window, which reorders the entire stack of windows i allready have out, and have to relocate my mouse on the new window.
Nope. All you have to do is go to the menu bar, pull down the Window menu, and choose the title of the window you're looking for. Same amount of work as involved in using a tab.
PLUS if I want to find the old window, I have to find it burried next to a myriad of other apps.
Nope. The window you were just using is always the window right below the one you're currently using. Cool how that works, huh?
MDI is the future.
Heh. No, dude, MDI is the way-off distant past. Microsoft introduced it with the original Windows, and it's hung around with ever-decreasing persistence ever since. Even Microsoft has largely abandoned it now; Word has been an SDI application since at least Office 2000, and possibly before that.
MDI is a throwback, a regression. A mutation, if you will.;-)
As far as the typing thing you described goes, I can honestly say that I've never even thought of something like that before. It doesn't strike me as something I'd ever use. I've almost always got one hand on the mouse anyway.
With a row of tabs, I can just see everything in my working set, and then select a tab to go there (just like hitting a link in spirit).
How is that different from the "Window" menu? Since "Window" is in the menu bar at the top of the screen, it's way easier to hit with the mouse. Two clicks (or a click-and-drag) gets you where you want to be. Granted, that's twice as many clicks as you'd have to use with tabs, but the Window menu doesn't have any of the bad implications that tabs have. There's no ambiguity between closing a window and closing a tab, for instance. You're also not limited in how long your window titles can be, because in the menu they're represented vertically instead of horizontally. When you pull down the Window menu, you get to see as much of each page title as will fit across your screen, dozens of characters at least. (When we all have 23" monitors, it'll be hundreds!)
Look at Mozilla, or even the Apple home page that *explicitly* uses tabs as the navigational metaphor.
Okay, if we're gonna get into this, we might as well get into it. Here's the problem with tabs.
In Chimera or whatever, a tab basically represents an invisible view. (Here I'm using "view" in the sense of NSView, a representation of in-memory contents on the screen, with a scroll bar and stuff.) Normally a view is bound to a window. Think TextEdit here. If you open a document, you get a window that contains a view of that document. When you close the window, the view is closed, too. The view doesn't linger around.
But tabbed browsing breaks the one-to-one link between views and windows. One window can have more than one view. In and of itself that's okay, except for the fact that no other application works like that. If I open two documents in TextEdit (for example), I get two windows. Close one, and the other stays open. Tabs don't work like that. If you close a window that contains three tabs, you lose not only the view you were actively looking at, but two other views that you weren't seeing at that moment. So you instantly have a user interface problem there.
So to solve that problem, let's completely separate views from windows. Views are now global, associated with an application instance. Any window can display any view. (What if you assign two windows to the same view, and then click a link in one of them? Well, both windows are going to update, of course. Does that make any sense? Intuitively, no. But in context of the detached-view metaphor, yes. So we'll go with it for now.)
So let's say you launch Safari. You get one view created for you automatically, and one window to show it to you. That view, in that window, loads your home page. But let's say you want to create a new view. (I would say a new tab, but we're not using tabs. I hope this isn't too hard to follow. It makes perfect sense in my head.) So you go to the menu and... what? What are you really doing? Creating a new view, or pushing the existing view to the back of some notional pile? What you really want to do is set the current view aside and create a new one, one that you can work with for a while before returning to this one again. How do we represent that in the form of a menu item? We could say "new view," but then you have to explain somehow what a "view" is. Remember, a view is invisible until a window is assigned to it, so "new view" really means to create something that you can't see. That's confusing. What if we approach it from the other angle? Rather than creating a new view, you're taking the one you're currently working with and setting it aside. Maybe the menu item is simply "set aside." I don't know; we can work out those details later. But this is a critical point!
So now you've got a window with two views. You can only look at one view at a time, of course, but if you should want to see two things at once you can open another window and pick the other view. And so it goes.
So you get to the point where you're done with one of the views. You want to get rid of it. You're not going to use it any more. What do you do? Close the window? No, remember, the contents of the window are persistent now. Closing a window doesn't make its view go away. So we have to come up with yet another new menu item. "Close view?" Yeah, I guess, but how can you "close" something that doesn't have any physical representation on screen? "Delete view?" That's not perfect either, but it'll do for now.
So where are we? Our users are having to spend a lot of time thinking about logical entities that have no physical screen representation: views. They're having to think about creating and deleting views. The old trick of simply closing a window doesn't get it done, because we've changed the way windows and their contents are related to each other.
All in all, it's a hell of a mess.
On the other hand, you can do everything you want to do right now with windows. Wanna click a link, but not read the resulting page right now? Open it in a new background window. (Command-shift-click; the request is in to make this a context menu item, too.) Wanna reduce desktop clutter? Minimize windows to the dock. Wanna get to any window in a single click? Use the "Window" menu to select it by title, just as you would a tab.
So the situation here is not a question of whether or not "tabbed browsing" (but without the tabs) would be good, or even possible. It's a question of whether it would, if perfectly implemented, provide some new feature or benefit that cannot currently be enjoyed by the users. The answer is no. So why go upsetting the whole goddamn user interface paradigm apple cart (no pun intended) to implement tabbed browsing, when it provides no new functionality?
WebCore.framework and JavaScriptCore.framework work like DSO's or DLL's, if that means anything to you. The difference is that a framework can be bundled inside an application or available externally. If you look in/System/Library/Frameworks, you'll find stuff like AppKit.framework, which every application on your computer (Cocoa, anyway) links to at run time. If Apple puts WebCore and JavaScriptCore (and maybe WebKit) in the operating system-- in other words, puts them in/System/Library/Frameworks in a future version of OS X-- then programs like OmniWeb will be able to link to them at run time. Future improvements to those frameworks will apply to those programs automatically.
But as of right now, WebCore and the others aren't part of the OS. They're bundled right inside Safari. If Apple decides to leave them out of the OS, then OmniGroup will still be able to use them, but they'll have to distribute the frameworks inside of the OmniWeb package. In that case, updates to the frameworks would have to go from Apple to OmniGroup to the user.
I imagine Apple is going to make WebCore et al. part of the operating system real soon. It's just too darned useful; even apps like Project Builder need to be able to parse HTML to display documentation and whatnot. The million-dollar question is whether they're going to do the same thing with WebKit. If so, expect to see about a hundred special-purpose Cocoa web browsers for OS X in the first week after release. It'll be so easy to write your own web browser, what with PB and IB and all, that you'll hardly be able to avoid it!;-)
Now all I have to do is convince them that the lack of type-ahead-links and type-ahead-find in web pages are truly important shortcomings in Safari
What are those? I'm not familiar with those features.
I'm afraid that tabs might be beyond their UI guidelines.
There's an extremely active discussion going on over in the Apple support forum about how-- if at all-- to implement a multiple document interface for Safari. There seem to be three camps on the issue: 1) Tabs are absolutely essential for browsing, and not including them is stupid. b) Tabs are bad and wrong, but some kind of multiple-document interface would be a good idea. iii) The best way to browse the web is with the good old single-document interface paradigm: one web page, one window.
Myself, I fall somewhere between b and iii. I think a multiple-document interface for browsing is a dumb idea-- once you look past the superficial details of how to arrange the widgets on screen, you run into a whole assload of inconsistencies and irregularities in the paradigm-- but I think so many people are clamoring for it that it makes sense to try to make it work. But I wouldn't vote for a MDI that's anything less than absolutely perfect. Better not to use MDI at all, even as an option, than to implement it in a bad or illogical way.
Well, uh, KHTML is already under the GPL. Shouldn't these guys be thanking the KDE Project for writing the code in the first place?
Sure, appreciation all around. But from OmniGroup's perspective, what Apple did was more significant. (Not more important, not better, just literally more significant.) Apple removed the dependency on Qt and created an Objective C API for KHTML. That was a ton of work, not to be underestimated. Without it, KHTML wouldn't have been of any use to any Mac developer.
In fact, since Apple based WebCore/JavaScriptCore off GPL code...
Let's be precise. KHTML and KJS (and by extension WebCore and JavaScriptCore) are LGPL, not GPL. This is an important distinction. If either of those components had been GPL only, Apple would not have been able to use them.
I can't give you the information you want, but I wanted to let you know that I've appealed to somebody who can. Dave Hyatt works on WebCore (he has a blog) and if anybody can provide a pointer to docs, he probably can.
The most likely answer is simply going to be no, there's no public documentation yet, and to wait before trying to do what you're trying to do. But you never know. I'll post if I get a response. (I'm sure Dave's very, very busy just now.)
All you have to do to take advantage of a new version of WebCore is to link in the new framework when it becomes available.
I feel kinda dirty replying to my own post like this, but I wanted to offer more details on this to anybody who's interested. I've just posted a journal article describing how to use custom-built JavaScriptCore and WebCore frameworks with Safari. In addition to being a really cool way to get in there and start playing with the new frameworks, this illustrates just how easy it's going to be for OmniGroup to build their browser.
At some point in the future, Apple may even choose to ship WebCore.framework and JavaScriptCore.framework as part of the core OS, so anybody can use them to render HTML and handle JavaScript in their Cocoa applications. (WebCore presents an Objective C interface, so it's callable from Cocoa, but not from Carbon. I think.) Of course, thanks to the way packages and frameworks work on OS X, anybody who wants to build their own version of WebCore or JavaScriptCore and ship it with their application is free do to so.
This is really exciting, y'all. This is the way free software is supposed to work.
Even though I understand the old-style ones, I particularly like their slick error messages. They're written in high-quality, clear language that even a novice is going to have no trouble understanding. For a choice example, try refreshing a page with a submitted form on Safari, and then try doing it with any other browser.
For those without access to a Mac, here's the error message.
Are you sure you want to send a form again?
To reopen this page, the form you completed to open the page the first time must be sent again. This may cause the website to repeat actions it took the first time you sent the form.
I agree, but compared to Chimera, Safari is wonderful. I haven't spent much time with the WebCore code yet, so I'm not sure if the Quartz stuff is in there or in Safari itself.
The great thing about WebCore is that it's entirely isolated from the browser itself.
Most of the bugs users have encountered in Safari have been in WebCore-- stuff not rendering properly. As Apple continues to improve WebCore, with community help, the reliability and performance of all WebCore-based browsers will climb. All you have to do to take advantage of a new version of WebCore is to link in the new framework when it becomes available. Then you're done.
So basically there's no reason for OmniGroup, or anybody else, to wait.
1. Yes, Safari is free. No, it is not open source. WebCore (which is KHTML plus some other stuff) and JavaScriptCore (which is KJS, more or less) are open source, and you can download them from here. WebCore is basically a software component, not an application.
2. OmniGroup is excited because Apple has given the OS X developer community a solid, fast, and very (though not yet perfectly) compliant HTML component. This will allow OmniGroup to write OmniWeb 5 (or whatever) around WebCore and JavaScriptCore-- which takes care of turning HTML into stuff on the screen and handling the JavaScript runtime and whatnot-- so they can spend all of their time and effort on the features. This is basically the story of Mozilla, Chimera, and Phoenix, and others. One rendering component, lots of apps built around it to suit different needs.
3. OmniWeb has some cool features that frankly don't belong in Safari: built-in regular-expression URL filtering, for just one example. Some kind of MDI ("tabbed") interface could possibly be another.
4. OmniWeb has never "force fed you banner ads." It's just a browser. You can use it for free, but OmniGroup prefers that you pay for it. No big deal.
Using the modem is the only thing my PowerBook can do under OS X that it can't under Debian.
Wow! Debian can run Photoshop, iTunes, and Word, both play and burn DVD's (video and data), rip CD's to AAC, watch QuickTime movies, interface with your iPod, sync to both your Bluetooth phone and your Palm, run Project Builder and Inferface Builder, run Sherlock, and play Medal of Honor? Amazing. Truly, this is a wonderful time to be alive.
Either that, or you could just be fucking wrong. Whichever.
So you should have a separate window for every preference dialog?
Behold the OS X System Preferences application. That's a good multi-mode, non-document user interface. Each preference pane takes over the whole window, except for the toolbar. Preference panes can be selected from the menu, from the main screen, or from the user-configurable toolbar. This beats the shit out of tabs because it's extensible, among other reasons.
Of course, some preference panes include tabs within them. I'll consider those to be just barely acceptable, as long as the content of each tab is independent of each other tab, and there are no more than about 4 or 5 tabs in total.
Sherlock also has the same basic UI: each Sherlock channel is a pane, and each pane is independent. Wouldn't work for a browser, because it's not suitable for a document-type interface, but for a multi-mode interface, it kicks.
What kills me is that people bitch about something like wanting tabs, and people come around saying "No. It doesn't make your life any easier because I say it doesn't.
Actually, just to be clear, I'm saying that I don't care whether tabs in your web browser make your life easier or not. They're a bad UI design, and if asked I would opine that they don't belong in any browser, even as an option. If you don't like it, either use a browser that has them, like Mozilla, or write your own. Like Mozilla. But don't argue that they should be included in a browser that strives to have a clean, consistent, friendly UI. They shouldn't.
You stupidly make the point that if it wasn't for the free software that Apple is using, they could develop/use something else. Duh!
Doesn't that mean, then, that Apple doesn't depend on those things? Hmm?
GCC was developed by/for the GNU project, which was what I was talking about.
Look, please make up your mind, okay? Are we talking about the compiler, or the user space utilities? If we're talking about the compiler, then Apple's developers wrote most of it, and they could easily use a different compiler if it came down to that. No dependency there. If we're talking about the user space, it all came from FreeBSD, not from the GNU collection. No dependency there, either. Clear now?
Sure, they are definately in competition, but they are ALSO cooperating with the free software community, and doing so very openly.
The "GNU/Linux community" does not equal the "free software community." The free software community includes entities like the FreeBSD project and the Mach project, the two projects that have contributed most to OS X. Apple does not cooperate with the "GNU/Linux community." They compete.
You, OTOH, can't even admit that the platform that you use has benefitted a lot from the free software community you so despise.
Again, please make up your mind. Are we talking about the "free software community," or the "GNU/Linux community?" They're not the same thing. Apple works with the free software community. Apple does not work with the "GNU/Linux community." Got it?
Ah. It seems you are learning a valuable lesson: what you consider to be "proprietary" is not inherently bad. What you consider to be "Free" is not inherently good. The world is not a battle of "us versus them" (or in this case, "you versus us") but rather a bunch of people all struggling to make their way together.
One should use the best tool for the job, based on one's own judgment. If one uses a second-best tool simply because it is "Free," then one is still using a second-best tool.
WTF is your problem with recognizing that GNU/Linux has made software that has benefitted Apple?
Nothing. My problem is when somebody says that OS X depends on Linux or GNU software. That isn't remotely true.
And with regards to GCC, sure, Apple may have developed the Objective C parts of the compiler, but unix tools(everything on OSX that isn't part of the GUI) aren't written in Objective C.
Heh. That's right. They were written by the FreeBSD developers. Not the "GNU/Linux community," whatever the heck that means.
Apple chose to use tools developed by the GNU/Linux community, because they were they best tools to suit what they needed.
Yes. But the GNU tools in use at Apple aren't core to their work. OS X doesn't "depend on" GNU or Linux in any sense at all. OS X "depends on" Mach and FreeBSD. Apple's relationship to the "GNU/Linux community" is a competitive one, not a cooperative one. Apple is (rightly!) trying to lure users away from Linux and get them to use OS X for their desktop and laptop computers.
Oh, and by the way, how's that anger management course working out for you? Doesn't seem to be helping much, from what I can see.
Project Builder, while an outstanding IDE, is hardly the acme of user interface design. That said, it still conforms to the "one document, one window" convention: in single-window mode, each project occupies one window. In "many windows" mode, a window is used for each major UI element, including one window per file. The difference is that single-window mode treats the project as the document, while "many windows" mode treats each file as a document.
Next time you post something sarcastic, you might want to take just a second to make sure you're right first. Otherwise, embarassment could result.
The way I use tabs is that I open a new tab for a sub-page on the same site (e.g. I might have one window with tabs containing the slashdot main page, a slashdot discussion, a subthread in the discussion etc.) and a new window for a new, unrelated site.
SnapBack is your friend! It lets you drill down and then easily pop back up without having to have either piles of tabs or stacks of windows. In fact, I'm using it right now to reply to my Slashdot messages.
Nowhere! That was my point. While it is possible for tabs to be implemented well, and no doubt there are times where they're downright necessary, as a rule they're bad and wrong.
No. NIB files just contain the UI layout and bindings. There's no actual logic in the NIB files. In other words, you might be able to change a NIB to include a tab bar, but you'd be unable to make the tab bar do anything.
Look at Office. Open 3 word docs and they all stay in one window.
No, they don't. Oh, wait, you're thinking of Microsoft's ill-advised MDI paradigm. I know for a fact that Word 2000 no longer forced that particular beast on users; I can't recall exactly when Microsoft dropped it.
MDI is a dumb idea. It blurs the line between an application and a document, and not in a good way. One document, one window is the right way to go.
Tabs, to me at least, should be present in almost any application
Oh, please. You have got to be kidding me. Tabs don't even really belong in preference dialogs, though that's where they got their start and that's where they mostly remain entrenched.
I shouldn't have 24 windows open all over my desktop if I'm only using three applications.
Pray tell, how are you going to look at two web pages at the same time unless you have two different windows? So it's not "one window with one tab per page," and it's not "one window per page." It's some bastardized combination of the two: "one window with some tabs, and another window with some other tabs." That's the kind of wooly-headed liberal thinking that leads to being eaten.
I do all this anyway, but just use command-click to pop multiple windows on IE and now Safari.
You can also use cmd-shift-click to pop windows into the background. Command-click opens new windows in the foreground, which isn't always exactly what you want.
Depends on? No. OS X "depends on" the kernel and the user space utilities. The compiler is not a big deal (and besides, NeXT and Apple practically did all the work on the Objective C parts of GCC anyway); if it weren't for GCC, it would be some other Objective C compiler. Same with KHTML. If it hadn't been KHTML, it would have been something else. (In fact, I'd be willing to guess that Apple would have written their own HTML rendering component if KHTML hadn't been available or suitable.)
The "GNU/Linux" (whatever) community really hasn't contributed a damn thing to Apple or to OS X, except providing a UNIX-based operating system that, by comparison, makes OS X look even sweeter than it is.
Slashdot Mirror
It clutters up the taskbar, mostly
;-) We are talking about Macs here, after all.
;-)
The what?
When I use an SDI UI I have to click on some other browser window, which reorders the entire stack of windows i allready have out, and have to relocate my mouse on the new window.
Nope. All you have to do is go to the menu bar, pull down the Window menu, and choose the title of the window you're looking for. Same amount of work as involved in using a tab.
PLUS if I want to find the old window, I have to find it burried next to a myriad of other apps.
Nope. The window you were just using is always the window right below the one you're currently using. Cool how that works, huh?
MDI is the future.
Heh. No, dude, MDI is the way-off distant past. Microsoft introduced it with the original Windows, and it's hung around with ever-decreasing persistence ever since. Even Microsoft has largely abandoned it now; Word has been an SDI application since at least Office 2000, and possibly before that.
MDI is a throwback, a regression. A mutation, if you will.
As far as the typing thing you described goes, I can honestly say that I've never even thought of something like that before. It doesn't strike me as something I'd ever use. I've almost always got one hand on the mouse anyway.
With a row of tabs, I can just see everything in my working set, and then select a tab to go there (just like hitting a link in spirit).
How is that different from the "Window" menu? Since "Window" is in the menu bar at the top of the screen, it's way easier to hit with the mouse. Two clicks (or a click-and-drag) gets you where you want to be. Granted, that's twice as many clicks as you'd have to use with tabs, but the Window menu doesn't have any of the bad implications that tabs have. There's no ambiguity between closing a window and closing a tab, for instance. You're also not limited in how long your window titles can be, because in the menu they're represented vertically instead of horizontally. When you pull down the Window menu, you get to see as much of each page title as will fit across your screen, dozens of characters at least. (When we all have 23" monitors, it'll be hundreds!)
Look at Mozilla, or even the Apple home page that *explicitly* uses tabs as the navigational metaphor.
Okay, if we're gonna get into this, we might as well get into it. Here's the problem with tabs.
In Chimera or whatever, a tab basically represents an invisible view. (Here I'm using "view" in the sense of NSView, a representation of in-memory contents on the screen, with a scroll bar and stuff.) Normally a view is bound to a window. Think TextEdit here. If you open a document, you get a window that contains a view of that document. When you close the window, the view is closed, too. The view doesn't linger around.
But tabbed browsing breaks the one-to-one link between views and windows. One window can have more than one view. In and of itself that's okay, except for the fact that no other application works like that. If I open two documents in TextEdit (for example), I get two windows. Close one, and the other stays open. Tabs don't work like that. If you close a window that contains three tabs, you lose not only the view you were actively looking at, but two other views that you weren't seeing at that moment. So you instantly have a user interface problem there.
So to solve that problem, let's completely separate views from windows. Views are now global, associated with an application instance. Any window can display any view. (What if you assign two windows to the same view, and then click a link in one of them? Well, both windows are going to update, of course. Does that make any sense? Intuitively, no. But in context of the detached-view metaphor, yes. So we'll go with it for now.)
So let's say you launch Safari. You get one view created for you automatically, and one window to show it to you. That view, in that window, loads your home page. But let's say you want to create a new view. (I would say a new tab, but we're not using tabs. I hope this isn't too hard to follow. It makes perfect sense in my head.) So you go to the menu and... what? What are you really doing? Creating a new view, or pushing the existing view to the back of some notional pile? What you really want to do is set the current view aside and create a new one, one that you can work with for a while before returning to this one again. How do we represent that in the form of a menu item? We could say "new view," but then you have to explain somehow what a "view" is. Remember, a view is invisible until a window is assigned to it, so "new view" really means to create something that you can't see. That's confusing. What if we approach it from the other angle? Rather than creating a new view, you're taking the one you're currently working with and setting it aside. Maybe the menu item is simply "set aside." I don't know; we can work out those details later. But this is a critical point!
So now you've got a window with two views. You can only look at one view at a time, of course, but if you should want to see two things at once you can open another window and pick the other view. And so it goes.
So you get to the point where you're done with one of the views. You want to get rid of it. You're not going to use it any more. What do you do? Close the window? No, remember, the contents of the window are persistent now. Closing a window doesn't make its view go away. So we have to come up with yet another new menu item. "Close view?" Yeah, I guess, but how can you "close" something that doesn't have any physical representation on screen? "Delete view?" That's not perfect either, but it'll do for now.
So where are we? Our users are having to spend a lot of time thinking about logical entities that have no physical screen representation: views. They're having to think about creating and deleting views. The old trick of simply closing a window doesn't get it done, because we've changed the way windows and their contents are related to each other.
All in all, it's a hell of a mess.
On the other hand, you can do everything you want to do right now with windows. Wanna click a link, but not read the resulting page right now? Open it in a new background window. (Command-shift-click; the request is in to make this a context menu item, too.) Wanna reduce desktop clutter? Minimize windows to the dock. Wanna get to any window in a single click? Use the "Window" menu to select it by title, just as you would a tab.
So the situation here is not a question of whether or not "tabbed browsing" (but without the tabs) would be good, or even possible. It's a question of whether it would, if perfectly implemented, provide some new feature or benefit that cannot currently be enjoyed by the users. The answer is no. So why go upsetting the whole goddamn user interface paradigm apple cart (no pun intended) to implement tabbed browsing, when it provides no new functionality?
Depends.
/System/Library/Frameworks, you'll find stuff like AppKit.framework, which every application on your computer (Cocoa, anyway) links to at run time. If Apple puts WebCore and JavaScriptCore (and maybe WebKit) in the operating system-- in other words, puts them in /System/Library/Frameworks in a future version of OS X-- then programs like OmniWeb will be able to link to them at run time. Future improvements to those frameworks will apply to those programs automatically.
;-)
WebCore.framework and JavaScriptCore.framework work like DSO's or DLL's, if that means anything to you. The difference is that a framework can be bundled inside an application or available externally. If you look in
But as of right now, WebCore and the others aren't part of the OS. They're bundled right inside Safari. If Apple decides to leave them out of the OS, then OmniGroup will still be able to use them, but they'll have to distribute the frameworks inside of the OmniWeb package. In that case, updates to the frameworks would have to go from Apple to OmniGroup to the user.
I imagine Apple is going to make WebCore et al. part of the operating system real soon. It's just too darned useful; even apps like Project Builder need to be able to parse HTML to display documentation and whatnot. The million-dollar question is whether they're going to do the same thing with WebKit. If so, expect to see about a hundred special-purpose Cocoa web browsers for OS X in the first week after release. It'll be so easy to write your own web browser, what with PB and IB and all, that you'll hardly be able to avoid it!
Now all I have to do is convince them that the lack of type-ahead-links and type-ahead-find in web pages are truly important shortcomings in Safari
What are those? I'm not familiar with those features.
I'm afraid that tabs might be beyond their UI guidelines.
There's an extremely active discussion going on over in the Apple support forum about how-- if at all-- to implement a multiple document interface for Safari. There seem to be three camps on the issue: 1) Tabs are absolutely essential for browsing, and not including them is stupid. b) Tabs are bad and wrong, but some kind of multiple-document interface would be a good idea. iii) The best way to browse the web is with the good old single-document interface paradigm: one web page, one window.
Myself, I fall somewhere between b and iii. I think a multiple-document interface for browsing is a dumb idea-- once you look past the superficial details of how to arrange the widgets on screen, you run into a whole assload of inconsistencies and irregularities in the paradigm-- but I think so many people are clamoring for it that it makes sense to try to make it work. But I wouldn't vote for a MDI that's anything less than absolutely perfect. Better not to use MDI at all, even as an option, than to implement it in a bad or illogical way.
Well, uh, KHTML is already under the GPL. Shouldn't these guys be thanking the KDE Project for writing the code in the first place?
Sure, appreciation all around. But from OmniGroup's perspective, what Apple did was more significant. (Not more important, not better, just literally more significant.) Apple removed the dependency on Qt and created an Objective C API for KHTML. That was a ton of work, not to be underestimated. Without it, KHTML wouldn't have been of any use to any Mac developer.
In fact, since Apple based WebCore/JavaScriptCore off GPL code...
Let's be precise. KHTML and KJS (and by extension WebCore and JavaScriptCore) are LGPL, not GPL. This is an important distinction. If either of those components had been GPL only, Apple would not have been able to use them.
I can't give you the information you want, but I wanted to let you know that I've appealed to somebody who can. Dave Hyatt works on WebCore (he has a blog) and if anybody can provide a pointer to docs, he probably can.
The most likely answer is simply going to be no, there's no public documentation yet, and to wait before trying to do what you're trying to do. But you never know. I'll post if I get a response. (I'm sure Dave's very, very busy just now.)
All you have to do to take advantage of a new version of WebCore is to link in the new framework when it becomes available.
I feel kinda dirty replying to my own post like this, but I wanted to offer more details on this to anybody who's interested. I've just posted a journal article describing how to use custom-built JavaScriptCore and WebCore frameworks with Safari. In addition to being a really cool way to get in there and start playing with the new frameworks, this illustrates just how easy it's going to be for OmniGroup to build their browser.
At some point in the future, Apple may even choose to ship WebCore.framework and JavaScriptCore.framework as part of the core OS, so anybody can use them to render HTML and handle JavaScript in their Cocoa applications. (WebCore presents an Objective C interface, so it's callable from Cocoa, but not from Carbon. I think.) Of course, thanks to the way packages and frameworks work on OS X, anybody who wants to build their own version of WebCore or JavaScriptCore and ship it with their application is free do to so.
This is really exciting, y'all. This is the way free software is supposed to work.
For those without access to a Mac, here's the error message.
I agree, but compared to Chimera, Safari is wonderful. I haven't spent much time with the WebCore code yet, so I'm not sure if the Quartz stuff is in there or in Safari itself.
The great thing about WebCore is that it's entirely isolated from the browser itself.
Most of the bugs users have encountered in Safari have been in WebCore-- stuff not rendering properly. As Apple continues to improve WebCore, with community help, the reliability and performance of all WebCore-based browsers will climb. All you have to do to take advantage of a new version of WebCore is to link in the new framework when it becomes available. Then you're done.
So basically there's no reason for OmniGroup, or anybody else, to wait.
Nearly everything you said is wrong.
1. Yes, Safari is free. No, it is not open source. WebCore (which is KHTML plus some other stuff) and JavaScriptCore (which is KJS, more or less) are open source, and you can download them from here. WebCore is basically a software component, not an application.
2. OmniGroup is excited because Apple has given the OS X developer community a solid, fast, and very (though not yet perfectly) compliant HTML component. This will allow OmniGroup to write OmniWeb 5 (or whatever) around WebCore and JavaScriptCore-- which takes care of turning HTML into stuff on the screen and handling the JavaScript runtime and whatnot-- so they can spend all of their time and effort on the features. This is basically the story of Mozilla, Chimera, and Phoenix, and others. One rendering component, lots of apps built around it to suit different needs.
3. OmniWeb has some cool features that frankly don't belong in Safari: built-in regular-expression URL filtering, for just one example. Some kind of MDI ("tabbed") interface could possibly be another.
4. OmniWeb has never "force fed you banner ads." It's just a browser. You can use it for free, but OmniGroup prefers that you pay for it. No big deal.
Are we a little more clear now, at least?
Using the modem is the only thing my PowerBook can do under OS X that it can't under Debian.
Wow! Debian can run Photoshop, iTunes, and Word, both play and burn DVD's (video and data), rip CD's to AAC, watch QuickTime movies, interface with your iPod, sync to both your Bluetooth phone and your Palm, run Project Builder and Inferface Builder, run Sherlock, and play Medal of Honor? Amazing. Truly, this is a wonderful time to be alive.
Either that, or you could just be fucking wrong. Whichever.
I personally think tabs make it more user friendly and if every program included them like I think they should ;-) then it would be consistent.
This, as has been said before, harkens back to the bad old days of Windows' MDI paradigm. It was a bad idea then, and it's a bad idea now.
And why can I get to the System preferences eight different ways? I should be able to do it one way.
You can get to it two ways: launching the System Preferences app, or using the System Preferences menu item. That's it. Just two.
So you should have a separate window for every preference dialog?
Behold the OS X System Preferences application. That's a good multi-mode, non-document user interface. Each preference pane takes over the whole window, except for the toolbar. Preference panes can be selected from the menu, from the main screen, or from the user-configurable toolbar. This beats the shit out of tabs because it's extensible, among other reasons.
Of course, some preference panes include tabs within them. I'll consider those to be just barely acceptable, as long as the content of each tab is independent of each other tab, and there are no more than about 4 or 5 tabs in total.
Sherlock also has the same basic UI: each Sherlock channel is a pane, and each pane is independent. Wouldn't work for a browser, because it's not suitable for a document-type interface, but for a multi-mode interface, it kicks.
What kills me is that people bitch about something like wanting tabs, and people come around saying "No. It doesn't make your life any easier because I say it doesn't.
Actually, just to be clear, I'm saying that I don't care whether tabs in your web browser make your life easier or not. They're a bad UI design, and if asked I would opine that they don't belong in any browser, even as an option. If you don't like it, either use a browser that has them, like Mozilla, or write your own. Like Mozilla. But don't argue that they should be included in a browser that strives to have a clean, consistent, friendly UI. They shouldn't.
When the vendor flops or gets bought and closed, your code turns to dust. I've seen it happen too many times.
You should know better. Code doesn't stop working when a vendor goes away.
With the number of Free tools that are as good as or much better than CF, their days seem numbered.
It startles me, in this day and age, just how common that misconception still is.
You stupidly make the point that if it wasn't for the free software that Apple is using, they could develop/use something else. Duh!
Doesn't that mean, then, that Apple doesn't depend on those things? Hmm?
GCC was developed by/for the GNU project, which was what I was talking about.
Look, please make up your mind, okay? Are we talking about the compiler, or the user space utilities? If we're talking about the compiler, then Apple's developers wrote most of it, and they could easily use a different compiler if it came down to that. No dependency there. If we're talking about the user space, it all came from FreeBSD, not from the GNU collection. No dependency there, either. Clear now?
Sure, they are definately in competition, but they are ALSO cooperating with the free software community, and doing so very openly.
The "GNU/Linux community" does not equal the "free software community." The free software community includes entities like the FreeBSD project and the Mach project, the two projects that have contributed most to OS X. Apple does not cooperate with the "GNU/Linux community." They compete.
You, OTOH, can't even admit that the platform that you use has benefitted a lot from the free software community you so despise.
Again, please make up your mind. Are we talking about the "free software community," or the "GNU/Linux community?" They're not the same thing. Apple works with the free software community. Apple does not work with the "GNU/Linux community." Got it?
Ah. It seems you are learning a valuable lesson: what you consider to be "proprietary" is not inherently bad. What you consider to be "Free" is not inherently good. The world is not a battle of "us versus them" (or in this case, "you versus us") but rather a bunch of people all struggling to make their way together.
One should use the best tool for the job, based on one's own judgment. If one uses a second-best tool simply because it is "Free," then one is still using a second-best tool.
WTF is your problem with recognizing that GNU/Linux has made software that has benefitted Apple?
Nothing. My problem is when somebody says that OS X depends on Linux or GNU software. That isn't remotely true.
And with regards to GCC, sure, Apple may have developed the Objective C parts of the compiler, but unix tools(everything on OSX that isn't part of the GUI) aren't written in Objective C.
Heh. That's right. They were written by the FreeBSD developers. Not the "GNU/Linux community," whatever the heck that means.
Apple chose to use tools developed by the GNU/Linux community, because they were they best tools to suit what they needed.
Yes. But the GNU tools in use at Apple aren't core to their work. OS X doesn't "depend on" GNU or Linux in any sense at all. OS X "depends on" Mach and FreeBSD. Apple's relationship to the "GNU/Linux community" is a competitive one, not a cooperative one. Apple is (rightly!) trying to lure users away from Linux and get them to use OS X for their desktop and laptop computers.
Oh, and by the way, how's that anger management course working out for you? Doesn't seem to be helping much, from what I can see.
Uh hello?
Project Builder, while an outstanding IDE, is hardly the acme of user interface design. That said, it still conforms to the "one document, one window" convention: in single-window mode, each project occupies one window. In "many windows" mode, a window is used for each major UI element, including one window per file. The difference is that single-window mode treats the project as the document, while "many windows" mode treats each file as a document.
Next time you post something sarcastic, you might want to take just a second to make sure you're right first. Otherwise, embarassment could result.
The way I use tabs is that I open a new tab for a sub-page on the same site (e.g. I might have one window with tabs containing the slashdot main page, a slashdot discussion, a subthread in the discussion etc.) and a new window for a new, unrelated site.
SnapBack is your friend! It lets you drill down and then easily pop back up without having to have either piles of tabs or stacks of windows. In fact, I'm using it right now to reply to my Slashdot messages.
Where do you think they belong, then?
Nowhere! That was my point. While it is possible for tabs to be implemented well, and no doubt there are times where they're downright necessary, as a rule they're bad and wrong.
No. NIB files just contain the UI layout and bindings. There's no actual logic in the NIB files. In other words, you might be able to change a NIB to include a tab bar, but you'd be unable to make the tab bar do anything.
Anyway, tabs are bad and wrong.
Look at Office. Open 3 word docs and they all stay in one window.
No, they don't. Oh, wait, you're thinking of Microsoft's ill-advised MDI paradigm. I know for a fact that Word 2000 no longer forced that particular beast on users; I can't recall exactly when Microsoft dropped it.
MDI is a dumb idea. It blurs the line between an application and a document, and not in a good way. One document, one window is the right way to go.
Tabs, to me at least, should be present in almost any application
Oh, please. You have got to be kidding me. Tabs don't even really belong in preference dialogs, though that's where they got their start and that's where they mostly remain entrenched.
I shouldn't have 24 windows open all over my desktop if I'm only using three applications.
Pray tell, how are you going to look at two web pages at the same time unless you have two different windows? So it's not "one window with one tab per page," and it's not "one window per page." It's some bastardized combination of the two: "one window with some tabs, and another window with some other tabs." That's the kind of wooly-headed liberal thinking that leads to being eaten.
I do all this anyway, but just use command-click to pop multiple windows on IE and now Safari.
You can also use cmd-shift-click to pop windows into the background. Command-click opens new windows in the foreground, which isn't always exactly what you want.
Depends on? No. OS X "depends on" the kernel and the user space utilities. The compiler is not a big deal (and besides, NeXT and Apple practically did all the work on the Objective C parts of GCC anyway); if it weren't for GCC, it would be some other Objective C compiler. Same with KHTML. If it hadn't been KHTML, it would have been something else. (In fact, I'd be willing to guess that Apple would have written their own HTML rendering component if KHTML hadn't been available or suitable.)
The "GNU/Linux" (whatever) community really hasn't contributed a damn thing to Apple or to OS X, except providing a UNIX-based operating system that, by comparison, makes OS X look even sweeter than it is.