7 ms·

Wio: A Clone of Plan 9’s Rio for Wayland

170 points by ddevault 8y ago

cnasc 8y ago
This is really cool! I've always wanted to use a Rio-like WM but my chronic lack of gumption kept me from installing one. Wio looks sufficiently neat that I think I should get around to trying it. For people who like new window manager things and also Rio, it's worth also checking out this piece of the Arcan Project: https://arcan-fe.com/2017/04/17/one-night-in-rio-vacation-photos-from-plan9/ https://arcan-fe.com/2017/04/17/one-night-in-rio-vacation-ph...
Avi-D-coder 8y ago
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 8y 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 8y 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 8y 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 8y 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 8y ago
    [deleted]
- orbifold 8y 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 8y 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 8y 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.
mncharity 8y ago
Can anyone suggest interesting work that is kind of the opposite of this? Vast real estate, rich HIDs, dynamic autonomous presentation? So focused on many/big screens, with an eye towards future high-res AR/VR 3D, rather than a single "space is precious" small screen. Rich human interface devices, like multitouch and 3D hand pose and stylus and head position and gaze, rather than a single mouse. Display as a dynamic ecosystem of presentations, under the influence of multiple agents, rather than detailed manual control. UI as collaborative improv dance, rather than as micromanagement. Punchcards and console toggles; teletype printer; VT100 terminal; small bitmapped monitor and mouse; larger monitor; largerer monitor; largererer; multiple monitors; with multitouch and stylus tablet; future high-res AR/VR... as tech so very slowly becomes less crippling, the UIs do too... Hmm, though for current VR, with its 1980's VGA-like non-blurry pixels are more precious than they've been for decades, fine-grained control and space sharing might be quite nice?
- saulrh 8y ago
  I don't think that I'd expect those interfaces would exist yet, nor are they going to be coming up relatively soon. You mostly see interfaces that have a ton of work put into them either when someone is smoothing off every possible rough edge they can find to cater to the widest possible audience (e.g. Windows Desktop), or when someone is optimizing the heck out of their interface to improve performance on a very specific use case. The second case clearly isn't what we're looking for; those interfaces will tend to be massively refined with all the cruft cut off, and in many cases the very first thing that goes is any trace of analog input or output. There's a reason that some of the most impressive feats of human bandwidth are from typists and players of rhythm games like Guitar Hero. The first case isn't going to happen until the necessary interface peripherals and interaction paradigms are common enough for large reserves of programmer effort to be expended on refining the experience for the common use case. Even then I don't know how rich the interface will be; at a certain point you run into issues of simple kinematics, things like gorilla arm and the fact that the mouse is actually incredibly precise. You can get approximations, but the only thing I'd want to use for real work is "like the setup I already have, but with monitors projected into a virtual space rather than hanging off arms on my desk".
tambourine_man 8y ago
Video doesn’t play on iOS
- naikrovek 8y ago
  It might if you wait. It shows a gray screen for a good while before you see something that indicates that the video is actually working.
  - Crestwave 8y ago
    It really does not play on iOS, as in it's replaced by a crossed-out play symbol.
  - cmroanirgo 8y ago
    Yeah. I thought it was a problem on my end (new OS installed!). It certainly would've been better if there was some kind of video in the first few minutes, rather than just a gray screen!
- mikelward 8y ago
  Or Android. I get audio but no video.
  - mikelward 8y ago
    Wait. That's the video. A mouse pointer appears around 0:29.
- bonyt 8y ago
  I used an iOS view source app and pulled the webm url, and played it with VLC for iOS. https://yukari.sr.ht/wio.webm https://yukari.sr.ht/wio.webm
  - tambourine_man 8y ago
    Which view source app did you use? I used to resort to firebug light (DOM viewer) bookmarklet but it doesn’t seem to work anymore.
jimjimjim 8y ago
This looks like a really interesting project. Im always looking for new window interaction styles. And this seems refreshing after years of minor tweaks on win95’s style. I really should have tried plan9 years ago instead of always procrastinating.
abrowne 8y ago
I was wondering recently if I could tell Sway to use floating mode for all windows as a kind of first step to something like this. This is obviously much better, though!
ubercow13 8y ago
In what way is this not possible with X11? Don't for example tabbed containers in i3 kind of work like this?
- hawski 8y ago
  This project is very cool, but I also think it was kinda possible on X11. However not as easy and that's why this project is exciting for me. I tried to hack on tabbed from suckless [0] with a little utility to achieve a similar behavior. An X11 proxy that would rewrite window creation so that the parent window would be tabbed xid and not root window [1]. It kinda worked, but I never finished this for transient windows. So you would start with a terminal inside tabbed instance with tabs hidden. The terminal would be behind chrwin proxy. Then when you launch anything inside, it would become a new tab and tabbed would switch immediately to it. There could be a possibility to kill the terminal after spawning a new client. But I intended to just leave it by default so you would go back to it. Edit: that was my first approach. I wanted then to not rewrite window creation, but to reparent it afterwards. Something like this. It was supposed to simplify transient window handling, because the client would take care for it. At least that's what I remember. [0] https://tools.suckless.org/tabbed/ https://tools.suckless.org/tabbed/ [1] https://github.com/hadrianw/chrwin https://github.com/hadrianw/chrwin
