Re: [Bashburn-info] I'd like to propose new verbose functionality

[Steven W. O. <st...@sy...>]

On Tuesday, Aug 26th 2008 at 17:10 -0000, quoth Markus Kollmar:

=>Steven W. Orr wrote:
=>> On Tuesday, Aug 26th 2008 at 13:39 -0000, quoth Anders Lind?n:
=>> 
=>> =>> Also, I think it makes more sense for the information to go to the
=>> screen
=>> =>> so the user gets feedback at the time that he executes something. Trying
=>> =>> to go to a logfile *after* the session is over seems to defeat the
=>> purpose
=>> =>> of learning what's happening while it's happening.
=>> =>>
=>> =>True, but wouldn't it also be a good idea to have a log file that
=>> =>people can just send to us incase something goes wrong?
=>> 
=>> We can do that too. :-)
=>> 
=>> If there are no objections, I'll stick it on the list and probably get to it
=>> later tonight.
=>> 
=>>   
=>Hm, my opinion is also to have a log-file. But there should be a option to
=>deactivate it. Also the log file should not grow to big.
=>
=>Comment to "verbose functionality":
=>The unix veterans told us that a programm should just do it's work and only be
=>VERY verbose if something does not function right or the function fails or in
=>case of an other error.
=>
=>So we read in the book "The Art Of Unix Programming" (Eric S. Raymond):
=>
=>"Go ahead and give your GUIs progress bars for long operations."
=>
=>"Your interface design as a whole should obey a Rule of Least Surprise, but
=>the content of messages should obey a Rule of Most Surprise - be chatty only
=>about things that deviate from what's normally expected."
=>
=>"If you want chatty progress messages for debugging purposes, disable them by
=>default with a verbosity switch."
=>
=>So where do you think exactly more verbosity is needed?
=>
=>Markus Kollmar

Markus, I took the liberty of answering you on the list. It really should 
be part of the public discussion of the tool.

I think verbosity is the wrong phrase to be using. There are lots of GUIs 
out there that do lots of things. I categorize some GUIs (like BB as 
wrappers for complex systems of commandline interfaces. For example, if I 
was going to write a wrapper around The Dreaded find Command, I would want 
to see the generated commands. Why? Because this is not about finding 
files. It's about making it easier to run the find command.

In the case of BashBurn, we're not talking about a new GUI interface that 
reimplements what cdrecord + company already do. We're talking about a GUI 
wrapper around a set of very complicated commandlines.

I claim that the context of Raymond's quote is different. He's talking 
about display of things like error messages, warning messages or even 
informative messages that result from these either these operations or 
from operations that are not even commandline based. I'm talking 
about the (17?) commands themselves.

I very much like the idea of being able to turn on seeing the commandlines 
that are generated as part of the regular output produced by the wrapper 
(as opposed to the logfile). To see the generated errors that result is a 
totally different discussion.

BTW, I wish more people would read TAOUP.

-- 
Time flies like the wind. Fruit flies like a banana. Stranger things have  .0.
happened but none stranger than this. Does your driver's license say Organ ..0
Donor?Black holes are where God divided by zero. Listen to me! We are all- 000
individuals! What if this weren't a hypothetical question?
steveo at syslang.net