Customizing Columns in OmniFocus 2.3
Today’s update to OmniFocus, v2.3, is all about (OK, is mostly about) column customization. OmniFocus 2 introduced the Fluid layout, which turned tasks with a lot of data—defer and due dates, flags, context, project, and notes—into a readable row.
With 2.3’s Custom Columns layout, you can pick and choose what data you’d like to show, which Perspectives show what (Pro), or just flip a switch once to effect change everywhere.
[…]
This update also introduces Title Folding, which collapses an action’s title to just one line to keep row height consistent. Unless the row is selected, of course, in which case it’ll unfold. Turn it on in the View menu (Show Full Item Title->When Selected).
The Fluid layout was terrible for data density. An esoteric preference was added to put everything back on one line, but there was still too much white space. This update is a step in the right direction because in Custom Columns mode the rows are spaced more tightly. I’m not fond of seeing “defer” and “due” placeholders in every row, though; previous versions only showed these on mouseover, reducing the clutter.
There’s still no way to reduce the width of the sidebar (which is about 2x as wide as my widest context name), nor is there a way to resize the columns (which devote 3–4x as much space as needed to my project names).
Update (2015-12-04): William Van Hecke and Curt Clifton:
On the surface, the solution might seem to be to just bring back OmniFocus 1’s spreadsheetesque layout. But we believed we could design for these needs while holding on to OmniFocus 2’s hard-earned improvements in approachability. The result of this quest for balance is the new Custom Columns layout. Superficially, it looks a bit like OmniFocus 1, but Custom Columns have a lot more intelligence behind the scenes.
Update (2015-12-10): William Van Hecke and Curt Clifton:
Here’s a diagram showing the structure of controllers and views in an OmniFocus window before we added Custom Columns layout.
[…]
For Custom Columns layout we needed to use different table cell views, but wanted to retain as much of the existing, working code as possible. As the figure above shows, both
OFIProjectTableCellViewandOFIActionTableCellVieware backed by.xibfiles and have a common superclass,OFIActionProxyTableCellView. We wanted to add two more leaf nodes and.xibs for Custom Columns layout:OFIProjectColumnarTableCellViewandOFIActionColumnarTableCellView. These classes needed to share some behavior with each other, but also needed to share some behavior with their corresponding Fluid variant. For example, bothOFIActionTableCellViewandOFIActionColumnarTableCellViewneeded to manage their status circles. This is a classic example of the diamond inheritance problem.Since Objective-C (and Swift) don’t have multiple inheritance, we chose to solve this diamond inheritance by introducing assistant classes for the action and project table cell views. Here’s a diagram showing that design.
[…]
Cocoa’s solution for these cases is
NSStackView, which allows you to set priorities on subviews and have them automatically removed as needed.NSStackViewis great for many use cases. Unfortunately, we’ve found that it doesn’t yet perform adequately when used in table cell views, many dozens of which can be laying out at once (for example, while you resize a window).
