Google Browsersync

[Asher]

dp

[Asher]

Steve Ballmer is a business man.

Fun with OS X:

General (Mac OS X)

1.

Pressing any key on the keyboard will wake the computer from sleep, but clicking the mouse button will not.
2. In Windows and in Mac OS pre-X, an ellipsis following the label for a button or menu item means further information is required to carry out the command implied by the label. In Mac OS X, however, an ellipsis means nothing in particular, and so does the lack of an ellipsis. (For anything you think it might mean, at least one of these is a counterexample: Open Location… in Safari; About in any application, Address Panel in Mail, and Downloads in Safari; the main Help menu item in any application.)
3.

The Application menu (which appears to be a dumping ground for menu items that should not exist) has a different width in every application. This means the File, Edit, and View menus are in a different position on the menu bar in every application, making them slower to get at.
4.

Some windows use a brushed metal appearance, while others do not. This distinction exists for no apparent reason.
5.

In the Finder, Safari, Mail, and the Help Viewer, instructions for using a search field are placed inside the field, disappearing when the field is focused. This slows you down by making you check whether the text needs deleting every time you use the field, and it also hides the instructions just when you need them most.
6.

Date and time entry fields in OS X are several hundred percent slower to use than the equivalent controls in Windows or Mac OS pre-X.
* The ↑ and ↓ keys cannot be used to increment and decrement values.
* The ← and → keys cannot be used to navigate between components of a date or time. Tab and Shift+Tab are used for this purpose, inconsistent with their use in all other controls in the OS.
* Mistyped values cannot be retyped without selecting or deleting the previous value first.
7.

Some listboxes (such as the Song list in iTunes, and the Buddy List in iChat) alternate blue and white highlighting to distinguish consecutive items, while others (such as the Source list in iTunes, and the List view in the Finder) do not. This variation exists for no apparent reason. To make things worse, Mail uses the same shade of blue by default to highlight message threads.
8.

Disclosure triangles always look unavailable. (Indeed, they are almost indistinguishable from the icon of an unavailable Forward button in Safari or the Finder.)
9.

Exceptions to the previous problem are the disclosure triangles used in Open and Save dialogs and in the Authenticate alert. These disclosure triangles have a different appearance from those in the rest of the OS, for no apparent reason.
10.

Pressing the Escape key would be a reliable method of cancelling any drag, except that it doesn’t work when dragging an icon out of the Dock.
11.

Dragging to the menu bar would be a reliable method of cancelling any drag, except that it doesn’t work when moving a window.
12.

Sheets move together with their parent window, which is good, but they cannot be moved independently of their parent window, which is bad. When asked if I wanted to save changes [sic] to a newly-created TextEdit document, I could not remember whether what I had started typing was important, and I could not move the sheet out of the way to look.
13.

Until you start dragging, resize handles and scrollbar thumbs give no indication of whether you clicked on them successfully or whether you missed.
14.

Any scrollbar, when scrolled as far as possible to the top or left, looks as if it could be scrolled three or four pixels further upward or leftward.
15.

The subtle ribbing within a scrollbar thumb stays in the same place (relative to the scrollbar as a whole) while the thumb is being dragged. This is subtly distracting because it does not make sense: the ribbing is not visible in the rest of the scrollbar trough, and therefore must be part of the thumb.
16.

It is easy for important controls — such as a window’s scrollbar buttons and resize handle — to become unclickable because they are stuck under the Dock. The Dock cannot be hidden temporarily, but even if it could, that would only be a workaround, not a solution. 2004-02-28: It has been pointed out to me that Command+Option+D will put the Dock into auto-hide mode, which is somewhat similar to hiding it temporarily. I hadn’t found this myself because it isn’t mentioned in the help topic Shortcuts for the Dock, or in the help topic Shortcuts for the system, or in the help topic Using the Dock, or in the help topic The Dock is in my way, and because the Dock submenu of the Apple menu had been removed by FruitMenu which I was using to fix the jumping-menus problem. Incidentally, I’d expect the need for a The Dock is in my way help topic to result in the Dock itself being fixed by the third annual update to the OS, but it hasn’t.
17.

