VIM-inspired split windows

[krillr]

I'd love to see VIM's window-splitting capabilities brought to QuteBrowser. As far as I can tell, this functionality doesn't exist anywhere.

[lahwaacz]

It does, it's called tiling window manager.

[krillr]

That's not integrated into the browser, and doesn't necessarily use VIM's window splitting commands. I'd prefer to manage browser windows inside the browser -- as do most people who use VIM and its GUI derivatives while also using a tiling window manager.

[The-Compiler]

I can see how this could be useful to some, but this is one of those things which is probably not going to happen until someone comes up with a very good pull request 😉

[nabsiddiqui]

Couldn't you gain a similar functionality by using something like i3 and setting "tabs are windows" to true? Currently, you can detach any tab into its own window and also open any url in its own window. While I could imagine if you weren't using a tiling window manager that this could be useful, if you are using one, what would be gained other than having to learn and set up another set of commands for moving between splitsi in the browser?

[krillr]

Well, while i3 is very popular as a tiling window manager, tiling window managers are not that popular on their own. Also, while I understand that there's a small amount of "feature duplication" if one /is/ using i3, people do use things like screen/tmux in their terminals while also using i3...

[nabsiddiqui]

Yes, but when people use tmux/screen with i3 it is mainly for features that i3 can't also duplicate like resuming sessions, buffers, etc. I wouldn't see why one would use tmux or screen otherwise. You would just have to memorize more keyboard shortcuts rather than having a standardized one with the tiling window manager.

Either way, this is going off topic. I can see the benefit of using splits also if you aren't using a tiling window manager.

I'm not trying to be combative. I'm just trying to figure out if there is another way you can gain the functionality you desire, since the likelihood that this will be implemented in qutebrowser is currently very small.

[blyxxyz]

dwb has this feature.

I can't get dwb to run without segfaulting, but I think you do that with xv, for toggling the visibility of a tab. A tab with visibility toggled stays visible in a split view when you switch to another tab.

[The-Compiler]

That's an interesting approach - not full-blown tiling, but simply having an always-visible pane. Then again, I'm using a tiling WM, so I personally am not really interested in this feature 😉

[haasn]

To me it seems like the better way to approach this would be any necessary UX improvements to :tab-detach/:tab-attach:, because splitting and merging windows is basically already part of that workflow.

Personally, the only reason I use split windows in vim is because vim's limitations force a single-window workflow. (If I could open the same file twice, I would)

[lahwaacz]

Vim doesn't have such limitation - you're likely limited by missing edit conflict resolution. This problem does not apply to read-only documents, including pages in qutebrowser.

In vim, :split results in two viewports on the same file - is something like that even possible with webkit/webengine?

[lamarpavel]

Vim doesn't have such limitation - you're likely limited by missing edit conflict resolution. This problem does not apply to read-only documents, including pages in qutebrowser.

This is an important point. It raises the question what kind of communication we expect split windows to have. Web-pages aren't entirely read-only, think about input fields or drop down menus, or anything involving ajax etc.
I can't see any use in multiple views on the same page in a webbrowser except to view different parts of the page side by side (eg. the index at the top and some text in the middle), but that does not justify all the added complexity for me.

Split windows that aren't views on the same object are an entirely different beast. I think this is what @haasn was talking about. But the question about expectations are still there as soon as you compare it to vim. The discrepancy between vims buffers and views on files and a webbrowsers interaction with webpages is subtle at first but comes with different expectations that make it hard to unify. Thus, I would rather not have split windows in qutebrowser but instead well established workflow between separate windows .
Of course, it is not trivial to implement all the functionality of split windows with separate windows, but I think we should first try that route and see what's possible.

[haasn]

Vim doesn't have such limitation - you're likely limited by missing edit conflict resolution.

Yes it does - I can't share state (e.g. buffers, macros, clipboards etc.) between multiple windows, so I'm forced to constrain myself to a single window / vim instance if I don't want to impact my usability.

For qutebrowser similarly, we have to ask ourselves what state users will want to share between windows. Fortunately, qutebrowser already supports multiple windows already which means we already share most of the state, and I'm not sure what is left.

