Open Roemer opened 7 years ago
Yeah that could get a bit annoying. Not sure how best to do it, since it will need to run the tiny shim exe to open the GUI. Typically that is handled without opening the other Window. If you close that console window, does it close the GUI app? If so it sounds like it is not opening a GUI shim but a console shim (incorrectly marked shim).
No, the GUI app stays open. I also manually created a shim with the GUI flag to make really sure it is correctly flagged.
The shim exe is a command line app I suspect. Would it be possible to have a shim exe with an invisible gui for that case?
Invisible GUI? Interesting. Not completely sure of how that would be implemented, but I like it.
There's many possibilities to achieve this. I think WinForms is easier and has a much smaller footprint than WPF. Here's a google result as a start:
This might also be worth a try:
Create a new console app then then change the "Output Type" type to "Windows Application" (done in the project properties)
I have a good idea of a path forward. Let me give it a shot. Thanks for the suggestions!
Any progress on this? I'm experiencing it with consolez, and as a workaround just stopped managing consolez install via chocolatey, but I guess "stop using the tool" is not really the workaround everyone would be happy with ;-).
Just sayin' so you knew there are more of us who find this behaviour annoying ;-)
I must be one who doesn't see this behavior pretty much at all. As an update, this is still waiting on prioritization.
I get the annoying aspect, hopefully we can get it fixed for upcoming releases.
Any update on this?
Guys, this is super annoying. Here's a real use case scenario: I use Total Commander. I also use cbucher's variation of Console2, which can be installed with:
choco install console
Installing it this way, creates a shim
. Which takes precedence before the actual executable. Except for the fact, that the shim opens a black console window which blinks and disappears immediately. This is not visible when I run console.exe
from console. But since console.exe
is console, I'm typically running it from Total Commander (so from GUI app, not from console app). And this causes the shim-blink, every single time.
I stopped managing ConsoleZ with chocolatey for that reason, super, super annoying...
Also, this pop-up seems to make the window that opens after the Shim no longer take focus. So say I open kitty, by typing kitty
into my start menu and hitting enter:
Any updates on this? This is quite annoying...
I'm joining this issue as it's really a show-stopper for me. If it was just about a console window which shortly "blinks" and disappears, I could probably live with it but as a long-term user of ConEmu console manager, it messes with my workflow. Let me explain.
ConEmu has a feature of capturing all opened console windows, so no matter how a console window is opened, it always ends up in the ConEmu where I can use all its features. Chocolatey's console shim is being captured also, of course. Every app installed using Chocolatey opens a new tab in ConEmu when executed. It looks like the following:
I have to manually close each such tab to un-mess my ConEmu. That's not very user-friendly behavior. Could we focus on this issue, please? Would you accept a PR with a fix? I can probably try to take a look at it unless anyone more experienced with Chocolatey would.
Just wanna add my two cents, that this has always tickled me wrong too. So, the code of shimgen is (and is decided to remain) closed source, but it doesn't look (from my limited POV) like there's an active maintainer? 😕 It's kinda not right to have a project with such a huge userbase set up that way. What does the license owner stand to gain by keeping it under lock and key but also neglected? Keep the license restrictive if you want, at least let the community pull some weight by enabling pull requests. Is the problem that shimgen uses some sort of secret windows API that's under NDA? In such a case, couldn't chocolatey use a different shim implementation? I googled for this issue and didn't realize for a while that I was reading a chocolatey competitor's repo where they talk about using a different impl. In fact, I just came across this too but am not sure how to interpret the response. Is there a laundry list of subtle requirements shimgen must meet to work properly with no reliable way to test them, making it dangerous to accept crowdsourced modifications?
I'm going to preface this by saying that I don't actually know all of this for sure, and that some of this is speculation/extrapolation.
but it doesn't look (from my limited POV) like there's an active maintainer? 😕
It is created by RealDimensions Software LLC, which as far as I know is pretty much Rob Reynolds/Ferventcoder, so the same person that created Chocolatey and is the person who wrote a lot of the choco. So basically, this is maintained alongside choco, just in a closed source manner.
Choco has had very little development work done since early 2019, and similarly, this has not had very much done since a bit before then. As far as I can tell, they have been instead focused on working on Chocolatey.org and things related to Chocolatey licensed editions.
What does the license owner stand to gain by keeping it under lock and key but also neglected?
IMO, there have not been large issues with shimgen recently, the large things were pretty much ironed out. I think that there are much larger issues with choco to sort out before working on shimgen.
Is the problem that shimgen uses some sort of secret windows API that's under NDA?
🤷
In the readme for this repository they basically say that the reason that shimgen is not open source is not going to be publicly revealed.
I speculate that shimgen was created before chocolatey for business was envisioned, and thus, having shimgen closed source is a method to help make some money while still being able to mostly work on open source software, notice in the license that it talks about being able to pay for getting a license to use shimgen for a non-open source project. And that shimgen is doing something at least slightly clever (at least at the time), so unless someone else figured it out, then this is a unique software, unlike some other things which lots of people could make given enough time and resources.
In such a case, couldn't chocolatey use a different shim implementation?
IMO, yes. It would require work, but it is quite doable.
Based on some changes happening to the Chocolatey repositories, this issue has been moved from the chocolatey/shimgen repository to the chocolatey/home repository.
For some UI applications, a dos window pops up for a moment before the actual windows is shown. Example: Install sysinternals (with choco), create a shortcut on desktop or taskbar, start the app. Not sure, but maybe it also has something to do with CLink installed.
Another +1 from me. This is super annoying if you are using the new Windows Terminal and enabled it to replace cmd. If you have a minimized terminal, or one in the background somewhere, then when you start a shim'd app, that terminal is forced into the forground, as a new tab is created and then instantly removed.
Install it with scoop, no problems.
When I open a gui application shim, it first quickly opens a console window. This can be very annoying when using an alternative console like ConEmu which then everytime gets a new tab.
┆Issue is synchronized with this Gitlab issue by Unito