Re: [PATCH] git-gui: use gray selection background for inactive text widgets

From: Stefan Haller <stefan@haller-berlin.de>
To: me@yadavpratyush.com
Cc: serg.partizan@gmail.com, git@vger.kernel.org
Subject: Re: [PATCH] git-gui: use gray selection background for inactive text widgets
Date: Mon, 30 Nov 2020 21:18:36 +0100	[thread overview]
Message-ID: <20201130201837.19091-1-stefan@haller-berlin.de> (raw)
In-Reply-To: <20201130180827.2oimhr3vmjq7tzaq@yadavpratyush.com>

On 30.11.20 19:08, Pratyush Yadav wrote:
> On 30/11/20 03:41PM, serg.partizan@gmail.com wrote:
>> On Sun, Nov 29, 2020 at 18:40, Stefan Haller <stefan@haller-berlin.de>
>> wrote:
>>> After spending quite a while single-stepping through lots of Tk code, I
>>> found the reason. On Mac, disabled text widgets simply don't draw the
>>> selection background. [1]
>>>
>>> I can see three options for solving this:
>>>
>>> 1) Don't use "state focus" and "state !focus" on the text widgets, but
>>>    instead set the selection color manually using "text conf sel
>>>    -background". Disadvantage: have to calculate the disabled color
>>>    using a heuristic like I did for the file lists in my v2 patch.
>>>
>>> 2) Don't use "configure -state disabled" to make the diff text widget
>>>    read-only; instead, use one of the other methods from [2].
>>>    Disadvantage: quite a big change, and seems complex to me.
>>>
>>> 3) Enable the the diff widget when it loses focus, and disable it again
>>>    when it gets focus. I tried this in a quick prototype, and it works
>>>    very well. It just *feels* wrong to enable a read-only text widget
>>>    while it is unfocused; but I couldn't find any situation where it
>>>    would behave wrong, because as soon as you try to interact with it,
>>>    the first thing that happens is that it gets disabled again.
>>>
>>> I tend towards option 3, because it's reasonably simple and works. I'll
>>> work on a patch tomorrow unless anybody has objections.
>>>
>>
>> I don't like any of this options, as it makes code complicated. I personally
>> would prefer to not implement this feature at all, but that's just me.
>
> That is my first thought as well. All 3 alternatives are less than
> ideal. I don't think the problem is big enough to warrant adding hacks
> like this. They will come back to bite us sooner or later.
>
> If you _really_ want to fix this, maybe try convincing the Tk devs about
> fixing it.

Yeah, maybe. Just for the record, here's a patch that does it (in the next
message), and frankly, I don't think it's so bad. I do think it's enough of an
improvement that it's worth having. I guess I'll have to maintain it in my local
build if you don't like it.

-Stefan