Fix some tooltip related problems

classic Classic list List threaded Threaded
40 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Fix some tooltip related problems

martin rudalics
I intend to apply the attached patch to master.  Its ChangeLog goes
as below.  Comments and suggestions welcome.

Thanks, martin

-------------------------------------------------------------------

Fix some tooltip related problems

Replace 'tooltip' frame parameter with a 'tooltip' member in
the frame structure.  For GTK+ builds use 'tip_last_frame' to
find the frame for which the currently visible tooltip was
made.  For modeline help-echoing have tooltips show applicable
actions only.

* lisp/bindings.el (mode-line-default-help-echo): New function
as default value of homonymous option.
* src/dispextern.h (tip_frame, tip_window): Remove
declarations.
* src/frame.c (make_frame): Initialize new frame structure
member 'tooltip'.
(Fframe_list, other_frames): Rewrite with new macro
FRAME_TOOLTIP_P.
(syms_of_frame): Remove Qtooltip.
* src/frame.h (struct frame): New member 'tooltip'.
(FRAME_TOOLTIP_P): New macro.
* src/gtkutil.c (xg_prepare_tooltip, xg_hide_tooltip): Rewrite
using boolean return values.
* src/nsfns.m (tip_frame): Remove declaration.
* src/w32fns.c (w32_display_monitor_attributes_list)
(w32_display_monitor_attributes_list_fallback): Rewrite with
new macro FRAME_TOOLTIP_P.
(tip_last_string, tip_last_frame, tip_last_parms): New Lisp
scalars replacing Lisp vector last_show_tip_args.
(x_create_tip_frame): Set new frame's 'tooltip' structure
member to true, remove setting of Qtooltip frame parameter.
(x_hide_tip): Additionally test tip_frame for liveness.
(Fx_show_tip): Handle last_show_tip_args to tip_last_frame,
tip_last_string and tip_last_parms conversion.
(syms_of_w32fns): staticpro tip_last_frame, tip_last_string
and tip_last_parms instead of last_show_tip_args.
* src/w32term.c (w32_read_socket, x_new_font): Rewrite with
new macro FRAME_TOOLTIP_P.
* src/w32term.h (tip_window): Add external declaration.
* src/xdisp.c (x_consider_frame_title, prepare_menu_bars)
(should_produce_line_number): Rewrite with new macro
FRAME_TOOLTIP_P.
(note_mode_line_or_margin_highlight): If
`mode-line-default-help-echo' specifies a function, call it to
produce help echo string.
* src/xfns.c (x_make_monitor_attribute_list)
(Fx_display_monitor_attributes_list): Rewrite with
new macro FRAME_TOOLTIP_P.
(tip_last_string, tip_last_frame, tip_last_parms): New Lisp
scalars replacing Lisp vector last_show_tip_args.
(x_create_tip_frame): Set new frame's 'tooltip' structure
member to true, remove setting of Qtooltip frame parameter.
(x_hide_tip): Rewrite with additional tests of frames for
liveness and taking into account that for GTK+ tips the
reference frame is now stored in tip_last_frame instead of
tip_frame.
(Fx_show_tip): Handle last_show_tip_args to tip_last_frame,
tip_last_string and tip_last_parms conversion.  For GTK+ store
FRAME argument in tip_last-frame.
(syms_of_xfns): staticpro tip_last_frame, tip_last_string
and tip_last_parms instead of last_show_tip_args.
* src/xterm.c (x_update_begin, handle_one_xevent, x_new_font)
(x_set_window_size): Rewrite with new macro FRAME_TOOLTIP_P.
* src/xterm.h (tip_window): Add external declaration.

tooltip.diff (54K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: Fix some tooltip related problems

Drew Adams
(If this has no effect on users or Lisp then you can
ignore this message.)

Could you perhaps describe the changes in terms of what
changes for (1) users and (2) existing Lisp code?  And
could you describe the problem(s) it is meant to solve?

> Replace 'tooltip' frame parameter with a 'tooltip'
> member in the frame structure.

I don't find a `tooltip' parameter mentioned in the
docs (e.g. Emacs 26 pretests).  Is this related to
variable `tooltip-frame-parameters'?

If so, this might break code (of which I have some)
that uses that variable to configure tooltip frames.

Does this affect use of `x-show-tip' or `tooltip-show'?

> For modeline help-echoing have tooltips show applicable
> actions only.

What does that mean?  What "inapplicable" stuff will
users no longer be able to see in tooltips?

Reply | Threaded
Open this post in threaded view
|

Re: Fix some tooltip related problems

martin rudalics
 > (If this has no effect on users or Lisp then you can
 > ignore this message.)
 >
 > Could you perhaps describe the changes in terms of what
 > changes for (1) users and (2) existing Lisp code?  And
 > could you describe the problem(s) it is meant to solve?
 >
 >> Replace 'tooltip' frame parameter with a 'tooltip'
 >> member in the frame structure.
 >
 > I don't find a `tooltip' parameter mentioned in the
 > docs (e.g. Emacs 26 pretests).  Is this related to
 > variable `tooltip-frame-parameters'?

No.  In Emacs 26 a tooltip's frame has a parameter called 'tooltip'
set to t.  But tooltip frames are hardly visible - `frame-list' and
`other-frames' don't show them - so it's unlikely that you've seen
that parameter.

 > If so, this might break code (of which I have some)
 > that uses that variable to configure tooltip frames.

`tooltip-frame-parameters' continues to work as before.

 > Does this affect use of `x-show-tip' or `tooltip-show'?

No.

 >> For modeline help-echoing have tooltips show applicable
 >> actions only.
 >
 > What does that mean?  What "inapplicable" stuff will
 > users no longer be able to see in tooltips?

For example, with emacs -Q and the mouse over the right part of the
single modeline you won't see a tooltip because the corresponding
window is already selected, occupies the whole frame and can be
neither removed nor resized.

martin

Reply | Threaded
Open this post in threaded view
|

Re: Fix some tooltip related problems

Eli Zaretskii
In reply to this post by martin rudalics
> Date: Mon, 08 Jan 2018 10:53:40 +0100
> From: martin rudalics <[hidden email]>
>
> I intend to apply the attached patch to master.  Its ChangeLog goes
> as below.  Comments and suggestions welcome.
>
> Thanks, martin
>
> -------------------------------------------------------------------
>
> Fix some tooltip related problems
>
> Replace 'tooltip' frame parameter with a 'tooltip' member in
> the frame structure.  For GTK+ builds use 'tip_last_frame' to
> find the frame for which the currently visible tooltip was
> made.  For modeline help-echoing have tooltips show applicable
> actions only.

What would that do to Lisp code that was probing that frame parameter?
I think for backward compatibility we should pretend in
frame-parameters and frame-parameter that this parameter still exist,
at least for tooltip frames.

IOW, remove it only for internal bookkeeping.

Thanks.

Reply | Threaded
Open this post in threaded view
|

RE: Fix some tooltip related problems

Drew Adams
In reply to this post by martin rudalics
..

Thanks for those answers.

>  >> For modeline help-echoing have tooltips show applicable
>  >> actions only.
>  >
>  > What does that mean?  What "inapplicable" stuff will
>  > users no longer be able to see in tooltips?
>
> For example, with emacs -Q and the mouse over the right part of the
> single modeline you won't see a tooltip because the corresponding
> window is already selected, occupies the whole frame and can be
> neither removed nor resized.

I guess you mean this tooltip:

 mouse-1: Select (drag to resize)
 mouse-2: Make current window occupy the whole frame
 mouse-3: Remove current window from display

As one user, in that context I'd rather still see those
mouse actions shown in a tooltip, for info/learning
purposes.  It would be good to dim them, however.

This is like showing `Edit' menu item `Cut' when the
buffer is read-only: we still show the menu item even
when it cannot be used in the current context.

It's true that for some menu items we use :visible
instead of :enable.  For the example you gave, I think
the :enable behavior is more appropriate: teach users
that it exists and tell them it is currently unavailable.

IMO, that's the right way to handle that particular
"inapplicable" action: show it, so users can learn
about those mouse actions even in that context - but
make clear that, although generally available, they
are not available currently.

So as one user I'd vote against this change, unless
I saw some good reasons for it or unless users will
somehow be given the choice.

What's the reason for this change?

What are the criteria that determine when such
"inapplicable" actions are not shown?  (I'm guessing
that the example you gave is not the only one.)

Reply | Threaded
Open this post in threaded view
|

Re: Fix some tooltip related problems

martin rudalics
In reply to this post by Eli Zaretskii
 > What would that do to Lisp code that was probing that frame parameter?
 > I think for backward compatibility we should pretend in
 > frame-parameters and frame-parameter that this parameter still exist,
 > at least for tooltip frames.
 >
 > IOW, remove it only for internal bookkeeping.

How about adding it to `tooltip-frame-parameters' then?

martin

Reply | Threaded
Open this post in threaded view
|

Re: Fix some tooltip related problems

Eli Zaretskii
> Date: Mon, 08 Jan 2018 20:06:17 +0100
> From: martin rudalics <[hidden email]>
> CC: [hidden email]
>
>  > What would that do to Lisp code that was probing that frame parameter?
>  > I think for backward compatibility we should pretend in
>  > frame-parameters and frame-parameter that this parameter still exist,
>  > at least for tooltip frames.
>  >
>  > IOW, remove it only for internal bookkeeping.
>
> How about adding it to `tooltip-frame-parameters' then?

I don't mind, but what I meant was to allow Lisp code written to
manipulate tooltips to be able to find the 'tooltip' frame parameter
when calling frame-parameter(s) for the tooltip frames.  This should
preferably happen even if some code removes that parameter from
tooltip-frame-parameters.

Reply | Threaded
Open this post in threaded view
|

Re: Fix some tooltip related problems

martin rudalics
In reply to this post by Drew Adams
 > I guess you mean this tooltip:
 >
 >   mouse-1: Select (drag to resize)
 >   mouse-2: Make current window occupy the whole frame
 >   mouse-3: Remove current window from display
 >
 > As one user, in that context I'd rather still see those
 > mouse actions shown in a tooltip, for info/learning
 > purposes.

The info is wrong and nothing can be learned from wrong info.

 > It would be good to dim them, however.

There's no option to do that and there won't be any with system
tooltips.

 > What's the reason for this change?

To stop showing misleading information.

martin

Reply | Threaded
Open this post in threaded view
|

Re: Fix some tooltip related problems

martin rudalics
In reply to this post by Eli Zaretskii
 > I don't mind, but what I meant was to allow Lisp code written to
 > manipulate tooltips to be able to find the 'tooltip' frame parameter
 > when calling frame-parameter(s) for the tooltip frames.  This should
 > preferably happen even if some code removes that parameter from
 > tooltip-frame-parameters.

OK.  I'll leave it as in Emacs 26 then.

martin

Reply | Threaded
Open this post in threaded view
|

RE: Fix some tooltip related problems

Drew Adams
In reply to this post by martin rudalics
>  > I guess you mean this tooltip:
>  >
>  >   mouse-1: Select (drag to resize)
>  >   mouse-2: Make current window occupy the whole frame
>  >   mouse-3: Remove current window from display
>  >
>  > As one user, in that context I'd rather still see those
>  > mouse actions shown in a tooltip, for info/learning
>  > purposes.
>
> The info is wrong and nothing can be learned from wrong info.

The same is true of most (probably all) of the places
where we show a dimmed menu item: the action is
"inapplicable".  That doesn't mean that showing it is
"wrong" and that "nothing can be learned" from seeing it.

A lot CAN be learned from such info.  That's why we
(and zillions of other applications) show it - dimmed.

>  > It would be good to dim them, however.
>
> There's no option to do that and there won't be any
> with system tooltips.

Why not?

Are you saying that this _cannot_ be done or only that
you've decided that it "won't" be done?  If the latter,
why?

>  > What's the reason for this change?
>
> To stop showing misleading information.

See above.  It's not misleading, if you dim it.
Showing "Edit > Cut" is not misleading when "Cut"
is "inapplicable" but it is dimmed to show that
cutting is not currently available.

Reply | Threaded
Open this post in threaded view
|

Re: Fix some tooltip related problems

martin rudalics
 > A lot CAN be learned from such info.  That's why we
 > (and zillions of other applications) show it - dimmed.

Have you ever seen one of those zillion applications show a dimmed
tooltip?

 >>   > It would be good to dim them, however.
 >>
 >> There's no option to do that and there won't be any
 >> with system tooltips.
 >
 > Why not?
 >
 > Are you saying that this _cannot_ be done or only that
 > you've decided that it "won't" be done?  If the latter,
 > why?

It cannot be done.  System tooltips have a uniform appearance.  So
dimming is not applicable for the default user on GNU/Linux - the vast
majority of Emacs users.  IIUC the same holds for Mac users.

martin

Reply | Threaded
Open this post in threaded view
|

RE: Fix some tooltip related problems

Drew Adams
>  >>   > It would be good to dim them, however.
>  >>
>  >> There's no option to do that and there won't be any
>  >> with system tooltips.
>  >
>  > Why not?  Are you saying that this _cannot_ be done
>  > or only that you've decided that it "won't" be done?
>
> It cannot be done.  System tooltips have a uniform appearance.  So
> dimming is not applicable for the default user on GNU/Linux - the
> vast majority of Emacs users.  IIUC the same holds for Mac users.

I see.  Well if it can't be done then it can't be done.

I have a naive question, though - your mention of "system
tooltip" isn't clear to me.

I thought that Emacs tooltips were Emacs frames.  What
prevents Emacs from doing what it wants in such a frame?
This works for me, for example:

(x-show-tip (propertize "abc" 'face '(:foreground "gray")))

What's different here from what you are talking about?

OK, I'm using MS Windows.  But does this not work also
on GNU/Linux and Mac?

And if that doesn't work on such platforms, can't we use
a ("normal") Emacs frame where such things do work?  Just
what is it that makes it impossible for Emacs to dim the
text in a tooltip?  Sorry, but this is not clear to me.

Reply | Threaded
Open this post in threaded view
|

Re: Fix some tooltip related problems

Alan Third
On Wed, Jan 10, 2018 at 07:55:41AM -0800, Drew Adams wrote:
> (x-show-tip (propertize "abc" 'face '(:foreground "gray")))
>
> What's different here from what you are talking about?
>
> OK, I'm using MS Windows.  But does this not work also
> on GNU/Linux and Mac?

This doesn’t work on the NS port. Tooltips on that platform are
neither system tooltips nor fully‐fledged frames. I think it also
doesn’t work with certain X toolkits (GTK?) where they use system
tooltips.

> And if that doesn't work on such platforms, can't we use
> a ("normal") Emacs frame where such things do work?  Just
> what is it that makes it impossible for Emacs to dim the
> text in a tooltip?  Sorry, but this is not clear to me.

It’s beyond me why you’d want to dim a tooltip. Dimming of menu items
is standard behaviour on many platforms whereas dimming a tooltip is,
afaik, a completely novel behaviour and as a result would just be
confusing.
--
Alan Third

Reply | Threaded
Open this post in threaded view
|

RE: Fix some tooltip related problems

Drew Adams
> > (x-show-tip (propertize "abc" 'face '(:foreground "gray")))
> >
> > What's different here from what you are talking about?
> > OK, I'm using MS Windows.  But does this not work also
> > on GNU/Linux and Mac?
>
> This doesn’t work on the NS port. Tooltips on that platform are
> neither system tooltips nor fully‐fledged frames. I think it also
> doesn’t work with certain X toolkits (GTK?) where they use system
> tooltips.

I see.

> > And if that doesn't work on such platforms, can't we use
> > a ("normal") Emacs frame where such things do work?  Just
> > what is it that makes it impossible for Emacs to dim the
> > text in a tooltip?  Sorry, but this is not clear to me.
>
> It’s beyond me why you’d want to dim a tooltip. Dimming of menu items
> is standard behaviour on many platforms whereas dimming a tooltip is,
> afaik, a completely novel behaviour and as a result would just be
> confusing.

1. The ability to use different Emacs faces in a tooltip
   frame is much more general than the use of that ability
   to dim the text in a tooltip.  It's a general feature.

   I didn't realize that Emacs was so limited in this regard
   on other platforms.  Thank goodness it works without a
   problem on at least some platforms (e.g. Windows).

   Given that limitation, I repeat the question: Can't we
   use a ("normal") Emacs frame, where things such as faces
   do work, to implement tooltips?

