command line vs gui
in [General Linux]
|
Prev: micro solution backpack cd-writer hell
Next: "...error while loading shared libraries: libg2c.so.0"
From: Rick Pikul on 19 Nov 2005 00:39 On Fri, 18 Nov 2005 18:40:04 +0100, Peter T. Breuer wrote: > In comp.os.linux.misc blmblm(a)myrealbox.com <blmblm(a)myrealbox.com> wrote: >> In article <o4d153-rna.ln1(a)news.it.uc3m.es> [ptb wrote], >>>> line. I did say that GUIs are good for some purposes. Can you give >>>> an example of a GUI you think is "state of the art" (whatever that >>>> means)? >>> >>>Grr .. I'll volunteer one: writing html. > >> Say what? "Writing HTML" is a task/job, not a UI, no? > > I mean it's an example of a purpose for which GUIs are well suited, > which I thought he was trying to ask. How do you get that from: "Can you give an example of a GUI you think is 'state of the art'...?"? I'm honestly curious. -- Phoenix
From: Peter T. Breuer on 19 Nov 2005 03:41 In comp.os.linux.misc Rick Pikul <rwpikul(a)sympatico.ca> wrote: > On Fri, 18 Nov 2005 18:40:04 +0100, Peter T. Breuer wrote: >> In comp.os.linux.misc blmblm(a)myrealbox.com <blmblm(a)myrealbox.com> wrote: >>> In article <o4d153-rna.ln1(a)news.it.uc3m.es> [ptb wrote], >>>>> line. I did say that GUIs are good for some purposes. Can you give >>>>> an example of a GUI you think is "state of the art" (whatever that >>>>> means)? >>>> >>>>Grr .. I'll volunteer one: writing html. >> >>> Say what? "Writing HTML" is a task/job, not a UI, no? >> >> I mean it's an example of a purpose for which GUIs are well suited, >> which I thought he was trying to ask. > How do you get that from: "Can you give an example of a GUI you think is > 'state of the art'...?"? I daresay one get as far as "can you give" before the phone rings. Peter
From: Peter T. Breuer on 19 Nov 2005 03:43 Lee Sau Dan <danlee(a)informatik.uni-freiburg.de> wrote: > repeat block? i.e. repeated whitespace characters affect semantics? > That'd be very error prone! Occam does that too - and occam is the basis of verifiably correct programs (i.e. that meet their specifications) written for the transputer. Peter
From: Lee Sau Dan on 19 Nov 2005 11:32 >>>>> "notbob" == notbob <notbob(a)nothome.com> writes: >> It can! A command like: draw_line (0,0)-(20,10) draws a line >> inclined at 30 degrees w.r.t. the x-axis. Much easier and >> _more precise_ than having to aim at the exact coordinates with >> a mouse. notbob> You are correct, of course, but very few programs don't notbob> have some sort of snap capability. I once used a early notbob> computer graphics program where all lines were done with notbob> coordinates. What a nightmare! This was made even worse notbob> by the fact each line's x,y, and z coord had it's own notbob> entry box in the gui and required hitting tab and arrow notbob> keys move from one to the other. Very tedious and slow. Metapost and metafont has a built-in entity representing points. You don't have to specify coordinate values for drawing. You can use the "point" objects to specifying how lines and curves are drawn. The coordinates can be specified implicitly by giving equations relating them to one another. Something like this: (width,height) = (400pt, 300pt); point a, b, c; a = (0,0); c = (width,height); b-a = c-b; % b lies midway between line-segment joining a and c draw a--b; % draws a line from (0,0) to (200pt, 150pt) where 'pt' is the unit "point" == 1/72.27 inch. So, in metapost, one usually does not need to specify coordinates, other than a few "anchor" points or parameters. Most points are specified implicitly using equations. The section formula z = (1-t)*a + t*b even has a short form z=t[a,b], which is quite handy. -- Lee Sau Dan §õ¦u´° ~{@nJX6X~} E-mail: danlee(a)informatik.uni-freiburg.de Home page: http://www.informatik.uni-freiburg.de/~danlee
From: Lee Sau Dan on 19 Nov 2005 11:58
>>>>> "Jacob" == Jacob Sparre Andersen <sparre(a)nbi.dk> writes: >> I think that one could design a GUI for programmers, for >> example by providing a way to build a data flow from building >> blocks (a bit like Apple's Automator, but more powerful). Jacob> Maybe. A GUI would probably assist creating more Jacob> complicated data flows than the single stream inherent in Jacob> the traditional model with pipes in shells. Bash allows multiple data flows and it's not difficult to do: comm -12 <(sort a.txt) <(sort b.txt) | uniq -c | sort -nr This command feed 2 pipes (from 2 'sort' processes) into the 'comm' process, and then feeds 'comm's output to 'uniq' and the a third 'sort'. >> I doubt one could design a shell for non-programmers that >> suited them better than a GUI. Jacob> Having seen travel agents working in their shell, and Jacob> having tried to use the GUI's made available by the Jacob> airlines on the web, I disagree with that. I've also seen bond tradering using a Bloomberg terminal to query bond prices and enter trades. It's a CLI, and they like it for the brevity. The commands are cryptic, too. But they prefer to type less and avoid the mouse, rather than forgoing speed and productivity. Jacob> I think what matters isn't programmers/non-programmers, as Jacob> much as how often you have to use the interface. Exactly! Even on airline websites, I would type in airport codes (whenever possible) rather than selecting from the lengthly list of airports/cities in the combo box. Jacob> It may though be that programmers have lower patience with Jacob> the UI's interfaces, and thus are quicker to adopt the Jacob> shell - especially if it actually is scriptable and not Jacob> just a TUI. If you have to do many things repeatedly, you'll appreciate the CLI, which has history, and allows you to write shell scripts. >> - Apple's commando interface that allowed one to pop up a >> GUI-dialog with which one could both see and set all options >> for a command Jacob> That's a nice idea. Another nice idea (I can't remember Jacob> _where_ I saw it) is to let a GUI generate commands in the Jacob> shell. That allows the user to take the generated commands Jacob> and generalize them as needed. This is possible with Emacs, and I think also possible with the Gimp. But this has to be done in an architectural level. Emacs maps every key to a function with a eLISP name. You can always invoke the same function from eLISP code. So, it's scriptable. Further, Emacs allows the user to rebind the keys to any eLISP function. So flexible! Gimp has a similar design: the menus invoke functions, which can be invoked from the Scheme-based scripting language. Too bad that most people who develop GUI-based programs do not organize their programs this way. Many even put the code for the operations into the callback/handlers of the GUI buttons/menus. The IDE's used by them usually invite them to do this. (So, I think these IDE's are flawed. They don't guide their users to do the right thing. They only encourage dirty-and-quick development.) -- Lee Sau Dan §õ¦u´° ~{@nJX6X~} E-mail: danlee(a)informatik.uni-freiburg.de Home page: http://www.informatik.uni-freiburg.de/~danlee |