Prev: micro solution backpack cd-writer hell
Next: "...error while loading shared libraries: libg2c.so.0"
From: Benni on 18 Nov 2005 10:30 Reinder Verlinde wrote: > - Microsoft's upcoming shell that gets rid of text as the I/O format. Never seen a UNIX shell?
From: Jacob Sparre Andersen on 18 Nov 2005 10:39 Reinder Verlinde wrote: > Christopher Browne wrote: > I would say that some (all?) of the fundamental differences between > shell and gui are: > > - a shell requires one to memorize available options, whereas a GUI > allows you to easily discover them That is not the case with the shell I use (Zsh). A press on the tabulator key will generally (unfortunately not always) give me a list of available commands/options/files. > - a shell is command-centered; GUIs are data-centered. I'm not sure what you mean by this, but you may be right. > - GUIs use direct manipulation Yes (sort of). > 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). Maybe. A GUI would probably assist creating more complicated data flows than the single stream inherent in the traditional model with pipes in shells. > I doubt one could design a shell for non-programmers that suited > them better than a GUI. Having seen travel agents working in their shell, and having tried to use the GUI's made available by the airlines on the web, I disagree with that. I think what matters isn't programmers/non-programmers, as much as how often you have to use the interface. It may though be that programmers have lower patience with the UI's interfaces, and thus are quicker to adopt the shell - especially if it actually is scriptable and not just a TUI. >> Well, 'find' is probably not the most "user-friendly" program ever >> created. I use it, surprisingly often; some coworkers, who are >> otherwise very knowledgeable, emit blank stares when they encounter >> it. It would be nice if something better had been created; alas, I >> haven't seen better alternatives forthcoming... > > I assume that this is to do with the Unix 'find' command. This shows > another difference between GUIs and shells: GUIs tend to improve > over time 'all over the board'; shells and shell commands in some > areas can not. Some improvements I know of in shells are: > - line editing > - history buffer > - command completion (still in its infancy because it does not know the > syntax of commands) You should take a look at Zsh and see if you really think the description "in its infancy" is proper. > - 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 That's a nice idea. Another nice idea (I can't remember _where_ I saw it) is to let a GUI generate commands in the shell. That allows the user to take the generated commands and generalize them as needed. > - Microsoft's upcoming shell that gets rid of text as the I/O format. I'm not exactly sure how that can be said to be an improvement. Formally adding other content types is a good idea (in practice it has already been done a long time ago), but removing text as an I/O format seems to remove a lot of the possibilities you have with shells. Greetings, Jacob -- "simply because no one had discovered a cure for the universe as a whole - or rather the only one that did exist had been abolished"
From: Peter T. Breuer on 18 Nov 2005 11:46 In comp.os.linux.misc blmblm(a)myrealbox.com <blmblm(a)myrealbox.com> wrote: > Maybe I lack experience with really well-written GUIs -- very possible > since I'm a little fanatical about doing most things from a command > 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. Peter
From: notbob on 18 Nov 2005 12:26 ["Followup-To:" header set to comp.os.linux.misc.] > Grr .. I'll volunteer one: writing html. ????? Not sure what you mean, "writing" html. Why would a gui be that much better than a cli editor? I would agree for a wysiwyg gui like Dreamweaver, but for writing? I, myself, use quanta, a gui based writer (not wysiwyg), much like Homesite. I use it because I'm not very experienced at html and quanta automatically throws up tag menus/prompts for us html dummies. OTOH, if I'm just doing a quick code edit, I'm more likely to use a CLI editor with syntax highlighting like jed or emacs rather than fire up the whole quanta program. Now, if you ARE completely clueless on html code, a gui program like Dreamweaver is excellent. I have a friend who builds good web pages and knows zip about the underlying code. Dreamweaver's drag and drop gui interface makes this possible. Again, it boils down to knowledge. nb nb
From: blmblm@myrealbox.com on 18 Nov 2005 12:29
In article <o4d153-rna.ln1(a)news.it.uc3m.es>, Peter T. Breuer <ptb(a)oboe.it.uc3m.es> wrote: >In comp.os.linux.misc blmblm(a)myrealbox.com <blmblm(a)myrealbox.com> wrote: >> Maybe I lack experience with really well-written GUIs -- very possible >> since I'm a little fanatical about doing most things from a command >> 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? One can write HTML with GUI tools or with .... Well, I don't know; does vim count as a GUI tool? -- | B. L. Massingill | ObDisclaimer: I don't speak for my employers; they return the favor. |