{"thread":{"id":"54973","subject":"[PATCH] gitk: check main window visibility before waiting for it to show","startedAt":"2021-01-09T23:27:26Z","lastAt":"2024-11-19T18:49:25Z","messageCount":8,"participants":["Tobias Pietzsch via GitGitGadget","Beat Bolli","Johannes Schindelin","Paul Mackerras","Junio C Hamano","Johannes Sixt"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"413946","messageId":"pull.944.git.git.1610234771966.gitgitgadget@gmail.com","threadId":"54973","inReplyTo":null,"subject":"[PATCH] gitk: check main window visibility before waiting for it to show","fromName":"Tobias Pietzsch via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2021-01-09T23:26:11Z","receivedAt":"2021-01-09T23:27:26Z","isPatch":true,"sender":{"key":"name:Tobias Pietzsch","avatar":null},"body":"From: Tobias Pietzsch \n\nIf the main window is already visible when gitk waits for it to\nbecome visible, gitk hangs forever.\nThis commit adds a check whether the window is already visible.\nSee https://wiki.tcl-lang.org/page/tkwait+visibility\n\nSigned-off-by: Tobias Pietzsch \n---\n gitk: check main window visibility before waiting for it to show\n \n If the main window is already visible when gitk waits for it to become\n visible, gitk hangs forever.\n \n This commit adds a check whether the window is already visible. See\n https://wiki.tcl-lang.org/page/tkwait+visibility\n \n The symptom of the for-ever waiting is that gitk shows just an empty\n window, like this: https://tinyurl.com/yxr5qlf6 It happens (to me) on\n macOS 11.1 with git-gui installed via homebrew. It doesn't happen on\n macOS 10.14.\n\nPublished-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-944%2Ftpietzsch%2Fmaster-v1\nFetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-944/tpietzsch/master-v1\nPull-Request: https://github.com/git/git/pull/944\n\n gitk-git/gitk | 2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git a/gitk-git/gitk b/gitk-git/gitk\nindex 23d9dd1fe0d..cd02b4d50fc 100755\n--- a/gitk-git/gitk\n+++ b/gitk-git/gitk\n@@ -12658,7 +12658,7 @@ catch {\n wm iconphoto . -default gitlogo gitlogo32\n }\n # wait for the window to become visible\n-tkwait visibility .\n+if {![winfo viewable .]} {tkwait visibility .}\n set_window_title\n update\n readrefs\n\nbase-commit: 72c4083ddf91b489b7b7b812df67ee8842177d98\n-- \ngitgitgadget\n"},{"id":"413991","messageId":"bdaab72b-37f4-658a-716a-d6a958b6f709@drbeat.li","threadId":"54973","inReplyTo":"pull.944.git.git.1610234771966.gitgitgadget@gmail.com","subject":"Re: [PATCH] gitk: check main window visibility before waiting for it to show","fromName":"Beat Bolli","fromEmail":"dev+git@drbeat.li","sentAt":"2021-01-10T22:23:15Z","receivedAt":"2021-01-10T22:24:19Z","isPatch":true,"sender":{"key":"dev+git@drbeat.li","avatar":"https://avatars.githubusercontent.com/u/21444?v=4"},"body":"On 10.01.21 00:26, Tobias Pietzsch via GitGitGadget wrote:\n> From: Tobias Pietzsch \n>\n> If the main window is already visible when gitk waits for it to\n> become visible, gitk hangs forever.\n> This commit adds a check whether the window is already visible.\n> See https://wiki.tcl-lang.org/page/tkwait+visibility\n>\n> Signed-off-by: Tobias Pietzsch \n> ---\n> gitk: check main window visibility before waiting for it to show\n>\n> If the main window is already visible when gitk waits for it to become\n> visible, gitk hangs forever.\n>\n> This commit adds a check whether the window is already visible. See\n> https://wiki.tcl-lang.org/page/tkwait+visibility\n>\n> The symptom of the for-ever waiting is that gitk shows just an empty\n> window, like this: https://tinyurl.com/yxr5qlf6 It happens (to me) on\n> macOS 11.1 with git-gui installed via homebrew. It doesn't happen on\n> macOS 10.14.\n\nThanks, this also occurred on my macOS 10.14.6 just an hour ago after a\nrecent brew upgrade, and the patch makes gitk usable again.\n\nCheers, Beat\n"},{"id":"507196","messageId":"71af9e7f-84b2-437e-7167-2dd0add02f1b@gmx.de","threadId":"54973","inReplyTo":"ddee92a7-3d1e-f869-9cc4-72b70eee0dd5@gmx.de","subject":"Re: The health of gitk, was Re: [PATCH] gitk: check main window visibility before waiting for it to show","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2024-11-13T07:47:41Z","receivedAt":"2024-11-13T07:47:47Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Just one quick additional note:\n\nOn Wed, 13 Nov 2024, Johannes Schindelin wrote:\n\n> This morning, I woke up to find a new PR in microsoft/git\n> (https://github.com/microsoft/git/issues/704) that cherry-picks the patch\n> that was offered in this here mail list thread. That patch is almost four\n> years old, i.e. just about ready to enter pre-school and to learn how to\n> read and write. Yet apart from Beat's confirmation that it fixes a real\n> bug, this here patch has been treated with silence.\n\nEven Homebrew is waiting with bated breath for that patch to be picked up:\n\n- https://github.com/Homebrew/homebrew-core/pull/68865\n\n- https://github.com/carlocab/homebrew-core/blob/a236345fdfbb37465edc0b5a0ad1a51dcbd84423/Formula/git-gui.rb#L19-L26\n\nCiao,\nJohannes\n"},{"id":"507253","messageId":"ZzWkgblaoWehC0kY@thinks.paulus.ozlabs.org","threadId":"54973","inReplyTo":"ddee92a7-3d1e-f869-9cc4-72b70eee0dd5@gmx.de","subject":"Re: The health of gitk, was Re: [PATCH] gitk: check main window visibility before waiting for it to show","fromName":"Paul Mackerras","fromEmail":"paulus@ozlabs.org","sentAt":"2024-11-14T07:19:29Z","receivedAt":"2024-11-14T07:19:36Z","isPatch":true,"sender":{"key":"paulus@ozlabs.org","avatar":"https://avatars.githubusercontent.com/u/1606439?v=4"},"body":"On Wed, Nov 13, 2024 at 08:41:42AM +0100, Johannes Schindelin wrote:\n> Hi Hannes,\n> \n> I would like to offer this thread as Exhibit A in support for the case I\n> started making at [GitMerge '24](https://git-merge.com/) to convince you\n> to consider maintaining gitk in addition to Git GUI.\n> \n> Having one maintainer of Git GUI and gitk would make for a quite natural\n> fit, I would think, as both are written in Tcl/Tk, neither is used by the\n> core Git contributors because they are GUI programs, both lower the bar\n> for new Git users because they are GUI programs, and either would be\n> subject for eviction from git/git unless maintained by an active\n> volunteer.\n> \n> From what I see, Git GUI is in real good hands since you took over, I see\n> reports and patches picked up quickly and the style of your replies is\n> refreshingly constructive and friendly.\n> \n> This morning, I woke up to find a new PR in microsoft/git\n> (https://github.com/microsoft/git/issues/704) that cherry-picks the patch\n> that was offered in this here mail list thread. That patch is almost four\n> years old, i.e. just about ready to enter pre-school and to learn how to\n> read and write. Yet apart from Beat's confirmation that it fixes a real\n> bug, this here patch has been treated with silence.\n> \n> Unfortunately, the original GitGitGadget PR had to be locked down and\n> therefore Tobias would not be able to send another iteration even if he\n> wanted to (which I doubt, given the experience on this mailing list).\n> \n> Therefore I see the need not only to revive this thread, but also to look\n> for an active gitk maintainer.\n> \n> May I ask you, now in public, whether you would be potentially open to\n> maintain gitk in addition to Git GUI? If so, I would then start a proper\n> new thread to nominate you officially.\n\nIf Hannes is willing to take this on, I would support that fully and I\nwould also be happy to assist. I know I was extremely slack about\ngitk patches for a long while, but I think I have a little more free\ntime now, having retired.\n\nThere is another issue which will need to be sorted out, which is\nwhether to persist with a separate tree that gets merged into the git\nrepository, or just edit the copy of gitk in the git repository.\nThere have been tree-wide patches applied to the git tree which\naffected gitk, meaning that my gitk repository is now out of sync.\nI recently (as in several weeks ago) sent Junio Hamano an email asking\nthis question, and asking for his opinion on the best way to proceed\nwith gitk patches, but got no reply.\n\nPaul.\n"},{"id":"507254","messageId":"xmqqed3e6xxl.fsf@gitster.g","threadId":"54973","inReplyTo":"ZzWkgblaoWehC0kY@thinks.paulus.ozlabs.org","subject":"Re: The health of gitk, was Re: [PATCH] gitk: check main window visibility before waiting for it to show","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-11-14T08:07:18Z","receivedAt":"2024-11-14T08:07:21Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Paul Mackerras writes:\n\n> I recently (as in several weeks ago) sent Junio Hamano an email asking\n> this question, and asking for his opinion on the best way to proceed\n> with gitk patches, but got no reply.\n\nAh, it was probably (just) before I took a few weeks off, and I\ncompletely forgot about it. I tried to be careful pushing back\npatches that touch both inside and outside gitk but I wouldn't be\nsurprised if some slipped in by mistake. We could split them out\nand get your tree back in sync, if you prefer to keep gitk as\nsemi-independent project that is subtree bound to our tree. The\narrangement had merit in early days, back when git itself and gitk\ncould have different release cadence, but in practice, I haven't\nseen gitk separately issuing freestanding releases to end users (or\nend-users installing versions of gitk independent from the version\nof git they have, for that matter), so perhaps the separate tree\narrangement has outlived its usefulness? I dunno.\n\nThanks.\n"},{"id":"507442","messageId":"5ccc1943-c2a3-4896-a858-aa5fd6cdd426@kdbg.org","threadId":"54973","inReplyTo":"ZzWkgblaoWehC0kY@thinks.paulus.ozlabs.org","subject":"Gitk maintainership, was Re: The health of gitk","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2024-11-17T15:26:41Z","receivedAt":"2024-11-17T15:26:56Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 14.11.24 um 08:19 schrieb Paul Mackerras:\n> On Wed, Nov 13, 2024 at 08:41:42AM +0100, Johannes Schindelin wrote:\n>> Hi Hannes,\n>>\n>> I would like to offer this thread as Exhibit A in support for the case I\n>> started making at [GitMerge '24](https://git-merge.com/) to convince you\n>> to consider maintaining gitk in addition to Git GUI.\n>>\n>> Having one maintainer of Git GUI and gitk would make for a quite natural\n>> fit, I would think, as both are written in Tcl/Tk, neither is used by the\n>> core Git contributors because they are GUI programs, both lower the bar\n>> for new Git users because they are GUI programs, and either would be\n>> subject for eviction from git/git unless maintained by an active\n>> volunteer.\n>>\n>> From what I see, Git GUI is in real good hands since you took over, I see\n>> reports and patches picked up quickly and the style of your replies is\n>> refreshingly constructive and friendly.\n>>\n>> This morning, I woke up to find a new PR in microsoft/git\n>> (https://github.com/microsoft/git/issues/704) that cherry-picks the patch\n>> that was offered in this here mail list thread. That patch is almost four\n>> years old, i.e. just about ready to enter pre-school and to learn how to\n>> read and write. Yet apart from Beat's confirmation that it fixes a real\n>> bug, this here patch has been treated with silence.\n>>\n>> Unfortunately, the original GitGitGadget PR had to be locked down and\n>> therefore Tobias would not be able to send another iteration even if he\n>> wanted to (which I doubt, given the experience on this mailing list).\n>>\n>> Therefore I see the need not only to revive this thread, but also to look\n>> for an active gitk maintainer.\n>>\n>> May I ask you, now in public, whether you would be potentially open to\n>> maintain gitk in addition to Git GUI? If so, I would then start a proper\n>> new thread to nominate you officially.\n> \n> If Hannes is willing to take this on, I would support that fully and I\n> would also be happy to assist. I know I was extremely slack about\n> gitk patches for a long while, but I think I have a little more free\n> time now, having retired.\n> \n> There is another issue which will need to be sorted out, which is\n> whether to persist with a separate tree that gets merged into the git\n> repository, or just edit the copy of gitk in the git repository.\n> There have been tree-wide patches applied to the git tree which\n> affected gitk, meaning that my gitk repository is now out of sync.\n> I recently (as in several weeks ago) sent Junio Hamano an email asking\n> this question, and asking for his opinion on the best way to proceed\n> with gitk patches, but got no reply.\n\n[For some reason, Dscho's original message didn't make it to my mailbox.]\n\nI have given the idea to take maintainership of Gitk ample\nconsideration, and I would accept the task. Paul, let me know how to\nproceed.\n\nRegarding whether to have a separate tree or not, I would prefer a\nseparate tree at this time, but only for the reason that it is known\nground for me, and not that it has some (technical) advantage.\n\n-- Hannes\n\n"},{"id":"507577","messageId":"Zzxhn64xeQv6ItXm@thinks.paulus.ozlabs.org","threadId":"54973","inReplyTo":"5ccc1943-c2a3-4896-a858-aa5fd6cdd426@kdbg.org","subject":"Re: Gitk maintainership, was Re: The health of gitk","fromName":"Paul Mackerras","fromEmail":"paulus@ozlabs.org","sentAt":"2024-11-19T09:59:59Z","receivedAt":"2024-11-19T10:00:06Z","isPatch":false,"sender":{"key":"paulus@ozlabs.org","avatar":"https://avatars.githubusercontent.com/u/1606439?v=4"},"body":"On Sun, Nov 17, 2024 at 04:26:41PM +0100, Johannes Sixt wrote:\n\n> I have given the idea to take maintainership of Gitk ample\n> consideration, and I would accept the task. Paul, let me know how to\n> proceed.\n\nThat's great! Thanks for taking that on.\n\n> Regarding whether to have a separate tree or not, I would prefer a\n> separate tree at this time, but only for the reason that it is known\n> ground for me, and not that it has some (technical) advantage.\n\nI think you want to clone my tree at git://git.ozlabs.org/~paulus/gitk\nand work out what to do about the commits that it lacks. Then it's a\nmatter of the usual maintainership process (e.g., apply patches,\npublish your tree somewhere, and ask Junio to pull from it).\n\nIn the current upstream git tree, I see two commits that were applied\nto a clone of my tree, then pulled into the git tree:\n\nbb5cb23daf751790950ff9f761f8884e21c88d00\n7dd272eca153058da2e8d5b9960bbbf0b4f0cbaa\n\nI assume you can pull them into your clone of my tree using suitable\ngit commands (I guess you would create a branch with 7dd272eca153 as\nits head and do git pull --ff from that).\n\nThere are three commits that touch the gitk-git directory in the git\ntree directly:\n\n65175d9ea26bebeb9d69977d0e75efc0e88dbced\nd05b08cd52cfda627f1d865bdfe6040a2c9521b5\n728b9ac0c3b93aaa4ea80280c591deb198051785\n\nI assume you want to make the same changes in your gitk tree, so as to\navoid conflicts in future. I expect git would merge commits in the\ngitk tree making the same changes as are already in the git repo\nwithout fuss.\n\nThere is also b117cee32259acf923c3ada52b4dd89f2ea6a454 which touches\ngitk-git in the 'seen' branch of the git tree. I don't know what you\nwould need to do about that, if anything.\n\nI hope that helps.\n\nRegards,\nPaul.\n\n"},{"id":"507635","messageId":"3184ac87-f53c-4b21-99ba-e3ef7fc648a7@kdbg.org","threadId":"54973","inReplyTo":"Zzxhn64xeQv6ItXm@thinks.paulus.ozlabs.org","subject":"Re: Gitk maintainership, was Re: The health of gitk","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2024-11-19T18:49:10Z","receivedAt":"2024-11-19T18:49:25Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 19.11.24 um 10:59 schrieb Paul Mackerras:\n> In the current upstream git tree, I see two commits that were applied\n> to a clone of my tree, then pulled into the git tree:\n> \n> bb5cb23daf751790950ff9f761f8884e21c88d00\n> 7dd272eca153058da2e8d5b9960bbbf0b4f0cbaa\n> \n> I assume you can pull them into your clone of my tree using suitable\n> git commands (I guess you would create a branch with 7dd272eca153 as\n> its head and do git pull --ff from that).\n> \n> There are three commits that touch the gitk-git directory in the git\n> tree directly:\n> \n> 65175d9ea26bebeb9d69977d0e75efc0e88dbced\n> d05b08cd52cfda627f1d865bdfe6040a2c9521b5\n> 728b9ac0c3b93aaa4ea80280c591deb198051785\n> \n> I assume you want to make the same changes in your gitk tree, so as to\n> avoid conflicts in future. I expect git would merge commits in the\n> gitk tree making the same changes as are already in the git repo\n> without fuss.\n> \n> There is also b117cee32259acf923c3ada52b4dd89f2ea6a454 which touches\n> gitk-git in the 'seen' branch of the git tree. I don't know what you\n> would need to do about that, if anything.\n\nThanks a lot for doing all the digging, this is very helpful. I'll\npublish the repository on Github later this week or over the weekend.\n\n-- Hannes\n\n"}]}