[PATCH] Add trim support to qapitrace GUI app

[Zack Rusin]

On Friday, March 16, 2012 02:51:54 PM Dan McCabe wrote:
> 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.

No, you'd just click on that undo and go back to the original one in this 
case.
 
> 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 :).

No, I'm making an argument for making gui more useful than command line tools. 
Not a wrapper for people who refuse to write a command, just a lot better 
experience for everyone.
  
> The name chosen is as well defined as the name of a trace created with
> the GUI. 

No, it really isn't. My issue with the name is very simple and that it's not 
related to the trim operation at all, e.g. you click on a call to trim the 
trace, some file is generated. What is its name? Name of the trace.trimmed? 
What if you already generated that file? name_of_the_trace.1.trimmed? What if 
you already had it? name_of_trace_.2.trimmed? Which one of all of those files 
is related the the trim that trimmed to call 256? Will you remember the next 
day?

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

I sort of doubt that. QFileInfo::baseName returns just the base name of the 
file, not the directory structure. You're not specifying the directory at all 
which means it's using the currently working dir of the binary.  I'm guessing 
that it works for you, ironically, only because you're starting it from a 
terminal because if you started if from the gui the currently working binary 
dir would be /usr/bin or even / which isn't even't writable and trimming will 
just fail. 
It'd be good if you could at least fix those two issues.
 
z