In many applications (including iChat, Help Viewer, Mail, Preview, and Safari, but not iTunes), scrollbars in a background window will scroll in response to the same click used to bring the window frontwards (in Apple parlance, they allow click-through). This makes focusing a window without scrolling it frustratingly difficult, since the scrollbar trough is often a large fraction of the only visible edge of the window.

Finder (10.3)

18.

Adding unpredictability to the previous problem, a Finder window’s scrollbar correctly ignores click-through when it takes focus from another Finder window, but incorrectly allows click-through when it takes focus from a non-Finder window.
19.

The Finder presents a non-spatial interface by default. Those people most likely to need the simplicity and realism of a spatial interface are those least likely to realize it exists or how to achieve it.
20.

Even when the spatial mode is achieved, it fractures by allowing the same item to be visible in two places at once. This problem can be experienced by opening the Desktop folder, or by expanding the disclosure triangle in a list view for a folder that is already open in its own window.
21.

Normally, an alias to an item has the same icon as the original item. Unfortunately, there are some exceptions. These include (unless their icons have already been customized) the Applications folder, the Library folder, the System and System Folder folders, the Users folder, anyone’s home folder, their Desktop folder, their Documents folder, their Library folder, their Movies folder, their Music folder, their Pictures folder, and their Public folder. In other words, for all folders that have non-generic default icons, aliases to those folders fail to inherit the same icons.
22.

Unlike the Trash in Mac OS pre-X, and even the Recycle Bin in Windows, the Trash in Mac OS X has no idea where any of the items inside it came from. Only the most recently trashed item can be restored to its previous location (unless you remember the location and drag it there yourself), and even that can only be done (using the Undo command) if trashing that item was the most recent action performed in the Finder.
23.

Trying to open a file in the Trash from the Finder will, correctly, produce an error message (to prevent people from relying on the existence of a file that will disappear when the Trash is emptied). Dragging a document from the Trash to an application should result in the same error message, but it does not; the application will happily edit and save the document back to the Trash.
24.

All folder windows zoom out from their icon when opened, and zoom back into their icon when closed. All, that is, except for the Trash.
25.

An item’s color label highlights its text but not its icon. This allows a blue-labelled icon to look selected when it is not. It also causes unnecessary difficulty in finding a labelled item quickly, particularly when it is selected or when it is in Icon view.
26.

It is impossible to view, let alone modify, an item’s color label from its Info window.
27.

Disks cannot be given color labels, for no apparent reason.

Safari (1.2)

28.

Clicking once in the address field does not do what people want 99 percent of the time, which is selecting the address so it can be replaced by typing a new one. (This can be done without interfering with those who want to select only part of the address, as demonstrated by Firefox and by Internet Explorer for Mac.)
29.

Safari’s View menu gives greatest prominence to those items that will be used least often.
30.

The dates in Safari’s History menu do not follow the format you choose in the Formats tab of the International panel in System Preferences.
31.

Dragging a bookmark from Safari’s Bookmarks page to the Trash trashes the bookmark, as it should. Dragging a bookmark from Safari’s Bookmarks Bar to the Trash highlights the Trash, as if the bookmark will be trashed, but the trashing never happens.
32.

It is unnecessarily difficult to tell whether you successfully clicked on a link (or dragged a link to a window), or whether — as often happens with unsteady hands or dirty cybercafe mice — you just missed. The cursor does not change at all; nor is there an indeterminate progress indicator, as might be expected from software that has no idea when or whether a remote server will respond. The only feedback is a partial, non-animated filling in of the address field, looking almost indistinguishable from selected text in the field.
33.

The Show in Finder buttons in the Downloads window always look unavailable.
34.

