Qutebrowser: Multiple instances using profiles

[Ram-Z]

Profiles would allow loading different instances of qutebrowser with different settings. A profile would inherit the settings and key bindings from the default, but would also allow overriding them from a special section of the main config file.

Here is a mock config for 2 profiles in addition to the default. (assuming #499)

general:
  wrap-search: false
  private-browsing: false
ui:
  default-zoom: 100
profiles:
- private:
    general:
      private-browsing: true
- icantsee:
    ui:
      default-zoom: 400

When one runs qutebrowser --profile private a new instance of qutebrowser is launched in private-browsing mode. And any other profile specific settings are applied as well.

Only the options that are overridden should be set in the profiles settings. Something similar should exist for overriding key bindings.

Some thoughts

• Profiles should probably share as much as possible with each other by default (cache, local-storage, offline-storage).
• Sessions should be profile agnostic, i.e. any profile should be able to open any sessions saved by a different profile
  
  
  
  • The above might result in problems when two profiles open the same session and have auto-save-sessions enabled. I'm not sure what to do in this case, either 'lock' a session when it is first opened and disallow other profiles to open it, or show a warning dialog giving a choice to start a new session, copy the session or ignore the warning.
  
  
• QLocalServer path should contain the profiles name and be unique for each profile.
• Links opened from the command line or a .desktop file should be sent to the profile given in --profile or the default if not set.
• One profile could open links in another through ICP. (f.ex :hint profile private) Or even send the current tab. (not sure how to select which window to open it in if the profile has more than one)
• The default WM_CLASS could be set to the profile name (#514), or left since one can set it with --qt-name

• This would be a solution to #510 since one could create a new profile at will (even reload it multiple times), set profile specific settings. For debugging you might want to be able to disable sharing the caches and storages.

  Use cases

• html mailcap for mutt: open a minimal qutebrowser window for the html mail.

  • Barely any ui elements
  • :open is aliased to :open profile default, therefore sending all new tabs to other instances
  • not saving sessions
• private profile:
  
  
  
  • private-browsing
  
  
  • no javascript
  
  
  • no plugins
  
  

[The-Compiler]

I really like the idea, but I think it won't be possible to share _any_ data when using multiple instances...

• Cache: Might be possible when reimplementing a QAbstractNetworkCache entirely on our own.
• Local/offline storage: Probably not possible, as it's handled by QtWebKit.
• Cookies/config/sessions/...: Possible because we handle those, but still hard to find a way to handle this correctly and cross-platform.

I think I'll probably end up implementing this but still with a single instance, i.e. the QLocalServer will have the same name, #510 would be solved independently, and #514 still won't be possible :-/

Before ca85dde71f9f59ba5f12dbb01dd6a686a1876d06 it was actually possible to launch multiple instances, and it caused a lot of trouble which I decided wasn't easy to fix.

[Ram-Z]

• Local/offline storage: Probably not possible, as it's handled by QtWebKit.

Not even when setLocalStorage() is set to the same path? I don't know if it might lead to complications, but it seems possible to set them to the same directory.

• Cache: Might be possible when reimplementing a QAbstractNetworkCache entirely on our own.

Naively I'd say that if the cache is written to disk, other instances should be able to use it. Not sure how Qt handles things though.

Could you elaborate on the issues you had before ca85dde?

[The-Compiler]

I'm closing this as well - I also think this will get much harder with QtWebEngine, and be more trouble than it's worth. Sorry!

[hobofan]

For anyone coming to this issue in search of a solution, you can have multiple profiles by creating different base directories which can be provided to qutebrowser like so:

qutebrowser --basedir ~/.qutebrowser/profile1