bossanova808

(settings.json attached as requested)

I think you may be right - looking in there I see two things with the same name:

            {
                "guid": "{51855cb2-8cce-5362-8f54-464b92b32386}",
                "hidden": true,
                "name": "Ubuntu",
                "source": "CanonicalGroupLimited.Ubuntu_79rhkp1fndgsc"
            },
            {
                "font": 
                {
                    "face": "Fira Code Retina",
                    "size": 11.0
                },
                "guid": "{2c4de342-38b7-51cf-b940-2309a097f518}",
                "hidden": false,
                "name": "Ubuntu",
                "source": "Windows.Terminal.Wsl",
                "startingDirectory": "~"
            },

I don't know why - and I see that if I choose (leave chosen) the default one, it does not work, but if I manually choose the other Ubuntu, it does then work:

I can see this 'double' Ubuntu entry (one marked 'hidden', the other not) in the settings.json of two machines. On both of those, if I select the 'non-default' Ubuntu, it then works and creates the embedded tab as expected.

I have no real idea why there are two entries there - these are very vanilla WSL2/Ubuntu installations. That said there are a variety of ways of installing such, and I can't explicitly recall what method (E.g. Windows store vs. say: https://learn.microsoft.com/en-us/windows/wsl/install)

These double entires cause no issues in Windows Terminal itself, and I wonder whether you should be perhaps also hiding the 'hidden' profiles...and at least not labelling a hidden one as the default. The hidden entry is NOT the default one as identified in the settings.json file by UID (as you'll see) - so that at least is an incorrect label.

I suspect you're parsing this and using the name as the key, rather than the UID, or something like that, and the two entries are confusing things.

(But I think between the WT version change and this, we're at least getting to the heart of the issues now, and thanks for your help, it's appreciated!)

My default profile in Windows Terminal is Ubuntu (WSL2)

I create a new Windows Terminal entry in RDM:

And the profile is set to the default:

I then get:

...if I don't put in an explicit reference to wt.exe (but it does not actually work even if I do, with any wt.exe on my system including the one mentioned to download above).

Once again, I ask that you please simply properly document the steps needed to create an entry in RDM that does this - i.e. simply opens an embedded Windows Terminal tab showing the default profile (i.e. Ubuntu for me).

I do understand WT can host multiple profiles etc, but at the moment I can only get an embedded WT using the old console host approach. Yes, that works, but it seems an overly complicated mechanism given there is a WT entry type - surely that should work?

I'm a bit confused - what then is the point of your 'Windows Terminal' entry type? As this seems to me to be completely non-functional currently.

The setting and error I get when using it is this (but this is the same for any version of wt.exe on my system):

Just to be clear - when I say it is working for me - I am using the setup as per this post: https://forum.devolutions.net/topics/42004/windows-terminalnot-working-since-update-to-20241290-64bit#192203 - which embeds the terminal in an RDM tab. It works for now at least. I guess that's the Console Host approach Nathan mentioned.

I can't get a 'Windows Terminal' entry, as such, to work, using either my regular wt.exe or this RDM version - I get a pop up window with an error.

(It would be nice if these different approaches to using Windows Terminal were documented somewhere!)

Ok, have now done this on 4 separate machines (Win 11 and one Win 10) and this fix is working on all those machines. Thanks!

Now on a second machine, worked there too.

Have only tried one machine (of 3 where I use this) - but it worked for me on that first one!

Have been using Windows Terminal outside of RDM extensively (on three machines all showing this RDM issue), with no problems (so far anyway!)

I thought it would only be a matter of time for others to run into this.

I have sent requested materials via the support case, but not heard much back yet. Fingers crossed they are working on it!

I still suspect this:

>> I see this in your Changelog and suspect it might be responsible:

>> Fixed an issue where wrong Windows Terminal would be launched in certain circumstances

But maybe check your Windows updates to see what has landed recently? Here are mine - the issues started around the 15th of May or so IIRC, so might be a clue there?

Yes the email here is fine, thanks

I saw today's version: 2024.1.30.0 64-bit - and got excited as apparently there was a Terminal related fix in it, but still no go I'm afraid.

Also not working with the 2023 version I'm afraid.

Nothing appearing under the logs there (at all?!) - perhaps something to conisder, logging all the commands you use to open external things in there, would obviously help a lot in such a scenario as this.

Hmm, no, those older versions don't solve the issue.

So either the new version somehow corrupted the setup (don't think so, and again I can't re-create a new one that works - I store my connections in a connections.xml file and have also tried to revert to prior versions of that without it solving the issue) - or some change has come along to Windows/WSL2 that RDM is not yet ready for.

This machine here at home is Win 23H2 22631.3593 and I expect my other one at work is the same.

Surely there is a way to see what is happening, some logs or something??

(Note I have also tried a bunch of new setups with Windows Terminal as the type, can't get anything to work - they all do the same 'tab appears in background then disappears' thing.)

Not completely sure which version I was on before, sorry, although I do update regularly (either when prompted by RDM itself, or every month or so I run winget upgrade)

Is there an easy way to re-install older versions without stuffing up my config - running the installers just exits with a message about a newer version being installed.

I do not run RDM with elevated priviliges - I am only using it for SSH/Windows Terminal and WinSCP and with all of those I use a private key to log in etc. (if needed, it's not on Windows Terminal/WSL obviously)

Screenshots:

(Should not that no profile works, i.e. it is not just the Ubuntu profile that doesn't work - my Powershell, Command Prompt etc. also don't work - the issue very much seems to be that RDM can't start Windows Terminal itself anymore.

Since updating to RDM 2024.1.29.0 64-bit (via winget upgrade --all), Windows Terminal support in RDM is now broken for me (on at least two machines tested so far).

I can't get it to open at all - the tab appears but is not switch to, and then a few seconds later disappears. Have been using this profile for a couple years now quite happily.

I cannot find any useful logs or visibility on what is happening in RDM.

I see this in your Changelog and suspect it might be responsible:

Fixed an issue where wrong Windows Terminal would be launched in certain circumstances

wsl.exe --update in a powershell window reports WSL is up to date, and there's no issue opening the profile in Windows terminal itself. It's a Ubuntu 22.04 installation.

Sure,

Red window is a standard SSH into a Ubuntu VPS, the yellow is a windows terminal running WSL2 Ubuntu. Note the complete absense of a scrollbar on the second window (makes no difference if there is a history or not). There _is_ a scrollbar there, it's just only half visible and black, so you get no indication it is there, and it's barely usable even if you know it is because you can't see what you're doing.

The last screenshot shows what you see if you do manage to work out it is there and grab the half bar.

(all screenshots are right to the right edge of the screen)

This seems to be working well - many thanks.

One more issue, though - the scrollbar is off screen to the right and looks it isn't there (on my 4K monitor anyhow) - I can just grab it, but versus e.g. an SSH session, it's janky.

This is great, I look forward to testing it once it becomes available.

That's great to hear.

Right, you're correct - it picks up the font, but not any changes of the size/weight (bold etc) of the font (if changed in the terminal profile). I see why you've implemented it the way you have, and that makes sense once explained - but it's certainly non obvious that it works that way and requires the custom option - so perhaps even some line of instruction there would help a lot.

Are you saying you can't reproduce the focus issues at all? The right click menu problem is intermittent, but the lack of immediate focus in a WSL2 tab is 100% reproducible here, on two machines. E.g. I have two tabs, one set up as a normal SSH into a server, the other a WSL Terminal. If I click the tab for SSH, I can immediately start typing into that window and input is accepted. If I click the tab for WSL, it does not yet accept input (clear because there is no flashing cursor as there is in WSL normally) - I have to manually click into that tab, the cursor then appears, and I can type away...

It's great to see Windows Terminal support in RDM.

Using Win 11, all up to date (RDM and Windows). Also tried on a Win 10 machine, also all up to date.

A couple of issues:

1. I am seeing consistent focus issues. Unlike every other RDM session, I have to manually click into the WSL terminal window to get focus. And before I do this, if I right click the tray menu, it pops up, but then immediately disappears as I go to select something. I have to then click in the WSL terminal window in RDM, and the right click tray menu starts to work properly again

2. The setup flow is...odd. It was only by watching you intro video carefully that I saw you have to import the profiles from WSL to then be able to successfully set a font. I assumed it would pick up the font in the WSL profile, but it did not. So I was stuck for a while until I happened to notice you were using 'custom' for the profile, which then gives an Appearance tab - not visible at all until I did this import, whilst just using the profiles. This was quite confusing and could definitely be improved.

Other than those two point, it's fabulous to have this in RDM - really very useful indeed, and much better than the older approach of using the old console host.