From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Allan Gottlieb Newsgroups: gmane.emacs.help Subject: Re: finding the face of a popup Date: Fri, 31 Aug 2007 18:38:47 -0400 Message-ID: References: <87lkbwhur5.fsf@lion.rapttech.com.au> <87hcmiiuso.fsf@lion.rapttech.com.au> <878x7tig1j.fsf@lion.rapttech.com.au> <871wdki9bs.fsf@lion.rapttech.com.au> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1188599964 7707 80.91.229.12 (31 Aug 2007 22:39:24 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 31 Aug 2007 22:39:24 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sat Sep 01 00:39:21 2007 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1IRF8z-0002eo-Q0 for geh-help-gnu-emacs@m.gmane.org; Sat, 01 Sep 2007 00:39:14 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IRF8z-00031S-0m for geh-help-gnu-emacs@m.gmane.org; Fri, 31 Aug 2007 18:39:13 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IRF8j-00031M-T3 for help-gnu-emacs@gnu.org; Fri, 31 Aug 2007 18:38:57 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IRF8h-00031A-De for help-gnu-emacs@gnu.org; Fri, 31 Aug 2007 18:38:56 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IRF8h-000317-7v for help-gnu-emacs@gnu.org; Fri, 31 Aug 2007 18:38:55 -0400 Original-Received: from smtp.cs.nyu.edu ([128.122.140.230]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1IRF8g-0001gR-Vl for help-gnu-emacs@gnu.org; Fri, 31 Aug 2007 18:38:55 -0400 Original-Received: from ajglap.localdomain (ool-4578d5e5.dyn.optonline.net [69.120.213.229]) (authenticated bits=0) by smtp.cs.nyu.edu (8.13.6/8.13.6) with ESMTP id l7VMcqTK011556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 31 Aug 2007 18:38:52 -0400 (EDT) Original-Received: by ajglap.localdomain (Postfix, from userid 1502) id 4472519D971; Fri, 31 Aug 2007 18:38:47 -0400 (EDT) In-Reply-To: <871wdki9bs.fsf@lion.rapttech.com.au> (Tim X.'s message of "Fri\, 31 Aug 2007 15\:04\:07 +1000") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) X-Detected-Kernel: Solaris 9 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:47046 Archived-At: At Fri, 31 Aug 2007 15:04:07 +1000 Tim X wrote: > At the risk of thrashing the issue within an inch of its life.... I agree that we have thrashed this enough and will stop with this posting > There was something bugging me about the issue of a better interface to > communicate the tooltip info and then I realised what it was. The problem > here isn't really an interface problem, but rather a terminology and > communication problem. All of this occured because it wasn't obvious that > the feature being observed was called a tooltip. It is likely that even if > C-u C-x = did include information about tooltips that may appear near > point, anyone who didn't know what a tooltip was or know that the popup was > a tooltip is likely not to recognise that the additional bit of information > being communicated related to the temporary popup - in the worst case, it > might even create more confusion. My suggestion was not about tooltips specifically, but about popups. If C-u C-x = said something like "placing the mouse over this field pops text using the tooltip face", I would have known what to look for (indeed, I should have anyway) even though the text was unreadable in this case (foreground=background). > The solution is likely much harder to achieve than making an addition to > the interface as it is a much more difficult problem to define precisely - > how do you ensure users are familiar with the names of all the interface > components and what is the best way of communicating that information. Some > would argue that it just needs to be made clearer in the manual or maybe > suggest adding it to the FAQ etc. However, there are a large number of > users who never bother with manuals/faqs. some would argue thats their > problem then - if they don't read the odcs, they get the confusion they > deserve. However, I think thats a bit of a cop out - we know there is a > significant number of people who dont read docs, but part of a good > interface design is to have an interface that doesn't need the user to read > through a bunch of docs before they can start using it. > > I don't know the answer - not even sure if there is an answer. > > One addition, which I know is a bit tricky, that I would like to see in > emacs is code that will either prevent or warn against face colour options > that will be unreadable. This is tricky because of so many unknown > variables, such as screen size, resolution, font, user eye sight > etc. However, things could probably be improved by eliminating the really > obvious cases, such as the original issue that started this thread - a > tooltip with the same foreground and background colour. I suspect Allan > wouldn't have had as difficult a time working out what the popup was if he > had been able to at least read the text being displayed. He would have seen > it was some form of help information, which may have either narrowed down > the areas in the manual to search or jogged the memory enough that he would > have been able to use things like apropos to find the face. Agreed, completely. > While on this topic, I have a couple of questions about face colours. I > actually don't worry about them anymore, but when I use to, I had issues > because I always use to use a black background. However, often faces have > defaults that are obviously based on white/light backgrounds, resulting in > defaults that are often difficult or impossible to read. There is a > variable that can be set to specify the type of default background > i.e. 'dark, but it doesn't seem to do anything - you still get default > faces that are dark on dark. > > is this problem due to people not using/defining faces correctly or is this > a limitation of the way face properties are implemented. More specifically, > what does the default-frame-mode variable actually do as it doesn't seem to > have any real affect? I also have trouble because I use a black background. I currently use color-theme and the specific theme dark-laptop. However, it is not perfect. The unreadable tooltip, modeline-inactive that looks like the window itself, customized buttons not raised, ... . I have fixed some and will eventually fix all the ones I need. I have found the color-theme infrastructure to be quite useful. allan