From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756240Ab1KIIxE (ORCPT ); Wed, 9 Nov 2011 03:53:04 -0500 Received: from mx3.mail.elte.hu ([157.181.1.138]:59662 "EHLO mx3.mail.elte.hu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751422Ab1KIIxB (ORCPT ); Wed, 9 Nov 2011 03:53:01 -0500 Date: Wed, 9 Nov 2011 09:51:20 +0100 From: Ingo Molnar To: Gerd Hoffmann Cc: Arnaldo Carvalho de Melo , Theodore Tso , Anthony Liguori , Pekka Enberg , Vince Weaver , Avi Kivity , "kvm@vger.kernel.org list" , "linux-kernel@vger.kernel.org List" , qemu-devel Developers , Alexander Graf , Blue Swirl , =?iso-8859-1?Q?Am=E9rico?= Wang , Linus Torvalds , Thomas Gleixner , Peter Zijlstra Subject: Re: [F.A.Q.] the advantages of a shared tool/kernel Git repository, tools/perf/ and tools/kvm/ Message-ID: <20111109085120.GD11473@elte.hu> References: <20111107203255.GF24234@thunk.org> <4EB85969.2010108@codemonkey.ws> <12F471C8-2CF3-4CD7-B417-C8CC898669E6@mit.edu> <20111108093225.GB32533@elte.hu> <20111108125609.GA14272@ghostprotocols.net> <4EB9315A.10806@redhat.com> <20111108143228.GC14272@ghostprotocols.net> <4EB94D08.3010207@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EB94D08.3010207@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-ELTE-SpamScore: -2.0 X-ELTE-SpamLevel: X-ELTE-SpamCheck: no X-ELTE-SpamVersion: ELTE 2.0 X-ELTE-SpamCheck-Details: score=-2.0 required=5.9 tests=BAYES_00 autolearn=no SpamAssassin version=3.3.1 -2.0 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Gerd Hoffmann wrote: > > For reference, the default set of colors now is (from > > tools/perf/util/ui/browser.c): > > > > static struct ui_browser__colorset { > > const char *name, *fg, *bg; > > int colorset; > > } ui_browser__colorsets[] = { > > { > > .colorset = HE_COLORSET_TOP, > > .name = "top", > > .fg = "red", > > .bg = "default", > > Bad idea IMO. Setting only one of foreground+background gives > pretty much unpredictable results. My xterms have different > background colors, the ones with a root shell happen to have a > (dark) red background. Which results in red-on-dark-red text. Not > good. > > I'd strongly suggest to either set both background and foreground > to default or to set both to a specific color. When doing the > latter make sure the colors have enougth contrast so they are > readable. Indeed. What we want to have is to have a set of distinctive colors - just two (background, foreground) colors are not enough - we also need colors to highlight certain information - we need 5-6 colors for the output to be maximally expressive. Is there a canonical way to handle that while still adapting to user preferences automatically by taking background/foreground color scheme of the xterm into account? I suspect to fix the worst of the fallout we could add some logic to detect low contrast combinations (too low color distance) and fall back to the foreground/background colors in that case. Plus allowing full .perfconfig configurability of all the relevant colors, for those with special taste. Thanks, Ingo From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:49441) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RO3u1-00027f-On for qemu-devel@nongnu.org; Wed, 09 Nov 2011 03:53:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RO3u0-0006xN-AO for qemu-devel@nongnu.org; Wed, 09 Nov 2011 03:53:01 -0500 Received: from mx3.mail.elte.hu ([157.181.1.138]:44329) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RO3u0-0006wy-2T for qemu-devel@nongnu.org; Wed, 09 Nov 2011 03:53:00 -0500 Date: Wed, 9 Nov 2011 09:51:20 +0100 From: Ingo Molnar Message-ID: <20111109085120.GD11473@elte.hu> References: <20111107203255.GF24234@thunk.org> <4EB85969.2010108@codemonkey.ws> <12F471C8-2CF3-4CD7-B417-C8CC898669E6@mit.edu> <20111108093225.GB32533@elte.hu> <20111108125609.GA14272@ghostprotocols.net> <4EB9315A.10806@redhat.com> <20111108143228.GC14272@ghostprotocols.net> <4EB94D08.3010207@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EB94D08.3010207@redhat.com> Subject: Re: [Qemu-devel] [F.A.Q.] the advantages of a shared tool/kernel Git repository, tools/perf/ and tools/kvm/ List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: Pekka Enberg , Theodore Tso , Peter Zijlstra , "kvm@vger.kernel.org list" , qemu-devel Developers , Vince Weaver , "linux-kernel@vger.kernel.org List" , Arnaldo Carvalho de Melo , Blue Swirl , Alexander Graf , Avi Kivity , =?iso-8859-1?Q?Am=E9rico?= Wang , Thomas Gleixner , Linus Torvalds * Gerd Hoffmann wrote: > > For reference, the default set of colors now is (from > > tools/perf/util/ui/browser.c): > > > > static struct ui_browser__colorset { > > const char *name, *fg, *bg; > > int colorset; > > } ui_browser__colorsets[] = { > > { > > .colorset = HE_COLORSET_TOP, > > .name = "top", > > .fg = "red", > > .bg = "default", > > Bad idea IMO. Setting only one of foreground+background gives > pretty much unpredictable results. My xterms have different > background colors, the ones with a root shell happen to have a > (dark) red background. Which results in red-on-dark-red text. Not > good. > > I'd strongly suggest to either set both background and foreground > to default or to set both to a specific color. When doing the > latter make sure the colors have enougth contrast so they are > readable. Indeed. What we want to have is to have a set of distinctive colors - just two (background, foreground) colors are not enough - we also need colors to highlight certain information - we need 5-6 colors for the output to be maximally expressive. Is there a canonical way to handle that while still adapting to user preferences automatically by taking background/foreground color scheme of the xterm into account? I suspect to fix the worst of the fallout we could add some logic to detect low contrast combinations (too low color distance) and fall back to the foreground/background colors in that case. Plus allowing full .perfconfig configurability of all the relevant colors, for those with special taste. Thanks, Ingo