Project Sewer

How can a GUI and pipes interact?

A GUI can be any part of the pipeline.

First the GUI can be a sink, accepting data from the pipeline. This is the most obvious exmaple of GUIs working with pipes. It is natural for the GUI to display the final result of the pipe. Command line programs like pg, more and less currently serve this role. A GUI pager could provide the same functionality or even increased functionality with vertical and horizontal scrolling.

Second, the GUI can be a filter by reading data from the pipe and then sending it on. The odometer.tcl is an example of this. It listens on STDIN, writes to STDOUT and displays the number of bytes passed in a window. Other examples might be a last line read displayer, a progress bar, or a GUI tee program that writes to a window instead of a file.

A GUI can also be a data source. The GUI pager mentioned above could have an option to "Send to Pipe". The user would then specify the pipe in some manner and the data contained in the pager would be forwarded to the pipe. An example might be that you wanted a word count (wc) of the file. Just press "Send to Pipe", enter "wc | " and a new window would be opened that had the results of wc.

A GUI can also be thought of as allowing the user to interact on the pipeline. With command line pipes, the user doesn'e have much chance to even observe the data, let alone change it. GUI filters and sinks will allow more control and flexibility for the user.

Also, instead of creating huge menu structures with options people don't need, GUI programs should allow for users to add menu options on the fly, or configure them as they like. The menu options will be tied to pipes. The user will only see the options they really need and use. The programs themselvs become smaller as the program only need provide a small bit of functionality while delegating tasks to other small and specialized tasks.

posted by Matt @ 8:40 PM