[PATCH] Add trim support to qapitrace GUI app

[Zack Rusin]

On Thursday, March 15, 2012 03:02:17 PM José Fonseca wrote:
> Usually I'd say that trim is one of those transformations that would
> be better easily done inside the GUI process, without forking a
> separate apitrace command.
> 
> But honestly I don't know any more. There's simply not enough people
> working on the GUI for me to be picky about these things. And having
> the GUI to be a layer on top of the the CLI might actually be a good
> way to ensure the GUI keeps receiving more new features, without too
> much code duplication.  At the end of the day, the GUI user doesn't
> care how we implement stuff as long as it works..
> 
> What are your thoughts on this, Zack?

Yea, I think that the cli tools are ok for now. Granted that the main reason 
we use a separate process for retracing was that we didn't want the ui 
crashing or misbehaving due to problems with the drivers which isn't a worry 
here, but it's not a huge problem. 
I'd be probably a bit more worried that from the gui perspective it's a little 
underwhelming. For example if you're running a release build you won't see 
absolutely anything happening when trimming finishes. You click on an item and 
seemingly nothing happens - a magical file is created somewhere. That's not a 
terribly good ui design :) 
Without some sort of integration like a view with the list of currently 
available trim files that can be replayed/compared for the currently opened 
trace file, I'm not sure what's the point of doing it from the ui because it 
will just make that functionality a lot harder than it is from the command 
line. So I think however features are implemented in the ui is fine, I'd just 
like to see them actually integrated in the ui.

z