boomlinde 8y ago
Interesting project! For X11 users there's 9wm. I wonder how it compares to Wio.

170 points by ddevault 8y ago

This is really cool! I've always wanted to use a Rio-like WM but my chronic lack of gumption kept me from installing one. Wio looks sufficiently neat that I think I should get around to trying it. For people who like new window manager things and also Rio, it's worth also checking out this piece of the Arcan Project: https://arcan-fe.com/2017/04/17/one-night-in-rio-vacation-photos-from-plan9/ https://arcan-fe.com/2017/04/17/one-night-in-rio-vacation-ph...

Avi-D-coder 8y ago

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 8y 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 8y 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 8y 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 8y 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 8y ago
  [deleted]
orbifold 8y 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 8y 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 8y 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.

mncharity 8y ago

Can anyone suggest interesting work that is kind of the opposite of this? Vast real estate, rich HIDs, dynamic autonomous presentation? So focused on many/big screens, with an eye towards future high-res AR/VR 3D, rather than a single "space is precious" small screen. Rich human interface devices, like multitouch and 3D hand pose and stylus and head position and gaze, rather than a single mouse. Display as a dynamic ecosystem of presentations, under the influence of multiple agents, rather than detailed manual control. UI as collaborative improv dance, rather than as micromanagement. Punchcards and console toggles; teletype printer; VT100 terminal; small bitmapped monitor and mouse; larger monitor; largerer monitor; largererer; multiple monitors; with multitouch and stylus tablet; future high-res AR/VR... as tech so very slowly becomes less crippling, the UIs do too... Hmm, though for current VR, with its 1980's VGA-like non-blurry pixels are more precious than they've been for decades, fine-grained control and space sharing might be quite nice?

saulrh 8y ago
I don't think that I'd expect those interfaces would exist yet, nor are they going to be coming up relatively soon. You mostly see interfaces that have a ton of work put into them either when someone is smoothing off every possible rough edge they can find to cater to the widest possible audience (e.g. Windows Desktop), or when someone is optimizing the heck out of their interface to improve performance on a very specific use case. The second case clearly isn't what we're looking for; those interfaces will tend to be massively refined with all the cruft cut off, and in many cases the very first thing that goes is any trace of analog input or output. There's a reason that some of the most impressive feats of human bandwidth are from typists and players of rhythm games like Guitar Hero. The first case isn't going to happen until the necessary interface peripherals and interaction paradigms are common enough for large reserves of programmer effort to be expended on refining the experience for the common use case. Even then I don't know how rich the interface will be; at a certain point you run into issues of simple kinematics, things like gorilla arm and the fact that the mouse is actually incredibly precise. You can get approximations, but the only thing I'd want to use for real work is "like the setup I already have, but with monitors projected into a virtual space rather than hanging off arms on my desk".

tambourine_man 8y ago

Video doesn’t play on iOS

naikrovek 8y ago
It might if you wait. It shows a gray screen for a good while before you see something that indicates that the video is actually working.
- Crestwave 8y ago
  It really does not play on iOS, as in it's replaced by a crossed-out play symbol.
- cmroanirgo 8y ago
  Yeah. I thought it was a problem on my end (new OS installed!). It certainly would've been better if there was some kind of video in the first few minutes, rather than just a gray screen!
mikelward 8y ago
Or Android. I get audio but no video.
- mikelward 8y ago
  Wait. That's the video. A mouse pointer appears around 0:29.
bonyt 8y ago
I used an iOS view source app and pulled the webm url, and played it with VLC for iOS. https://yukari.sr.ht/wio.webm https://yukari.sr.ht/wio.webm
- tambourine_man 8y ago
  Which view source app did you use? I used to resort to firebug light (DOM viewer) bookmarklet but it doesn’t seem to work anymore.

jimjimjim 8y ago

This looks like a really interesting project. Im always looking for new window interaction styles. And this seems refreshing after years of minor tweaks on win95’s style. I really should have tried plan9 years ago instead of always procrastinating.

abrowne 8y ago

I was wondering recently if I could tell Sway to use floating mode for all windows as a kind of first step to something like this. This is obviously much better, though!

ubercow13 8y ago

In what way is this not possible with X11? Don't for example tabbed containers in i3 kind of work like this?

hawski 8y ago
This project is very cool, but I also think it was kinda possible on X11. However not as easy and that's why this project is exciting for me. I tried to hack on tabbed from suckless [0] with a little utility to achieve a similar behavior. An X11 proxy that would rewrite window creation so that the parent window would be tabbed xid and not root window [1]. It kinda worked, but I never finished this for transient windows. So you would start with a terminal inside tabbed instance with tabs hidden. The terminal would be behind chrwin proxy. Then when you launch anything inside, it would become a new tab and tabbed would switch immediately to it. There could be a possibility to kill the terminal after spawning a new client. But I intended to just leave it by default so you would go back to it. Edit: that was my first approach. I wanted then to not rewrite window creation, but to reparent it afterwards. Something like this. It was supposed to simplify transient window handling, because the client would take care for it. At least that's what I remember. [0] https://tools.suckless.org/tabbed/ https://tools.suckless.org/tabbed/ [1] https://github.com/hadrianw/chrwin https://github.com/hadrianw/chrwin

boomlinde 8y ago

Interesting project! For X11 users there's 9wm. I wonder how it compares to Wio.