rachel wrote:No such assumption; I'm not familiar with those programs.
Okay, good. We just get a lot of that here.
There does seem to be an almost 1-1 mapping between a hb_job_t and the parameters that the CLI version takes. Maybe that's more of a coincidence than was apparent.
I'll admit it was an assumption that the CLI version would parse the commandline arguments into a hb_job_t, and then call the same code to actually process the job as the GUI version does, with a pointer to that structure. I assumed that, because that's how I'd have written it.
I'm sorry if my post confused matters; I didn't realize how much research you'd done already. It functions exactly how you think they should. The CLI parses arguments into a job struct, and so does the GUI.
Mm. As mentioned in my long post, I'm not thoroughly against submitting a patch myself, except that I'd have to climb the whole Cocoa development learning curve from scratch to do it. (I've just spent this evening reconnoitering, as it were.) It seems, however, that it shouldn't take long for someone already familiar with this project. I'd certainly be up for writing the C to actually print the hb_job_t struct data to file, but at the moment I wouldn't have any way of testing it.
Well first of all, understand that when a dev here says "we await a patch" or whatever it's not just a write-off...contributions are always welcome, we have a dire need of new developers.
I don't know any Cocoa myself yet (well, I'm learning...halfway through the intro O'Reilly book). So let me say, there's a great way to get your stuff into the GUI...it's the method I've used successfully on several occasions...
Step 1: Write something that works in the CLI. Make it really easy from the interface's point of view...
ideally, just another variable to load. Do everything else in libhb. Remember: the CLI was originally called HBTest. It's a testing ground. Things should work there before they reach the GUI.
Step 2: Show people it works and get it checked into the source.
Step 3: Beg dynaflash =) This is why you want something that's really easy from the interface's point of view. Just a string to load, maybe a checkbox that's a boolean. If you check the Trac timeline, you'll see he's single-handedly keeping the GUI from falling apart, and it's grueling. At the same time, he's expanding it with cool new features. So dynaflash is a busy man. I try to give him as little work as possible.
In this case, you're going to want to do is have a string variable I guess. Use a conditional on whether or not it exists as a boolean for whether or not to save the job list right before work begins. Then you put a conditional somewhere in the workflow (if you're really interested in pursuing this I'll tell you exactly where tomorrow) which could call a function in, I guess, common.c, to actually write the jobs to disk. At least, that's how I'd do it. Sounds like you have a hell of a lot more coding experience than me, though, so I'll admit right now that it's pretty crude.
The other problem is going to be file path. You could have another variable, a string, to store that.
So lemme imagine a theoretical command line:
./HandBrakeCLI -i dvd -o ~/Movies/movie.mp4 --saveJob ~/Documents/hb-job-log.txt
Loading would be a little more difficult, but I can see it happening.
One really useful thing this could do is add a sort of queue to the CLI, which currently lacks it. You'd have to add another variable which would say whether or not to continue with the encode after writing the log. Then you could send a bunch of commands to the CLI, and have it append the jobs to a text file instead of encoding. When you're ready to encode, just do
./HandBrakeCLI --loadJobs ~/Documents/hb-job-log.txt
It'd be kinda cool. I really mean it when I say I look forward to seeing a patch.
The opacity isn't in the options to Handbrake, but in obtaining the values to supply to those options from a DVD in the drive.
It just occurred to me that the Handbrake GUI is already good at harvesting that data, as well as the exact encoding options and cropping etc. from a user, so exporting them from a hb_job_t struct would be not too hard.
And the CLI already knows how to parse them back...
I'm not sure what you mean...the CLI has default values it loads and default cropping and aspect ratio it applies that function the exact same as the GUI, as far as I know.
From my imperfect understanding it looked like an NSButton like the Show Queue or Add To Queue buttons could be made, with a Connection to a method in Controller.mm ExportQueue, alongside AddToQueue, which would call the probably plain C function to write the contents of the hb_job_t struct to which we'd have the pointer (as we do in AddToQueue) to file. Except there's some Cocoa business I don't know with a file save selector I'm sure...
That's pretty much it, I think. So hey, maybe you won't have to beg dynaflash at all. You're already better off that me ;P
and what's needed is probably simple enough not to warrant that. (It could literally still be a list of command-line parameters, one per job; after all, the CLI version already has code to parse that, and in fact it would then be trivial to write a shell script to feed each such job to the CLI version without that needing extra support at all...)