[PATCH] Add trim support to qapitrace GUI app

[Zack Rusin]

On Thursday, March 15, 2012 06:49:28 PM Dan McCabe wrote:
> What UI would you like to see? A message box indicating the name of the
> trime file, perhaps? Something else? I'm open to suggestion.

To be honest the ideal way that feature would be implemented would be if it 
actually trimmed the trace right in the view, i.e. clicking on a call and 
selecting "trim" would trim the trace in place and the edit menu would have 
get an "undo/restore original trace" option that would go back to the original 
trace. That'd make the feature substantially better in the gui than in is from 
the terminal, which is what we should strive to.

My biggest worry for the gui was always that it might deteriorate into a bad 
wrapper for the console tools. By a bad wrapper I mean that it's going to be 
harder to do things in the gui than it is to them from the command line and 
unfortunately that's the case for this feature. It's simply faster and easier 
to copy the current call idx from the detail view and paste it into a 
echo <paste here>|xargs -i apitrace trim --callset 0-{} -o trimmed.trace.{} 
app.trace && qapitrace trimmed.trace.{}
rather then clicking on a call, selecting option to trim, going to the file 
menu, selecting open trace, navigating through the entire directory structure 
(file dialog always opens in the home dir right now so every single time 
you'll try to open a new trim you'll endup navigating the entire hierarchy), 
scanning the dir, finding the file that was generated, opening that and doing 
that again just to get back to the original trace. Especially that with the 
console tools it's a matter of hitting the up key and with the gui you need to 
do all the random clicks all over again with no way of automating it.

So doing things in the gui just for the sake of doing them in the gui when the 
console tools are a lot more effective seems counter productive. Gui should 
always improve upon the console tools. Especially that any added code never 
comes free. Or at least that's how I always saw it, if others disagree I'm 
ultimately fine with whatever at least until I'll find time again to hack on 
this.

> The point of doing trimming in the UI is that, with frame thumbnails
> (and soon call thumbnails), you know visually that frame/call to select
> for the trim. You don't need to write down the frame/call number and
> then run a separate app and type in the call set by hand. My
> implementation currently has these two features (thumbnails and trim) as
> separate implementations, but once they are intergrated, ...

But like I mentioned above it's actually a lot quicker and simpler to 
copy&paste one number then doing file system browsing with a number of mouse 
clicks to find one saved file, especially that it's going to be saved in a not 
well defined location with a not well defined name (fwiw, at least the file 
name should have the index of the call it was trimmed to in the name).

z