Slashdot Mirror

← Back to Stories (view on slashdot.org)

Pipes In GUI? (Redeux)

Posted by Cliff on from the questions-redeux dept.

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?

3 of 12 comments (clear)

  1. Non-distributed Piper by jmv · · Score: 2

    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.

    --
    Opus: the Swiss army knife of audio codec
  2. It's a good idea by Bryan+Andersen · · Score: 4

    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.

  3. Good Examples of GUIs + Pipes by Wills · · Score: 2

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

    --
    Scroogle