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

[Markus K. <mar...@on...>]

Steven W. Orr wrote:
> 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.
>   
That is ok Steven, that is what I wanted in fact!! ;-)  Ohhh - I have 
totally overlooked that my replying's to you have not reached all (the 
whole bashburn-list).

> 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.
>
>   
Hmm, yes  Raymond surely talks also about commands like "cp" which need 
no messages about what they did. But since we have a more complicated 
programm, it would perhaps be helpful for the user to have messages 
which give him a little the feeling that basburn does nothing bad 
(messages he could disable anyway if he want).
> 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.
>
>   
Ok, yes so this commandlines would also have a little bit the function 
of a progress bar (one can see, what is going on and whether something 
stops).

> BTW, I wish more people would read TAOUP.
>
>   
Yes, it is a really great book. It opened my eyes and shows the beauty 
of unix. Or to see why there is more Unix nature in one line of shell 
script than there is in ten thousand lines of C.

:-)