When a link’s href attribute contains a stray space character (for example, Safari will go to the intended page, but it will never mark the link as visited.
35.

Multi-line text fields use a proportional font rather than a fixed-width font.
36.

Safari does not support HTML 4’s label element, but allows it to be styled. Many misguided Web authors style label in various ways to indicate its clickability, making its unclickability confusing.
37.

When the currently selected option in a select element is too wide to fit in the option menu, it is truncated. The truncation should be indicated with an ellipsis, but it is not.

Mail (1.3.3)

38. The network activity window is called Activity Viewer in Safari, but just Activity in Mail. This distinction exists for no apparent reason.
39.

The Stop buttons in Mail’s Activity Viewer are over-large and garish, and have a different appearance from those in Safari’s Downloads window for no apparent reason.
40.

The default set of toolbar buttons in Mail’s Customize Toolbar dialog is not actually the default set. The true default set also includes the Junk button, at the opposite end of the toolbar from the Delete button. But in the junk filter’s Training mode Delete and Junk are used in tandem (first mark a message as junk, then delete it), while in Automatic mode they are close substitutes (Delete to delete a message, or Junk to delete it and future messages like it). Therefore they should be immediately next to each other by default.
41.

Mail does not allow plain text attachments to be saved, assuming instead that they are part of the message text.

iChat (2.0)

42.

iChat’s Buddy List window uses a mini-sized scrollbar, despite the rest of the controls in the window (and the scrollbar in instant message windows) being normal size.
43.

If an instant message window is as tall as possible, every time you type a space the text field scrolls back to the first line, hiding what you just typed.
44.

The Page Up, Page Down, Home, and End keys can be used to scroll through a Web page in Safari even when the address field is focused. The same should work in an iChat instant message window when the text field is focused, but they do not.

Help Viewer (2.0.4)

45.

The Back, Forward, and Home buttons in the Help Viewer have a slightly different appearance from those in Safari, for no apparent reason.
46.

The search field is the only usefully focusable control when the Help Viewer opens. (Focusing the content area is not useful when the Help Viewer opens, since the contents page for an application’s help should be — and usually is — too short to need scrolling.) Therefore the search field should be focused by default, but it is not.
47.

The Help Viewer often takes a second or more to perform an action. During this time, it never provides feedback that anything is happening.
48.

Unsuccessful search terms are not displayed in the Help Viewer’s No matching topics were found page. This, combined with the lack of in-progress feedback, makes it impossible to tell whether a second search has also been unsuccessful or whether it is merely taking a very long time.

[Asher]

The problem does not lie with the Dock itself—if it makes a great demo, leave it in—but with Apple's apparent belief that it is a complete solution. The Dock is akin to a brightly-colored set of children's blocks, ideal for your first words—dog, cat, run, Spot, run—but not too effective for displaying the contents of War and Peace.

Contrary to my previously-held position, I no longer believe Apple should get rid of the Dock. It's just too pretty there in the store, and it does help set Mac apart from the more utilitarian appearance of Windows (although Windows grows more attractive with every release). You want that in sales. You want a visibly-apparent manifestation of the personality of the underlying technology. That's why automakers spend milliions making the outside of the car project an image of what's underneath the skin.

A certain class of Apple users—those who check their email once or twice a week and sometimes need to print an attached photo—may need nothing more than the Dock.

The rest of us need more powerful tools, so,
Apple, leave the Dock as the smashing demo it is, but also supply some serious, information-dense tools. You have the talent and wherewithal to make such tools as attractive as the Dock if only you will cease seeing this one single object as a complete solution.

Apple has made a few improvements to the Dock in the last three years. Items no longer jump around seemingly at random, although the size of the Dock continues to "wheeze" in and out without user control.. Items also act like buttons, so clicking anywhere within their confines will open them. Apple also quickly gave us the ability to turn off magnification, a major improvement in day-to-day usability.

The other good news is that independent solutions now exist for getting around every limitation of the Dock. Read Make Your Mac a Monster Machine to learn how to turn your Mac into a high-productivity, but still fun workhorse. Meanwhile, here are eight continuing problems with the Dock, plus a new one, a decided lack of color. Most of these are inherent, and the solution is more and varied tools. A few can be directly addressed by design tweaks.

The Dock by default sucks up around 70 pixels square minimum, more than four times as much vertical space as either the Windows task bar or the Macintosh menu bar. (Yes, you can set it much smaller, but then you make it progressively more difficult to identify an icon without "scrubbing" the screen with your mouse to reveal its label.) Couple that with Apple's move to 16:9 wide screens (read: short screens), and you have a real problem. For good measure, add in the Dock's habit of floating on top of working windows, and you have little choice but to hide it.

8.
Identical icons look identical
This was originally entitled "Identical pictures look identical." I pointed out that the Dock's use of thumnails in small sizes made all normal text documents look pretty much alike. Apple has now dumped thumbnails in return for identical icons. My original advice still holds: "We need information on data types, file sizes (as represented by the thickness of the icon), age, etc." They've now given us data type. We need more—any attribute that can help differentiate one object from another.

The better solution to this and many of these other limitations is to supplant the Dock with additional objects that are designed for representing groups of non-application objects, so that people aren't even attempting to put folders and documents in this already overloaded single object.


7.
Dock objects have no labels
The objects in the dock do not have labels.

That works fine in the demo, since every object shown is completely unlike every other object. However, put in three or four folders next to each other and the user becomes clueless.

Yes, the user can "scrub" the length of the Dock, forcing one label at a time to appear as they root around for the right folder. However, that takes time and, when dragging a document, ensures a high rate of serious error.

Again, the best solution is to provide something other than the Dock specifically designed to show such objects.
6.
Dock objects need color
Here's a different set of Word documents. (Well, you knew that from the picture, didn't you?) I have applied to each a different, bright color. (I particularly like the green one.)

