lkml.org 
[lkml]   [2010]   [Mar]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: KVM usability
On 03/07/2010 11:56 AM, Pekka Enberg wrote:
> Hi Avi,
>
> (slightly off-topic)
>
> On Sun, Mar 7, 2010 at 11:35 AM, Avi Kivity<avi@redhat.com> wrote:
>
>> perf really is wonderful, but to be really competitive, and usable to more
>> developers, it needs to be in a graphical environment. I want 'perf report'
>> output to start out collapsed and drill down by clicking on a tree widget.
>> Clicking on a function name opens its definition. 'perf annotate' should
>> display annotations on my editor window, not in a pager. I should be able
>> to check events on a list, not using 'perf list'.
>>
> People keep bringing this up but I don't quite agree. Mac OS X has
> "shark" which is pretty much what you describe above. However, having
> used both, I prefer perf's simple UI for two reasons: it's much easier
> to automate perf commands and text-based reports are superior for
> sharing results (and keeping track of results when doing performance
> optimizations).
>

Yes, you (and me as well). But most people are quite unlike new and
me. There's a reason GUIs dominate today, and there are even a few
kernel developers that don't use mutt for reading email.

Even for command-line-happy people, GUIs still have an advantage in that
it is much easier to discover features by exploring the UI vs. reading
manual pages.

> That said, AFAICT, it should be pretty simple to implement a
> shark-like UI with GTK as current perf code is pretty good fit for
> that. I've pondered about doing that myself but quite frankly, I don't
> see any big gains in that.
>

Because you are only interested in your own itches (which is perfectly
legitimate, but will keep perf's userbase down).

--
error compiling committee.c: too many arguments to function



\
 
 \ /
  Last update: 2010-03-07 11:15    [from the cache]
©2003-2011 Jasper Spaans