[Scummvm-devel] CLI frontend for the tools.
Max Horn
max at quendi.de
Tue May 12 11:56:19 CEST 2009
Hi Joakim!
Am 12.05.2009 um 00:30 schrieb Remere:
> Hello, as you might recall, I'm one of the GSoC students. But I've
> been quite busy lately, but now I thought to gather input on how to
> actually realize it.
Good idea ;).
> What I'm curious is the style of the CLI arguments to the program,
> as unifying them will mean cleaner code for the tools, and make it
> easier for the people who prefer the terminal to use.
> You can find how all the individual tools now work here (ie. CLI
> style): http://scummvm.svn.sourceforge.net/viewvc/scummvm/tools/trunk/README?revision=35144
> For the extraction tools, the format of input parameters is quite
> well defined, however, I propose that output should be controlled by
> a '-o' parameter, which is a directory (or filename, depending on
> the tool) to output to, which would default to './' (currernt
> directory, if the output is a single file, default name is based on
> the tool used).
That sounds like a good idea, at least in principle. To indirectly
also respond to Thierry's questions: Some tools use -d, others use -o;
but -o usually is used is use to specify an output FILE, not a dir,
aye. Personally, I am happy with using either -o or -d for this. This
is, after all, only a minor point and trivial to change later on (if
it is *not* trivial, you made some serious mistake in the design of
your code *ggg*).
And I agree with the choices of the current dir as the default target.
This matches the behavior of tar, unzip, unrar, gunip, bunzip2 and
other extraction tools, and in general, the behavior of unix tools.
> A special --tool parameter is supplied to select the correct format
> if it cannot be decided by heuristic
Sounds good!
Side note: I have pondered something like that for ScummVM in the
past: Add an "auto" mode to scummvm: just point it at a directory, and
say go/auto/run, e.g.
./scummvm --path=/foo/bar go
and it will try to auto-detect a game in the specific dir and run it.
No need to specify a gameid or anything. If it can't determine the
game uniquely, it could start and show a dialog with a list of all
matches and let the user pick one...
In the launcher, this could be realized by adding a variant to the
"Run" button: "Run..." (available if you hold a modifier key?) would
open a directory selector dialog, from which you can choose a dir, and
it'll run the game in there, without adding it to the launcher.
Well, in the end of the day, I never implemented any of these, because
it didn't seem to be worth the effort... :)
> (perhaps the tool should also ask for input then also?). So the
> format becomes:
> extract [extra params] [--tool tool-to-use] inputfiles.... [-o
> outputfile]
That sounds sensible to me. If the *internal* API is similar (both in
structure and cleanliness), then this will also make it very
convenient to add a GUI atop of it.
> For the compression tools the format is slightly more complex,
> mainly because alot of tools expect specific parameters,
Which tools expect which special parameters? Maybe we can get rid of
some of them; the fewer of these special cases we need, the better.
> also:
> compress [extra-params] [--tool tool-to-use] [tool-specific-params]
> inputfiles [-o outputfile/dir]
> extra-params is generally compression specifics such as bitrate.
> Perhaps I'll also write better documentation of this.
In my eyes that is a crucial part of your task, actually ;). I.e. the
extract/compress tools should be accompanied by an updated README; and
also they should print sensible usage instructions when run without
any args. Don't forget to implement "--help" and "--version", too.
We could also provide man pages for them (bonus task ;).
> Opinions are most welcome, I probably haven't covered all angles
> here, and maybe another argument style is preferred?.
So far, this looks pretty good to me :)
Some *internal* details:
If you have time left after you are done with your tasks for GSoC and
are bored *g*, here is another fun project: Also implement the
functionality of the encode_dxa tool, as well as convert_dxa.* batch
files into a CLI/GUI tool. By using "our" Smacker decoder code, and
coupling that with the encode_dxa code, so that users can directly
convert from Smacker to DXA....
Or maybe we should just submit an updated "ScummVM DXA" codec to
FFmpeg and ask people to use that to encode stuff as DXA? :)
Cheers,
Max
More information about the Scummvm-devel
mailing list