From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: YAMAMOTO Mitsuharu Newsgroups: gmane.emacs.devel Subject: Re: RFC: status icon support again Date: Sun, 03 Feb 2008 18:23:40 +0900 (JST) Message-ID: <20080203.182340.144431297.mituharu@math.s.chiba-u.ac.jp> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1202030634 24010 80.91.229.12 (3 Feb 2008 09:23:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 3 Feb 2008 09:23:54 +0000 (UTC) Cc: emacs-devel@gnu.org To: tromey@redhat.com Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Feb 03 10:24:15 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1JLb5C-0001uT-GX for ged-emacs-devel@m.gmane.org; Sun, 03 Feb 2008 10:24:14 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JLb4k-0000Gi-LS for ged-emacs-devel@m.gmane.org; Sun, 03 Feb 2008 04:23:46 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JLb4h-0000EC-Lj for emacs-devel@gnu.org; Sun, 03 Feb 2008 04:23:43 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JLb4g-0000CF-Rt for emacs-devel@gnu.org; Sun, 03 Feb 2008 04:23:43 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JLb4g-0000C2-OB for emacs-devel@gnu.org; Sun, 03 Feb 2008 04:23:42 -0500 Original-Received: from mathmail.math.s.chiba-u.ac.jp ([133.82.132.2]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JLb4g-0001A2-6m for emacs-devel@gnu.org; Sun, 03 Feb 2008 04:23:42 -0500 Original-Received: from localhost (church [133.82.132.36]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id 59C432C40; Sun, 3 Feb 2008 18:23:39 +0900 (JST) In-Reply-To: X-Mailer: Mew version 3.3 on Emacs 22.1 / Mule 5.0 (SAKAKI) X-detected-kernel: by monty-python.gnu.org: NetBSD 3.0 (DF) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:88081 Archived-At: >>>>> On Sun, 03 Feb 2008 00:35:37 -0700, Tom Tromey said: >>> Another benefit of the use of keymaps is that it makes easier to >>> move between status icons from/to tool bar icons (and possibly >>> also between menu bar items?), in the case that the use of either >>> is impossible/inappropriate. > In my view toolbars and the status area are very different; though > it is true that there is some overlap between them. I can imagine that they are usually used for different purposes. Nevertheless I think they are very similar in attributes they have and functionality they provide. > In an earlier message you mentioned toolbars being integrated into > redisplay. This was one disconnect for me -- I don't see how, or > why, we would want to integrate status icons into redisplay. They > are not connected to a frame at all. I can't say users never want to make changes to some attributes of status icons depending on the frame. >>> I think user-configurable event dispatcher tables should always be >>> implemented as keymaps unless there are strong reasons to avoid >>> them. > May I ask why? I think the reason is rather apparent. That provides uniform interface to elisp programmers and they can use existing keymap functions to manipulate those tables. > I have basically two reasons for the approach I have taken. > First, it is simple and easy to understand. In Gtk, a status icon > only has two possible events; using a keymap for this seemed like > overkill. Are you possibly thinking about using one keymap per one status icon? It's natural to use one keymap for the set of all status icons, just as in tool bar keymaps. > Second, unlike the keymap idea, I knew how to implement it this way. > I suppose ignorance is no excuse, though. Generally speaking, I don't think it's a good idea to add a new feature that is implemented without understanding how the existing related/similar features are implemented in the target application. YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp