From: Allan Gottlieb <gottlieb@nyu.edu>
To: help-gnu-emacs@gnu.org
Subject: Re: finding the face of a popup
Date: Fri, 31 Aug 2007 18:38:47 -0400 [thread overview]
Message-ID: <yu9r6ljtjm0.fsf@nyu.edu> (raw)
In-Reply-To: <871wdki9bs.fsf@lion.rapttech.com.au> (Tim X.'s message of "Fri\, 31 Aug 2007 15\:04\:07 +1000")
At Fri, 31 Aug 2007 15:04:07 +1000 Tim X <timx@nospam.dev.null> 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
prev parent reply other threads:[~2007-08-31 22:38 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-27 18:53 finding the face of a popup Allan Gottlieb
2007-08-27 19:14 ` John Paul Wallington
2007-08-27 19:50 ` Allan Gottlieb
[not found] ` <mailman.5416.1188244253.32220.help-gnu-emacs@gnu.org>
[not found] ` <87lkbwhur5.fsf@lion.rapttech.com.au>
[not found] ` <mailman.5457.1188311130.32220.help-gnu-emacs@gnu.org>
2007-08-29 8:55 ` Tim X
2007-08-29 14:22 ` Allan Gottlieb
2007-08-29 15:26 ` Peter Dyballa
2007-08-29 16:30 ` Allan Gottlieb
2007-08-29 18:29 ` Peter Dyballa
2007-08-29 21:28 ` Allan Gottlieb
[not found] ` <mailman.5504.1188397377.32220.help-gnu-emacs@gnu.org>
2007-08-30 8:26 ` Tim X
2007-08-30 11:57 ` Allan Gottlieb
2007-08-30 15:26 ` Drew Adams
[not found] ` <mailman.61.1188475058.18990.help-gnu-emacs@gnu.org>
2007-08-31 5:04 ` Tim X
2007-08-31 22:38 ` Allan Gottlieb [this message]
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=yu9r6ljtjm0.fsf@nyu.edu \
--to=gottlieb@nyu.edu \
--cc=help-gnu-emacs@gnu.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.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.