Tinderbox Forum

Outline View : Restrict movement to container?

HI,

I’m working with a big messy mind map and imported it’s note inside TB9. Currently I’m working with simple structure

Root->2021->MindMap

I’m doing all work inside Mindmap container, When processing notes, I have to re-create hierarchy by moving items in outline view , I accidentally keep moving items to 2021 container , is there a way to restrict the movement of outline to "Mindmap"container in current situation.

Not really; you could use a rule, but that’s overkill.

Suggestion 1: increase the magnification in the outline, to make the drop targets easier to hit.

Suggestion 2: the sort of sorting is often easier to do in map view

Thanks ! I will look again into Map view or create a new map and do everything in root

I may be missing something, but if you are moving items within 2021, then hoist the container so only the container is in view.

To ‘hoist’ a container in Outline, i.e. make only that container’s children/descendants in-scope of the view, double-click the 2021 containers outline icon.

When as container is hoisted in Outline view, as in Map view you see a breadcrumb bar at the top of the view. Click any item in that bar to re-set the current view to that scope.

On 9.0 , even if an item is hoisted, you can move it to root level. Using Shift+Tab , unless I’m missing some keyboard shortcut

Not for me—ah, the ⇧+⇥ (Shift+Tab) shortcut, does work but doesn’t show the effect until the view is refreshed. You can promote a note (via shortcut) out of the current hoisted scope but the Ui fails to show this correctly)

I don’t think the result is intentional but either result is a fault of sorts:

  • To me, the shortcut should have no effect if used on the child of a hoisted container. The logic being, if you want to promote the child, first change the view scope to one including the intended target location. IOW, you can’t —via shortcut or other menu command—move the note out of the current view. Of course, action code is an exception but we’re not talking about code here.
  • Alternatively, if the note can be shifted out of current view scope, the UI should update accordingly.

To me the first makes more sense.

Another take is that if Shift+Tab moves the note out of current scope, the view is auto-shifted up one level so that the shifted note remains visible.

BINGO this is precisely what my request was , that I’ve selected the scope , ideally it should adhere to it.Maybe 9.5 @eastagate

Now issue #3433 on the roadmap.