2. Wrt dimming a tooltip to show that its text, or some of it,
   applies generally, or at least in some contexts, but does
   not apply currently:

   The argument that we shouldn't do it because that would be
   "novel" isn't a good argument.  That a feature is "novel" is
   an argument neither for nor against its being added to Emacs.

   Emacs has, from the beginning, done things that weren't
   mainstream or even, yes, that were completely novel.
   There are some Emacs features that are still not found
   outside Emacs even though they've been in Emacs for decades.

   Ask yourself: How did dimming of menu items become standard
   behavior?  How did that feature ever get added to anything?
   Certainly not by someone who argued that it shouldn't be
   added because it is "novel" or is not yet standard.

   Did someone have to explain to you what a dimmed menu item
   is all about?  Is that inherently confusing the first time
   someone sees it?  I think not.  A tooltip with dimmed text
   is no more confusing.

Reply | Threaded
Open this post in threaded view
|

Re: Fix some tooltip related problems

Alan Third
On Wed, Jan 10, 2018 at 01:02:42PM -0800, Drew Adams wrote:
>    Given that limitation, I repeat the question: Can't we
>    use a ("normal") Emacs frame, where things such as faces
>    do work, to implement tooltips?

I believe it should be possible now we have undecorated frames
available. I’ve made a (really bad) attempt at proving we can do it.
Patch attached.

My emacs lisp skills are rather bad, so I couldn’t work out how to get
tooltip-hide to work, or how exactly I should set the size of the
tooltip, or how to not display the modeline, but it kind of works...
Someone who knows what they’re doing should be able to make a better
fist of it than me.

One possible issue is that it might be difficult to stop frame‐based
tooltips from crossing screens on multi‐monitor setups. I know we fix
that in Objective‐C code in NS, I don’t know if lisp knows enough
about screen geometry to get round it.

(BTW, I just noticed that under NS toolbar tooltips are native, while
other tooltips aren’t.)

>    Did someone have to explain to you what a dimmed menu item
>    is all about?  Is that inherently confusing the first time
>    someone sees it?  I think not.  A tooltip with dimmed text
>    is no more confusing.

I disagree, a menu item is interactive, or not if it’s dimmed, so it
becomes clear quite quickly what dimming means. A dimmed tooltip is
still a tooltip, just a bit harder to read. It takes further action to
discover that the information its giving you isn’t currently usable.

--
Alan Third

0001-Implement-rubbish-frame-base-tooltips.patch (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: Fix some tooltip related problems

Drew Adams
> >    Given that limitation, I repeat the question: Can't we
> >    use a ("normal") Emacs frame, where things such as faces
> >    do work, to implement tooltips?
>
> I believe it should be possible now we have undecorated frames
> available. I’ve made a (really bad) attempt at proving we can do it.
> Patch attached.
>
> My emacs lisp skills are rather bad, so I couldn’t work out how to get
> tooltip-hide to work, or how exactly I should set the size of the
> tooltip, or how to not display the modeline, but it kind of works...
> Someone who knows what they’re doing should be able to make a better
> fist of it than me.

Thanks for working on this.

I would hope that whatever implementation is ultimately used
is used for the existing functions (e.g. `x-tooltip-show'),
so that nothing changes for users/Lisp.

> One possible issue is that it might be difficult to stop frame‐based
> tooltips from crossing screens on multi‐monitor setups. I know we fix
> that in Objective‐C code in NS, I don’t know if lisp knows enough
> about screen geometry to get round it.

I don't think we should _necessarily_ force all of a tooltip's
text to be on a single monitor.  Though that might make sense
in some cases in others it might not.  At most, the ability to
do that would be a nice-to-have and not something needed or to
be imposed (IMO).

Put differently, it can be useful to _be able_ to position
_any_ frame so that it does not extend across monitors, when
possible.  But that shouldn't necessarily be imposed on any
frame, including, I think a tooltip.

> >    Did someone have to explain to you what a dimmed menu item
> >    is all about?  Is that inherently confusing the first time
> >    someone sees it?  I think not.  A tooltip with dimmed text
> >    is no more confusing.
>
> I disagree, a menu item is interactive, or not if it’s dimmed, so it
> becomes clear quite quickly what dimming means. A dimmed tooltip is
> still a tooltip, just a bit harder to read. It takes further action to
> discover that the information its giving you isn’t currently usable.

That's reasonable.  Not a big deal/difference though (IMO).

The ability to get the general info is more important than
any possible confusion (which I expect to be none) someone
might have from not immediately understanding that dim means
that trying the indicated action produces no effect.

Reply | Threaded
Open this post in threaded view
|

Re: Fix some tooltip related problems

Eli Zaretskii
In reply to this post by Drew Adams
> Date: Wed, 10 Jan 2018 13:02:42 -0800 (PST)
> From: Drew Adams <[hidden email]>
> Cc: martin rudalics <[hidden email]>, emacs-devel <[hidden email]>
>
>    Given that limitation, I repeat the question: Can't we
>    use a ("normal") Emacs frame, where things such as faces
>    do work, to implement tooltips?

We do have that capability on almost all platforms, but the default on
some of them is to use the system tooltips, and on others there's no
other way.

Reply | Threaded
Open this post in threaded view
|

Re: Fix some tooltip related problems

Yuri Khan-2
In reply to this post by Alan Third
On Thu, Jan 11, 2018 at 2:17 AM, Alan Third <[hidden email]> wrote:

> It’s beyond me why you’d want to dim a tooltip. Dimming of menu items
> is standard behaviour on many platforms whereas dimming a tooltip is,
> afaik, a completely novel behaviour and as a result would just be
> confusing.

It might be worthwhile to look at how tooltips of other unavailable
things behave.

Case in point: A disabled button on a toolbar that shows icons only
(no text labels). The text label traditionally goes into the tooltip.
The tooltip is displayed always, no matter if the button is enabled or
disabled.

However, in that case we have a visual indication that the button is
disabled: its icon goes gray and dim. We don’t have that indication on
the modeline of the only window in an Emacs frame.

Also, this discussion assumes that we need to hide, or modify the
appearance of, the tooltip *because* the actions it describes are
unavailable. How could we change the behavior so that they would be
available even if the window is the only one in its frame?

Possible answer: Look at the splitter controls in some of Microsoft
products (Word, Visual Studio). (Or LibreOffice Calc.) The splitter is
there always, and always draggable, whether the window is split or
not. If the window is split, dragging the splitter resizes the panes.
If the window is not split, dragging the splitter splits it. If the
window is split and the user drags the splitter to either extreme end
of the range, the pane that got resized to zero is removed.

Reply | Threaded
Open this post in threaded view
|

Re: Fix some tooltip related problems

martin rudalics
In reply to this post by Drew Adams
 > I thought that Emacs tooltips were Emacs frames.  What
 > prevents Emacs from doing what it wants in such a frame?
 > This works for me, for example:
 >
 > (x-show-tip (propertize "abc" 'face '(:foreground "gray")))
 >
 > What's different here from what you are talking about?
 >
 > OK, I'm using MS Windows.  But does this not work also
 > on GNU/Linux and Mac?
 >
 > And if that doesn't work on such platforms, can't we use
 > a ("normal") Emacs frame where such things do work?  Just
 > what is it that makes it impossible for Emacs to dim the
 > text in a tooltip?  Sorry, but this is not clear to me.

System tooltips are lightweight objects with restricted abilities.
They have uniform appearance and the single tooltip window is usually
shared among all running programs and the operating system.

Emacs tooltips are merely an emulation of system tooltips.  Most
restrictions of system tooltips have been retrofit artificially, like
uniform faces which are built into `tooltip-show' (but can be avoided
by using `x-show-tip' as you mention above) or the fact that only one
tooltip can be present at any time.

The great disadvantage of Emacs tooltips is that they are heavyweight
precisely due to their versatility.  Showing an Emacs tooltip here on
Windows with -Q incurs an entire GC cycle.  Also, there are some minor
annoyances like the one that showing Emacs tooltips for menu items
depends on the presence of a blinking cursor.

martin

Reply | Threaded
Open this post in threaded view
|

RE: Fix some tooltip related problems

Drew Adams
In reply to this post by Yuri Khan-2
> Also, this discussion assumes that we need to hide, or modify the
> appearance of, the tooltip *because* the actions it describes are
> unavailable. How could we change the behavior so that they would be
> available even if the window is the only one in its frame?

Yes, I considered that.  Clearly, for the more specific
question about _this_ tooltip, providing different
actions in the sole-window case might be a reasonable
approach.

But that doesn't address the more general question of
describing generally-but-not-currently-available actions.
Regardless of whether alternative actions can be found
in this or that case, the question of dimmed-tooltip
usefulness remains.

12