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