Re: finding the face of a popup

[Tim X <timx@nospam.dev.null>]

Allan Gottlieb <gottlieb@nyu.edu> writes:

> At Thu, 30 Aug 2007 18:26:48 +1000 Tim X <timx@nospam.dev.null> wrote:
>
>> Allan Gottlieb <gottlieb@nyu.edu> writes:
>>
>>>
>>> I believe that the description of a face given by placing point
>>> over a field and typing C-u C-x = should tell you
>>> the face of a popup that is triggered when the mouse is over that
>>> field.
>>>
>>
>> I think the problem with that is that you are mixing up two different
>> levels of the application. The popup/tooltip is a function of the mouse
>> location. The  C-u C-x = describes what is around point and the tool tip is
>> not really around point - in fact, technically, you could define a tool tip
>> that pops up whenever the mouse enters the (buffer - its not done because
>> that would be annoying, but it could be done).
>
> In that case info about the popup could be given whenever you execute
> C-u C-x = in that buffer.  I agree with you that such behavior would
> be annoying, but it could be done.  That is you could keep the rule
> that C-u C-x = gives info about the current face and any popups that
> are triggered.
>
>> With respect to your other point of list-faces-display not being good
>> enough because you might have more than one face with the same color -  I
>> think thats a non-issue. There are only a couple of faces you cannot put
>> point on - tooltip and modeline are two obvious ones. For the others, you
>> can use the C-u C-x =.  However, the main reason I think its a non-issue is
>> that its not a common or frequent problem and when it is, you do have a
>> solution - even if its not what you would want in your ideal
>> world.
>
> I agree with you but would say "(very) unimportant issue"
>
>> Regardless of different opinions, the really good thing is that if you feel
>> its important enough that C-u C-x = displays information about a tooltip
>> which may be triggered nearby, then you can go and implement it.
>
> Agreed.  I should point out that I mentioned the specific interface in
> reply to Eli who asked for it.
>

At the risk of thrashing the issue within an inch of its life....

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. 

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. 

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?

Tim



-- 
tcross (at) rapttech dot com dot au