One attribute newly (re)introduced for objects in OS 10.3, Panther, was user-settable color. In OS 9, this color was applied to the icon. Because of limitation in the algorithm, it produced mixed results, doing well with most icons, but failing badly for icons that had one strong predominant color already. Instead of addressing this problem, the OS X Finder team instead colored the text. Well, more precisely, they colored the general area around the text.

The Dock team apparently did not hear about any of these goings-on, because color is completely ignored by the Dock, both in the icon and the text, eliminating yet another attribute.

Color needs to be restored, with a more sophisticated algorithm, to the icons in general, and the Dock icons in particular.

5.
The Trash Can belongs in the corner

This decision was so wrong that several replacement desktop trash cans have appeared to address it. Dock diehards point out that they always use Command-Delete anyway. Of course they do! That's because having a hidden, constantly-shifting trash can sucks!

4.
The Dock's locations are unpredictable

Apple's solution to the early fire storm of protest over the Dock was to allow the user to hide it. That way, it doesn't float over all your applications. Slide below the screen with your mouse and the Dock appears.

This Windows copy job, unfortunately, suffers from the same defect as the Windows Task Bar: You can't predict where a given object is until you reach the bottom of the screen and cause the Dock to appear. Worse than with Windows, your job is not over. Now, you begin the task of scrubbing the length of the Dock, trying to force the labels to appear, hoping you won't go far enough out of range in the process to cause the bar to disappear on you. (The Dock is linear; the human hand was designed to move in an arc. We don't do well with scrubbing.)

3.
The Dock is a sprawler

The corners and edges of the screen are proven by Fitts’s Law to be the most easily reached targets. The low-information-density Apple Dock takes up a variable, but large measure of one entire side of the screen, leaving little or no room for high-density docks, such as those of DragThing. It's target region sprawls even beyond, covering one entire side of the screen.

This excessively-large target also ensures many mistakes, where people are simply sweeping the mouse too far while engaged in their application, suddenly triggering the hidden Dock.

The Dock needs to have a visible target. Hit the target and the Dock opens. Miss the target and the Dock won't open. Then supply a very slight delay, measured perhaps one twentieth or one tenth of a second to prevent accidental triggering. (The Dock, at the time of 10.3's release, has an excessively long delay, probably in response to the invisible, unpredictable sprawl problem herein discussed.)

This tab could be dynamic, one or two pixels deep and running the full length of the Dock, with the Dock acting much as it does now except in a more predictable manner. Or the user could elect to set a labelled tab of user-defined width, freeing up a lot of precious edge space. Still another option might have the Dock triggered by throwing the mouse in a corner. This could relieve much of the frustration of the variable-location trash can. Throw the mouse in the lower right-hand corner to grow the Dock up the display from that point, leaving the trash can in a consistent, predictable location.

