[PATCH] gitk: check main window visibility before waiting for it to show

[PATCH] gitk: check main window visibility before waiting for it to show

[Tobias Pietzsch via GitGitGadget]

From: Tobias Pietzsch <pietzsch@mycroft.speedport.ip>

If the main window is already visible when gitk waits for it to
become visible, gitk hangs forever.
This commit adds a check whether the window is already visible.
See https://wiki.tcl-lang.org/page/tkwait+visibility

Signed-off-by: Tobias Pietzsch <pietzsch@mycroft.speedport.ip>
---
    gitk: check main window visibility before waiting for it to show
    
    If the main window is already visible when gitk waits for it to become
    visible, gitk hangs forever.
    
    This commit adds a check whether the window is already visible. See
    https://wiki.tcl-lang.org/page/tkwait+visibility
    
    The symptom of the for-ever waiting is that gitk shows just an empty
    window, like this: https://tinyurl.com/yxr5qlf6 It happens (to me) on
    macOS 11.1 with git-gui installed via homebrew. It doesn't happen on
    macOS 10.14.

Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-944%2Ftpietzsch%2Fmaster-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-944/tpietzsch/master-v1
Pull-Request: https://github.com/git/git/pull/944

 gitk-git/gitk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gitk-git/gitk b/gitk-git/gitk
index 23d9dd1fe0d..cd02b4d50fc 100755
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -12658,7 +12658,7 @@ catch {
     wm iconphoto . -default gitlogo gitlogo32
 }
 # wait for the window to become visible
-tkwait visibility .
+if {![winfo viewable .]} {tkwait visibility .}
 set_window_title
 update
 readrefs

base-commit: 72c4083ddf91b489b7b7b812df67ee8842177d98
-- 
gitgitgadget

Re: [PATCH] gitk: check main window visibility before waiting for it to show

[Beat Bolli]

On 10.01.21 00:26, Tobias Pietzsch via GitGitGadget wrote:
> From: Tobias Pietzsch <pietzsch@mycroft.speedport.ip>
>
> If the main window is already visible when gitk waits for it to
> become visible, gitk hangs forever.
> This commit adds a check whether the window is already visible.
> See https://wiki.tcl-lang.org/page/tkwait+visibility
>
> Signed-off-by: Tobias Pietzsch <pietzsch@mycroft.speedport.ip>
> ---
>     gitk: check main window visibility before waiting for it to show
>
>     If the main window is already visible when gitk waits for it to become
>     visible, gitk hangs forever.
>
>     This commit adds a check whether the window is already visible. See
>     https://wiki.tcl-lang.org/page/tkwait+visibility
>
>     The symptom of the for-ever waiting is that gitk shows just an empty
>     window, like this: https://tinyurl.com/yxr5qlf6 It happens (to me) on
>     macOS 11.1 with git-gui installed via homebrew. It doesn't happen on
>     macOS 10.14.

Thanks, this also occurred on my macOS 10.14.6 just an hour ago after a
recent brew upgrade, and the patch makes gitk usable again.

Cheers, Beat

Re: The health of gitk, was Re: [PATCH] gitk: check main window visibility before waiting for it to show

[Johannes Schindelin]

Just one quick additional note:

On Wed, 13 Nov 2024, Johannes Schindelin wrote:

