[PATCH] Add trim support to qapitrace GUI app
zen3d.linux at gmail.com
Thu Mar 15 15:49:28 PDT 2012
On 03/15/2012 02:28 PM, Zack Rusin wrote:
> On Thursday, March 15, 2012 03:02:17 PM José Fonseca wrote:
>> Usually I'd say that trim is one of those transformations that would
>> be better easily done inside the GUI process, without forking a
>> separate apitrace command.
>> But honestly I don't know any more. There's simply not enough people
>> working on the GUI for me to be picky about these things. And having
>> the GUI to be a layer on top of the the CLI might actually be a good
>> way to ensure the GUI keeps receiving more new features, without too
>> much code duplication. At the end of the day, the GUI user doesn't
>> care how we implement stuff as long as it works..
>> What are your thoughts on this, Zack?
> Yea, I think that the cli tools are ok for now. Granted that the main reason
> we use a separate process for retracing was that we didn't want the ui
> crashing or misbehaving due to problems with the drivers which isn't a worry
> here, but it's not a huge problem.
> I'd be probably a bit more worried that from the gui perspective it's a little
> underwhelming. For example if you're running a release build you won't see
> absolutely anything happening when trimming finishes. You click on an item and
> seemingly nothing happens - a magical file is created somewhere. That's not a
> terribly good ui design :)
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.
> Without some sort of integration like a view with the list of currently
> available trim files that can be replayed/compared for the currently opened
> trace file, I'm not sure what's the point of doing it from the ui because it
> will just make that functionality a lot harder than it is from the command
> line. So I think however features are implemented in the ui is fine, I'd just
> like to see them actually integrated in the ui.
The point of doing trimming in the UI is that, with frame thumbnails
(and soon call thumbnails), you know visually that frame/call to select
for the trim. You don't need to write down the frame/call number and
then run a separate app and type in the call set by hand. My
implementation currently has these two features (thumbnails and trim) as
separate implementations, but once they are intergrated, ...
More information about the apitrace