Multi-window tab navigation history behaviour

vvvv gamma bug
1

I’d like to give feedback regarding the multi-window (docking) feature.
It’s really great to be able to view multiple patches at the same time. thanks for introducing it last year!

Unfortunately, I’m finding myself falling back to single view because the navigation history completely breaks apart when working with multiple windows.

…I wonder if it’s only me being incredibly frustrated, maybe because I still don’t get how things work.

My simple thinking is that each window (I mean “docking space”, where you can have tabs), should have its PRIVATE navigation history.
This history should simply keep track of the active tabs of the window so that you can go back and forth through it.
There shouldn’t be any “global” history, that tries to keep track of across-windows jumps. that simply messes up things, in my opinion.
each window just minds its space.

“across-windows” case scenario:
if you middle-click on a node to navigate to its definition and the definition patch is open as a tab in another window, this is what should happen:

  • the tab of the patch definition should become the active one in the window where it belongs.
  • this tab should also go on top of the history stack of the parent window
  • nothing should change (no new active tab and no navigation history update) in the window where we come from

in this way, i can keep track of the navigation of each window, i know where i came from and can eventually go back to it.
everything else across the windows feels overdone and not effective.

I’d like to get devvvvs and users opinion

thanks

1 Like
2

We thought a lot about this topic indeed.
In our discussions, we covered browser-like navigation - with a history per tab - and all sorts of modes unheard of or known from other authoring environments.
Then we realized that this shouldn’t block us from already offering multiple windows, docking etc.
So this is something that we likely come back to.

2 Likes
3

I agree the back/forward navigation is mostly ALMOST what you expect. I would actually prefer a global history across documents.

If I click into a hierarchy of nodes I expect that if I go “back” I always go back to where I was before, like the back button in a browser. Since in a browser tab you can navigate pages, it makes sense that the history is per tab. But in vvvv each page opens in a new tab, so it makes sense that if you go back you go backwards through the tabs.

This mostly works if you go like 1 or 2 hierarchies deep, but once you work across documents it usually breaks, meaning you press back multiple times, but never go back to where you were and end up having to manually find the patch.

The tabs also don’t tell/show you which document something is in, making it even more difficult.

I think one way to improve browsing patches is to actually provide an alternative to the tabs, which brings me back to the Document Panel. If it could show open files and their patches in a hierarchy, that would really help.

anyways, +1 for a global history like I in the browser. It’s sort of muscle memory, as the back/forward button on the mouse work in the browser and in vvvv. If they are the same buttons by default, I believe they should work the same way.

4

wait, we need to clarify something :)
I’m against a Global History, if by that we mean something that keeps track of active tabs across multiple windows.
It should behave like in a browser: if you create a new window, that window has its tab history, that doesn’t interfere with the other windows.

Certainly we could discuss what’s the best scenario, where you don’t open a new tab for every navigation action you take.

My point here is:
instead of rethinking the whole thing, which might be too resource-consuming for devvvvs, there could be some minor changes that would still improve A LOT the general experience.
As I said, the current history handling makes multi-window unusable in a serious development workflow, at least for me.
For that reason I proposed to instantiate an active tab history for every window, keeping them as independent as possible.
I think this would drastically improve the experience without forcing a complete re-conceptualization and development phase.

5

I agree with you, when they are separate windows, then the history should be separate. The way it works for tabs in a browser it should work like that for windows in vvvv.