[PATCH] Add trim support to qapitrace GUI app

[Dan McCabe]

On 03/17/2012 09:08 AM, Zack Rusin wrote:
> 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.
Will do.
>
> z