GUI pipes - Printable Version
+- nixers (https://nixers.net)
+-- Forum: General (https://nixers.net/forumdisplay.php?fid=3)
+--- Forum: Psychology, Philosophy, and Licenses (https://nixers.net/forumdisplay.php?fid=28)
+--- Thread: GUI pipes (/showthread.php?tid=2292)
RE: GUI pipes - Halfwit - 28-01-2020
(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?
RE: GUI pipes - eduarch42 - 28-01-2020
(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.
RE: GUI pipes - eduarch42 - 28-01-2020
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
RE: GUI pipes - josuah - 08-04-2020
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"...
RE: GUI pipes - twee - 13-04-2020
All this talk of drag and drop and music has reminded me of some things: sunvox and pure data. 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).
RE: GUI pipes - z3bra - 14-04-2020
(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 ☺
RE: GUI pipes - twee - 14-04-2020
Don't forget to pipe the icing!
RE: GUI pipes - phillbush - 01-05-2020
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.
RE: GUI pipes - ckester - 01-05-2020
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.)
RE: GUI pipes - z3bra - 02-05-2020
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 !).