[PATCH] Add trim support to qapitrace GUI app
zack at kde.org
Sat Mar 17 09:08:31 PDT 2012
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
> 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
> 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
It'd be good if you could at least fix those two issues.
More information about the apitrace