One of the mixed blessings about developing software for the mac is that there's high user interface standards. And, more or less, a push for consistency. This is good in one way. Any good framework will already handle drawing of most items. Buttons, menus, tables, etc. Cocoa throws in more things for free, like spell checking and drag-and-drop for text fields and the like.
But what about things not in the framework? Custom controls and displays? Throwing in code is the easy part; the hard part is knowing what it should do; the behaviors and graphic styles necessary. One of the biggest request for help on the dev boards, and tools offered, is to recreate the look and feel of some of Apple's programs in order to maintain consistency. One of the biggest features of Leopard that won't be trumpeted is pushing aside aqua, brushed metal, and a few other window designs in exchange for a single consistent window style.
The project I'm working on has something akin to a file browser in it. It's different enough to merit its own custom code. This means looking at how the finder handles selection and dragging. Since I don't have the 10.5 seed, I took a look at how the 10.4 Finder does things. I've used macs for years, and it's only now that I noticed this very strange inconsistency in how it's done. Here's to hoping they FTFFed in 10.5.
There are three ways to view files in a Finder window. The first two are descendants of the classic MacOS, the last from a NextStep heritage. Icon view is where the files are spatially placed to the user's wishes with the label under or to the right of the icon. List view is a table, with sortable columns for file name, date modified, file size, etc., and each file is its own row. Column view at first glance is related to list view, with files sorted by name, showing only the icon and file name. But instead of columns for more file details, the column to the right is the contents of the selection, allowing you to drill down. But there's some inconsistencies.
List view:
- Selecting a file causes the entire row to be highlighted, but doesn't darken the icon.
- Command-clicking then dragging a selected file will deselect the file and not drag it.
- Dragging an unselected file will select the file before the file's dragged.
- A dragged file has no highlights on the text or icon.
- When something is dragged onto an application or folder, the destination looks identical to being selected.
- Afterwards, the selection is either cleared, or set to the dragged file.
Column view:
- Selecting a file causes the row in that column to be highlighted, and doesn't darken the icon, the same as list view.
- Command-clicking then dragging a selected file will deselect the file, but will drag it (unlike list view).
- Dragging an unselected file will not change the selection (unlike list view).
- A dragged file has no highlights on the text or icon like list view.
- When something is dragged onto an unselected application or folder, the destination has a rounded rectangle highlight on just the text, the icon is darkened, and generic folder icons open slightly (unlike list view).
- When something is dragged onto a selected application or folder, the destination has the row highlighted like a selection, but the icon is still darkened, and generic folder icons still open slightly (unlike list view).
- Afterwards, the selection is unchanged (unlike list view).
Icon view:
- Selecting a file causes the text to be highlighted in a rounded rectangle, and a grey rounded rectangle behind the icon. If there's more than one line, it's a rounded version of the union of the rectangles. The icon's selection rectangle doesn't touch the text selection area (Unlike either List or Column). And finally, the icon itself isn't darkened.
- Command-clicking then dragging a selected file will deselect the file, but will drag it (like Column, but unlike list view).
- Dragging an unselected file will select the file before it's dragged (like list view, but not column view).
- A dragged file appears as it does on the window. Therefore, a selected file, while dragged, will have the rounded rectangle highlight and background (unlike both list and column view).
- When something is dragged onto an unselected application or folder, the destination appears as if selected with the icon un-darkened (Like list view, unlike column view) but generic folder icons open slightly (unlike list view, but like column view).
- When something is dragged onto a selected application or folder, the destination has the file highlighted like a selection, but the icon is still undarkened (like list view, unlike column view), and generic folder icons still open slightly (like column view, unlike list view).
- Afterwards, the selection is unchanged (like column view, unlike list view) if the dragged file went inside a folder. Otherwise, if the file is in that window, the selection is changed to the dragged file (unlike either list or column view).
So. Which behavior should my app emulate? Were it not for the fact that booting into MacOS 9 (in order to get screenshots for "Return of Buster") almost made things unbootable (Almost making it the "Revenge of Buster"), I'd catalog the classic behavior. I don't include the open/save dialogs because those aren't the typical file browsers I need to emulate. But last, but not least, there's one final area of file display to consider: The Dock.
Consistency with the Dock isn't as vital, as it is a separate entity. Because of the ability to quit an application by removing it from the dock, it's understandable that, while list, icon, and column view leave the un-ghosted file image behind, the dock removes it. Text labels aren't displayed unless the mouse is over them. Because the text label isn't shown normally, the lack of green selection areas is also understandable.
However, it is noteworthy that when clicked, the icons do darken while in place (unlike column, list, or icon view), but when dragged, are ghosted versions of the unselected file (like list and column view, but not icon view). Futhermore, Dragging a file over a dock application or folder darkens the icon (like column and unlike icon and list view).
So. What's a coder to do? There's so many standards, and I'm not privy to how things are in 10.5. But as an attempt at consistency and usability, here is behavior I've chosen:
None of the finder views darken the icon during selection, but column view and the dock both darken the icon of a drag destination. Since it's good to differentiate between being a valid drop destination, and merely being selected, darkening the drag destination icon seems like a logical choice.
Only column view has a different highlight area for drop destinations and selections, highlighting only the text and not the icon for the former, and including the icon, and entire row for the latter. If the dock is included, the fact that the dock doesn't highlight any area adds to the 'Icon destinations are only darkened, not highlighted' rule. Finally, like differentiating between selection and drag destinations, differentiating between drag destinations that are unselected and drag destinations that are selected makes the final argument for this otherwise rare behavior.
- Unselected: No highlight, light icon
- Selected: Highlighted icon and text, light icon
- Drop destination: Highlighted text only, dark icon
- Selected drop destination: Highlighted icon and text, dark icon
The highlight area is a full rectangle only when the selection area stretches to the edges (List and column view), as in the selections of list and column. When the highlight area doesn't reach, the region's corners are rounded (Icon view, column drop destination). While icon view has a different color and separate rounded rectangle for the icon's highlight area, I see no reason why it shouldn't be part of the text highlight area instead.
Quickly dragging a file (like column view), as well as dragging a command-click deselected file (like column and icon view) will cause the drag to happen, with the file still unselected. Finally, like files from column and list view, the file isn't highlighted, as the transparency is sufficient. This is also because other dragged items, such as selected text, aren't highlighted, either. Also using dragged text as a deciding metaphor, a successful drop will select the dropped item; an unsuccessful drop won't change the selection.
Of course, this might all change with 10.5's release, but if it means a finally consistent set of behaviors, it'll be worth it. Trying to keep up with shifting UI standards is a real drag.