(This by the way, is the way the Windows XP task bar should be triggered, instead of having any touch of the bottom of the screen display it.)
2.
The Dock replaced better objects

Both OS 9's Tab Menus and the Applications Menu are being forced into the dock. Tab menus were formed by dragging a Finder folder to the bottom of the screen, where it turned into a multi-level hierarchical menu. Tab menus in OS 9 had problems, not the least of which was that, every few weeks, the Mac crashed in such a way that they all moved to the center of the screen, opened as normal windows in random positions, and each had to be dragged to the bottom of the screen and placed in the desired position again.

A Dock-like device would be of great value in upgrading the current tab menu scheme. Unfortunately, while you can now drop a Finder folder in the Dock, then right-click on it to reveal it's contents in a Tab Menu style, it remains fatally flawed, since every one of your Tab Menu folders will have the same name displayed—namely, none.

Fortunately, however, actual improvements on the old Tab Menu do exist, even if Apple has lost the ability to make them. You'll find one discussed in, Make Your Mac a Monster Machine. In the old days at Apple, when we saw something like DragThing on the market, we would go buy it and incorporate it into the system. Let's hope someone at Apple is still watching out.

(We once had a couple of Berkeley students come down on the bus to Apple to demo what was to become Multifinder, the first instance of the modern Finder we've all come to love. We sent them back to Berkeley in a nice, shiny limo, along with a big, fat check.)

The Applications menu, in OS 9, sat in the upper right hand corner of the screen, giving people reasonable access to running applications. It had its problems; for example, it neatly avoided high-speed access by not accepting a click from the absolute corner of the screen. Nonetheless, it worked well enough and took up little space.

When we invented pull-down menus for the Lisa computer, back in the late-seventies, the concept was that you wanted to create information-dense objects that took up minimal screen space. The result was a single label that would instantly reveal a whole bunch of objects when touched. The Applications menu did that. The Dock, on the other hand, is as big when "closed" as it is when "open," unless you have magnification turned on, which causes some of us to become sea-sick. (Again, a great demo, but a poor daily performer.)

The Dock is also throwing the application menu's items in with everything else in the Dock, forming just one big jumble. (The applications are now arranged on one end, but that doesn't seem much of a win; it is still one big jumble.) Again, as revealed in Make Your Mac a Monster Machine a solution once again exists: The Applications menu is back, though from a third party. Apple needs to incorporate it once again into the interface, making it triggerable from a corner touch.

1.
The Dock adds bad behavior

The Dock adds a whole new behavior: Object annihilation. Drag an object off the dock and it disappears in a virtual puff of smoke. This is the single scariest idea introduced to the Macintosh since the original bomb icon. How would you feel if you spent eight hours working on your first Macintosh document, only to have it disappear entirely when you try to move it from the dock to the desktop? Pretty disorienting, no? This is a completely unnecessary concept for the user to have to learn, particularly in such a painful way. Makes for a "hot demo" though, doesn't it?

[Asher]

I recently tried to scroll through a list-view folder on an SMB share containing about 2,000 files using the Panther Finder on a dual 2GHz G5. The server was on the local 100Mbps LAN. It took me several minutes of patient hand-holding as I dragged the scroll thumb through small portions of the file list, waiting each time for the Finder to slowly display the icons for the newly revealed files before it would let me continue.

The Finder would literally not let me scroll to any of the "unknown" portions of the file list until it had finished doing whatever it was doing to display the icons of the newly revealed files. These files were all of the same type, and were plain, flat files with no resource forks and no Mac-specific metadata. Only after fighting with the window for several minutes was I finally able to drag the scroll thumb from the top to the bottom in one continuous motion.

Listing that same directory from the command line is nearly instantaneous. Some overhead for the GUI is expected, but this is ridiculous.

Unfortunately, making a lightning-fast GUI file browser is actually a very hard problem full of special-cases and in need of clever optimization. The Mac OS X Finder appears to use a lot of standard Mac OS X controls and views. Performance improvements in the Finder have partially been a result of the optimization of these OS-provided widgets.

But while optimizing common controls is an important task that can significantly improve the performance of all applications simultaneously, certain applications simply have needs that are far beyond what generic controls can provide. The Finder is one such application. Whether through completely new custom controls or through clever subclassing, the Finder needs to implement its views with an eye towards efficiently handling thousands of files and folders with ease and speed.

