From: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
To: Namhyung Kim <namhyung.kim@lge.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>,
Paul Mackerras <paulus@samba.org>, Ingo Molnar <mingo@elte.hu>,
Namhyung Kim <namhyung@gmail.com>,
LKML <linux-kernel@vger.kernel.org>,
Pekka Enberg <penberg@kernel.org>
Subject: Re: [RFC PATCHSET] perf ui: Small preparation on further UI work
Date: Mon, 26 Mar 2012 14:38:17 -0300 [thread overview]
Message-ID: <20120326173817.GN25820@infradead.org> (raw)
In-Reply-To: <1332751896-11210-1-git-send-email-namhyung.kim@lge.com>
Em Mon, Mar 26, 2012 at 05:51:31PM +0900, Namhyung Kim escreveu:
> This is my initial work of UI generalization. As we now get GTK2 support on
> perf report, improve setup_browser() to handle it properly so that we can
> add various UI specific initialization codes to the function. At least, we
> need basic error/warning handlers ASAP to see what's going on when an error
> occurred, IMHO.
>
> I put new file setup.c under ui directory (not under util/ui) and it may or
> may not be compiled depending on the system configuration. I think it'd be
> better moving generic UI codes to the directory and TUI specific codes to
> ui/tui, and so on, so that the util directory doesn't contain any UI codes.
> But before proceeding, I'd like to listen to your opinions :).
My plans were for util/ui/ to be this generalization you want to, hence
I didn't use the 't', i.e. I didn't call it util/tui/, because tui would
be just one of the possible backends.
But that still needs more work that I haven't be able to pursue. Pekka
thinks that doing it that way is not OK as it would limit what one could
do with a more featureful UI like GTK+.
I would like to still pursue a simple GUI using a function table for
the simple operations we use in the hists browser in
tools/perf/util/ui/ but if others want to pursue it the way the GTK+
browser is being worked on, more power to them.
So I would just leave things in tools/perf/util/ui/ and do what you did
in moving the TUI specific bits to a separate function, even ui__init()
would be ok for now, and then at setup_browser() check what kind of
interface is being used and call ui__init() if it is the TUI and the
gtk init one if GTK+ was chosen.
But wouldn't introduce tools/perf/ui/setup.c for that, no need for new
directory trees, I think :-)
- Arnaldo
> Any comments are welcome.
> Thanks.
>
> Namhyung Kim (5):
> perf ui: Make setup_browser() generic
> perf ui: Drop arg[cv] arguments from perf_gtk_setup_browser()
> perf ui: Add gtk2 support into setup_browser()
> perf gtk: Rename functions for consistency
> perf ui: Change fallback policy of setup_browser()
>
> tools/perf/Makefile | 7 ++++-
> tools/perf/builtin-report.c | 5 +---
> tools/perf/ui/setup.c | 44 +++++++++++++++++++++++++++++
> tools/perf/util/cache.h | 24 +++++++++++-----
> tools/perf/util/gtk/browser.c | 27 +++++++++---------
> tools/perf/util/gtk/gtk.h | 4 +++
> tools/perf/util/ui/setup.c | 61 +++++++++++++++-------------------------
> 7 files changed, 108 insertions(+), 64 deletions(-)
> create mode 100644 tools/perf/ui/setup.c
>
> --
> 1.7.7.6
next prev parent reply other threads:[~2012-03-26 17:38 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-26 8:51 [RFC PATCHSET] perf ui: Small preparation on further UI work Namhyung Kim
2012-03-26 8:51 ` [PATCH 1/5] perf ui: Make setup_browser() generic Namhyung Kim
2012-03-26 8:51 ` [PATCH 2/5] perf ui: Drop arg[cv] arguments from perf_gtk_setup_browser() Namhyung Kim
2012-03-26 8:51 ` [PATCH 3/5] perf ui: Add gtk2 support into setup_browser() Namhyung Kim
2012-03-26 8:51 ` [PATCH 4/5] perf gtk: Rename functions for consistency Namhyung Kim
2012-03-26 8:51 ` [PATCH 5/5] perf ui: Change fallback policy of setup_browser() Namhyung Kim
2012-03-26 9:46 ` [RFC PATCHSET] perf ui: Small preparation on further UI work Pekka Enberg
2012-03-26 17:38 ` Arnaldo Carvalho de Melo [this message]
2012-03-27 10:44 ` Pekka Enberg
2012-03-27 13:55 ` Arnaldo Carvalho de Melo
2012-03-28 2:14 ` Namhyung Kim
2012-03-28 14:28 ` Arnaldo Carvalho de Melo
2012-03-29 1:03 ` Namhyung Kim
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120326173817.GN25820@infradead.org \
--to=acme@ghostprotocols.net \
--cc=a.p.zijlstra@chello.nl \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=namhyung.kim@lge.com \
--cc=namhyung@gmail.com \
--cc=paulus@samba.org \
--cc=penberg@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox