It happened when searching for a keyword in many nodes. After the results have been generated, as shown below, moving between any panes except for pane 1 will not reload/search again.
It happened when searching for a keyword in many nodes. After the results have been generated, moving between any panes except for pane 1 will not search again.
But moving from pane2 to pane1 or from pane1 to pane2 will make it search again.
It seems logical that when you move a pane, Workflowy might want to refresh the contents of the pane. There are some elements, like Workflowy dates, that don’t automatically update in other panes. That would catch those if a pane in was moved. But if that is indeed the case, then it seems logical that any pane move would trigger a refresh of that pain.
In my testing, it looks like moving a pane into or out of pane 1 one triggers a refresh of all panes. Moving between pane two and pane three does not trigger a refresh. I would say that’s the bug, moving between panes other than pane 1 does not trigger a refresh.
If you change one of the items that does not immediately reflect in other panes (WF date for example) when you move those other panes they are not accurate. So a refresh on moving a pane fixes that.
It’s a half fix. If I am looking at my 5 pane next 5 days search view any dates I change in one pane don’t reflect in the others until a refresh is done.
Interesting. It seems to me that either design philosophy is plausible:
Changing the position of a pane also refreshes its contents (which you two favor AFAICT).
Changing the position of a pane doesn’t change its contents, just like changing its width or resizing the browser window. I favor this approach because I think it’s cleaner for distinct operations to remain separate; also one does not always want searches to refresh mid-stream (e.g. if one is in the middle of entering a child node under a search hit), and it seems a bit arbitrary for a position change to cause such a refresh.
But either way, I agree that pane 1 should act the same as the other panes.
Which brings me back to my ongoing plea (not stated for several weeks so perhaps it’s ok to repeat it now)… all panes should be equal citizens with each other but also with a simple single pane; all commands that work in a simple single pane should automatically work in each of multiple panes, and vice versa (except of course where they are intrinsically inapplicable because they refer to another pane.)
It seems that technically, rather than in terms of design philosophy, pane 1 is much, much more important than any other.
Like, I am focusing pane 8, then open the a node in the sidebar, expecting it to open in pane 9, but it only opens in pane 1. Besides, there are so many pane-1-only bugs.
IMO, moving a pane should change nothing about it except its location on the screen (and of course its sequence number within the window, i.e. pane 1, pane 2, etc.)
