Tag Archives: linus

GUI piping instead of screen shots

Currently I have to share info via capturing screen shots of various tools. An example of where this is required is in Eclipse’s Java developers environment.

The Eclipse IDE via the various added plugins and features captures a lot of metadata about a project and its various assets. For example, in the outline view you can see various listings with applied filters. Now try to share that in an email or document. You have to take a snap shot of the screen. This is not a very practical example, it’s just to show the issue. This issue comes in various other plugins like Team providers. Note, I’m not singling out Eclipse on this; all tools and applications have this problem.

While screenshots can convey the original purpose of sharing a particular view of data, they are very difficult to reuse in diverse ways. For example, we may want to sort or filter a listing of data. Or we we may want to reuse that data with external reporting or metric applications. With a GUI screen shot this is not possible.

Graphical tools should allow piping of information. As in Unix piping, a tool should allow re purposing of its generated data. This is not just a developers geeky need; many times error pop ups and other types of displays do not allow the end user to copy the actual ASCII textual information.

There are many ways of doing this. At root, the two options are textual piping, as used in *nix systems, and object piping, as used in PowerShell.

The ideal solution would allow a drag&drop functionality. This is already used in many apps via OS or application level support. For example, right click on the browser and you can copy stuff. Yet, even in the browser scenario, the data result is not semantic (based on the information context), it’s just text or via the contextual menu a set of standard objects.

One possibility is that a drag&drop sets up a pipe line and a standard markup of the data is transferred.


Creative Commons License
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.

Why are command shells one dimensional?

Despite all this touch this or that and 3D gee wiz shown in movies we are still in the punch card age to some extent.

Decades ago you had to create code that was chopped up into a fixed line length; some positions where even used for specific things. An example is the programming of Fortran using punch cards.

You’ll find this punch card single line interface still alive today. The browser address bar is such an interface. And, afaik, most command shells operate in a per line manner, the enter key executes the command line (which could itself be composed of multiple commands, pipes, redirections, and mutliple ‘command streams’). If you want to enter text to create commands in a more natural 2D manner, you have to create scripts or programs or open up special shells that allow you to highlight text and execute it.

One current way of minimizing this one-dimensional limitation is allowing the single line to be rich. For example, in Bash you can do some powerful stuff on the single command line, like history, substitutions, and so forth. But, this is just a geeky way to control a system. What is needed is a domain specific language per task. Or is natural language processing the only solution?

I could be wrong, of course, and so what. Just making an observation.

Interesting comparison: Bash vs. PowerShell

Creative Commons License
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.