Support for multiple windows

[rajabiy]

Make possibility to open doc link in new window by pressing middle mouse button like in web browsers.

[ssokolow]

Agreed. This is my number-two productivity issue with Zeal. (number-one being slow searching since I search far more often than I middle-click)

I lose so much time and motivation from having to open a new tab, manually search up the page I was already on, and then click the link I wanted to middle-click.

[trollixx]

@ssokolow Since version 0.2.0 Zeal does support middle-clicking a link to open it in a new tab. Ctrl+Click has the same effect.

Implementing support for multiple windows is tricky, mostly because of architectural problems.

[ssokolow]

Not quite. I'm on 0.2.1 and what trips me up is that I keep trying to middle-click things in the left pane because...

1. The state of the left pane is not cloned in a new tab, so I can't just open a new tab and then left-click.
2. I want to keep my current history clean rather than opening a new copy of the current page with no history, than left-clicking in the original tab
3. Even if I resign myself to confusing tab history, there's no easy way I can find to say "open a new tab at the current location" (ie. middle-clicking the reload button in a browser)
   so I don't lose my history

[trollixx]

@ssokolow

1. I see. Yeah, we can preserve current state of the left pane when a new tab is open.
2. I am not sure what exactly you're saying here. A new tab shouldn't have history of your current one, unless it's a duplicate.
3. Duplicate tab feature #524. Should be pretty easy to implement.

[ssokolow]

For 2, I'm saying that, because I can't easily open a new tab from the left pane and "new tab" doesn't clone its state, my only way to preserve the tree expand/collapse state is to search up the current right pane's contents in the new tab, disconnecting it from its true history in the process.

[trollixx]

This is an old issue, that I think was more or less addressed.

I don't see much value in supporting multiple windows, when nowadays we have a much better tab management, than we used to.

Duplicate tab feature (#524) was implemented, and ability to synchronize left pane with the contents of the webview is tracked under #131.

[ssokolow]

While I would personally be satisfied with better tab management, I should play devil's advocate by saying that tab-switching isn't always a sufficient substitute for multiple windows.

For example, in GIMP, it frustrates me me that I can't use single-window mode, but tear off tabs into their own windows. (I have three monitors and it'd be nice to not have tab-switch or zoom as every second action for the kinds of workflows I'm using there.)

The en vogue solution for that sort of "extremely parallel use of views" is support for splitting the window vertically or horizontally, and that is superior to multiple windows when you want to work inside a single monitor without using a tiling window manager, but it's worse with multi-monitor setups where the user wants to spread the application across multiple monitors which may not be uniformly sized. (eg. a laptop with an external monitor or two.)

TL;DR: Before considering this completely solved, it'd be a good idea to solicit feedback on whether anyone has "view things in parallel" needs not satisfied by tab-switching.

[trollixx]

I see your point, but I honestly can't imagine that having multiple windows with docs would be a popular use case.

Also, how should plugin integration work in a such scenario? When a search gets invoked from an IDE, which window should pop up, and show the results?

[ssokolow]

Also, how should plugin integration work in a such scenario? When a search gets invoked from an IDE, which window should pop up, and show the results?

There are two ways which come to mind:

1. While I find it annoying because of how it interacts with my workflow, Firefox pops up externally opened tabs in whichever window last had certain kinds of interaction. (Which means that, whenever I interact with YouTube on my left monitor, I have to open and close a new tab on my middle monitor to restore the intended behaviour.)

2. The approach I'd like to see in Firefox, which would also apply here, is to just remember one of the windows as "primary" and always open new stuff there.

As for navigating an existing tab vs. opening a new one, why not do it in a manner similar to how browsers handle window.name and the target attribute? (If nothing matches, open a new tab with that name. Otherwise, navigate the tab which matches.)

[trollixx]

Currently external requests never create new tabs. There's a ticket to make this behavior configurable (#845), but I haven't thought about automatically figuring out what to do. I don't think there's a reliable way, perhaps better add an optional parameter for plugins to tell Zeal how to handle a request.

[trollixx]

And you are right, it is possible to add a setting option to control which window should be chosen.

Something like:

• Last active window
• Primary window

Where the first window becomes primary by default, and then just have a checkable menu entry to change that later.

[ssokolow]

Currently external requests never create new tabs. There's a ticket to make this behavior configurable (#845), but I haven't thought about automatically figuring out what to do. I don't think there's a reliable way, perhaps better add an optional parameter for plugins to tell Zeal how to handle a request.

In that case, I advise making the Back and Forward buttons middle-clickable (and cloning the history to the created tab) and the tabs drag-reorderable, so It's easy to overrule plugins that decide to hard-code the behaviour to something I don't want.