Re: Tracking Focus Between NSOutlineViews
Re: Tracking Focus Between NSOutlineViews
- Subject: Re: Tracking Focus Between NSOutlineViews
- From: Luther Baker <email@hidden>
- Date: Sun, 02 Nov 2014 21:29:31 -0600
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 <email@hidden> wrote:
>
> On 3 Nov 2014, at 11:13 am, Luther Baker <email@hidden> 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 (email@hidden)
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:
This email sent to email@hidden