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
_______________________________________________
apitrace mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/apitrace
