-
-
Notifications
You must be signed in to change notification settings - Fork 693
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open multiple windows / instances? #169
Comments
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. |
@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. |
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. |
Out of all the features I've habitually tried to use so far, |
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. |
Are multiple windows considered/worked on? |
No ETA for now. |
In Linux, does the min browser always run on single instance mode? from what I know electron app in macOS always run in single instance mode |
@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. |
Multiple instances don't behave nicely on macOS though. |
This comment has been minimized.
This comment has been minimized.
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:
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. |
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. |
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. |
This comment has been minimized.
This comment has been minimized.
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? |
This comment has been minimized.
This comment has been minimized.
I mean sharing the same instance even though it spawned multiple times. $ min &
$ min The second time I run What I mean sharing the same instance is when I inspect it using process manager (like $ kitty &
$ kitty &
$ ps | grep kitty It will tell me that there are 2 $ kitty -1 &
$ kitty -1 &
$ ps | grep kitty It will tell me there is only 1 |
@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:
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). |
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. |
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). |
const isFirstInstance = app.requestSingleInstanceLock()
if (!isFirstInstance) {
app.quit()
return
} Should be able to open more windows now |
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. |
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 😁 |
to create different instances of the browser, until one with multiple windows is stablished and as a workaround, follow these steps for Linux:
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 |
@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...
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. Let me know your thoughts! |
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. |
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?
The text was updated successfully, but these errors were encountered: