[PATCH] Add trim support to qapitrace GUI app
zack at kde.org
Thu Mar 15 14:28:11 PDT 2012
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 :)
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.
More information about the apitrace