[PATCH] Add trim support to qapitrace GUI app

[Dan McCabe]

On 03/17/2012 09:46 AM, Dan McCabe wrote:
> 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
>

Hi Zack,

I resubmitted a new rev. of the patch that addresses your issues. Please 
review at your earliest convenience.

Thanks.

cheers, danm