From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: Binding a command to the down-event of a toolbar button Date: Fri, 31 Mar 2006 10:35:55 -0800 Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1143830202 9478 80.91.229.2 (31 Mar 2006 18:36:42 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 31 Mar 2006 18:36:42 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 31 20:36:38 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1FPOTt-0006VW-9f for ged-emacs-devel@m.gmane.org; Fri, 31 Mar 2006 20:36:21 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FPOTs-00066e-Iu for ged-emacs-devel@m.gmane.org; Fri, 31 Mar 2006 13:36:20 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FPOTh-00066A-Bl for emacs-devel@gnu.org; Fri, 31 Mar 2006 13:36:09 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FPOTf-00064v-M1 for emacs-devel@gnu.org; Fri, 31 Mar 2006 13:36:08 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FPOTf-00064n-Hl for emacs-devel@gnu.org; Fri, 31 Mar 2006 13:36:07 -0500 Original-Received: from [141.146.126.228] (helo=agminet01.oracle.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.52) id 1FPOW7-0007KZ-7Q for emacs-devel@gnu.org; Fri, 31 Mar 2006 13:38:39 -0500 Original-Received: from rgmsgw300.us.oracle.com (rgmsgw300.us.oracle.com [138.1.186.49]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2VIa3jE008101 for ; Fri, 31 Mar 2006 12:36:05 -0600 Original-Received: from dradamslap (dhcp-amer-whq-csvpn-gw3-141-144-82-76.vpn.oracle.com [141.144.82.76]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id k2VIa2st017865 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 31 Mar 2006 11:36:03 -0700 Original-To: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE 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:52264 Archived-At: >> Is such behavior normal in tool bars in other user interfaces? >> If not, I think we should not do it. Why not? It's often good to stick to "normal", "standard", or common UI features so that users know what to expect. But what's the harm in providing functionality where the common UIs have none? You're missing the point. You're proposing we implement the capacity to provide a certain kind of GUI feature. Before we do that, I want to know whether users expect or want that kind of feature in GUIs. If they don't, let's save the trouble of writing and maintaining code to implement it. You're missing the point. I'm not proposing that we implement anything. I said "What's the harm?", arguing only against the proposition that we should stick to what other UIs do. Your reason for proposing that we *not* implement this feature is based only on what other user interfaces do and what users are asking for today. You focused only on benefit, not cost, and you weighed the possible benefit in a narrow way. So I responded to the question of benefit: whether such a feature might be useful. You proposed judging use value based only on what users might already expect or request. I argued that that's too conservative, that Emacs shouldn't necessarily limit its features to what other UIs provide or what users are already asking for. My guess is that many (most?) of the most important Emacs features were not developed because users asked for them or because other UIs already had them. They were invented or discovered by Emacs user-developers (many by you!). Such stuff is being created everyday, with varying degrees of usefulness ;-). In sum, without considering cost, I see no reason "why not". Now you raise the question of cost. Good initiative. No sense guessing at benefits if we have no idea what this costs. Obviously, if the cost to develop a new feature is great, and the expected benefit is small, then it should not be undertaken. We do not know that that's the case here. The cost/benefit questions are: a) What might be the benefit? b) What would be the cost (implementation and maintenance)? Wrt benefit, let's not worry about what user's might expect from other UIs, since this feature would neither satisfy those expectations nor interfere with them - that consideration is irrelevant. That's the point I made previously. If the cost is minor then we don't need to assess a large benefit. So what's the cost? We can guess that maintenance cost is roughly proportional to implementation complexity. Anyone have an idea how hard this would be to implement? Some people have already expressed interest in the feature here, so presumably the benefit would not be zero. IMO, Stefan's press-and-hold media-player app is argument enough in terms of benefit, if the cost is small enough. Likewise, the arguments for mouse clicks other than mouse-1.