My current project idea is for a 3 way split view app with milestones on the left (in a source view), hierarchical tasks in the middle (a standard outline view) and a swappable details area in the right pane (this is sort of what omnifocus does).
You start the app and if you select a milestone I show a "milestones detail editor view" in the right "details" area. Also, after selecting that milestone, a hierarchical view of milestone tasks shows up in the middle view. Now you select one of the tasks the details area changes to show a task editor for that specific task. All good so far. Oh, you realize you need to fix something in the milestone ... so you tap that same milestone again and the milestone editor shows back up on the right (and yes, the task is still selected in the middle, just not emphasized). Is that behavior an anti-pattern of some sort? Is there a more intuitive way? Is FR a rabbit hole ... bcs naively, it certainly seems to be what I'm looking for. I thought the current trend was away from modals and panes ... so I was trying to keep everything in one window. Are people not contextually repurposing areas like this? In my mind, I was thinking "It's always an editor of whatever is currently in focus.". Would appreciate any alternatives or validation either way. Thanks as always for lending your skills to this discussion! Thanks, Luther > On Nov 2, 2014, at 5:27 PM, Graham Cox <[email protected]> wrote: > > >> On 3 Nov 2014, at 9:50 am, Luther Baker <[email protected]> wrote: >> >> Now, off to the right side of the window, I have a context DETAIL view that >> displays a few editable fields - depending on the the active selection >> (just like Xcode does with the contextual right hand view). >> >> The outline view delegates fire when a selection changes ... or should >> change -- but they don't say anything if you simply "reselect" an existing >> selection (turning it from GRAY to BLUE). > > There is no change to the selection. What has happened is that there has been > a change to the view that has first responder status in the window. > >> Is there a best practice convention to "follow" the active selection so I >> can update the contextual view correctly? I am using view based outline >> views -- so I guess I could put mouse handlers on them - or the rows - or >> the cells ... but I'd prefer to use the NSOutlineView tooling (if it >> exists) to track the active selection. > > I think this may indicate a problem with your design, if the current first > responder makes a difference to your detail view, you're probably Doing It > Wrong™. What happens when you tab into one of those detail fields? It becomes > first responder itself, so all of your outline views lose focus. If you were > tracking this FR status to update your detail view, trying to type into a > field would cause that field to disappear. > > I would just use the selection indexes of your outline view(s) to set up your > detail views and ignore FR state. Tracking FR state can be done but it's > actually not that easy, since there are no notifcations you can hook into, > though you can KVO observe it. This is likely deliberate to stop people > trying to do the sort of thing you think you want here. Your outline view > delegates are informed when the selection changes, that's the only > information you should be using to determine your detail view content. > > --Graham _______________________________________________ Cocoa-dev mailing list ([email protected]) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
