This might be wayyyyyyyy too far out there, but I had another thought, when browsing this Federated Wiki site...
Right now we have '1' editable window, and #153 is reaching for 'N' editable windows... maybe it would be easier (or a half-measure towards that goal) to implement '2' editable windows?
Imagine, for a moment, that your zim editing window was divided into two panels:
1. by enforced policy, the panels could not be displaying the same page
- or if it was allowed, then one could not be edited
2. links followed in the left panel are opened in the right pane
3. links followed in the right pane (or the forward navigation arrow) effectively "slides" the view to the left:
- swap: so the right page is now rendered in the left panel
- then call the same logic as a left-link (open it in the now-blank right panel)
4. similarly, the back navigation arrow "slides" the stack the other way
- swap: the left page is rendered in the right panel
- then pop off the next item from the history stack, which becomes the page name for the left panel
...and if you want to get even CRAZIER the current navigation aids (calendar, index, attachments, backlinks) could simply be a toolbar button that causes that widget to be opened in the right panel as if the next page...
I busy designing where to go with the Gtk3 interface. I want to stay close to what users are familiar with but have done some thinking on navigation using multiple windows.
In essence my idea is that you can have multiple windows showing a page or a search result, but all links open in the main window. They way this would work is e.g. a search result is shown in the main window but has a "pop out" button which results in a separate window. This new window acts as a navigation aid opening pages in the main window of the notebook.
Using panes instead of windows would be a simple extension - I prefer windows myself, but the same base classes could easily be used for interaction between panes.
I ran across this video, which seemed quite relevant. It shows a multi-tiered journal-summarization workflow which I was already trying to do with Zim (but found to be a bit clumsy with the current UI).
Perhaps this video shows the idea "close enough" to imagine...
Just dreaming at this point... :)
The video tutorial on InDiGrid's homepage shows the true power of multi column editing. This is imho a killer feature and would take Zim to the next level!
The design philosophy of this app is also very insightful.
I think the tutorial shows a flow that works very well with an strict outliner. Not so sure it would be as appealing for a more mixed content editor like zim.
Open to patches / plugins, but planning a multi-window version myself.
Most helpful comment
I ran across this video, which seemed quite relevant. It shows a multi-tiered journal-summarization workflow which I was already trying to do with Zim (but found to be a bit clumsy with the current UI).
Perhaps this video shows the idea "close enough" to imagine...
Just dreaming at this point... :)