Even in situations where the underlying data is the gating performance factor (e.g. slow network disks), the Finder must do everything it can to remain responsive, showing as little or as much information as it has at the moment, but never blocking the user from interacting with the GUI. Controls and views that expect to be backed by in-memory objects and data structures are poorly suited to this task.

Independent of any other interface issues, I hope to someday view, scroll through, and manipulate vast numbers of files and folders in the Mac OS X Finder with the thoughtless confidence befitting a modern operating system running on a multi-gigahertz machine with gigabytes of RAM. Sorry, Panther Finder, but you are not yet that file manager.
Taking a poll

There's one final aspect of the Finder's performance that deserves some mention here, even though it's actually a usability issue at its core...or rather, it should be. As any software developer will tell you, "Polling is bad, m'kay?" Polling is the act of repeatedly rechecking some condition. An example that's relevant to the Finder would be repeatedly asking, "Are there any new files in this folder? Are there any new files in this folder? Are there any new files in this folder? Are there any new files in this folder?" and on and on at some regular interval.

This, needless to say, is not the best use of CPU cycles, since the answer will be the same nearly all of the time: "there are no new files in this folder, now leave me alone!" Okay, so I added that last part, but the sentiment is apt. Polling is indeed bad.

But if you think about the situation described above, the apparent responsiveness of the Finder seems to depend on the frequency of that accursed polling. Let's say you download a file to your desktop using a web browser. If the Finder only polls the desktop folder every ten seconds, that file won't show up for an average of 5 seconds. That's hardly "responsive."

Another alternative is to simply update Finder views when the user (or another program) tells the Finder to do so. This eliminates costly polling entirely. Even better, if applications faithfully notify the Finder of any changes they make to the file system, there will be no lag at all between the creation of a file and its appearance in the Finder. This is the system that Apple has chosen for the Mac OS X Finder, and it sounds like a good one.

In practice, however, not all applications appropriately notify the Finder after making changes to the file system. A command-line utility from the FreeBSD world is the worst-case scenario. It certainly can't be expected to have Mac-specific code for sending notifications to the Finder. Files created by one of these "uncooperative" (from the Finder's perspective) applications simply wouldn't show up in the Finder at all. Yikes.

The Mac OS X Finder has worked around this problem by polling just once when the user starts to do something with a particular folder. For example, a file copied to the desktop with the command-line utility "cp" will not appear until the user activates the Finder by clicking on the desktop, a Finder window, the Finder's Dock icon, etc.

Now it seems like we've covered all the bases. There's no polling at all, and the Finder is reasonably aware of any kind of changes to the file system. But issues remain. Most frustratingly, sorted list-view windows in the Finder have an annoying habit of updating just as you try to grab a file from them. If you're not paying enough attention, the window will re-sort its contents (due to a newly added, deleted, or modified file) and replace the file you meant to grab with another file. It is all too easy to really hose yourself this way, especially when deleting files.

This whole situation — polling vs. responsiveness — is somewhat indicative of what I have always viewed as a problem with the direction of Mac OS X's development. Granted, polling is bad, but its existence in classic Mac OS was indicative of a value system that put the user experience first. "What is the best possible user experience?" is the primary question, only then followed by "How can we make that happen?" In Mac OS X, it seems to me that the first priority has been to do what is most efficient, and then try to provided the best user interface that can feasibly be implemented on top of that foundation. The shoe is on the wrong foot in such a system.

It may seem contradictory to swear up and down about poor performance on the one hand and then ask that the user experience take precedence over all other concerns on the other, but performance is part of a good user experience. Focus on the user and performance will mostly take care of itself...yes, possibly meaning that you will have to implement new OS features in service of the user experience that you hope to provide. But the end result will be a better overall system. Quartz is one example of this principle in action, but the Mac OS X Finder seems to be a result of the opposite value system.

