Feature request - parent attribute view/window

I’ve started using Tinderbox to manage my meetings and notes and have developed a pretty robust process. One thing I’m finding is that I would like to be able to see and edit the attributes of the parent folder (i.e. the shell of the meeting) while I’m working on notes inside the container (i.e. the notes about the meeting). See the image below.

  1. I have a meeting container, I click into it
  2. I add notes about the meeting
  3. I’d like to able to click a hotkey and display and edit the attributes of the parent (I’ve mocked this up in the image)

I’m wondering if this ever might be possible.

Why not have another tab in which the parent is visible?

That certainly works but that requires swapping back and forth between tabs. You could also open a separate window, which is the option I do now, but this only works when you’re on a big monitor.

Why not keep the meeting info and the notes for the meeting in the same note, and then explode it later?

Seems a bit three-ring-circusy to participate in a meeting, manage a bunch of different attributes in different notes, fiddle with a map, and jump around from note to note. The fancy stuff can be done outside the meeting time maybe?

We’ll, for a variety of reasons:

  1. the meeting container is different than the notes and ideas generated during the meeting
  2. I create the container first and then start generating the notes in the container. When a note is created in the meeting container I have the note ID $ID(parent) added to the new child note’s $Source. Now if that original person, idea, project note moves out of the original meeting container I can always track it back to its source
  3. Sometimes I setup meeting containers a few days ahead of time so that I can drop in prep notes.
  4. There are other reasons too

Actually, the app design logic here is, IOM, wrong. In Map view If I deselect all map items, then if I call get info on a container map when no item is selected, I should get the parent (container) info, not nothing as it is patently obvious as to use intent.

Edit: on re-test above is not true

As discussed elsewhere, if working at root different rules apply. But, friends don’t let friends make root level maps for other than quick tests. For a long term doc, put ‘content’ in a root container, IOW not your top map not being at root level. Your future self will thank you.

Took me a bit to understand what you’re saying here. I actually to very little at the root. Everything is in sub-containers. I never thought about clicking on the map to get the parent container info view to come up. I could see what that would be useful in many contexts, but in the one I’m working through it would not be. The info pane gives me too many options, I just want see the attributes that I associated with the parent’s prototype. Maybe, rather than executing it in the way I did in my mockup, there would be a new menu in the info, something like “PrototypeAtt”, i.e. Prototype attributes. This would filter the attributes associated with the parent view to one view. I do see one problem with this is that this would not allow me to see the parent’s attributes, however, while working on the notes.

Thanks. But I’m not sure what I’m looking at.

The opt-cmd-x hotkey will open a small floating text window that includes all of the display attributes of the note. It’s not the same thing as what you’re suggesting but the window is compact enough to be perhaps manageable on small screens. Just a thought.

I’ve corrected my previous post above, Get Info can be called from the map background - i.e. no view selection either by Cmd+Opt+i or the context menu. No idea why that didn’t work the other day (and no, I wasn’t testing at root!).

Anyway, apologies to all for any confusion I may have caused.

@bcrane interesting idea, I can try that in my workflow.

Paul, I agree. I did not suggest that it needed to be a priority. Was just suggesting it as it is something I’d find helpful. I think I can use @bcrane’s suggestion to suite my purpose.