* Alexander Graf<agraf@xxxxxxx> wrote:
The 'UNIX secret' works for text driven pipelined commands where we areFurthermore, another negative effect is that many times features areI disagree there. Keeping things local and self-contained has been the UNIX
implemented not in their technically best way, but in a way to keep them
local to the project that originates them. This is done to keep deployment
latencies and general contribution overhead down to a minimum. The moment
you have to work with yet another project, the overhead adds up.
secret. It works really well as long as the boundaries are well defined.
essentially programming via narrow ASCII input of mathematical logic.
It doesnt work for a GUI that is a 2D/3D environment of millions of pixels,
shaped by human visual perception of prettiness, familiarity and efficiency.
The problem we're facing is that we're simply lacking an active GUI /Have you made thoughts about why that might be so?
desktop user development community. We have desktop users, but nobody feels
like tackling the issue of doing a great GUI project while talking to
qemu-devel about his needs.
I think it's because of what i outlined above - that you are trying to apply
the "UNIX secret" to GUIs - and that is a mistake.
A good GUI is almost at the _exact opposite spectrum_ of good command-line
tool: tightly integrated, with 'layering violations' designed into it all over
the place:
look i can paste the text from an editor straight into a firefox form. I
didnt go through any hiearchy of layers, i just took the shortest path
between the apps!
In other words: in a GUI the output controls the design, for command-line
tools the design controls the output.
It is no wonder Unix always had its problems with creating good GUIs that are
efficient to humans. A good GUI works like the human brain, and the human
brain does not mind 'layering violations' when that gets it a more efficient
result.