So let's look again at the responsiveness of the Finder when dealing with file system changes. Let's start with the premise that the Finder should always provide the user with an absolutely consistent view of the file system. This is essential to maintaining the illusion of direct manipulation. Obviously polling still sucks, especially if we need to poll several times every second in order to meet our responsiveness goals. What can we do that's better?

What if the responsibility for tracking file system changes and notifying any interested parties was moved from the applications to the operating system kernel itself? Since all local file I/O goes through the kernel anyway, surely it knows when, where, and how every change is made. This is all without polling, of course. There's no need to poll when you're the one making all the changes.

Well, it's Apple's lucky day. Faced with a similar problem — how to track state changes without costly, inefficient polling — those industrious FreeBSD developers have created a generic OS-level facility for asynchronous event notifications. It's called kqueue, and you can read all about it in this PDF file. Since Panther has synched with FreeBSD 5, it includes kqueue support. Now all the Finder has to do is register for notifications on all open Finder windows (and the desktop) and just sit back and wait for the operating system to inform it of any interesting events. Problem solved, and in a way that puts the user first!

Unfortunately, the Panther Finder does not do this. This feature is not absent due to the difficulty of its implementation. After a few days of effort, a handful of Ars Technica readers were able to whip something up that does the job. You can find the source code and some instructions for compiling it in the forum thread. The code is only about two pages long, and the most difficult part is finding a way to ask the Finder which windows are open. The code has to (sadly) poll the Finder periodically to gather this information. Apple's Finder developers would not have this problem.

So, why is there (apparently) no kqueue support in the Panther Finder? My guess is that Apple plans to add a new (or reimplement an existing) higher-level notification facility on top of kqueue, with APIs in CoreFoundation, and then Carbon and Cocoa on top of that. That's much more in keeping with Mac OS X's API structure than asking the Finder team to use the (decidedly Unix-y) kqueue APIs directly. But I could be wrong, and it could just be a lack of time that kept kqueue out of the Finder. Either way, in Mac OS X 10.4 the Finder team should proclaim "kqueue or bust."

[Verto]

Fun with Windows XP:

1. Pressing any key on the keyboard probably just caused you to download a malicious program that just changed all crucial filenames to pr0nf0rg0tz.

2. Unlike in OS X, where some windows use a brushed metal appearance and others use Aqua, but all look nice, Windows XP uses a consistently applied coat of Fugly.


Etc. Honestly, *****ing because iChat lists have an alternating blue and white highlight, but Mail doesn't. I'll take that over the problems besieging Windows anyday.

Oh, but wait. WINDOWS PLAYZ GAMES MACS SUCK LOLZZ

And yes, Ballmer is a businessman, although his talents are many and varied (DEVELOPER DEVELOPER DEVELOPER DEVELOPER ), which is why he took the comp back with him for MS tech people to look at. And that, apparently, was when the realized what a shoddy product they had created?

EDIT: And to clarify, I made my post after you posted the first copy paste. I really don't give a damn enough to read that all over again

[Asher]

If you're not naive, and if you're not mentally retarded, viruses should never be a problem on Windows.

Viruses and malware prey on stupidity, something that transcends OSes. If MacOS X had enough users to be worthwhile (their marketshare continued to fall in Q1 2006), they'd have malware up the yinyang too.

How many security fixes were in the last OS X patch anyway, 43 was it?

Here's something you may not know: Windows XP SP2 and Windows 2003 are government certified from a security standpoint (C2 cert), OS X has failed to certify yet.

[Fake Boris]

Bugs in software!!!

[Fake Boris]

Originally posted by Asher
The ****ty OS problem was fixed. You can boot into Windows XP on new Macs.

We're still waiting for a PowerPC fix.

[Dinner]

Originally posted by Verto
Fun with Windows XP:

1. Pressing any key on the keyboard probably just caused you to download a malicious program that just changed all crucial filenames to pr0nf0rg0tz.

2. Unlike in OS X, where some windows use a brushed metal appearance and others use Aqua, but all look nice, Windows XP uses a consistently applied coat of Fugly.

Is that the best you can come up with? I only use windows and I have not gotten any malicious programs in the last two years even though I share files all the time though I don't use IE.

[Verto]

That's all I cared to do. I don't want to put too much effort into responding to an old copy paste.