[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