From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:57017)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <mingo@elte.hu>) id 1RO3xg-00045S-TU
	for qemu-devel@nongnu.org; Wed, 09 Nov 2011 03:56:49 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <mingo@elte.hu>) id 1RO3xf-0007cg-PJ
	for qemu-devel@nongnu.org; Wed, 09 Nov 2011 03:56:48 -0500
Received: from mx3.mail.elte.hu ([157.181.1.138]:39853)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <mingo@elte.hu>) id 1RO3xf-0007ca-Id
	for qemu-devel@nongnu.org; Wed, 09 Nov 2011 03:56:47 -0500
Date: Wed, 9 Nov 2011 09:55:10 +0100
From: Ingo Molnar <mingo@elte.hu>
Message-ID: <20111109085510.GE11473@elte.hu>
References: <CAOJsxLEKx5M5L_N42pQpo2hcNhseQKhUo6CXAyQHesJRWFASKQ@mail.gmail.com>
	<4EB85969.2010108@codemonkey.ws>
	<12F471C8-2CF3-4CD7-B417-C8CC898669E6@mit.edu>
	<20111108093225.GB32533@elte.hu>
	<EDBAFB6F-4E3B-42B0-93E6-DF162B9859A6@mit.edu>
	<20111108125609.GA14272@ghostprotocols.net>
	<4EB9315A.10806@redhat.com>
	<20111108143228.GC14272@ghostprotocols.net>
	<4EB94D08.3010207@redhat.com>
	<20111108161342.GD14272@ghostprotocols.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20111108161342.GD14272@ghostprotocols.net>
Subject: Re: [Qemu-devel] [F.A.Q.] the advantages of a shared tool/kernel
 Git repository, tools/perf/ and tools/kvm/
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Alexander Graf <agraf@suse.de>, Theodore Tso <tytso@mit.edu>, Peter Zijlstra <a.p.zijlstra@chello.nl>, "kvm@vger.kernel.org list" <kvm@vger.kernel.org>, qemu-devel Developers <qemu-devel@nongnu.org>, Vince Weaver <vince@deater.net>, "linux-kernel@vger.kernel.org List" <linux-kernel@vger.kernel.org>, Pekka Enberg <penberg@kernel.org>, Blue Swirl <blauwirbel@gmail.com>, Avi Kivity <avi@redhat.com>, =?iso-8859-1?Q?Am=E9rico?= Wang <xiyou.wangcong@gmail.com>, Thomas Gleixner <tglx@linutronix.de>, Linus Torvalds <torvalds@linux-foundation.org>, Gerd Hoffmann <kraxel@redhat.com>


* Arnaldo Carvalho de Melo <acme@redhat.com> wrote:

> > sure the colors have enougth contrast so they are readable.
> 
> Problem is figuring out something that is considered a good default 
> :-\ There will always be somebody that will complain.
> 
> When doing the coding to allow using the default xterm colors I 
> tried several of the gnome-terminal xterm profiles and all looked 
> kinda sane for the "top" (hottest functions, with most hits) and 
> "medium" lines, where we combine some chosen foreground color 
> ("red" and "green").
> 
> Laziest solution would be: If the user customizes that much, could 
> the user please customize this as well? :-)

I don't think it's acceptable to output unreadable color combinations 
(red on dark red, etc.) in any case, so we should add some safety 
mechanism that detects bad color combinations and a fallback, static 
color scheme.

I like the current way how perf top/report adapts to the xterm color 
scheme. I use it both on dark and white backgrounds and it's easy to 
mistake it for --stdio output - which is good, a good TUI should 
blend into the console's color scheme. So i think we should keep that 
and just detect the few cases where it results in something 
unreadable.

Thanks,

	Ingo