3 ms·

Huh? None of these force single-instance by default

hombre_fatal 2mo ago
They don't do anything by default. The developer makes it do what the developer wants (not the user). You claimed the developer has to "actively block it" which isn't the case. Even in SwiftUI which has the simplest way to support multiple windows with zero work, the developer has to use WindowGroup, and if they didn't then you don't get to open more than one window.
- orbital-decay 2mo ago
  I did not claim it (another user did), but I think your reaction captures the overall sentiment ITT, which is taking perceived status quo as some fundamental thing and defending the worse solution instead of changing the status quo. If all that energy went into perfecting GUI apps the way you want them to work, the ecosystem would have been much healthier. I've seen it in Electron already, and TUI apps are headed the same way, it's simply inevitable. The JS and Python bloat and fragmentation of conventions are already there, reinventing things that used to be simple in a complex way is next (in a way it already happened, e.g. a ton of basic things like hotkey schemes have to be reinvented from scratch each time in TUIs).
  - hombre_fatal 2mo ago
    I don't understand what you're responding to. TUI apps are multi-instance by default since the user can invoke the program in different pty sessions. The developer would have to actively fight that. GUI SDKs generally require the developer to pick a solution. And it's easier to default to the simpler solution where you have one instance, one data model, one window. Whether things might change in the future isn't relevant because we're talking about how things are today, not speculating about the future. And the time to change one's opinion is when reality changes, not ahead of time based on how you think things hopefully will be.
    - deleted 2mo ago
      [deleted]
    - okanat 2mo ago
      > GUI SDKs generally require the developer to pick a solution. And it's easier to default to the simpler solution where you have one instance, one data model, one window. I don't know which GUIs you have programmed but for Windows and GNU/Linux this isn't the simplest option. It requires quite the effort to actually enforce single instance.
- brainwad 2mo ago
  The developer (of the app or the app framework) does have to deliberately implement "merging" of a second launched process. The default would be for the two processes to run side by side in both Windows and Linux. It has been that way forever. The merging behaviour is also in principle possible for TUIs, btw, it's just that nobody does it. But with something like tmux is would be easy to set up that all subsequent calls to your binary actually connect to the already open session launched by the first instance.
- fc417fc802 2mo ago
  You appear to be conflating multiple windows in a single process with multiple processes. The default is that each process is almost entirely isolated from the rest of the running system. You have to actively work to even detect that another instance of the program you wrote is running.

They don't do anything by default. The developer makes it do what the developer wants (not the user). You claimed the developer has to "actively block it" which isn't the case. Even in SwiftUI which has the simplest way to support multiple windows with zero work, the developer has to use WindowGroup, and if they didn't then you don't get to open more than one window.

orbital-decay 2mo ago
I did not claim it (another user did), but I think your reaction captures the overall sentiment ITT, which is taking perceived status quo as some fundamental thing and defending the worse solution instead of changing the status quo. If all that energy went into perfecting GUI apps the way you want them to work, the ecosystem would have been much healthier. I've seen it in Electron already, and TUI apps are headed the same way, it's simply inevitable. The JS and Python bloat and fragmentation of conventions are already there, reinventing things that used to be simple in a complex way is next (in a way it already happened, e.g. a ton of basic things like hotkey schemes have to be reinvented from scratch each time in TUIs).
- hombre_fatal 2mo ago
  I don't understand what you're responding to. TUI apps are multi-instance by default since the user can invoke the program in different pty sessions. The developer would have to actively fight that. GUI SDKs generally require the developer to pick a solution. And it's easier to default to the simpler solution where you have one instance, one data model, one window. Whether things might change in the future isn't relevant because we're talking about how things are today, not speculating about the future. And the time to change one's opinion is when reality changes, not ahead of time based on how you think things hopefully will be.
  - deleted 2mo ago
    [deleted]
  - okanat 2mo ago
    > GUI SDKs generally require the developer to pick a solution. And it's easier to default to the simpler solution where you have one instance, one data model, one window. I don't know which GUIs you have programmed but for Windows and GNU/Linux this isn't the simplest option. It requires quite the effort to actually enforce single instance.
brainwad 2mo ago
The developer (of the app or the app framework) does have to deliberately implement "merging" of a second launched process. The default would be for the two processes to run side by side in both Windows and Linux. It has been that way forever. The merging behaviour is also in principle possible for TUIs, btw, it's just that nobody does it. But with something like tmux is would be easy to set up that all subsequent calls to your binary actually connect to the already open session launched by the first instance.
fc417fc802 2mo ago
You appear to be conflating multiple windows in a single process with multiple processes. The default is that each process is almost entirely isolated from the rest of the running system. You have to actively work to even detect that another instance of the program you wrote is running.