GNU bug report logs - #75930
30.0.92; Setting default frame background color messes up mouse pointer

Previous Next

Full log

Message #50 received at 75930 <at> debbugs.gnu.org (full text, mbox):

From: Lars Rustand <rustand.lars <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Po Lu <luangruo <at> yahoo.com>
Cc: 75930 <at> debbugs.gnu.org
Subject: Re: bug#75930: 30.0.92; Setting default frame background color
 messes up mouse pointer
Date: Sat, 01 Feb 2025 14:18:16 +0100

TLDR; Can we avoid making the outline/border of the mouse pointer invisible?
----

Eli Zaretskii <eliz <at> gnu.org> writes:
 
>> I have identified the cause of part 1, but I have not (yet) found the
>> cause of part 2.
>
>I think part 2 happens as part of frame-set-background-mode, as I
>mentioned up-thread, and it makes sense to me.

Understood. I will accept this premise, even though I personally don't
fully agree with it.

>What this might mean is that if you don't want the effect the original
>recipe produces, you should call set-mouse-color again after
>set-background-color.

This suggestion seems to be based on a misunderstanding of which problem
I am actually reporting.

Unfortunately that will produce the exact result I am trying to avoid,
i.e. the mouse pointer on the right in my previously posted example
image, which has an invisible outline.

The last part of the original recipe (the --eval part) was only added
for demonstration purposes, to make the pointer outline clearly visible
against the background color to show clearly what is happening.

So, to be extra clear: the thing that I want to avoid is that passing
the --background-color argument causes the outline of the mouse pointer
to become invisible.

I guess this can be generalized to a slightly broader goal: Avoid making
the outline of the mouse pointer invisible, period. Or at the very
least, don't actively enforce that it becomes invisible like the current
x_set_mouse_color does.

>> Part 1 is that x_set_mouse_color incorrectly uses the background color
>> of the current (or default?) frame as the color of the border/outline
>> of the mouse pointer. This makes that border in effect become
>> completely invisible when hovering over the emacs frame, which can make
>> the mouse pointer very hard to see.
>
>What would you propose as an the alternative?

I realize that there is probably not a "perfect" solution to this, but I
can think of multiple ways that would be better than the current
situation.

1. Don't change the pointer outline color at all. Since set-mouse-color
   only accepts the foreground color as argument, I don't think it
   should change other colors than the one it is given as argument.
2. Apply the same logic as is currently used for the pointer foreground
   color. (See reference below)
3. Simply use the frame foreground color instead of the frame background
   color. This would be guaranteed to be visible against the background.
4. Use the "inverse" of the pointer foreground color.
5. Set it to either black or white, based on how light the pointer
   foreground color is.
6. Add a second (optional) argument to set-mouse-color, so the user is
   able to decide the color of the outline.

My preferred solution would be nr 1, possibly combined with 2 to avoid
leaving the outline color unchanged in cases where this would cause it
to be invisible.


The if-check (from x_set_mouse_color) referenced by point 2 above:

  /* Don't let pointers be invisible.  */
  if (mask_color == pixel)
    {
      x_free_colors (f, &pixel, 1);
      pixel = x_copy_color (f, FRAME_FOREGROUND_PIXEL (f));
    }


Po Lu <luangruo <at> yahoo.com> writes:

> But I am currently not horribly disposed to debug
> the details of Emacs code when one of its maintainers is deliberately
> turning a deaf ear to very reasonable requests on my part.  Namely, not
> merging a branch for another month or so, once I have had a chance to
> correct a number of its deficiencies.

I'm sorry to hear about this, but I hope this won't affect your
judgement when it comes to recognizing something as a bug or not. I
don't expect you to do the debugging for me, I'm willing to do all the
debugging and patching myself, as long as we can all agree about what
needs fixing, and what doesn't. In fact, I think I have all the details
I need in order to implement a solution (depending on which route we
want to go).

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.