Git: Git GUI pinned to taskbar appears as "Wish Application"

[daveheq]

I just installed Git for Windows (defaults) and when I pin Git GUI to the taskbar, closing it shows a genie lamp named "Wish Application", and when I click the icon to open Git GUI, it opens some empty Wish box and a box under it with command line (not like Git Bash, it's like white Notepad).

What is going on? I've never had the Wish Application, I was using Git Extensions and msysgit and Git GUI was fine, but Git for Windows uninstalled/dereferenced it and I'm not sure how to fix this.

git version 2.8.1.windows.1

[shiftkey]

@daveheq screenshot?

[daveheq]

[shiftkey]

I've never heard of this Wish Application, and even Google isn't helping me understand it, so I'm curious and a bit concerned about where this is coming from.

A couple of questions:

• Did you use the official installer from the Releases page? If not, which source?
• Which OS are you running?
• If you open PowerShell and run this command does it show you anything interesting?

Get-WmiObject -Class Win32_Product | Where-Object { $_.Name -like "*Wish*" }

[daveheq]

• I downloaded from here (Google search): https://git-scm.com/download/win
• I'm using Windows 7 Pro 64-bit
• I don't have PowerShell

I uninstalled Git for Windows and downloaded from the Releases page

[daveheq]

I just installed it from the Releases page and it's doing the same thing.

[shiftkey]

Was able to reproduce this on Win7 64-bit with Git-2.8.1-64-bit.exe. Seems to be isolated to the Git GUI executable:

Nothing evident in the file's properties about this "Wish Application":

Probably something related to packaging git-gui. I'll let @dscho chime in here, but I don't think it's as serious as first thought.

@daveheq do you know what version of Git were you running before this?

[daveheq]

I had Git-1.9.4-preview20140929.exe installed previously. Git GUI would behave just like any other Windows app.

The problem now is I can't open Git GUI by clicking the taskbar icon, it just opens these weird feather windows.

[daveheq]

This issue tracker is awesome by the way.

[daveheq]

Should I use Git-1.9.5 or an earlier version of Git-2.x?

[shiftkey]

Yep, I see something similar when launching the pinned app:

As a workaround, using a shortcut on the desktop for Git GUI works for me. You can actually pin this shortcut to the desktop, but this then shows the actual problem at play:

Opening up procmon you get a better idea of what's happening:

The first section is git-gui launching wish.exe which then runs some git commands. That seems to be the real app. The second section, I'm not so sure. This is the point where my knowledge stops, so I wish I was more help here.

Should I use Git-1.9.5 or an earlier version of Git-2.x?

I don't know how far back this goes, and given it's the first report of this I'm not sure on the urgency of this, and the work required to get it integrated with the taskbar correctly may be non-trivial. If you can live without pinning Git GUI to the taskbar then I'd suggest sticking with Git 2.x - there's lots of features and performance gains in Git 2.x that you're missing out on by reverting...

[shiftkey]

Side note: this isn't tied to a specific OS - same behaviour on Win10:

[shiftkey]

Updated the title to reflect what we've discovered.

[dscho]

I've never heard of this Wish Application

Git GUI is a Tcl/Tk script, and the shell to execute such scripts is called wish (for "WIndowing SHell", I guess).

To pin it correctly to the taskbar, I think we'll have to figure out a way how to set the RelaunchCommand property from Tcl/Tk.

[daveheq]

Pinning the Git GUI shortcut only pins the shortcut; clicking it opens another box at the end of the taskbar of the actual Git GUI interface, which is a bit out of the way and I group my related pinned apps together that I use often. So either I have to deal with a mostly-useless slot in the taskbar with the box I want at the end, or not have a pinned shortcut at all. Either way is inconvenient and adds time, and is the only app I'm having a problem with.

I could pin the previous Git GUI to the taskbar just fine without extraneous boxes and it would open the proper program in the right place, so I don't know why it's not possible now.

I had a similar problem with Eclipse and Netbeans, and I read I could just change a config file setting, but it worked (it would open the splash screen box in the taskbar at the end then close when the app would open).

[daveheq]

I found it was easier to use with the shortcut pinned to Start menu than taskbar.

[dscho]

Pinning the Git GUI shortcut only pins the shortcut

@daveheq yes, yes, I know, and I already provided the clue how to fix it: the RelaunchCommand property.

I could pin the previous Git GUI to the taskbar just fine without extraneous boxes and it would open the proper program in the right place, so I don't know why it's not possible now.

Yes, you don't know ;-)

Git GUI used to be backed by a .cmd file but now is an .exe. When spawning programs from a .cmd, the _Pin to Taskbar_ function remembers the original command-line, not so when spawning from .exe files.

[JohnEffland]

Here's a few more details on wish.exe from sysinternals running on Win 7 64 bit (showing image from git installed from Git-2.8.1-64-bit.exe):

[daveheq]

@dscho: As far as the "clue" you provided to fix it, you said "I think we'll have to figure out a way how to set the RelaunchCommand property from Tcl/Tk", so does "we" include me? I don't have the foggiest clue how to do that, and the link you left might as well be Greek to me (I don't have time to figure it out anyways unless there's just some instructions there I'm not recognizing), so I'm not even sure if that was intended for me.

