Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wrong icon gets rendered when directly running apps in terminal (double click exe to open terminal tab). #13111

Closed
AraHaan opened this issue May 16, 2022 · 7 comments
Labels
Area-DefApp Area-UserInterface Issues pertaining to the user interface of the Console or Terminal Issue-Bug It either shouldn't be doing this or needs an investigation. Priority-3 A description (P3) Product-Terminal The new Windows Terminal. Resolution-Duplicate There's another issue on the tracker that's pretty much the same thing.
Milestone

Comments

@AraHaan
Copy link

AraHaan commented May 16, 2022

Windows Terminal version

1.13.10984.0

Windows build number

10.0.22000.0

Other Software

My Discord Bot v2.1.100.

On my Discord bot, it is designed to have an application icon. However when Windows Terminal is configured to be the default console host, all terminal tabs do not render the application icon when you directly double click it's executable file to run it.

Steps to reproduce

  1. Build an .NET Console application with an *.ico file for the program's icon, then double click the built output so it launches in Windows Terminal.

Expected Behavior

For the icon of the application to be rendered on the tab. On MacOS it renders the icon just fine, however that is in Apple's terminal.

Actual Behavior

A different icon is rendered and is provided from the OS or some other application instead?

@AraHaan AraHaan added the Issue-Bug It either shouldn't be doing this or needs an investigation. label May 16, 2022
@ghost ghost added Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Needs-Tag-Fix Doesn't match tag requirements labels May 16, 2022
@zadjii-msft
Copy link
Member

zadjii-msft commented May 16, 2022

Huh. Coulda swore we were tracking this somewhere, but doesn't look like it. #10669 looks vaguely related, but that's not it.

For this to work, we'd probably need to some set of:

we need to both be able to get the info on what the icon was supposed to be, and the ability to turn icons in dll's and exe's into XAML icons.

@zadjii-msft zadjii-msft added Area-UserInterface Issues pertaining to the user interface of the Console or Terminal Product-Terminal The new Windows Terminal. Priority-3 A description (P3) Area-DefApp labels May 16, 2022
@ghost ghost removed the Needs-Tag-Fix Doesn't match tag requirements label May 16, 2022
@zadjii-msft zadjii-msft added this to the Backlog milestone May 16, 2022
@zadjii-msft zadjii-msft removed the Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting label May 16, 2022
@AraHaan
Copy link
Author

AraHaan commented May 16, 2022

Cant one use the Windows API to obtain the icon information from the program that terminal is about to run (when it determines the program is about to execute directly) in order to use that information to simulate a profile with the icon?

edit: something like https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-loadimagew

@zadjii-msft
Copy link
Member

Yea probably. Trick there is converting the HANDLE that returns into something that can be used as the source for a XAML icon. If you can figure that out, the rest of this probably isn't too hard to wire up.

@DHowett
Copy link
Member

DHowett commented May 16, 2022

@zadjii-msft I'm comfortable calling this a dupe of both of those issues. The description for "pass LNK/EXE data" suggests making a fake runtime profile for the handed-off application, and part of that would be making sure it's got the right icon. We do both, we get icons!

/dup #9458 #1504

@ghost
Copy link

ghost commented May 16, 2022

Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!

@ghost ghost closed this as completed May 16, 2022
@ghost ghost added the Resolution-Duplicate There's another issue on the tracker that's pretty much the same thing. label May 16, 2022
@DHowett
Copy link
Member

DHowett commented May 16, 2022

(Thanks for the report @AraHaan!)

@AraHaan
Copy link
Author

AraHaan commented May 16, 2022

Yea probably. Trick there is converting the HANDLE that returns into something that can be used as the source for a XAML icon. If you can figure that out, the rest of this probably isn't too hard to wire up.

On Winforms what I do is convert the HANDLE to an System.Drawing.Icon, and then convert the icon to an Bitmap, use the bitmap and icon for what I needed. I guess here could do something similar but have the bitmap saved to an temp bitmap file then try loading it as an XAML icon?

zadjii-msft added a commit that referenced this issue Aug 26, 2022
This PR by itself doesn't _really_ change much. Technically, now the Terminal will respect the Title of a `.lnk` when started for defterm, but we don't do anything else yet. Primarily, the goal of this PR is to just wire up startup info in OpenConsole to the connected Terminal. 
* This required a bit of changes in `srvinit.cpp:ConsoleEstablishHandoff` to replicate other bits of startup, where we crack open the connect message to get the relevant bits of info.
* We pack that all into a `TERMINAL_STARTUP_INFO`, which we pass along to the registered terminal application.
* `ConptyConnection` accepts the handoff, and gathers that information out of the `TERMINAL_STARTUP_INFO`
* Some other updates to the scratch sln were made to make it build again (related, but unimportant).
* This is a precursor to:
  * #13111
  * #12154
* Closes #9458
* Tested manually
* I work here
DHowett pushed a commit that referenced this issue Oct 14, 2022
This PR by itself doesn't _really_ change much. Technically, now the Terminal will respect the Title of a `.lnk` when started for defterm, but we don't do anything else yet. Primarily, the goal of this PR is to just wire up startup info in OpenConsole to the connected Terminal.
* This required a bit of changes in `srvinit.cpp:ConsoleEstablishHandoff` to replicate other bits of startup, where we crack open the connect message to get the relevant bits of info.
* We pack that all into a `TERMINAL_STARTUP_INFO`, which we pass along to the registered terminal application.
* `ConptyConnection` accepts the handoff, and gathers that information out of the `TERMINAL_STARTUP_INFO`
* Some other updates to the scratch sln were made to make it build again (related, but unimportant).
* This is a precursor to:
  * #13111
  * #12154
* Closes #9458
* Tested manually
* I work here

(cherry picked from commit 7e47f6a)
Service-Card-Id: 86230565
Service-Version: 1.15
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-DefApp Area-UserInterface Issues pertaining to the user interface of the Console or Terminal Issue-Bug It either shouldn't be doing this or needs an investigation. Priority-3 A description (P3) Product-Terminal The new Windows Terminal. Resolution-Duplicate There's another issue on the tracker that's pretty much the same thing.
Projects
None yet
Development

No branches or pull requests

3 participants