On Tue, 11 Sep 2012 13:11:08 +0000, John Maher wrote:
...
> I don't understand this statement at all. I'm talking about a simple
> wrapper.
Ok, I got that wrong. But exactly for those wrappers there is no point in
trying to do *everything* the CLI can do in the GUI as well. Streamline
the most important things. I've done such a thingie for myself for cvs;
you could just run update (where in svn you'd do status), click on
filenames to see the diff, and commit. Nothing more needes; the only
point was not to cut&pase the filenames.
Interestingly I do the same with git on the command line because those
tools have gotten better and more streamlined there.
> And it would be very easy in incorporate *everything*. Even
> command that have not been added yet.
You can't especially not shell invocations, as that would viod the spriti
of the GUI.
> Again, if necessary it can be, very easy. However that is not the point
> of the wrapper.
Yes, it is. Imagine a GUI for 'svn status'. Now imagine how you'd
do the equivalent of 'svn status | awk '/I / { print $2 } | xargs rm'
with that GUI, or even with the help of that GUI for the svn part.
Putting that in a script and name it svn-clean is two lines.
Putting that in a GUI (and esp. your svn status wrapper) is..how much?
...
> in designing a program. They are not
> as limited as you believe them to be.
Programs aren't. GUIs are, exactly because of their primary goal.
They want to avoid the plugs and bolts at the outside, and thus they
aren't pluggable and boltable. (And yes, they do make many things
easier. And other things impossible.) Even Word has a CLI; even
though it's gruesome and called word basic.
Andreas
--
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800
