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: customize value hooks - be able to edit color samples in different ways... Date: Sat, 3 Jun 2006 19:42:08 -0700 Message-ID: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1149388968 3630 80.91.229.2 (4 Jun 2006 02:42:48 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 4 Jun 2006 02:42:48 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jun 04 04:42:46 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 1FmiZc-0002Xk-L7 for ged-emacs-devel@m.gmane.org; Sun, 04 Jun 2006 04:42:40 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FmiZc-0000lh-0s for ged-emacs-devel@m.gmane.org; Sat, 03 Jun 2006 22:42:40 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FmiZR-0000lF-IH for emacs-devel@gnu.org; Sat, 03 Jun 2006 22:42:29 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FmiZQ-0000l3-EX for emacs-devel@gnu.org; Sat, 03 Jun 2006 22:42:28 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FmiZQ-0000l0-Av for emacs-devel@gnu.org; Sat, 03 Jun 2006 22:42:28 -0400 Original-Received: from [148.87.113.118] (helo=rgminet01.oracle.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.52) id 1FmigF-0005Hv-5T for emacs-devel@gnu.org; Sat, 03 Jun 2006 22:49:31 -0400 Original-Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.186.50]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id k542gPIJ030523 for ; Sat, 3 Jun 2006 20:42:25 -0600 Original-Received: from dradamslap (dhcp-amer-csvpn-gw2-141-144-72-16.vpn.oracle.com [141.144.72.16]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id k542gOgl024294 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Sat, 3 Jun 2006 20:42:25 -0600 Original-To: "Emacs-Devel" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 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:55680 Archived-At: For after the release - People have commented on the ugliness of Customize and the difficulty of navigating it without getting lost and frustrated. Another, more important (I think) way in which Customize can be improved is to provide for better interaction when defining and modifying values. You sometimes change a value, go off and do something to see if it's a good value, then come back and change it again. Tightening this tweaking loop would improve things quite a bit. Even when you don't need to leave Customize to judge a value, tweaking it can be unnecessarily difficult. Consider colors. You choose a color by entering its name or its RGB hex string. You can't compare the color you're tweaking to others, except perhaps by referring to `list-colors-display', which is limited to named colors. There are ways to pick a color that are simpler, more interactive, and more flexible. Some such color tweakers are available here and there in Emacs libraries, but there is no simple way of plugging them in, so that Customize can take advantage of them. 1. How about making the "sample"s for Customize faces (and other color fields) be potential buttons that let you change the color using some hook function? IOW, have a hook attached to the "sample" text, so that if the hook happens to be defined (non-nil), the text becomes a button that calls the hook function (to let you change the color). Different libraries could be used to provide different color-modification UIs (functions). There are various possibilities for interactive functions that change a color. My own code defines two: - A color palette that lets you define or modify a color in various ways. Pretty standard, outside of Emacs. - DoReMi, which lets you modify a color using the arrow keys or a mouse wheel. I'm not proposing using my code (FSF will not accept it anyway, since my employer won't sign the papers), but such a functionality is useful generally, and providing the hooks would encourage development of UI extensions to Customize. Note that a hook function here could even open a menu that provides more than one value-tweaking method (interface). One type of menu choice might be whether you want incremental tweaking to change only the sample or the face itself: automatic, on-the-fly "Set for Current Session". (DoReMi, for instance, changes the face as you tweak.) In the latter case, Customize needs to be made aware of the "external" change, and accept it as its own - but that's another story... 2. More generally, such hooked Customize fields need not be limited to colors; the same principle applies to other kinds of values. For example, a numeric field might hook to a function that lets you use a slider or a DoReMi-style function to adjust the value incrementally. Some such UIs might show you the potential (or the real) effect of tweaking elsewhere in Emacs. In sum: Use Customize as a UI framework, letting users call upon other functions to provide different value-choice or value-modification interfaces. Open up the customization UI to other libraries, as far as value manipulation is concerned. A side benefit of this would be to reduce the need to change Customize itself to provide such UI improvements. Over time, UI extensions that are appreciated could be incorporated into Emacs without adding them to the Customize code. Even then, users could continue to experiment with different UI functions. My guess (but I'm no expert on widgets or Customize) is that such a hook mechanism 1) would not be difficult to implement, 2) would be clean, and 3) would provide a great, immediate benefit, opening Customize to better value-defining UIs. Some of those might even be domain-specific, taking into account the particular field being modified (as opposed to just its type). WDOT?