Re: finding the face of a popup

[Allan Gottlieb <gottlieb@nyu.edu>]

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