How would one go to take the concept of unix piping into the GUI environment?
This is just a brainstorm thread, answer with ideas or leading questions.

Basically, that's how Plan 9 works: Piping into GUIs by exposing GUI elements as filesystems.

Ok ok, and what about implementing it as a series of programs, that are necessary to work on a non-Plan9 OS. I mean how would the GUI implementation be? I was thinking maybe some drag and drop, where you drag an "anchor" into a desired program, where the output of that program will be piped into the one desired.

(20-01-2020, 10:34 AM)jkl Wrote: Basically, that's how Plan 9 works: Piping into GUIs by exposing GUI elements as filesystems.

Are you sure? I've played around with Plan 9 a few times, but didn't see a way to trivially combine various existing GUI tools into new ones. I guess you could start a new rio session in a terminal, but I don't think that's really what eduarch42 means (?).

(24-01-2020, 05:43 AM)zge Wrote: Are you sure? I've played around with Plan 9 a few times, but didn't see a way to trivially combine various existing GUI tools into new ones. I guess you could start a new rio session in a terminal, but I don't think that's really what eduarch42 means (?).

Start a plan9 session, you end-up in a raw terminal without graphical ability.

Start acme, it opens as the root window.

Instead of acme, start rio, you can now open new windows in which start other programs, including acme.

That is how you can combine programs onto others on Plan9.

X11 has XEmbed [1], and tabbed [2] is an example that uses it for providing a "tab" feature to surf, st, and more.

[1]: https://en.wikipedia.org/wiki/XEmbed
[2]: http://tools.suckless.org/tabbed/

This means that programs can be chained together, but it hardly compares to a pipe.

I think that plan9 shines with its plumbing system. Hilight something with the mouse, middle click in another program and the content is pasted/reused in an other window.
And in essence, a plumbing system is made of pipes ;)

Yeah, i have tried 9plan (9front actually) because i want to take inspiration to a set of programs i'm trying to develop. A DAW (Digital Audio Workstation) that will consist of several independent programs. Meaning if i want to add distortion to a sound file, i'll need to first open the file opener program and then in a way chain it and pipe the output of the file to a distortion one. Having a "unix philosophy" based music creation suite.

Another good way to send data from one program to another would be drag & drop.
This puts the "piping" mechanism onto the user though, but would be a cool way to send data between programs. For example, select an audio portion, then drag it onto the "distortion window to convert it.

Yes, the drag & drop is already in a way a piping mechanisms, that i think could be ideal for GUI applications.

In plan9 there's control.h, which could be technically mangled into a file server for creating UI applications from say, a shell script. It's crazy cool. It uses channels internally (think Golang channels) but! Very important to state, it's unfinished, and a bit janky. The idea is there though.

(25-01-2020, 08:27 PM)eduarch42 Wrote: Yeah, i have tried 9plan (9front actually) because i want to take inspiration to a set of programs i'm trying to develop. A DAW (Digital Audio Workstation) that will consist of several independent programs. Meaning if i want to add distortion to a sound file, i'll need to first open the file opener program and then in a way chain it and pipe the output of the file to a distortion one. Having a "unix philosophy" based music creation suite.

https://github.com/ftrvxmtrx/neindaw maybe?

(28-01-2020, 08:54 PM)Halfwit Wrote: In plan9 there's control.h, which could be technically mangled into a file server for creating UI applications from say, a shell script. It's crazy cool. It uses channels internally (think Golang channels) but! Very important to state, it's unfinished, and a bit janky. The idea is there though.

Thanks for the recommendation, although i'm trying to develop it for it to be cross-platform. The 9plan topic was just for me to take inspiration in GUI pipes.

My tinkering process has taken me into a different perspective in how this software could look. I came up with making a general main program which will have inner windows like a piano-roll, note editor among other things. You could pipe for example the piano roll into a sound file and then pipe it into the note editor to replay the notes after.
The piping could be done with nodes (like the ones used in blender) and dragging and dropping. There's also the VSTs which in the music creation world are like plugins that provide new instruments, for handling them i could just create a "companion" program that will accept the VSTs file and open a window with the VST's UI in the main program with the other inner windows. I'm thinking developing this with rust and Dear ImGUI.
Any feedback appreciated

I feel stupid for sticking this talk everywhere I go, but here is it again: https://invidio.us/watch?v=RIctzAQOe44

The crux of it related to the context of this conversation : there ARE pipes in today's GUI: "pipes" (not as in pipe(2) syscall though) for putting the pixels onto the big frame of our screens, with internal (internal piping of X11) / extrenal (netowrk X11 export) protocols that handle the piping.

