Pipes In GUI? (Redeux)

jw3 revives an old question: "Unix wouldn't have 10% of its functionality without pipes, which allow gluing together smaller utilities and that way accomplish more complicated tasks. Fancy GUI's, however, while being nice and user-friendly and all are a totally different philosophy (see interview with David Korn, answer to question 6, which I rather fancied). Now I have found an ingenious project, called Piper, which tries to create a pipelike mechanism for a GUI interface. Interestingly enough, it is being written by biologists, who just lack the flexibility of the Unix piping mechanism, but, on the other hand, need lots of GUI for their work. What do you think about this project, fellow Slashdotters?" Based on the last conversation we've had on this topic, do you think the Piper project is a step in the right direction?

How about NeXTStep Services?

[Steven Borrelli]

Piper looks to be pretty heavy duty. How about something simple that is good for day-to-day use? NeXTStep had the built-in services menu, which provided a nice way to act upon clipboard data, whether the user had selected a file, image or text, and you could return any data type back to the caller.

I have fond memories of Scott Hess' excellent TickleServices [doubleu.com] for NeXTStep.

One of my favorite services was selecting some PGP-signed text and verifying it through the menu.

Non-distributed Piper

[jmv]

Piper looks to be pretty heavy duty. How about something simple that is good for day-to-day use?

Try Overflow (http://freespeech.sourceforge.net/overflow.html), it's the standalone (non-distributed) processing layer in Piper. It's simpler, and it has its own GUI.

for those who don't remember it...

[crovax]

the original article is here [slashdot.org].

--
Spelling by m-w.com [m-w.com].

It's a good idea

[Bryan Andersen]

I haven't looked at Pipes yet. I will tonight when I have more time, on the other hand...

I've been independently thinking of a Plugable GUI. What I was thinking of is a GUI library interface for programs. A program defines each data socket it has, what data is presented at it and how it can be manipulated. A separate part of the definition places the data sockets on windows in their correct places and defines the visual representation. At this point I feel the window definition part would be an XMLish like syntax to provide comonality across platforms and leverage existing knowledge. One of the things I wanted to make sure of is that the data sockets could be placed on multiple windows if desired. Because the window and data definitions are separated it's also possible to make multiple window repesentations for a prorgam and also to have some or all of the data sockets controlled by another program. A control socket library would be provided that allows a program to connect up to and manipulate the data sockets provided by another program. Note: this is what the GUI uses to attach to a program. The visual representation tells it what data sockes are there and how they are to be displayed. A program that is the combination of a few sub programs would have a visual representation that linked into one or more of the sub programs to control the data sockets that aren't controlled by the other programs. It would be an error to define a data socket without providing a visual representation, connection to a control socket or explicitly not giving it a visual representation.

Another part of the design is a network layer that allows one to hook up data sockes across systems seamlessly. It would be activated by changing the address of the socket to additionally specify a system and process group on that system rather than just the process group.

I unfortunatley haven't had much time to work on this idea even though I first dreamed it up back in 1989/1990. It had a little different form back then. It was to be the GUI interface for a flexible syntax programming language. Be thankfull I never release that upon the world. :) Right now I think I would implement it in Java or Nomen (when it's finished). Robots and robotic vision systems aare consuming all my time now.

Adobe has this patented

[fatmantis]

For what it's worth, I believe Adobe has this patented already, though I can't seem to find the entry at the USP&TO [164.195.100.11] just now, but you can see the application through their 'droplets' technology in Photoshop and other major apps.

This droplets scheme is a way to harness various functionality externally to the app, though the patent sure leaves it open enough in that it didn't specify app or OS at any point, and the language speaks of modules, processes and 'acting on external data sources'. It sounds like piping the modules together to me.

It's a good thing this is originating in Academia, through Unix, or there'd surely be trouble.

Good Examples of GUIs + Pipes

[Wills]

Actually the concept of combining Unix-style pipes and a GUI is not new:

• Visual programming languages [unige.ch], of which there are hundreds, are based on the same idea.
  
  
• Dataflow architectures [berkeley.edu] are also based on the same idea and have been around for many years.
  
  
• A good example is the visual programming environment Khoros Cantata [cs.ioc.ee] designed in the 1990s for image processing research. Programs are represented by a directed graph whose nodes are data sources, parameterised procedures, or outputs, and whose arcs are data flow paths (aka pipes).

  Here is an example Khoros program with "pipes" and GUI [cs.ioc.ee].

Re:Good Examples of GUIs + Pipes

[Bizzaro]

Actually the concept of combining Unix-style pipes and a GUI is not new

Yes, we know that it is not new ;-)

But, for the combination of visual programming, visual data flow, and P2P networking, Piper is in a pretty small field.

Khoros is actually most similar, but it is closed source and commercial.

Piper has some pretty unique ideas too.

--
This sort of thing has cropped up before. And it has always been due to human error.

Command Compilation in Piper

[Bizzaro]

For a document more directly related to this article (using Piper as a better UNIX GUI), try this link:

http://www.bioinformatics.org/piper/documentation/ command-compilation.html [bioinformatics.org]

--
This sort of thing has cropped up before. And it has always been due to human error.

Maya

[gtada]

Alias|Wavefront Maya has a similar architecture in it's node-based 3d package. Check out their Hypergraph and Hypershade to get an idea. :)

OS/2 had somthing like this

[Cogline]

I recall on OS/2 Warp (which I don't have installed right now, or I'd go home and check first), a similar functionality.

You could select some objects from the desktop (all items are objects and have methods and properties) and from the context menu choose Pick. What this did was allow the collection to be "dropped" on multiple items. In effect, if you could choose the proper items first, and have the proper items to drop on, you could "drop" them repeatedly. Like a pipe.

I recall that to buld programs to do this, you had to buy the SOM related products from IBM, which poor college students can't afford. So I did'nt have much of a chance to look into more details.

Re:Good Examples of GUIs + Pipes

[Wills]

From what I've seen, I certainly like Piper but I've seen fundamentally the same combination you cite of "visual programming, visual data flow, and P2P networking" in Khoros in the 1990.

You're wrong about Khoros being closed source; it is open source - you can download the source code here [ftp.ien.it] (if the link is broken, do a lycos ftp search for one of the sites still carrying it).

Re:How about NeXTStep Services?

[TotallyUseless]

NeXTStep services are alive and well in Mac OSX. Not too many apps offer access to this yet, but this will change. This is one of the most promising features for development on OSX imho.