Pipes In GUI's

Caine asks: "While having some dead time at work, I spent some time thinking about how to write a good GUI. I started thinking about if you could implement pipes in a GUI. My thought was something like this: You could connect two programs and/or widgets by a GUI pipe. This could be visualized if the user wanted to, as a thin, pulsating red line or something. For example, you could pipe your browsers' status/error window to a log colorer. You could also pipe other things than text, such as pictures; if you're watching a streaming movie you could pipe it into the graphic programs' filters for example. Basically they would do the same as a normal "|" but with all kinds of data and in a GUI. Has this ever been done or written about before? Any implementations?" Interesting idea, but before this would be possible, we'd have to introduce the concept of discrete input-channels and output-channels into our GUIs, and that's not as easy as it sounds.

Comments

I would say..

[Stskeeps]

A common/filetype description protocol, and then unix/tcp sockets, and simply open two connections as a pipe, shouldn't be as hard? sockets are about some of the simplest stuff to create pipes with

Re:I would say..

[Valdrax]

That's nice.

Now for the question that is being asked -- how do you do this in a GUI? We're not talking about the backend stuff, which everyone knows about. We're talking about what do you do with your mouse and icons (or whatever) to graphically create a pipe between two applications. How do you manipulate applications -- in a generic fashion -- to set up a pipe-like construct?

java?

[stubob]

I'm not sure if this is what you mean, but the Java event model seems to allow this. For example, if you type in one text window, you can send the KeyPressedEvents to another window and handle them differently there. I've never messed around with anything more complicated than forwarding MouseEvents (moving the mouse in one window recenters a map in a different window.) Also, with the JVM design, different JFrames can communicate with each other simply through object references.

I guess the same idea could be done with X by registering for and dispatching callbacks to other panels in the same way.

-----

Corba?? bonobo??

[bmetzler]

Aren't things like corba and bonobo methods for communicating with applications? Either I don't understand Bonobo, or I don't understand the question, or I've had too much Mountain Dew.

XML

[hodeleri]

XML would be a good way to get things like this done. If you could find a common namespace applications would easily be able to converse with each other to use only what they want.

--
Eric is chisled like a Greek Godess

Re:XML

[Valdrax]

Okay, great. You use XML.

Now how do you actually get two GUI programs to talk to one another using this XML-based pipe? That's the question. It's not about the backend, it's about how you use a GUI to get two GUI programs to pipe to one another. What do you manipulate? How do you visually show the user that the programs are connected? Etc.

Not exactly what you are looking for, but..

[GuardianLion]

There is a programming environment that works much like that, called Labview. They call it a "dataflow" language, and the design is all graphical, building components and connecting them together with "wires". Piping things off to other processes (within the environment, but it was multi-tasking) was really easy. It'd be hell to write a browser in, since it is built for real-time test and measurement, but I got it to do some fairly useful stuff, including some disk-based communication to get around whiny IS types.

It was actually a lot of fun to program in.

Re:Not exactly what you are looking for, but..

[nd]

BTW, LabVIEW 6.0 was just released this week, and it has been available for Linux since 5.0. See http://www.ni.com/linux.

I program in LabVIEW almost exclusively for my job, though I still prefer text-based languages.

Um, Bonobo, KDE's DCOP, OLE, any drag-n-drop

[hatless]

Plenty of GUI applications have been piping between each other for years now. Apart from some scientific and audio/video processing apps, the UI representation is usually different, but the purpose and function are the same. When you embed an updateable spreadsheet in a word processing document, that's piping. When you drag a document icon to a prionter icon, you're piping to the application that renders the document for printing, which in turn pipes to the print spooler. Ditto when you drag and drop a compressed file's icon onto an icon representing a decompression program.

Implementing a pipe metaphor into an entire UI framework isn't a bad idea. It is one that will likely have a small, techy audience. Using a nonverbal GUI to indicate what is being piped and to where, you run into a lot of ambiguity. When you connect one widget or window to another, what is it you're piping?

• the content of a widget, the underlying value passed by the widget, the functioning widget itself, or the bitmap/vector graphic contents of the widget?
  
• at this moment in time, or updated dynamically?
  
• Plain text? HTML? Richtext?
  

At a certain point in the stagnant WIMP interface, getting at these distinctions involves wizards and property sheets, and it ends up looking and feeling like an IDE.

Again, truly ubiquitous embedding and linking at the desktop environment level would be useful for programmers and for some power-user applications. But I wouldn't expect it to take the world by storm in the two-dimensional, mouse-driven windowing environments we use today, outside the self-contained applications (like audio processors) that it's used in already.

Apply the concept to VR interfaces and tactile interfaces, and maybe it'll be something fluidly usable for everyday use.

how about this...

[dutky]

There is a tool for MacOS called FilterTop which allows you to construct pipelines from special filter programs. You can then drag-and-drop files into the resulting filters (called 'droplets' in MacOS) and have the pipeline executed on the contents of the file, spitting the results out into another file afterwards.

I think that there was something else for the Mac, released back around 1995, that did something similar by arranging icons on the desktop, but I can't find any reference to it through Google.

Not drag and drop, dynamic content/static connect

[tolldog]

Where I see this usefull is where I have seen it implimented before. I have used a java gui tool kit that allowed me to create a data pipe from one node to the next. This made the programming for the app simpler. I see a similar idea for a gui.

For the developer:

What each window needs is some default output connectors and input connectors with defined data types. A great example of this is how the nodes in Maya work. The whole system is built of nodes with inputs and outputs. You can link an image file to a light and that light prjects the image. You link and expression that returns an image series, frame by frame, and now you have a slide/movie projector. The examples for the usefullness in development is endless.

For the user:
I can see where people, geeks and non-geeks could love something like this. If I want the output of notepad, perhaps some html I am working on, to be dynamicly displayed in netscape, I should be able to. OR... I could be working on a web page, have the text editor link to the html, the web development software link to some java script, and have GIMP link to the images. Any change in any of the tools, either cached or flushed, would update the look of the page, on the fly.

Why is this good?

It gets us back to the tool kit model, something that UNIX was based on. Build one tool, build it right. When somebody needs that tool functionality, pipe it. Do this with several tools and pipes and you can do anything. I see where too often the developer tries to throw too much functionality into the system (such as xemacs) and bloats it, where individual tools would work wonders.

Also, if the pipes were non-blocking, each tool could live in its own process space. This way if netscape stopped responding, you would not lose the work.

I see the benifits. I also see oponents pointing to similar ideas saying that this is similar enough to get it done. One such example would be the ability to embed something in a word doc. You can then double click on this and through the magic of windows be able to edit this data in the native app. This is close. This is more of a cached pipe approach. My problem with this is that the viewer is driving the changes (word) where in my earlier example, netscape was the results of the changes.
I see the order difference to be important because I don't want the viewing app to control how the content is generated, I just want it to display it.

I don't know... maybe it is too late for me to think straight... but I see this as posibly being the next good direction for a gui to take. What an idea!