Rio is beautiful as it can invoke itself in a window of itself (a second nested instance of itself).

Wayland is moving slightly more toward that direction. Looks like the maintainers are sick of some of the terrible designs (yet could do a lot with them) that goes with the X11 protocol and implementation. A wayland windows is more or less just exposing a rectangle for the client to draw in rather than handling a collections of sub windows that compose buttons and GUIs. Toolkits take this role instead.

I know the thread are "GUI pipes" and not "pipes making the GUI"...

All this talk of drag and drop and music has reminded me of some things: sunvox[1] and pure data[2]. Neither of them work exactly like pipes, but I think at the heart they are similar - the user creates nodes which do things and can drag the output of one into the input of another. Pure Data is much more of a full programming language (albeit media-focused) but they both capture what I think of when I think of GUI pipes quite will.

Which really, is just how analogue synthesizers and guitar pedals work; plugging wires into each other to layer effects. To be honest beyond music I'm struggling to find examples of how the piping metaphor can be found in real life (which is where I always look first when trying to find how to represent something on a computer).

[1]: https://warmplace.ru/soft/sunvox/
[2]: https://puredata.info/

(13-04-2020, 01:44 PM)twee Wrote: To be honest beyond music I'm struggling to find examples of how the piping metaphor can be found in real life

You run "kitchen robot" with a bunch of arguments (flour, sugar, eggs, …) then pipe the output to your hoven which in turn will output a cake ☺

Don't forget to pipe the icing!

I think that an application with GUI pipes should draw only what it is supposed to do; it should not draw status bar, tabs, scroll bars, buttons, menu bar, window border, window decoration, etc.

The application should print a status line into a pipe, and the window manager would draw the status bar below the window, removing from the application the need to draw the status bar.

The application should send the contents of its window into a pipe, and the window manager would draw the content in a window, removing the need for the application to draw a scroll bar and to fit its content into the window.

The application should have a socket to receive commands from the window manager. The window manager draw the buttons and menu bar. The user chooses an action in the menu bar drawn by the window manager, the window manager send this action to the application via socket, and the application does what it is supposed to do.

The application should have no URL bar or any kind of prompt. It would receive text from a prompt in the same style the surf(1) browser uses dmenu(1).

I think that GUI pipes are supposed to remove from the application the need to draw most of the things a modern application draw on its window, and pass to the window manager (or other software) the task to draw the interface to the user.

In my view of GUI pipes, the only thing in the window drawn by the application is the window content, the rest of the interface is drawn by the window manager or some other program.

I don't see why/how using pipes or sockets to ask a separate process to draw these window decorations would be any better than calling the API of a framework library(*), which is what most GUI applications currently do.

I.e., the API is already the interface enforcing the kind of separation of concerns you're looking for. For the process at the other end of the pipe/socket to work, you're going to have to send it pretty much the same data you're passing to the API, only now you'd be passing it via a more cumbersome mechanism.

(* Doesn't have to be a callback-driven framework, of course. A widget library or an immediate mode UI library like imgui or imtui is an interesting solution to some situations.)

Quote:In my view of GUI pipes, the only thing in the window drawn by the application is the window content, the rest of the interface is drawn by the window manager or some other program.

This would turn window managers into a huge bloated nightmare.

They would need to implement buttons, menu, popups, text areas, checkboxes, ... Effectively turning them into an API rather than a mere "pipe". This would also be extremely restrictive for softwares likes the Gimp that uses palettes, brushes and so on. It means that the Gimp could not run under all window managers, because not all of them would implement the required buttons drawing.

Pipes are a good mechanism, but they should not be forced in at all costs. Using the pipe(2) syscall internally is sexy though, and I would love to be able to call in any image viewer from within the Gimp to import an image, rather than relying on the builtin GTK file explorer.

As for surf(1), it doesn't use pipes to set the URL, but change a specific X atom on the surf window to define the URL (just like dwm statusbar), which means that xprop is enough to change surf current URL (so X atoms are used as a piping mechanism here, which is great !).

(20-01-2020, 01:41 AM)eduarch42 Wrote: How would one go to take the concept of unix piping into the GUI environment?

Here's something I often find myself doing:

$ find . -name "*.jpg" -newer timestamp | sxiv -io | iptckwed -i -a "b&w" ; touch timestamp

Here sxiv(1) is being used as an interactive filter to look at the new image files and pass the pathnames of the selected ones on to the next stage of the pipeline. Text in, text out, graphics in between.

Probably not what the OP was asking about, but I thought I should point out that some GUI programs already support piping scenarios like this.