[lahwaacz]

Yes it does - I can't share state (e.g. buffers, macros, clipboards etc.) between multiple windows

That does not prevent you to "open the same file twice", as you mentioned in your previous post. See @lamarpavel's post above for the state that is not shared between tabs/windows.

[a-roy]

I did some research on how this could be done, and I learned that the QTabWidget internally uses a QStackedWidget, which in turn uses a QStackedLayout to control the visibility and geometry of the pages. PyQt doesn't seem to give us access to that QStackedWidget (correct me if I'm wrong), meaning we can't directly override the behavior by inheriting from it. We will have to set up the geometry and visibility of the tab pages somewhere in the TabWidget or TabbedBrowser classes and ensure that these settings take precedence over the ones set by the QStackedLayout.

[lufte]

I'm working on a possible implementation for this. My idea is to split what's currently a Tab into a Tab and a Pane. The Pane would keep most of the functionality (everything web related, particularly) of the current Tab, while the new Tab would just be that, a tab, with a name, an icon and a container for one or more Panes arranged in a QGridLayout.

The tab bar will remain the same, each tab would show the name and icon of the page in their active pane. Same for the status bar.

[The-Compiler]

Thanks for taking a look! FWIW I don't want to stop you, but this is something where I'm not sure yet whether it's worth the complexity it entails. If you can get it to work and it's simple enough then sure, let's go for it - but if it introduces too many funny corner cases, this might be something I'll have to say "no" to.

[lufte]

Sounds fair. I might not even go all the way with it, but if do I'm hoping it is with a clean design. In anyway it will allow me to familiarize myself with the codebase and maybe tackle other issues.

[toofar]

Seperating the display tab from the web renderer might make proper lazy loading easier too.

[lufte]

I've been working on a standalone project for a QLayout that resembles Vim splitting behaviour here https://github.com/lufte/tiling-layout, specifically to implement this feature. Hopefully I'll be able to get started soon.

[lufte]

Hey guys, if you want to check out a super alpha implementation of this, you can do so at https://github.com/lufte/qutebrowser/tree/1716-20180930. Just follow the normal instructions for building qutebrowser from source but use that branch instead. Everything is absolutely broken, so don't try any fancy commands or stuff like that. You'll basically be able to :split or :vsplit panes, move between them with :pane-(left|top|right|bottom), and close them with :pane-close.

This will take a lot of work, but at least we have something to try out now. @The-Compiler if you are completely sure you'll never want to implement this, now is the time to say so and I'll stop working on it. If you're still unsure then no worries, you can always say no later 😄

[rakanalh]

One of the very nice features that we'll get when implementing this is the fact that we can get the inspector in the same window rather than a separate one. I am currently using the i3wm to put those side by side but it's a bit annoying TBH.

[The-Compiler]

@rakanalh I kinda see that as a separate thing because it requires much less thought (it's clear that commands always go to the main webview and not the inspector; it's relatively straightforward how it should behave together with tabbing, etc.) - in fact, there's already an open PR: #4290

[fzf]

@The-Compiler bumping @lufte version with basic implementation. @lufte any reason you didnt make a PR for it?

[lufte]

Yes, it's still lacking a lot of work and I'm not certain that it will be merged given the amount of pending issues and pull requests; specially if it's not a priority. I also started considering (as other users pointed) that maybe this is a responsibility for the window manager... I particularly started considering that when I became aware of all the work needed to implement it 😄

[Slider-Whistle]

Not important at this point, but I know of one plugin for either Chrome or Firefox (I forget) that would use this hack where it moves the current web page into a HTML frame on the left side of the screen.

[lufte]

That's an interesting take. You would lose some feedback. For example, qb would not be able to show you the available options when you start typing a combination that could match multiple bindings. It's a fair compromise though. I wonder to what length you could this. Would you limit it to window-related commands or to all commands? For example, would qb process the `j` keydown event itself to scroll down, or would it just expose a scroll-down command that you can bind outside of the browser in you own hotkey daemon?