Sorry for taking a bad assumption.Gale Andrews wrote: The "complaining" users I was referring to are only command line users, which is why I wondered if you had an opinion on which was best for them.
For commandline users, generally speaking, things they need should be accessible trough commandline.
Though, this is less valid for users of group 0 below. I do not know this group much, especialy I have no idea how large is that group. If you want to keep them in mind, consider settings things in Preferences, with command line options having preference if they are specified.
Remaining groups (as well as audacity team support stuff) will prefer if command line behaviour will not depend much
on the Preferences and, on the other hand, can be told to put
alias auda='audacity --one'
or
alias auda='audacity --each-import-to-a-separate-project'
to their shell configuration, at their will.
I think there might be several type of users:
0. GUI-type users starting app from commandline [and not much more].
Perhaps this was not their choice anyway, but during the time they learned to manipulate their files using commands cp, mv, rm and like.
Instead of documentation of commandline options, they will need a tutorial.
1. users starting app from commandline.
(They might miss any answer from commands 'man audacity' and 'info audacity'.)
They will like to insert four mp3 files into an existing .aup project file.
They like short command line options (e.g. shortcut --one for --import-to-one-project)
They need options grammar compatible with shell autoexpansion and shell grammar (For example: it would be a bad idea to prefix the files that have to be imported-by-reference by prefixes by @ or ~ or $, since autocompletion does not work properly after them. Perhaps avoid prefixes and use options instead.) If this is done well, it takes about ten (surprise?) keystrokes to start audacity LondonAlbum_song5Tralala_v3_2009-04-01_backup_before_allowing_compression.aup
They like options valid until the end of line (or until opposite options is given on the same commandline), e.g. --import-by-reference r1.mp3 r2.mp3 --import-by-copying cp3.mp3 cp4.mp3 (or better --ir r1.mp3 r2.mp3 --ic cp3.mp3 cp4.mp3)
I do not think the 'import all to one window' is their last need.
2. Users doing some tasks from commandline
Want to print and change ID3 tags from commandline.
(Note that means only touching .aup file, and possibly it might be several lines script using a free XMLtool.
Of course, several lines makes a few pages after some work, you know.)
Want to get info about project from commandline. See an above post for more ideas.
Want to do wav and mp3 export from commandline, including setting of parameters.
2b. Users doing some medium and complex tasks from commandline
Reference them to command pipe.
3. automation
What I have in mind is perhaps about that: During filling a form, there is a buton that popups Audacity window so that a voice sample can be recorded. After that is done, sample is sent together with form data to a database.
For this, the application should behave very consistently, be reliable, and must report all problems by exit value.
Option grammar should not be crazy, so that scipts should be able to generate commandline consistently.
Examples conserning reliability:
The application should not show last-oppend-file instead of that one specified on command line.
(Not very likely to happen with audacity, though possible: might it happen that if there is a problem with openning the file, audacity brings to front some window that already exists?)
The huge wav file comming from measurements or broadcast capture can be deleted only when it was _succefully_ converted to Audacity block files.
Daily podcast shound not be exported to internet if audacity crashed or went out of disk space right in middle of final export. (Perhaps even not if a clipping occured during equalization)
One instance architecture of Audacity might prove to be unsuitable from reliability point of view.
For point 3:
Note that that were just examples of reliability. Anything of that type has to be solved before the product gets distributed.
A single case or two of reliability failure excludes next ten generations of audacity from most automation applications.
Or worse, it causes much problems with hunderts or thousands of files distruted over the world, that will be either empty or of 'previous version' or 'very nice but all of them equal to the last file recorded in 1999 (or before April 31, 2009)'
goodThe behaviour on Windows importing files is:
* "Drag-and-drop from Explorer" and "select files in Audacity import window": files import into same project (whether single or multiple files)
<<does not seem to [be willing to] open multiple files>>* "Open with" from Explorer: files import into new project (Windows XP SP3 does not seem to open multiple files using "Open with", at least for me).
<<does not seem to [actually] open multiple files>>
do you mean:
A. there is no such possibity in XP (but note that I did open many .bmp files at once, some time ago, so that would depend on registry entries)
B. audacity does not open them - if only one of them is opened (this still means: in situation when some audacity window is already open),
that would be again 'only the first parameter from command line' feature/or/bug.