[Scummvm-devel] Fwd: CLI frontend for the tools.

[Remere]

Hello again! Reply took some time since gmail has been non-operational for
the last four or five days here, haven't been able to access it.

On Tue, May 12, 2009 at 11:56 AM, Max Horn <max at quendi.de> wrote:

> 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.
>
That's my reasoning as well, about the -d / -o point, changing (or making
both work) should be trivial, so it's not much work. :)

>
>
>  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... :)

While it's a nice idea, it's kind of out-of scope, maybe after the summer.
;)

>
>
>
>  (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.

Well, the order of input will be reversed for the GUI, inputfiles,
tool-to-use, extra params, outputfile. But pretty much the same experience.
:)

>
>
>  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 ;).

Yea, I'll do that.

>
>  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
>

Hmmm, I have no idea what you're talking about, sooooo, maybe after the
summer, when I know what you're talking about. :)

Cheers,
Joakim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scummvm.org/pipermail/scummvm-devel/attachments/20090519/0eef6699/attachment.html>