gitk: check main window visibility before waiting for it to show
PATCH 1/1 gitk: check main window visibility before waiting for it to show
From: Tobias Pietzsch <[email protected]>
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
---
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(-)
gitk-git/gitk +1 -1
@@ -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
Signature · 1 line
gitgitgadget
Quoted 14 lines · Tobias Pietzsch via GitGitGadget
From: Tobias Pietzsch <[email protected]>
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+visibilitySigned-off-by Tobias Pietzsch <[email protected]>---
gitk: check main window visibility before waiting for it to showIf the main window is already visible when gitk waits for it to become visible, gitk hangs forever.
Quoted 7 lines
This commit adds a check whether the window is already visible. See
https://wiki.tcl-lang.org/page/tkwait+visibilityThe 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
A message that is not in the archive (sent off-list or not yet received): [email protected]
Re: The health of gitk, was Re: [PATCH] gitk: check main window visibility before waiting for it to show
Just one quick additional note:
Quoted 6 lines · Johannes Schindelin
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
Ciao,
Johannes
Re: The health of gitk, was Re: [PATCH] gitk: check main window visibility before waiting for it to show
In reply to a message not in the archiveQuoted 28 lines · Johannes Schindelin
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).
Quoted 6 lines
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
Quoted 3 lines · Paul Mackerras
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
In reply to Paul MackerrasAm 14.11.24 um 08:19 schrieb Paul Mackerras:
Quoted 41 lines · Johannes Schindelin
Quoted 28 lines
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).
Quoted 6 lines
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.
Quoted 8 lines
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
Quoted 3 lines · Johannes Sixt
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.
Quoted 3 lines
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:
bb5cb23daf751790950ff9f761f8884e21c88d007dd272eca153058da2e8d5b9960bbbf0b4f0cbaa
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:
65175d9ea26bebeb9d69977d0e75efc0e88dbcedd05b08cd52cfda627f1d865bdfe6040a2c9521b5728b9ac0c3b93aaa4ea80280c591deb198051785
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
Am 19.11.24 um 10:59 schrieb Paul Mackerras:
Quoted 17 lines
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:
bb5cb23daf751790950ff9f761f8884e21c88d007dd272eca153058da2e8d5b9960bbbf0b4f0cbaaI assume you can pull them into your clone of my tree using suitable git commands (I guess you would create a branch with
7dd272eca153as its head and do git pull --ff from that).There are three commits that touch the gitk-git directory in the git tree directly:
65175d9ea26bebeb9d69977d0e75efc0e88dbcedd05b08cd52cfda627f1d865bdfe6040a2c9521b5728b9ac0c3b93aaa4ea80280c591deb198051785
Quoted 8 lines
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
b117cee32259acf923c3ada52b4dd89f2ea6a454which 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