[PATCH] Add trim support to qapitrace GUI app

[Dan McCabe]

On 03/15/2012 07:13 PM, Zack Rusin wrote:
> 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
Of course, the downside of that is that it prevents you from trimming at 
a later point in the trace. This is a relatively minor point, however.
>   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.
Agreed. But what I've taken is the first step in that direction.
>
> 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.
It seems to me that you are arguing against using the GUI tool in the 
first place. Which may be a reasonable argument. Or at least I'm not 
going to argue against 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).
The name chosen is as well defined as the name of a trace created with 
the GUI. It uses that same mechanism when a collision occurs. It is also 
in the same directory as the original trace (which is where I would 
expect to find it).
>
> z

Carl, since you are the customer of this feature, perhaps you might want 
to share your thoughts on these issues.

cheers, danm