<div><br><div>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.</div><div> </div><div class="gmail_quote"><div class="im">On Tue, May 12, 2009 at 11:56 AM, Max Horn <span dir="ltr"><<a href="mailto:max@quendi.de" target="_blank">max@quendi.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Joakim!<br>
<br>
<br>
Am 12.05.2009 um 00:30 schrieb Remere:<div><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
</blockquote>
<br></div>
Good idea ;).<div><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
You can find how all the individual tools now work here (ie. CLI style): <a href="http://scummvm.svn.sourceforge.net/viewvc/scummvm/tools/trunk/README?revision=35144" target="_blank">http://scummvm.svn.sourceforge.net/viewvc/scummvm/tools/trunk/README?revision=35144</a><br>


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


</blockquote>
<br></div>
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*).<br>


<br>
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.<div>
</div></blockquote></div><div>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. :) </div><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
A special --tool parameter is supplied to select the correct format if it cannot be decided by heuristic<br>
</blockquote>
<br></div>
Sounds good!<br>
<br>
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.<br>
./scummvm --path=/foo/bar go<br>
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...<br>


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


<br>
Well, in the end of the day, I never implemented any of these, because it didn't seem to be worth the effort... :)</blockquote></div><div>While it's a nice idea, it's kind of out-of scope, maybe after the summer. ;) </div>
<div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
(perhaps the tool should also ask for input then also?). So the format becomes:<br>
extract [extra params] [--tool tool-to-use] inputfiles.... [-o outputfile]<br>
</blockquote>
<br></div>
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.</blockquote></div><div>Well, the order of input will be reversed for the GUI, inputfiles, tool-to-use, extra params, outputfile. But pretty much the same experience. :)</div>
<div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
For the compression tools the format is slightly more complex, mainly because alot of tools expect specific parameters,<br>
</blockquote>
<br></div>
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.</blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
also:<br>
compress [extra-params] [--tool tool-to-use] [tool-specific-params] inputfiles [-o outputfile/dir]<br>
extra-params is generally compression specifics such as bitrate. Perhaps I'll also write better documentation of this.<br>
</blockquote>
<br></div>
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.<br>


We could also provide man pages for them (bonus task ;).</blockquote></div><div>Yea, I'll do that. </div><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Opinions are most welcome, I probably haven't covered all angles here, and maybe another argument style is preferred?.<br>
</blockquote>
<br></div>
So far, this looks pretty good to me :)<br>
<br></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Some *internal* details:<br>
<br>
<br>
<br>
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....<br>


<br>
Or maybe we should just submit an updated "ScummVM DXA" codec to FFmpeg and ask people to use that to encode stuff as DXA? :)<br>
<br>
Cheers,<br><font color="#888888">
Max<br>
</font></blockquote></div></div><br><div>Hmmm, I have no idea what you're talking about, sooooo, maybe after the summer, when I know what you're talking about. :)<br></div>
</div><br><div>Cheers,</div><div>Joakim </div>