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.
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.
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.
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.
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.
is there an update regarding this topic @gregsn@joreg@Elias? Are you planning to fix this in the near future?
I would suggest removing this multi-window feature entirely if you are not planning to fix the browsing history. Knowing that it’s there in this unusable state, it’s even more frustrating than dreaming about it for years lol
I agree that the multi-window system needs to be improved to be useful:
tabs on the top like in the main window and not the bottom
if I open a patch (middle-click) from a separate window it should open in a tab in that separate window as well and not the main window
as for the history it makes more sense what dottore says, that the history is per window
But I have a feeling that maybe it goes a bit deeper. I wonder what it would feel like if we actually browsed patches like we do in a browser, so I can eg. middle-click to go “into” a sub-patch, but I stay in the same tab. If I want it in its own tab, I can shift-middle-click. So basically exactly like in a browser and then the history is per tab, exactly like in a browser. Basically what happens now when you have a large patch and maybe even across multiple documents, you quickly end up with like 30 open “tabs”. Then I usually have to just close all 30 tabs and sort of start again, because most of the tabs I want to switch to are now in the that dropdown anyways, so I can’t really switch to the tab I want again quickly.
Obviously this would have to be tested and maybe there would even be different flavors that we can set, but I guess that would become hard to maintain quickly.
Still I would be curious what it would feel like to browse patches exactly like websites in a browser, so with tabs if we want and for quickly jumping in and out of patches it just stays in the same tab. Maybe we could have something like breadcrumbs to quickly jump back to parent patches, although I am aware there isn’t always a strict parent-child relationship.
I am happy to test and/or conceptualize, although it sounds like praxis has done that a lot as well.
