4 ms·

This is very cool, but I have to ask, why would I want new windows to take over their root? Most things launch asynchronously, leaving their parent usable. Did

This is very cool, but I have to ask, why would I want new windows to take over their root? Most things launch asynchronously, leaving their parent usable. Did plan 9 use this model because blocking launchers were the norm not the exception?

Sir_Cmpwn 7y ago
It's just a different model. It's hard to explain exactly why, but it works - though it's definitely not what most people are used to. Give it a shot! Though I'd recommend trying it out on Plan 9 itself, where the applications are designed around it, before settling your doubts for good.
- theoh 7y ago
  Isn't it more or less a case of usually launching an application into a newly created window? It's been a long time. The Plan 9 emphasis on per-process namespaces corresponds to the idea that a new graphical application is given a handle for a framebuffer that corresponds to the size of the window it can draw in. The Rio idiom has every window start by default as a textual terminal, so it's natural to be able to take over that framebuffer to run a graphical app. It's a bit like the situation on older systems, like Sun workstations, where the textual console and the graphical display were only informally separated: sometimes the X server's display would be interrupted by lines of text printed onto the screen by the kernel's console driver.
pfranz 7y ago
I agree. One thing that drives me nuts in macOS is launching something, hopping to another window while I wait for it to launch, then having the new window steal focus (multiple times). I'm very happy to see people experiment with new desktop models, though.
meruru 7y ago
Right now my environment has two ways of launching applications: dmenu for graphical programs and a terminal for textual programs. This feature could be leveraged to enable launching everything from dmenu (by always launching a terminal). That's something that I would appreciate. It would also enable access to stdout and stderr output of all launched programs after-the-fact. I would love this feature in my current wm.
- deleted 7y ago
  [deleted]
orbifold 7y ago
That’s what terminal programs do after all, so coming from text based applications it is natural. Personally I would prefer that if I openend an image file on the terminal, the image viewer took over the window.
arghwhat 7y ago
Whenever you run something from a terminal, you block and wait for its termination, so this is entirely normal. If you want two applications, you start two applications: First a window, then run it. Once the application terminates, the window returns to being a terminal. Basically, you create a window, and then decide its content. It's actually incredibly logical and intuitive to use if you have ever used a terminal.
- pavlov 7y ago
  "It's actually incredibly logical and intuitive to use if you have ever used a terminal." Or even a web browser... First you open a tab, then navigate to the content you want to display there.

Sir_Cmpwn 7y ago

It's just a different model. It's hard to explain exactly why, but it works - though it's definitely not what most people are used to. Give it a shot! Though I'd recommend trying it out on Plan 9 itself, where the applications are designed around it, before settling your doubts for good.

theoh 7y ago
Isn't it more or less a case of usually launching an application into a newly created window? It's been a long time. The Plan 9 emphasis on per-process namespaces corresponds to the idea that a new graphical application is given a handle for a framebuffer that corresponds to the size of the window it can draw in. The Rio idiom has every window start by default as a textual terminal, so it's natural to be able to take over that framebuffer to run a graphical app. It's a bit like the situation on older systems, like Sun workstations, where the textual console and the graphical display were only informally separated: sometimes the X server's display would be interrupted by lines of text printed onto the screen by the kernel's console driver.

pfranz 7y ago

I agree. One thing that drives me nuts in macOS is launching something, hopping to another window while I wait for it to launch, then having the new window steal focus (multiple times). I'm very happy to see people experiment with new desktop models, though.

meruru 7y ago

Right now my environment has two ways of launching applications: dmenu for graphical programs and a terminal for textual programs. This feature could be leveraged to enable launching everything from dmenu (by always launching a terminal). That's something that I would appreciate. It would also enable access to stdout and stderr output of all launched programs after-the-fact. I would love this feature in my current wm.

deleted 7y ago
[deleted]

orbifold 7y ago

That’s what terminal programs do after all, so coming from text based applications it is natural. Personally I would prefer that if I openend an image file on the terminal, the image viewer took over the window.

arghwhat 7y ago

Whenever you run something from a terminal, you block and wait for its termination, so this is entirely normal. If you want two applications, you start two applications: First a window, then run it. Once the application terminates, the window returns to being a terminal. Basically, you create a window, and then decide its content. It's actually incredibly logical and intuitive to use if you have ever used a terminal.

pavlov 7y ago
"It's actually incredibly logical and intuitive to use if you have ever used a terminal." Or even a web browser... First you open a tab, then navigate to the content you want to display there.