Subject: Re: new --to command line option
From: sam th (sam@bur-jud-118-039.rh.uchicago.edu)
Date: Wed Jan 26 2000 - 16:46:00 CST
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed, 26 Jan 2000, Paul Rohr wrote:
> At 11:20 AM 1/26/00 -0600, sam th wrote:
> >I have to disagree here. I think that we should definitely give useres
> >the option of file conversion and opening the regular program at the same
> >time.
>
> Is there a bad outcome if we *don't* allow this kind of flexibility? After
> all, they can just run it twice -- once to convert and once to see stuff.
>
> If you can think of a realistic use case -- for example, convert these files
> and let me see them -- then we could always *add* another command-line
> option to invoke this sort of "interactive conversion".
>
> >I admit to no seeing a use for it right off the bat, but giving our
> >users maximum flexibility whenever possible is something we should strive
> >for.
>
> Generality is good, but it's not an absolute good. Good UI design tries to
> optimize heavily for the most common case, while still permitting other
> tasks to get done somehow. The gyrations you have to go through should
> scale in proportion to how frequently that task is performed.
>
> Thus, in this case, we have two potential command-line UIs:
>
> command default behavior
> ------- ----------------
> abiword foo.doc -to abw [-quiet | -batch] display converted documents
> abiword foo.doc -to abw [-show | -verbose] pure batch mode, no graphics
>
> Which default is more common behavior? I'd tend to assume that the second
> is, by a long shot. Then again, I don't do much file conversion work, so I
> may not be the best person to ask.
I give on this one, however, I prefer the solution Paul suggests (a --show
option) to abiword -to abi; abiword. I think using an option just looks
nicer, in additon to having us give the user flexibility, rather than
having the user create it him/herself.
> Paul
>
> PS: What's the error-handling for this look like in batch mode? Only save
> the new file if it can be successfully converted, and it doesn't replace any
> existing files? How is the failure reported?
Currently, parseCommandLine is supposed to return false if it gets bad
argument, however, it always returns true. Joaquin's patch changes it so
that it returns false if the user specified -to, so that the app is not
started. _convertTo currently fprintf's to stderr if there is a problem
reading the file, and does nothing on writing errors. However, the MANY
differnt reading errors are not treated seperately, and finally, the error
code is likeley to generate bugs in the near future, as once Shaw
integrate the patch that I sent him (which should be soon), readFromFile
will no longer return a UT_Bool, but instead an UT_Error. I will send him
a patch that will hopefully fix this. Additionally, all the differnt
errors that could be generated should be treated seperately.
This brings up the further question of how we should treat error
messages on the command line. Should we just print them to stderr?
Should we give the user chocices as to wether or not to continue? If we
have abiword running on just a command line basis, these are issues we
need to consider.
>
> What about in interactive mode? Should it just do the conversion and *not*
> save the results until you've looked at them?
>
> Just being pesky. ;-)
>
Hope this is helpful.
sam th
sytobinh@uchicago.edu
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE4j3kpt+kM0Mq9M/wRAvq2AJ0TwVrxa6kMsqsfNH5UrZjAYKIVmACePp+Y
pS56Z9Nc9ZXSURjgSPd/L20=
=7dt8
-----END PGP SIGNATURE-----
This archive was generated by hypermail 2b25 : Wed Jan 26 2000 - 16:45:59 CST