Open multiple windows / instances?

[timkinnane]

I think min is a great tool for running focused web apps and dev tools. To that end, I'd like to have multiple instances open, so I can test apps with different concurrent browser sessions side-by-side, without having to tab through to see updates in each.

Is this possible, planned or not possible by design?

[CalObbur]

I also would like multiple instances to work, although maybe I should open a separate bug/issue for this?

With one Min instance, everything works fine. If I open another min instance on another desktop, autocomplete is broken, my settings to minimize the menu are reverted, and the tabs from my other instance are brought up instead of the blank start page. So technically I guess multiple instances do work aside from those bugs above.

[PalmerAL]

@CalObbur Multiple instances are probably never going to work, because two instances can't open the same IndexedDB database at the same time, which is why settings and autocomplete don't work. Multiple windows per instance is definitely doable however, and would solve most of the reasons that having multiple instances is necessary.

[ibash]

@PalmerAL was there a reason that multiple windows wasn't added? If not I could help out here, too. I'd live to see an awesome split view though (like #349).

[PalmerAL]

Yeah, I agree multiple windows would be a good idea. It's going to be fairly difficult to implement this, because a bunch of stuff (particularly the task system and session restore) was designed with the idea that there's only one open window, but I think it's definitely doable if you're interested in working on it.

[will-ca]

Out of all the features I've habitually tried to use so far, CTRL+N/File > New Window is the only one that hasn't worked. If it were possible to view multiple pages at the same time, then I'd frankly have a hard time thinking of any real functionality where Min is lacking when compared to the big browsers (Chrome, Firefox, etc).

[Kekker-git]

Multiple windows is the one thing min is missing for me. With other browsers, I'm often reading documentation or wiki pages in one window while I have a video playing in a window on my other monitor. For now, I have to keep a second browser installed to manage this.

[dancojocaru2000]

Are multiple windows considered/worked on?

[PalmerAL]

No ETA for now.

[DrSensor]

In Linux, does the min browser always run on single instance mode?
I mean when I spawn multiple min browser it will share the same instance (similar on how firefox -new-window or kitty --single-instance works)

---

^{from what I know electron app in macOS always run in single instance mode}

[PalmerAL]

@DrSensor Yes, that's done here.

Electron doesn't enforce single instance by default on macOS, but the OS tries to (by switching back to the existing instance when you open a file or click a link, rather than creating a new instance). So every app effectively ends up being single-instance, but you can still create multiple instances from the command line if you want to.

[dancojocaru2000]

Multiple instances don't behave nicely on macOS though.

[dancojocaru2000]

Well that comment is quite aggressive and possibly a bit insulting.

That aside, in case I wasn't clear enough, I'll detail.

macOS expects all windows of an app to be handled by a single instance of that app.

When you open multiple instances, something technically allowed but not encouraged, multiple side effects happen, including:

• each instance has a separate dock and Cmd+Tab icon
• Cmd+` doesn't switch between windows
• Cmd+Q only quits one instance, so it doesn't close all windows

And @dj-sash, remember. Open source and a GitHub repo doesn't mean you've suddenly got free labour to fulfil your wishes. Each project maintainer does what they want. It is their project, not yours.

What you can do is make improvement suggestions and hope the maintainer will like them and try to implement them.

If they won't, tough luck, c'est la vie. And with a "Don't make as if you do not know. Im sure you all do know it very well." attitude, I'm not sure you'll get much luck into getting your suggestions accepted.

[will-ca]

@dj-sash

If you're interested in getting "something good" , then I suggest submitting a pull request, instead of whinging, cussing, dictating, and lecturing about your perceived superficial shortcomings for a tool that someone has made, maintained, and given you access to for free.

...Personally, I do think that most of the changes you suggest seem quite "s...t" and unnecessarily heavy for how frivolous they are. Your attitude and sense of aggressive entitlement, even more so, and I seriously hope that I will never have the misfortune of ever having to work with you or use anything that you've made.

[dancojocaru2000]

And to further answer that "Don't make as if you do not know. Im sure you all do know it very well." comment, I could probably do it as well even though I have no experience with Electron if you give me 3 years and a constant supply of coffee.

Thing is, I have better things to do. And so do the maintainers most likely.

Managing multiple windows is a hard task, ensuring no conflicts appear, preparing emotionally for the "I can't move tabs between windows using drag & drop!!!!!!111!!!" issues when the first release of the feature is shipped. It's not impossible, of course. It's probably just hard, time consuming.

PalmerAL did mention at the beginning of this issue that they "agree multiple windows would be a good idea', so it's not like someone said no to the idea and you need to be persuasive. It's just that, at the moment, there is "No ETA for now.", likely due to the reasons I mentioned above.

So calm down with your "s..t" attitude, to use the same words you use.

[dancojocaru2000]

Version is just a number that, by convention, goes up.

ReactOS is at version 0.4.13 and it's been in development since 1998 (22 years ago).

How about you "shift your gear" and write this feature yourself if you want it so much?

[DrSensor]

@PalmerAL

@DrSensor Yes, that's done here.

I mean sharing the same instance even though it spawned multiple times.
From that source code, it means min doesn't allow me to spawn another min. So something like this is not possible:

$ min &
$ min

The second time I run min it will immediately force exit.

What I mean sharing the same instance is when I inspect it using process manager (like top or ps), it will tell me it only has one process running even though it's spawned multiple times. Take examples of kitty terminal, if I do:

$ kitty &
$ kitty &
$ ps | grep kitty

It will tell me that there are 2 kitty process running. However, if I use --single-instance flag:

$ kitty -1 &
$ kitty -1 &
$ ps | grep kitty

It will tell me there is only 1 kitty process running even though there is 2 kitty window shown up. The memory consumption is slightly bigger than without using single-instance mode but it's better than having 2 identical processes running. (2 identical processes cause twice memory consumption)

[PalmerAL]

@DrSensor Right, if you try to create a second instance it will stop; if you passed a URL to it, it will transfer over to the first instance and be opened there. I think that's what kitty is doing as well ("New invocations will instead create a new top-level window in the existing kitty instance").

Anyway, I figured I'd write down some of what would be required to support multiple windows in an instance:

1. Right now, we have a system where you can have multiple tasks open. I'd like to keep that (and tasks solve some problems windows don't, like letting you keep things open for weeks without cluttering up your desktop), so I think what would make sense is to have a global task list, and each window can have one of those tasks open at a time. If you open the task list and pick a task that's open in another window, the task transfers to the current window, and the other window goes back to the overlay.
2. To do that, you need a way to share the state of each tab and task between each window. The easy way to do that would be to just put it in the main process, but then you would need to send an IPC message each time you wanted to read anything from the tab state, which would be really slow. So what you would need to do is keep a copy in each window, but synchronize them somehow (and figure out when it's necessary to sync them).
3. You need to handle the case of "the task/tab got transfered to a different window" - by removing it from the tab bar, etc.
4. You need to figure out what to do with history. Right now, your history gets read from the database on startup and stored in-memory inside the window so that searching through it is fast, but if you tried to do this with multiple windows, the in-memory stores would get out of sync (eg. if you visited a page in one window, it would only be included in the store for that window). The easy way to fix this would be to move the history store to the main process, but IndexedDB isn't available in the main process. So then you need to either switch to a different database, or create an additional hidden window to run the service in (which also increases your memory overhead).
5. You need to figure out what to do with webview listeners - for example, there's some code inside the window that listens for URL changes, and decides whether to redirect the page to reader view. If you left it as-is, every window would receive events for every open webview, and this code would run multiple times. You could fix this by doing something like "only send a webview's events to the window it's open in", but some webviews aren't open in any window (eg. if you create a task, and then switch away from it). You could maybe move this code to the main process?
6. You would need to rewrite the session restore and window-creation code to support recreating multiple windows.
7. Probably some other stuff I'm forgetting.

None of this is impossible, and if someone wants to work on it you're welcome to! But I'm probably not going to in the immediate future given the time that would be involved.

(It may also be worth thinking about how this could be simplified. For example, if you had a separate task list per-window, and didn't allow transferring tabs between windows, you could eliminate 2, 3, and probably 5. It wouldn't be great from a UX standpoint though).

[dancojocaru2000]

I think that if a task is open in a window, selecting it from another window should instead bring the window currently containing the task in focus. I'm not sure how nice that would be.

[Syndamia]

Other browsers handle multiple windows quite a lot more simply - the last closed window is the one who's data is stored. I did some tests (on Brave and Firefox) and when I reopen the browser after closing many windows, the tabs that appear are from the last window I closed.

I don't believe that having one instance contain multiple windows is a good idea, because the point of having another window is so you have a new empty canvas to work on. I think the best system is to store the window data in the window itself and save it in permanent storage only when you close the window. Does that require a lot of code modification?

Note: Wexond is another electron-based browser, that does implement multiple windows (although some stuff don't work exactly like in other browsers, for example tabs are saved only from the first window instance, but history includes all windows). It could provide some ideas/clues on how to implement the feature (although it also uses React and we don't).

[UtopicUnicorns]

cd /usr/lib/min
doas lite-xl main.build.js //where doas can be sudo and lite-xl can be nano, vscode etc
go to line #\812
comment out line #\812 to #\817 (reference)

const isFirstInstance = app.requestSingleInstanceLock()

if (!isFirstInstance) {
  app.quit()
  return
}

Should be able to open more windows now

[johnathanz]

Thanks for the suggestion @UtopicUnicorns

+1 for multiple windows, Ideally as part of a Release candidate, so we don't have to mess with Source.

[UtopicUnicorns]

Thanks for the suggestion @UtopicUnicorns

+1 for multiple windows, Ideally as part of a Release candidate, so we don't have to mess with Source.

Thing is that this seems to be baked into the source.
So it might be completely intentional to only allow a single instance.

[PalmerAL]

I have a bunch of free time this week, so I decided to finally start working on this. I have a branch here: https://github.com/minbrowser/min/tree/multi-window . It's pretty rough, and has a lot of things that don't work yet, but if anyone's interested in trying it out you're welcome to. Your saved open tabs may get corrupted occasionally, so I'd recommend running in development mode using the readme instructions, which uses an isolated profile directory from your main Min installation, and not relying on it too much.

This uses the design I mentioned previously - there's a global task list that's shared across all windows, and picking an already-open task from the task overlay moves it to your current window. This is more difficult to implement than having separate task lists for each window, but I think it should be nicer to use. If anyone has thoughts on that, I'd be interested in hearing them!

I think I should be able to solve most of the big problems within the next few days, but time will tell 😁

[ruben2rl]

to create different instances of the browser, until one with multiple windows is stablished and as a workaround, follow these steps for Linux:

1. Create a new user with a home folder: sudo useradd -m username
2. Add password: sudo passwd username
3. Allow that user to use your screen: xhost +SI:localuser:username
4. Launch the program: sudo -u username -H min
   That's it!

For each user that you create, you'll be able to run a new window, the new home folder will only contain the files needed and will occupy a very small space in the hard drive

[flightmansam]

@PalmerAL I have been using the multi-window branch of min for a little bit now. I really like it, haven't experienced any corrupt tabs yet...

If anyone has thoughts on that, I'd be interested in hearing them!

I have had a thought about how this could work structurally. Since I generally organise my searches/tabs into project based tasks, I very much would be keen to have the same task on both windows. I understand this brings in a bunch of complications to consider from a UX/UI point of view, not to mention some concise messaging between the windows to negotiate.

I have come up with the following flow that might work. It is a .svg and if you open it in draw.io you can modify it if you like!?

1a. New windows with new tasks avoids the same task collision from the get-go.
1b. I very much like the idea of having a keyboard shortcut to "pop" my current tab into a new window (recall my attempt at putting the active tab into a small window). But I love the idea that you can view the same task on both windows (and navbars sync in real time...?).
2. So if this were implemented, the windows would have some method for communicating the tabid they are currently viewing and then would be able to lock/warn the user about accessing a currently viewed tab (from the other window).
3a. Perhaps the default option is to focus the locked tab,
3b. With a modifier key or alert box (or even a button in the navbar?) you can duplicate the locked tab so you can quickly view the same tab on both windows (noting that it is a brand new tab with the duplicate url.

Let me know your thoughts!

[PalmerAL]

Seven years later, this is finally done :) Beta release: https://github.com/minbrowser/min/releases/tag/1.28.0-beta

Currently, this is designed to have one task per window. I think having the same task in multiple windows in the way that Sam described could be useful; I chose to skip it to reduce the implementation complexity, but it should be possible to implement later.

[UtopicUnicorns]

Seven years later, this is finally done :) Beta release: https://github.com/minbrowser/min/releases/tag/1.28.0-beta

Currently, this is designed to have one task per window. I think having the same task in multiple windows in the way that Sam described could be useful; I chose to skip it to reduce the implementation complexity, but it should be possible to implement later.

Nice job.