Re: Tracking Focus Between NSOutlineViews
Again - thanks for the extended notes here. I really appreciate the extra context I get form this group. Thanks, -Luther On Sun, Nov 2, 2014 at 6:56 PM, Graham Cox wrote: > > On 3 Nov 2014, at 11:13 am, Luther Baker wrote: > > > 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. > > > Why not make the milestone tasks children of a milestone item in the same > outline view? Then you remove the ambiguity of which item is selected - > there's only one, whether it's a milestone, a task or a subtask. The detail > view should display whatever's appropriate to the 'level' of the item > selected. > > Depending on the complexity of your details though, these could even be > inline as items in the outline view itself. View-based outline view rows > make that much easier than it used to be, and often more versatlie, since > if the user decides to open more than one at a time, they can, and just > edit freely. > > > Is FR a rabbit hole ... bcs naively, it certainly seems to be what I'm > looking for. > > If your detail view changes according to FR status, I think it'll become a > rabbit hole, because of the case of neither outline view having focus. What > does the detail view display then? Nothing? If so, tabbing into a detail > view field will remove all of the views from the detail view, including the > field you just tabbed into. Derp. > > > I was trying to keep everything in one window. Are people not > contextually repurposing areas like this? > > Master-detail designs are fine, in many cases. I'm not suggesting you > don't do that, just avoid the potential ambiguity of having two master > views. > > > In my mind, I was thinking "It's always an editor of whatever is > currently in focus.". > > It can't be, because parts of the editor itself will sometimes (often) > have the focus. It should be "an editor of whatever is selected". But to > make that work you don't want the selection to be ambiguous. So extend the > hierarchy so that milestones are containers for task groups, and releases > are containers for milestones. Also, if you allow *multiple* selections in > the table, consider how you'd make that work. For example, if all tasks > share a detail interface, and you select more than one task, would it be > useful to allow the detail editor to allow values for those several tasks > to be edited simultaneously? All values or only some? How do you display > values that differ among the tasks? The question can be avoided by only > allowing one selection at a time, but this could limit the user's abilities > in ways that cause other issues. Suppose they need to change some value of > a whole lot of tasks to some common value - if they have to do this one > item at a time they'll be cursing you. (n.b. bindings has solutions for > many of these questions). > > > Is Xcode worth considering here? Tap a class file and you get details > about that class in the right pane. Open a XIB ... Tap something in the XIB > and the details pane changes to reflect the XIB selection, not the file > anymore. Same goes for core data modeling while creating entities. > > > > Does that not demonstrate a potentially fine way to build user facing > software? > > The selection in Xcode's source list chooses an appropriate editor for the > selection. One of those editors - IB - has its own outline view for its > object hierarchy. But that second outline view is really the "detail", not > a master picker for further detail - the rest of the view shows a different > representation of the same information, laid out spatially rather than > hierarchically. That's why the two representations' selections stay in > synch - they're two views of the same thing. (i.e. with IB showing you have > master->detail+detail, not master->master->detail). > > --Graham > > > ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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 arch...@mail-archive.com
Re: Tracking Focus Between NSOutlineViews
On 3 Nov 2014, at 11:13 am, Luther Baker wrote: > 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. Why not make the milestone tasks children of a milestone item in the same outline view? Then you remove the ambiguity of which item is selected - there's only one, whether it's a milestone, a task or a subtask. The detail view should display whatever's appropriate to the 'level' of the item selected. Depending on the complexity of your details though, these could even be inline as items in the outline view itself. View-based outline view rows make that much easier than it used to be, and often more versatlie, since if the user decides to open more than one at a time, they can, and just edit freely. > Is FR a rabbit hole ... bcs naively, it certainly seems to be what I'm > looking for. If your detail view changes according to FR status, I think it'll become a rabbit hole, because of the case of neither outline view having focus. What does the detail view display then? Nothing? If so, tabbing into a detail view field will remove all of the views from the detail view, including the field you just tabbed into. Derp. > I was trying to keep everything in one window. Are people not contextually > repurposing areas like this? Master-detail designs are fine, in many cases. I'm not suggesting you don't do that, just avoid the potential ambiguity of having two master views. > In my mind, I was thinking "It's always an editor of whatever is currently in > focus.". It can't be, because parts of the editor itself will sometimes (often) have the focus. It should be "an editor of whatever is selected". But to make that work you don't want the selection to be ambiguous. So extend the hierarchy so that milestones are containers for task groups, and releases are containers for milestones. Also, if you allow *multiple* selections in the table, consider how you'd make that work. For example, if all tasks share a detail interface, and you select more than one task, would it be useful to allow the detail editor to allow values for those several tasks to be edited simultaneously? All values or only some? How do you display values that differ among the tasks? The question can be avoided by only allowing one selection at a time, but this could limit the user's abilities in ways that cause other issues. Suppose they need to change some value of a whole lot of tasks to some common value - if they have to do this one item at a time they'll be cursing you. (n.b. bindings has solutions for many of these questions). > Is Xcode worth considering here? Tap a class file and you get details about > that class in the right pane. Open a XIB ... Tap something in the XIB and the > details pane changes to reflect the XIB selection, not the file anymore. Same > goes for core data modeling while creating entities. > > Does that not demonstrate a potentially fine way to build user facing > software? The selection in Xcode's source list chooses an appropriate editor for the selection. One of those editors - IB - has its own outline view for its object hierarchy. But that second outline view is really the "detail", not a master picker for further detail - the rest of the view shows a different representation of the same information, laid out spatially rather than hierarchically. That's why the two representations' selections stay in synch - they're two views of the same thing. (i.e. with IB showing you have master->detail+detail, not master->master->detail). --Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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 arch...@mail-archive.com
Re: Tracking Focus Between NSOutlineViews
On Nov 2, 2014, at 16:23 , Luther Baker wrote: > > Is Xcode worth considering here? Tap a class file and you get details about > that class in the right pane. Open a XIB ... Tap something in the XIB and the > details pane changes to reflect the XIB selection, not the file anymore. Same > goes for core data modeling while creating entities. > > Does that not demonstrate a potentially fine way to build user facing > software? What Xcode does kinda sucks. Did you notice that Xcode 6 introduce *two* highlight states into the navigator pane, just to resolve the sorts of ambiguities Graham mentioned? Suddenly, things get twice as complicated (in terms of working out what you’re looking at), and it doesn’t really solve the problem anyway. For example, if you click on the “other” highlighted item to get back its editor, you’ll usually start editing the file name accidentally. Also, your original plan breaks down when using the keyboard. Pressing Tab will change the item that’s controlling the detail view, but the think you tab to might not be your final destination. In your scheme, therefore, some state changes are not possible via the keyboard. You’re better off doing something simpleminded, such as: — Put a pushbutton in each outline list row, which causes the corresponding detail to appear — Put a pushbutton at the bottom of each outline list, which causes the detail corresponding to the selected list item to be displayed — Put a checkbox (which doesn’t have to look like a standard checkbox) in each list row, and coordinate the states between the items and lists. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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 arch...@mail-archive.com
Re: Tracking Focus Between NSOutlineViews
Good question. I struggled with that. For now, the 2 outline views give me the option of hierarchy should I need it ... Releases / milestones / iterations Features / tasks But to your point, browser semantics are an option if my design is going to confuse the user. Is Xcode worth considering here? Tap a class file and you get details about that class in the right pane. Open a XIB ... Tap something in the XIB and the details pane changes to reflect the XIB selection, not the file anymore. Same goes for core data modeling while creating entities. Does that not demonstrate a potentially fine way to build user facing software? Thanks, Luther > On Nov 2, 2014, at 5:42 PM, Graham Cox wrote: > > >> On 3 Nov 2014, at 9:50 am, Luther Baker wrote: >> >> I have multiple NSOutlineView objects on the screen at one time. >> >> As you select items in secondary outline views, the existing selections in >> the other outline views stay selected, and generally turn from a selected >> BLUE to an alternate selected GRAY. That is fine and expected. > > > Incidentally, are you sure NSBrowser wouldn't be a better fit? I'm wondering > how usable multiple NSOutlineViews would be. > > --Graham > > ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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 arch...@mail-archive.com
Re: Tracking Focus Between NSOutlineViews
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 wrote: > > >> On 3 Nov 2014, at 9:50 am, Luther Baker 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 (Cocoa-dev@lists.apple.com) 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 arch...@mail-archive.com
Re: Tracking Focus Between NSOutlineViews
On 3 Nov 2014, at 9:50 am, Luther Baker wrote: > I have multiple NSOutlineView objects on the screen at one time. > > As you select items in secondary outline views, the existing selections in > the other outline views stay selected, and generally turn from a selected > BLUE to an alternate selected GRAY. That is fine and expected. Incidentally, are you sure NSBrowser wouldn't be a better fit? I'm wondering how usable multiple NSOutlineViews would be. --Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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 arch...@mail-archive.com
Re: Tracking Focus Between NSOutlineViews
On 3 Nov 2014, at 9:50 am, Luther Baker 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 (Cocoa-dev@lists.apple.com) 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 arch...@mail-archive.com
Re: Tracking Focus Between NSOutlineViews
On Nov 2, 2014, at 4:50 PM, Luther Baker wrote: > 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). This is not a selection event. It's a change of the window's firstResponder. The outline view shows its selection in blue when it or one of its descendant views is the first responder of the key window. > Is there a best practice convention to "follow" the active selection so I > can update the contextual view correctly? You follow whether or not the window is key by observing the NSWindowDidBecomeKeyNotification and NSWindowDidResignKeyNotification notifications. If the window delegate implements -windowDidBecomeKey: and/or -windowDidResignKey:, it is made to observe those notifications with those methods automatically. You can follow a window's firstResponder using key-value observing (KVO). Regards, Ken ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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 arch...@mail-archive.com
Tracking Focus Between NSOutlineViews
I have multiple NSOutlineView objects on the screen at one time. As you select items in secondary outline views, the existing selections in the other outline views stay selected, and generally turn from a selected BLUE to an alternate selected GRAY. That is fine and expected. 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). 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. Just looking for some experienced input here, a rough suggestion in the right direction here so that I don't reinvent built in functionality. Every Source / Outline View / Detail view app is doing it these days. Thanks, -Luther ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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 arch...@mail-archive.com
