The Omni Group
These forums are now read-only. Please visit our new forums to participate in discussion. A new account will be required to post in the new forums. For more info on the switch, see this post. Thank you!

Go Back   The Omni Group Forums > OmniFocus > OmniFocus 1 for Mac
FAQ Members List Calendar Today's Posts

 
new column settings broke my perspectives Thread Tools Search this Thread Display Modes
i hate the new column flexibility. now it's practically impossible to get column widths to match between perspectives, or even to get the date columns to match each other within one perspective. and if i do spend time getting columns to match between perspectives, then i discover that one of the widths needs adjustment, i have to go into *every single perspective* to fix it. this basically means i will tend to live with column widths i don't care for (so, i will hate the program a little bit whenever i use it), and that i will avoid making new perspectives in the first place, since it's so much work getting them consistent with one another.

"thanks" for making OF even more cumbersome to use.
 
I'm getting the same error message (***-[NSCFDictionary setObject:forKey:]: attempt to insert nil key) when I click on the only of the column headings. And frankly, I would be the last person to attempt to insert a nil key.... ;-)
 
Just updated to latest version and the error message went away.
 
Quote:
Originally Posted by markb View Post
i hate the new column flexibility. now it's practically impossible to get column widths to match between perspectives, or even to get the date columns to match each other within one perspective. and if i do spend time getting columns to match between perspectives, then i discover that one of the widths needs adjustment, i have to go into *every single perspective* to fix it. this basically means i will tend to live with column widths i don't care for (so, i will hate the program a little bit whenever i use it), and that i will avoid making new perspectives in the first place, since it's so much work getting them consistent with one another.
Yeah, I spent some time not long ago trying to get the splitter between the Library and the content view to be consistent across perspectives, and I started to do the same with the columns when I saw that they'd moved into perspective land.

Gave up. Not worth it.

I can see wanting to include or not include certain columns in a given perspective, I suppose, (although I'm not clamoring for that feature myself), but I can't imagine needing this granularity of per-perspective control. Of course that opens up implementation questions: where do you store widths if the column visibility is in the perspective but putting widths there is a giant headache for users?

One answer would be to store app-wide widths for each column combination. Users wouldn't/shouldn't need to think about this at all, but observant users would notice that if they have a view with name, due date, and duration and adjust the width of the name column, the same width would appear in other views that include those particular columns.

Just so that i don't sound too cranky about this recent change, let me say thanks for one column-related feature: I like the way the window adjusts to the total column width. In other apps, when I grab ahold of a column's edge and start to move it, I never really know what other columns will adjust to accommodate my change, and it probably won't be the ones I really want to resize, which means an adjustment to one column's width will often require tinkering with several column widths to get what I want. In OmniFocus, the answer to that question is simple: when I resize a column, none of the other column widths will change. Thanks for that, really.

Last edited by davisre; 2007-12-08 at 01:23 PM.. Reason: typo
 
I have only three Perspectives I care about, and the default column widths seem OK so far. So the recent change was not a personal hardship. But I foresee making more use of Perspectives. So I agree with the concerns about perspective-specific column widths.

Quote:
Originally Posted by davisre
One answer would be to store app-wide widths for each column combination.
That seems like the right solution to me. This additional development effort would save the users a lot of time and frustration.

[submitted as formal feedback]
 
for me what would be ideal is nicely-behaving "auto" column widths, and to have this be the default. the only reason i change column widths is to make dates, projects, and contexts not wrap to two lines. it's easy to imagine the computer taking care of this for me, where those columns are always wide enough to make everything in the window one line, and the "topic" column is the lowest-priority if there's not enough total width to make everything one line tall.
 
Quote:
Originally Posted by markb
for me what would be ideal is nicely-behaving "auto" column widths, and to have this be the default.
It would be interesting to experience auto-width.

I suspect I'd want to override it for some columns (e.g., context in Planning mode, Project in Context mode) because some entries are unusually long. I'd rather truncate some of these rather than steal space from the Name column, which I want to be as long as practical.

If nicely-behaving auto-width could be based on the width of the majority of column values, not simply the widest value, I expect I'd be happy.
 
Quote:
Originally Posted by markb View Post
for me what would be ideal is nicely-behaving "auto" column widths, and to have this be the default. the only reason i change column widths is to make dates, projects, and contexts not wrap to two lines. it's easy to imagine the computer taking care of this for me, where those columns are always wide enough to make everything in the window one line, and the "topic" column is the lowest-priority if there's not enough total width to make everything one line tall.
I feel the same about this one.
 
Quote:
Originally Posted by Ward View Post
It would be interesting to experience auto-width.

I suspect I'd want to override it for some columns (e.g., context in Planning mode, Project in Context mode) because some entries are unusually long. I'd rather truncate some of these rather than steal space from the Name column, which I want to be as long as practical.

If nicely-behaving auto-width could be based on the width of the majority of column values, not simply the widest value, I expect I'd be happy.
I would like to have "auto-widths" for columns also!
 
auto widths would be OK and I can see the appeal, but my preference is for the ability to set default column widths that apply across perspectives.

Visually, I just like a little space in my columns so it orients right to my eye. The problem with auto widths is you get JUST enough width to avoid wrapping and that always looks cramped to me.

But if we could get them as options to do either, that would rock. But I agree, the current way it’s done and having to maintain it at the Perspective level is a problem.
 
 




Similar Threads
Thread Thread Starter Forum Replies Last Post
Omnigraffle canvas settings for 12-column grid? Handycam OmniGraffle General 3 2013-01-28 12:33 PM
iPhone v1.10 Broke Perspectives glass1234 OmniFocus for iPhone 3 2011-07-01 05:29 AM
Column width settings not working ? ayodh14 OmniFocus 1 for Mac 4 2011-03-16 05:21 AM
How to create a perspectives with settings for both modes? KeithFK OmniFocus 1 for Mac 1 2009-06-12 01:14 PM
Perspectives still broke in 539 ext555 OmniFocus 1 for Mac 0 2007-11-14 02:56 AM


All times are GMT -8. The time now is 04:54 AM.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2024, vBulletin Solutions, Inc.