As far as the taskbar spawning programs from .exe vs .cmd, every other program I have pinned came from an .exe file as far as I can tell (I either pinned them from the .exe file, its shortcut, or from the taskbar while the program was running). I'm not seeing that any of the programs I pin come from .cmd files, and I've seen in the past (like with Chrome) that shortcuts with command-line options can be pinned and behave as expected.

Let me know if you need any other details.

[dscho]

does "we" include me?

@daveheq I thought you were interested in seeing this issue resolved, so yes, I thought of "we" as "we", not as "I".

[daveheq]

Yes, I am interested in seeing it resolved, but when you say "we'll have to
figure out a way how to set the RelaunchCommand property from Tcl/Tk", I
don't think that's something I can help figure out (I'm not educated in
Windows programming and I don't have time to figure it out right now). I
just wanted to report the issue.

On Fri, Apr 22, 2016 at 12:59 AM, Johannes Schindelin <
[email protected]> wrote:

does "we" include me?

@daveheq https://github.com/daveheq I thought you were interested in
seeing this issue resolved, so yes, I thought of "we" as "we", not as "I".

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/git-for-windows/git/issues/737#issuecomment-213293087

Sent from my work computer

[dscho]

Yes, I am interested in seeing it resolved

Good.

I don't think that's something I can help figure out

Same here, for different reasons :smiley:

[daveheq]

@dscho I'm just trying to report a problem and help any way I can get it resolved, and clarify any ambiguous statements, such as your "we" statement with "clue" and "figure it out" (helping figuring it out is not the same as being interested in seeing it resolved). I hope the information here is clarified.

[dscho]

@daveheq sadly, I do not have any time left to work on this. Hopefully somebody will pick up where we (as in "you and me") left things.

[daveheq]

You don't have time, you make time.

[PhilipOakley]

You don't have time, you make time.

Is that what you meant to say? (was it rhetorical, or quizical, etc..)

I'm constantly amazed at what @dscho does achieve from his 24/7 level of contribution. Time is one thing that you can't make more of, especially if it's all allocated.

[daveheq]

It wasn't a question, it was a statement; people are constantly saying "I don't have time" (though dscho didn't say that exactly, he said he doesn't have any time left, which can mean ever), and it really comes down to them making time, so people are really using the inappropriate word. Now I wonder if dscho is just taking issue with me clearing up what he meant by "we" and "figure it out", and his disparaging comments on my ability to help with this project even if I coded in the language were neither useful nor called for.

I've upgraded to 1.9.5 by the way, which is problem-free. Something like getting the taskbar pin to work like other programs doesn't seem like a difficult thing to do, and I'm surprised it's the only program I've worked with with this "wish" problem; it's very odd, I think something was simply overlooked.

[dscho]

It's clear now that nobody will do anything about this issue, everybody is content to talk. So I close this issue.

[daveheq]

This is still an issue dscho; it's clear you don't want to fix it because you were offended by the talk, but OK, that's on you.

[dscho]

@daveheq I do not think that it is even possible for you to offend me.

What happened is this: you reported an issue, I had to estimate how important you think it is to resolve it. For such an estimate I typically take user's feedback and willingness to work at least _a little bit_ on the resolution into account.

It is quite obvious that you do not deem this important enough to tell _yourself_ to "make some time" to learn the things you need to learn to address this problem. In contrast, you seemed to be only happy to tell others what you think they should do. Yes, it took a bit more of my time than I would have liked to, but I also got several valuable conclusions out of this ticket.

In short: your actions totally agree with my assessment that this bug is not worth the effort to fix it.

[daveheq]

I'd love to work on it but that requires me learning the language which would take far more time than someone who already knows how to fix it, and that says nothing about my capability to fix it or learn the language well. I saw no reason for the issue to be closed, as it can be left open (even as the lowest priority) until someone can work on it, as is typical in these kinds of trackers. Closing it indicates you simply don't want the issue (or at least this specific issue number) revisited, so it isn't treating the issue fairly. Hopefully if someone else opens a new issue on it, it won't be closed and will simply be prioritized properly and left on the list of open issues.

[dscho]

I saw no reason for the issue to be closed, as it can be left open

If you want it open, you work on it. If you do not work on it, nobody will.

[daveheq]

Nobody will? You're predicting what everyone will do here? OK. Out.

[dscho]

Nobody will? You're predicting what everyone will do here? OK. Out.

It was a figure of speech to reflect what my experience tells me. And your reaction proved me 100% correct :stuck_out_tongue_winking_eye: