command line vs gui
in [General Linux]
|
Prev: micro solution backpack cd-writer hell
Next: "...error while loading shared libraries: libg2c.so.0"
From: Lee Sau Dan on 17 Nov 2005 10:49 >>>>> "Robert" == Robert Heller <heller(a)deepsoft.com> writes: Robert> The only sort of 'unifying' interface is going to be an Robert> *intelligent* voice-recognition / natural-language type of Robert> interface, ala Star Trek. Voice is serial and natural-language is CLI like. So, aren't you just talking about CLI using voice? I can't see how this unifies the GUI into it. How do you click with voice, or drag with natural-language? Robert> One way of thinking about the differences between a GUI Robert> (aka 'point-and-click') and a CLI and how they relate to Robert> how effectively one can communicate with one's computer to Robert> get stuff done is to consider that a GUI interface is not Robert> really much different than a pre-lingual communication Robert> system. I can't agree more. Imagine going to a drug store, where they store different drugs into different drawers or cupboard. You, an adult speaker, just go to the employee and tell them the *name* and *amount* of the drug you want to buy. (i.e. give a *command*) You delegate the task of digging out the drug to the employee. (I delegate locating the "find" binary to the system.) You get your drug in a few seconds. OTOH, some people seem to prefer not to say the name of the drug, but to wander around the drug store and open the drawers and cupboards themselves to locate something to _visually_ look like what they want to buy. They then pick that out. They think this is more efficient, because in this way, they've spent most of the time on actually finding the drug, instead of delegating that task to the employees of the store, who can do the search much better and faster. But strangely, these people tend to be very satisfied with this "achievement". Robert> One can replace 'point-and-click' with 'point-and-grunt' Robert> (ala proto-humans) or 'point-and-scream' (ala infants). Robert> In all of these cases, the communication is limited to the Robert> choices at hand, literally (the finite and *limited* set Robert> of things available on the screen). A CLI interface is Robert> not so limited. It has all of the advantages of a full Robert> blown language and can refer to things that are 'off Robert> screen' (things that are not visible). GUI: like a child pointing those candies he wants at a candy store (Why not say the names of the candies? Because they're not yet good enough at language and the terminologies.) CLI: like an adult getting drugs from a drug store: say the name and get the drug from the employees almost instantly. I find GUI very childish. -- 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 17 Nov 2005 10:54 >>>>> "Richard" == Richard Steiner <rsteiner(a)visi.com> writes: Richard> It's true that old-school *NIX folks seem quite resistent Richard> to the idea of putting anything between the user or Richard> administrator and the good old command line, but the Richard> concept was quite common in MS-DOS, and dozens of Richard> different "filemanager" and "menu system" implementations Richard> were created for DOS over the years, some of them Richard> relatively sophisticated. That's because DOS never had a decent shell. (Well... I haven't tried 4DOS seriously, though.) Unix has been having very productive and powerful and useful shells for decades. Now, with history and completion, those menu systems and file managers simply look redundant. >> In order to be a viable alternative to the command line, a menu >> system would have to be huge and unwieldly. Imagine writing a >> front-end to a command such as find without emasculating it. Richard> Not really. It just has to serve its defined purpose Richard> while allowing authorized users to bypass it and use the Richard> real shell for more complex tasks. True. Look at an ATM (even a text-only one). It's UI doesn't need to provide more than what you're supposed to do. So, I won't blame an ATM for not giving me a CLI. But for a general purpose PC and a developer's PC, please don't give me an ATM menu system or counter-productive GUI's. I don't want to be so restricted. -- 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 17 Nov 2005 10:57 >>>>> "Longfellow" == Longfellow <not(a)this.address> writes: Longfellow> I think many of us have settled on something like Longfellow> Fluxbox, perhaps with gkrellm in the slit, some Longfellow> serious slang apps (mutt, slrn), and a raft of GUI Longfellow> terminals stashed all over everywhere doing different Longfellow> things. I can launch the Gimp and run CLI ImageMagick Longfellow> stuff. I can run Audacity and sox on CLI. Mix and Longfellow> match GUI and CLI as appropriate. Longfellow> Best of both/many worlds means choosing what works Longfellow> best, and having the best means having all options at Longfellow> hand. It can be better! The two/many worlds could be able to interact with each other and work co-operatively to achieve something unprecedented. Of course, a choice between 2 worlds is something nice to have. But a _good_ blending of the 2 could cross-over and bring about innovations. -- 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 17 Nov 2005 11:06 >>>>> "notbob" == notbob <notbob(a)nothome.com> writes: notbob> While I consider the mouse a necessary input device, I notbob> loath to reach for the damned thing. It's a major pain to notbob> take my whole hand/wrist/arm away from it's notbob> rested/supported position at the keyboard and reach over notbob> and grab a hunk of plastic when I can just extend a pinky notbob> and execute a couple taps. But, the mouse is notbob> irreplaceable in certain applications. How can a keyboard notbob> easily create a diagonal line? It can't. 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. Of course, for casual drawing, the mouse is better. But if you want more precise drawing, you'd opt for a digitizer instead. Lacking such an expensive device, I'd choose to use the keyboard to type commands with precise coordinate values. (I like metapost, and I've used it to draw many diagrams.) notbob> So, it depends on what one is doing on the computer. Right. Pick the right tool. notbob> After more than a couple bouts with Repeated Strain Injury notbob> (RSI), I finally settled on a very efficient and low notbob> physical impact solution for CAD. A one handed keyboard notbob> (left) and a really good mouse. No kidding! Neither hand notbob> need leave their respective device. Keyboard for one or notbob> two tap command input and mouse for spacial graphics notbob> input. It worked like a charm and my RSI probs notbob> disappeared. I usually do that with XFig and recently the Gimp. Left hand on the keyboard for the short-keys. Right hand on the mouse to move the cursor and doing the clicks and drags. It's nice that in these programs, many tools in the toolbar can be activated by a *simple* key press (i.e. no Ctrl-Alt-Shift things). -- Lee Sau Dan §õ¦u´° ~{@nJX6X~} E-mail: danlee(a)informatik.uni-freiburg.de Home page: http://www.informatik.uni-freiburg.de/~danlee
From: blmblm@myrealbox.com on 17 Nov 2005 15:04
In article <M4ydnR00v5Qwv-HeRVn-hA(a)is.co.za>, <news(a)absamail.co.za> wrote: >> On 2005-11-16, silicono2(a)yahoo.com wrote: >> > I've had a Unix-using acquaintance tell me that he much preferred >> > command lines over GUI, even when using Windows. For all the >> > advantages >> > of GUI I agree that it's much easier to issue a series of commands in a >> > command line or do something like "copy *.* a:" as well. Can we >> > get the >> > best of both worlds with an interface using charts/fields of text? The >> > only example I can think of is BIOS config (also DOSshell a while ago), >> > obviously it hasn't caught on. >> > Of course you can argue that a fields/charts interface is in fact a >> > GUI, with "true" graphics simply replaced by ASCII graphics? >> >Chris F.A. Johnson wrote: >> There have been other attempts to do this, but there are good >> reasons they didn't catch on. >> >What are those "good reasons" ?! > >> I just read about two of them in an old (1988) book, Understanding >> UNIX, A Conceptual Guide. It mentions ASSIST, "a menu-driven. >> forms-based utility that helps the user construct Unix commands", >> and Visual Shell in XENIX, "a menu-driven user interface patterned >> after the MultiPlan spreadsheet". >> >> In order to be a viable alternative to the command line, a menu >> system would have to be huge and unwieldly. > >That's exactly what computing is for: to hide/protect the user from >'huge and unwieldly'. The 'huge and unwieldly' calculations are >hidden from me if I press a few buttons on my pocket calculator >to find 'the 3rd root of 17'. A misleading analogy, IMO. What a GUI hides is not so much the internals of what's happening as the full range of options one can use to control what's happening. >BTW thanks for the lead. I'll goog: 'ASSIST' & 'Visual Shell'. >The closest for me is mc the killer ap. well cloned from the >original AFAIK DOS-nc. > >> Imagine writing a >> front-end to a command such as find without emasculating it. >> >I've got very strong feelings about this topic. >And apparently the opposite ideas to you. >Your use of the word "emasculating" suggests that you don't want >to be isolated from the fascination of the internals of "find" when >you use it ? If "find" has fascinating irregularities like the english >language which makes it unsuitable for structuring/compacting >into a menu-tree, then it's not for computing. It's not the internals that would be hidden -- I like and use the "find" command, but I have no particular interest in knowing the details of how it turns those admittedly cryptic parameters into the desired output. What might be hidden, or at least made more difficult to use, is the full range of options. The input that controls what files are found can be almost arbitrarily complex, and building up arbitrarily complex expressions doesn't seem like a task for which a GUI is well suited. (I could be wrong about that, though.) > >If I'm doing an important/fascinating pencil & paper drawing, >[computing task] I don't want to be distracted by the details >to pencil-sharpening [the 'find' comand sysntax]. > But you probably want to control, for yourself, exactly how sharp the pencil is, the angle at which it contacts the paper, the amount of pressure exerted, etc., rather than selecting these things from a finite menu of choices, right? > >Robert Heller wrote:- >] Right. For some commands (such as find), there is no real chance of >] ANY viable 'graphical' interface. >I don't [want to] know the detailed syntax of find, but if it can't be >'structured' in a menu, then it's a mess and should be replaced. >]And for others a CLI interface might >] make no sense. The only sort of 'best of both worlds' is a GUI desktop >] that includes an 'shell window' (xterm+shell). >] >] The only sort of 'unifying' interface is going to be an *intelligent* >] voice-recognition / natural-language type of interface, ala Star Trek. >] >That's very wrong, but thanks for raising it. >There are 'two different worlds: > 1. musician, rigourous/trained thinkers, software developers ... > 2. CD-poppers, regular-rappers, M$-users ... > >Certain skills require a minumum of training and inate intelligence. >Even if you just want to be a 'ball player', you can't just get the skills >from an aerosol-can or a pill. > >Natural-language might be great eg. for simple stuff 'in the dark' >or if you've got your hands full. >Speech is much slower than 'mousing' and the visual channel is >far superior to the audio chanel in humans. >The see-recognise [vs. recall and type] and select is a winning >strategy. My prefered OS oberon-S3 is a text-based point & do. >The mouse is [possibly] corded, and the cords become instinctive. >So eg. you will visually scan the [usually multiple frames/windows >on the] screen and 'think' "I'll open that text file"; and your fingers >will instinctively cords the 'open file cord' when the cursor is over the >file-name. Or you will 'think' "I'll execute that command".... > >Importantly you don't need to burden you memory with: >is the command called Backup.DeleteFiles, or deleteBakFiles or .... > >I just can't explain why people would want to remember and type >in the required syntax for 'find', except that they like to think that >they are communucationg directly with 'the little man in the box' >instead of selecting from a predetermined set of options. Admittedly there might be a certain element of "I'm cool because I know this cryptic stuff." However: For commands one uses frequently, it can be faster to just type the thing than to mouse around in menus, and it's no more of a strain on memory than remembering .... oh, how you get from your house to some place you visit frequently, say, or a phone number you call often. (This may be a "YMMV" thing, though; there are people who will never remember phone numbers, no matter how often they call them.) (Maybe with programmable phones this is a moot point anyway, but it's the best example I can think of.) For commands one uses infrequently, GUIs are easier but may limit flexibility. Like I said with the pencil analogy earlier -- do you want to choose from a limited menu of options, or have access to all the possibilities inherent in the tool? > >] One way of thinking about the differences between a GUI (aka >] 'point-and-click') and a CLI and how they relate to how effectively one >] can communicate with one's computer to get stuff done is to consider >] that a GUI interface is not really much different than a pre-lingual >] communication system. One can replace 'point-and-click' with >] 'point-and-grunt' (ala proto-humans) or 'point-and-scream' (ala >] infants). In all of these cases, the communication is limited to the >] choices at hand, literally (the finite and *limited* set of things >] available on the screen). A CLI interface is not so limited. It has >] all of the advantages of a full blown language and can refer to things >] that are 'off screen' (things that are not visible). > >I suspect this whole debate is based on personality types: left-brain >vs. right-brain ? > Could be. -- | B. L. Massingill | ObDisclaimer: I don't speak for my employers; they return the favor. |