> This morning, I woke up to find a new PR in microsoft/git
> (https://github.com/microsoft/git/issues/704) that cherry-picks the patch
> that was offered in this here mail list thread. That patch is almost four
> years old, i.e. just about ready to enter pre-school and to learn how to
> read and write. Yet apart from Beat's confirmation that it fixes a real
> bug, this here patch has been treated with silence.

Even Homebrew is waiting with bated breath for that patch to be picked up:

- https://github.com/Homebrew/homebrew-core/pull/68865

- https://github.com/carlocab/homebrew-core/blob/a236345fdfbb37465edc0b5a0ad1a51dcbd84423/Formula/git-gui.rb#L19-L26

Ciao,
Johannes

Re: The health of gitk, was Re: [PATCH] gitk: check main window visibility before waiting for it to show

[Paul Mackerras]

On Wed, Nov 13, 2024 at 08:41:42AM +0100, Johannes Schindelin wrote:
> Hi Hannes,
> 
> I would like to offer this thread as Exhibit A in support for the case I
> started making at [GitMerge '24](https://git-merge.com/) to convince you
> to consider maintaining gitk in addition to Git GUI.
> 
> Having one maintainer of Git GUI and gitk would make for a quite natural
> fit, I would think, as both are written in Tcl/Tk, neither is used by the
> core Git contributors because they are GUI programs, both lower the bar
> for new Git users because they are GUI programs, and either would be
> subject for eviction from git/git unless maintained by an active
> volunteer.
> 
> From what I see, Git GUI is in real good hands since you took over, I see
> reports and patches picked up quickly and the style of your replies is
> refreshingly constructive and friendly.
> 
> This morning, I woke up to find a new PR in microsoft/git
> (https://github.com/microsoft/git/issues/704) that cherry-picks the patch
> that was offered in this here mail list thread. That patch is almost four
> years old, i.e. just about ready to enter pre-school and to learn how to
> read and write. Yet apart from Beat's confirmation that it fixes a real
> bug, this here patch has been treated with silence.
> 
> Unfortunately, the original GitGitGadget PR had to be locked down and
> therefore Tobias would not be able to send another iteration even if he
> wanted to (which I doubt, given the experience on this mailing list).
> 
> Therefore I see the need not only to revive this thread, but also to look
> for an active gitk maintainer.
> 
> May I ask you, now in public, whether you would be potentially open to
> maintain gitk in addition to Git GUI? If so, I would then start a proper
> new thread to nominate you officially.

If Hannes is willing to take this on, I would support that fully and I
would also be happy to assist.  I know I was extremely slack about
gitk patches for a long while, but I think I have a little more free
time now, having retired.

There is another issue which will need to be sorted out, which is
whether to persist with a separate tree that gets merged into the git
repository, or just edit the copy of gitk in the git repository.
There have been tree-wide patches applied to the git tree which
affected gitk, meaning that my gitk repository is now out of sync.
I recently (as in several weeks ago) sent Junio Hamano an email asking
this question, and asking for his opinion on the best way to proceed
with gitk patches, but got no reply.

Paul.

Re: The health of gitk, was Re: [PATCH] gitk: check main window visibility before waiting for it to show

[Junio C Hamano]

Paul Mackerras <paulus@ozlabs.org> writes:

> I recently (as in several weeks ago) sent Junio Hamano an email asking
> this question, and asking for his opinion on the best way to proceed
> with gitk patches, but got no reply.

Ah, it was probably (just) before I took a few weeks off, and I
completely forgot about it.  I tried to be careful pushing back
patches that touch both inside and outside gitk but I wouldn't be
surprised if some slipped in by mistake.  We could split them out
and get your tree back in sync, if you prefer to keep gitk as
semi-independent project that is subtree bound to our tree.  The
arrangement had merit in early days, back when git itself and gitk
could have different release cadence, but in practice, I haven't
seen gitk separately issuing freestanding releases to end users (or
end-users installing versions of gitk independent from the version
of git they have, for that matter), so perhaps the separate tree
arrangement has outlived its usefulness?  I dunno.

Thanks.

Gitk maintainership, was Re: The health of gitk

[Johannes Sixt]

Am 14.11.24 um 08:19 schrieb Paul Mackerras:
> On Wed, Nov 13, 2024 at 08:41:42AM +0100, Johannes Schindelin wrote:
>> Hi Hannes,
>>
>> I would like to offer this thread as Exhibit A in support for the case I
>> started making at [GitMerge '24](https://git-merge.com/) to convince you
>> to consider maintaining gitk in addition to Git GUI.
>>
>> Having one maintainer of Git GUI and gitk would make for a quite natural
>> fit, I would think, as both are written in Tcl/Tk, neither is used by the
>> core Git contributors because they are GUI programs, both lower the bar
>> for new Git users because they are GUI programs, and either would be
>> subject for eviction from git/git unless maintained by an active
>> volunteer.
>>
>> From what I see, Git GUI is in real good hands since you took over, I see
>> reports and patches picked up quickly and the style of your replies is
>> refreshingly constructive and friendly.
>>
>> This morning, I woke up to find a new PR in microsoft/git
>> (https://github.com/microsoft/git/issues/704) that cherry-picks the patch
>> that was offered in this here mail list thread. That patch is almost four
>> years old, i.e. just about ready to enter pre-school and to learn how to
>> read and write. Yet apart from Beat's confirmation that it fixes a real
>> bug, this here patch has been treated with silence.
>>
>> Unfortunately, the original GitGitGadget PR had to be locked down and
>> therefore Tobias would not be able to send another iteration even if he
>> wanted to (which I doubt, given the experience on this mailing list).
>>
>> Therefore I see the need not only to revive this thread, but also to look
>> for an active gitk maintainer.
>>
>> May I ask you, now in public, whether you would be potentially open to
>> maintain gitk in addition to Git GUI? If so, I would then start a proper
>> new thread to nominate you officially.
> 
> If Hannes is willing to take this on, I would support that fully and I
> would also be happy to assist.  I know I was extremely slack about
> gitk patches for a long while, but I think I have a little more free
> time now, having retired.
> 
> There is another issue which will need to be sorted out, which is
> whether to persist with a separate tree that gets merged into the git
> repository, or just edit the copy of gitk in the git repository.
> There have been tree-wide patches applied to the git tree which
> affected gitk, meaning that my gitk repository is now out of sync.
> I recently (as in several weeks ago) sent Junio Hamano an email asking
> this question, and asking for his opinion on the best way to proceed
> with gitk patches, but got no reply.

[For some reason, Dscho's original message didn't make it to my mailbox.]

I have given the idea to take maintainership of Gitk ample
consideration, and I would accept the task. Paul, let me know how to
proceed.

Regarding whether to have a separate tree or not, I would prefer a
separate tree at this time, but only for the reason that it is known
ground for me, and not that it has some (technical) advantage.

-- Hannes

Re: Gitk maintainership, was Re: The health of gitk

[Paul Mackerras]

On Sun, Nov 17, 2024 at 04:26:41PM +0100, Johannes Sixt wrote:

> I have given the idea to take maintainership of Gitk ample
> consideration, and I would accept the task. Paul, let me know how to
> proceed.

That's great!  Thanks for taking that on.

> Regarding whether to have a separate tree or not, I would prefer a
> separate tree at this time, but only for the reason that it is known
> ground for me, and not that it has some (technical) advantage.

I think you want to clone my tree at git://git.ozlabs.org/~paulus/gitk
and work out what to do about the commits that it lacks.  Then it's a
matter of the usual maintainership process (e.g., apply patches,
publish your tree somewhere, and ask Junio to pull from it).

In the current upstream git tree, I see two commits that were applied
to a clone of my tree, then pulled into the git tree:

bb5cb23daf751790950ff9f761f8884e21c88d00
7dd272eca153058da2e8d5b9960bbbf0b4f0cbaa

I assume you can pull them into your clone of my tree using suitable
git commands (I guess you would create a branch with 7dd272eca153 as
its head and do git pull --ff from that).

There are three commits that touch the gitk-git directory in the git
tree directly:

65175d9ea26bebeb9d69977d0e75efc0e88dbced
d05b08cd52cfda627f1d865bdfe6040a2c9521b5
728b9ac0c3b93aaa4ea80280c591deb198051785

I assume you want to make the same changes in your gitk tree, so as to
avoid conflicts in future.  I expect git would merge commits in the
gitk tree making the same changes as are already in the git repo
without fuss.

There is also b117cee32259acf923c3ada52b4dd89f2ea6a454 which touches
gitk-git in the 'seen' branch of the git tree.  I don't know what you
would need to do about that, if anything.

I hope that helps.

Regards,
Paul.

Re: Gitk maintainership, was Re: The health of gitk

[Johannes Sixt]

Am 19.11.24 um 10:59 schrieb Paul Mackerras:
> In the current upstream git tree, I see two commits that were applied
> to a clone of my tree, then pulled into the git tree:
> 
> bb5cb23daf751790950ff9f761f8884e21c88d00
> 7dd272eca153058da2e8d5b9960bbbf0b4f0cbaa
> 
> I assume you can pull them into your clone of my tree using suitable
> git commands (I guess you would create a branch with 7dd272eca153 as
> its head and do git pull --ff from that).
> 
> There are three commits that touch the gitk-git directory in the git
> tree directly:
> 
> 65175d9ea26bebeb9d69977d0e75efc0e88dbced
> d05b08cd52cfda627f1d865bdfe6040a2c9521b5
> 728b9ac0c3b93aaa4ea80280c591deb198051785
> 
> I assume you want to make the same changes in your gitk tree, so as to
> avoid conflicts in future.  I expect git would merge commits in the
> gitk tree making the same changes as are already in the git repo
> without fuss.
> 
> There is also b117cee32259acf923c3ada52b4dd89f2ea6a454 which touches
> gitk-git in the 'seen' branch of the git tree.  I don't know what you
> would need to do about that, if anything.

Thanks a lot for doing all the digging, this is very helpful. I'll
publish the repository on Github later this week or over the weekend.

-- Hannes