text:
WinUI 3.0 Alpha Template comment links

Describe the bug
The links in the comments in the code generated by the new project and new item options do not direct to the content the comment describes.
Steps to reproduce the bug

Steps to reproduce the behavior:

Create a new Blank App (WinUI UWP) project
Open MainPage.xaml.cs

There's a link in the comment in that file to https://go.microsoft.com/fwlink/?LinkId=402352&clcid=0x409
This redirects to an outdated doc that refers to Windows 8
(Yes, this is the same link that is used in the current UWP app)
There does not appear to be an appropriate Windows 10/UWP version of that document.
Remove this link (and comment) if no updated/appropriate document will be created.
If there is a plan to eventually add a document, then create an issue for it and have the link redirect to the issue until the document is created. Once the document exists the link can be redirected to that doc.
Updating the other UWP (non-WinUI) templates would be a nice improvement too but not sure where best to report this.
Also
When adding a new templated control (with the new template) the following is included in the generated *.xaml.cs file
// The Templated Control item template is documented at https://go.microsoft.com/fwlink/?LinkId=234235
That link goes to a 2.5 year old video that talks in general about Custom Controls but doesn't directly document the item template.
Adding a new CustomControl using the new template, includes the following comment in the .xaml.cs file
// The User Control item template is documented at https://go.microsoft.com/fwlink/?LinkId=234236
This link redirects to the out-dated document about Windows 8 project templates. Either redirect to an appropriate document or remove the link from the comment.
Expected behavior
Summary of above:

Don't link to docs that are known to be wrong or out of date.
Don't add links just for the sake of it.
If you want to link to a document that doesn't exist yet, put the

Version Info
Not in a NuGet package but in the templates released as the first public WinUI 3.0 Alpha templates. v3.0.0.1911010

Windows 10 version
Saw the problem?

Insider Build (xxxxx)

May 2019 Update (18362)
Yes

October 2018 Update (17763)

April 2018 Update (17134)

Fall Creators Update (16299)

Creators Update (15063)

Device form factor
Saw the problem?

Desktop
Yes

Mobile

Xbox

Surface Hub

IoT

Thanks for the detailed feedback @mrlacey. We'll address this. @SvetBonev, the same issues apply to the UWP templates that ship with VS. Do you want to open a bug to fix those, too?

As of the current 0.8 version, this has been fixed in the WinUI 3 templates -- the comment now reads
// To learn more about WinUI, the WinUI project structure,
// and more about our project templates, see: http://aka.ms/winui-project-info.

The other types mentioned ship with Visual Studio and can be reported to them here.
Closing this item.

authors: danzil krschau mrlacey


text:
Can’t scroll with Synaptics touchpad in WinUI Win32 apps

Describe the bug
This issue echoes https://github.com/microsoft/microsoft-ui-xaml/issues/2172 except it also applies to WinUI Win32. Scrolling does not work using an HP Spectre x360 that’s a few years old and does not have a precision trackpad, just like in the Windows Terminal’s issue. Windows has historically had issues with touchpad scrolling inactive windows, but here’s the bizarre part: an active WinUI Win32 window will not scroll, but an inactive window will, provided that a certain other window is active. Since this is convoluted, I will format it in a table.

Active window
Synaptics scrolling behavior

The WinUI Win32 app itself
No scrolling in WinUI Win32 app

Windows taskbar
Scrolling works in WinUI Win32 app

Any UWP app
Scrolling works in WinUI Win32 app

The desktop
No scrolling in WinUI Win32 app

Microsoft Edge (Chromium)
No scrolling in WinUI Win32 app

A different WinUI Win32 app
No scrolling in the other WinUI Win32 app

File Explorer
No scrolling in WinUI Win32 app, but File Explorer scrolls instead

Sorry if this is confusing. I was about to publish this issue before I realized that the window does scroll under certain circumstances (I have also tested this and it is true for XAML islands as well). The key takeaway, though, is that scrolling in WinUI Win32 does not function in a useful way with a Synaptics touchpad.
I assume that these are limitations in the Synaptics driver, but I would love it if WinUI Win32 apps worked just as smoothly with the touchpad as it does in UWP apps. If a UWP app is the active window, it always scrolls the correct inactive window if you mouse over it. This may not be possible, but I would expect, at the least, a patch to be applied to fix basic two-finger scrolling.
Steps to reproduce the bug
Steps to reproduce the behavior:

Attempt two-finger scroll with a Synaptics touchpad with your WinUI Win32 app active
It will not scroll
Try clicking other windows (like those described in the tab) and try using two-finger scroll on your WinUI Win32 app without clicking on it first
It may or may not scroll depending on what was focused (it’s worth pointing out that if it does scroll, it is not the same smooth experience as in UWP)

Expected behavior
I expect a WinUI Win32 app to scroll when the window is focused (must), scroll when the window is not focused (if possible), and scroll as smoothly as it does in UWP when using a Synaptics touchpad.
Version Info

NuGet package version:
Microsoft.WinUI 3.0.0-preview1.200515.3

Windows 10 version
Saw the problem?

Insider Build (xxxxx)

November 2019 Update (18363)
Yes

May 2019 Update (18362)

October 2018 Update (17763)

April 2018 Update (17134)

Fall Creators Update (16299)

Creators Update (15063)

Device form factor
Saw the problem?

Desktop
Yes

Mobile

Xbox

Surface Hub

IoT

Additional context
Using the on screen touchpad, which does successfully scroll in the WinUI Win32 app, it is apparent that the scrolling behavior is different between UWP and Win32. For example, the UWP app has a bouncing effect when scrolling to the ends. I think this warrants a separate issue, but I would like someone with a precision touchpad to test this first. Scrolling with the touch screen is identical for both.

the on screen touchpad is a PTP.
i don't think microsoft cares that win32 apps don't have overscroll or smooth scroll despite using it themselves.

Thanks for reporting this! We have some recent fixes that may address these issues. Working to repro with the latest builds; will investigate further if this is still an issue.

This affects WebView2 even in UWP applications, which is actually a win32 component - it's an easy repro if that's what you're searching for.

I believe this was fixed in Preview 3. If you still repro on Preview 3 or the upcoming Preview 4, please reactivate.

I believe this was fixed in Preview 3. If you still repro on Preview 3 or the upcoming Preview 4, please reactivate.

This is still a problem in WinUI 3

This is NOT fixed.
None of WinUI3 apps including WinUI 3 gallery app work correctly with My old Dell Inspiron 7437 note PC's touchpad. Strangely, it scrols if app is not focused though. BTW, WPF apps work fine without any problem.

source: gharchive/issue

authors: BreeceW Poopooracoocoo SKhalidQ codendone mqudsi stevewri torum

repo: microsoft/microsoft-ui-xaml

license: MIT

license_type: permissive

license_source: github-api


text:
SwipeControl (WUX/MUX) causes random crashes in ListView

Describe the bug

Scrolling down a ListView with a large number of items, each having a SwipeControl in its template, randomly triggers a crash. By "randomly" I mean the crash happens when scrolling, at some point, which varies every time. The same crash happens with:

A custom control which has the SwipeControl in its template
The Windows.UI.Xaml.Controls.SwipeControl
The Microsoft.UI.Xaml.Controls.SwipeControl (WinUI 2.4.2)

Steps to reproduce the bug

Download the repro: SwipeItemsCrashRepro.zip
Build and run the app
Scroll to the bottom, and eventually back up

NOTE: the repro uses the MarkdownTextBlock from the toolkit, which for some reason causes the crash to happen much more rapidly. Replacing it with just a TextBlock still causes the crash, but you then need to scroll up and down for quite a bit before observing the crash, for some reason.

I also prepared two crash dumps, one with the WUX control and one with the MUX one:

Crash dump with Windows.UI.Xaml.Controls.SwipeItems
Crash dump with Microsoft.UI.Xaml.Controls.SwipeItems

Expected behavior

Scrolling down the list should work as expected.
Screenshots

Version Info

NuGet package version:

Microsoft.UI.Xaml 2.4.0

Windows 10 version
Saw the problem?

Insider Build (19041.264)
Yes

November 2019 Update (18363)

May 2019 Update (18362)

October 2018 Update (17763)

April 2018 Update (17134)

Fall Creators Update (16299)

Creators Update (15063)

Device form factor
Saw the problem?

Desktop
Yes

Mobile

Xbox

Surface Hub

IoT

@Sergio0694 Thanks for reporting. If you have a standalone repro app that you can share, that would be helpful. Thanks!

Hey @ranjeshj, thank you for chiming in!
I've managed to create a minimal repro, I've added a link to the main post! 😊

Hmm.. I'm not seeing the crash with the repro app with mouse wheel scroll or touch scroll. Does it crash immediately or take a while of usage ?

Huh, that's weird. Yeah it's pretty much instantaneous for me, I can repro this 100% of the time both in my app and in the repro project I shared. You're on Windows 10 19041 too, correct?

@kikisaints Have you had a chance to try the repro to see if it crashes on your PC too?

This crashed for me right away as soon as I grabbed the scrollbar and dragged down on 19041.

Removing needs-winui-3 because I suspect this is a swipe issue and could maybe be fixed before winui3

Hey @StephenLPeters - that's amazing!
So glad to hear that, thank you for looking into this! 😊

Crash does not happen on 18363.836 with 18362 SDK.

Thanks @Felix-Dev!
It really looks like this crash is only happening starting from Windows 10 19041 🤔

@StephenLPeters @michael-hawker If you can repro this, can you share the native callstack for the crash ?

Pinging @michael-hawker in case he missed the previous notification 😄
Also @kikisaints I was wondering if the two crash dumps I shared were useful?
Can't recall if I also shared them with @ranjeshj, in case I haven't and you'd like me to forward them to you just let me know!

I mean I'm pretty sure the bug is still there 😅

@Sergio0694 it is indeed. I am able to reproduce this still.

This should be fixed in the next version of WindowsAppSDK.

authors: Felix-Dev Sergio0694 StephenLPeters bkaankose llongley michael-hawker ranjeshj


text:
WinUI 3: ICustomProperty members are not called

I implemented ICustomPropertyProvider and ICustomProperty for my view model set to DataContext.
On WinUI 3 ICustomPropertyProvider returns ICustomProperty implementation for each property but ICustomProperty members are never called. Hence UI is empty.
Steps to reproduce the bug

Clone https://github.com/xperiandri/Elmish.Uno
Check-out uno_winui branch
Launch Samples.Windows.Package project
Navigate no any page using the list on the main page

Expected behavior
WinUI calls Getter's of ICustomProperty instances
Screenshots

Version Info
NuGet package version:
[WinUI 3 - Windows App SDK 0.8: 0.8.0] If you're seeing your issue in older previews of WinUI 3, please try this release.
Windows app type:

UWP
Win32

No
Yes

Windows 10 version
Saw the problem?

Insider Build (xxxxx)

May 2021 Update (19043)
Yes

October 2020 Update (19042)

May 2020 Update (19041)

November 2019 Update (18363)

May 2019 Update (18362)

October 2018 Update (17763)

April 2018 Update (17134)

Fall Creators Update (16299)

Creators Update (15063)

Device form factor
Saw the problem?

Desktop
Yes

Xbox

Surface Hub

IoT

@chiaramooney

@alwu-msft Do you know much about ICustomPropertyProvider and its associated types?

@xperiandri Just as a disclaimer, I don't have any experience working with F# code and I'm inexplicably unable to set breakpoints on your ICustomPropertyProvider implementation, so apologies in advance for asking stupid questions.
Were you able to verify that the ICustomPropertyProvider implementation's methods were being invoked? My instinctive thought is that WinUI is unable to determine that your custom types implement ICustomPropertyProvider or ICustomProperty, which then leads me to ask how you're generating a F# WinRT projection; a missing WinRT projection would exhibit similar behavior to what you're seeing.

According to MSFT presentation from Windows Developer TAP program from November 2020 and https://github.com/microsoft/CsWinRT/issues/602 C# WinRT team state that in .NET 5 interoperability with WinRT is language agnostic

Were you able to verify that the ICustomPropertyProvider implementation's methods were being invoked?

Yes, of you set a breakpoint

But in src/Elmish.Uno/DynamicCustomProperty.fs on line

The overall implementation is uno_winui is implementation the same as in develop in

The overall implementation is uno_winui is implementation the same as in develop in src/Elmish.Uno.Uwp/ViewModel.cs

Presumably the C# version of this scenario works as expected?

After all since yesterday, yes it works as expected. But it is compiled for UWP, not WinUI .NET 5

Yeah, you're correct that Elmish.Uno.Uwp wouldn't be an analogous scenario because .NET Native has built-in WinRT projection support.
@Scottj1s Is CsWinrt projection generation truly language-agnostic? I'm trying to understand why WinUI would be able to successfully QI for an interface on one F# class (ViewModel) but not another one (DynamicCustomProperty). The best wild guess I can come up with is that the act of assigning an instance of ViewModel to the DataContext property on the CsWinrt projection of a WinUI class (e.g. Frame) causes the F# object to be put inside some kind of CsWinrt wrapper type, and so when WinUI QIs for ICustomPropertyProvider the CsWinrt wrapper is able to find and return it. However, I assume that there isn't a true WinRT projection for the ViewModel class, so when it in turn returns an instance of DynamicCustomProperty, CsWinrt doesn't come into play at all so naturally WinUI is unable to QI it for ICustomProperty. Is this a case where they simply need to manually register a bunch of type mappings with CsWinrt? Or are the missing pieces more fundamental than that?

Any updates?

@xperiandri You're correct that because CsWinrt generates CLS-compliant code any .NET language (including F# as you know) is able to consume the WinRT projections that it produces. However, that is only part of the WinRT interop story; in order for a pure F# class to advertise that it implements a WinRT interface (e.g. ICustomProperty) and have that interface be discoverable/invokable by a WinRT component (e.g. WinUI 3), there needs to be a mapping from the F# class to its WinRT projection. For C# classes, this is done automagically by the CsWinrt machinery, but as there is no equivalent FsWinrt for F# you would have to roll your own solution. Your ViewModel class is working by happenstance; assigning it to the projected FrameworkElement.DataContext property causes it to be marshalled in a way that appears to allow its ICustomPropertyProvider implementation to be discoverable by WinUI, but this is pretty specific case.
You may be able to take advantage of CsWinrt APIs to minimize the amount of code you need to write yourself, but ultimately full F# WinRT interop is simply not a scenario that we currently support (#740 is the proposal to address that).

@alwu-msft so what do I need to implement manually as a current workaround in order to make it work?

To be honest, I couldn't say because I'm very much not an expert in the area. You may be able to glean enough information from the CsWinRT documentation to determine what gaps need to be filled in.
I'm going to close this issue because this scenario requires F# support for which is already tracked by an existing issue.

authors: StephenLPeters alwu-msft xperiandri


text:
Window does not resize when being dragged between displays with different DPI

Describe the bug
The main application window does not resize itself when being dragged between displays with different DPI.
Primary is a 4K 150% DPI display.
Secondary is a FHD 100% DPI display.
Steps to reproduce the bug
1.) Create a new WinUI 3 app with the template: Blank App, Packaged (WinUI 3 in Desktop)
2.) Build and run the app
3.) Move the app between two displays with differing DPI settings
Expected behavior
The main app window should resize.
Screenshots
The main app window stays the same on all displays.
NuGet package version
1.0.0
Packaging type
Packaged (MSIX), Unpackaged
Windows version
Windows 10 version 2004 (19041, May 2020 Update)
IDE
Visual Studio 2022
Additional context
No response

This is still not fixed in https://github.com/microsoft/WindowsAppSDK/discussions/2331

For what it's worth, here's how I handled it in WinUIEx:
https://github.com/dotMorten/WinUIEx/commit/74b9de2d1a470bdf4c3d736f61d4f0a47e715d40
Basically detect WM_DPICHANGE from the windows messages, then grab the windows size, device by old dpi and multiply by new dpi.
The entire AppWindow API around window sizing should have been in device independent units. Not sure why it was exposed as uint raw pixels - no one wants to work in those units.

I appreciate your support, but bugs like this should have never made it into the first stable release. The fact that it is still not fixed nearly half a year and 3 point fixes is a real downer. Remember this is basic windowing functionality, dragging a window from one screen to another is nothing that is special.

The PR with the functionality is ready for the next shipping vehicle which is WinAppSDK 1.2. It doesn't meet the bar for 1.1 at this point because 1.1 Preview3 is practically done (and Stable is only for new supercritical crashes)
The workaround proposed by @dotMorten is correct. WM_DPICHANGE is the message that you need to listen to and resize the window based on the dpi.

@dotMorten
Did you try your fix for yourself? If i use the current WinUI3 1.0.3 and WinUIEx 1.4 in a fresh created app by just replacing the default Window base with WindowEx in MainWindow.cs and MainWindow.xaml.cs the app crashes when being dragged between monitors with different DPI settings.

@Balkoth Figured it out and published an update.

https://docs.microsoft.com/en-us/windows/win32/hidpi/wm-dpichanged
Has this always been there? I saw your implementation looks like the suggested c++ code there. I worked around it by limiting the amount of handled WM_DPICHANGED messages to 1 per 100ms an locking on the firtst receive. Will try this approach and report back.

@Balkoth Please discuss this in the linked WinUIEx issue above

@marb2000
Has the fix made it into v1.1.0? I upgraded my project and removed my workaround and the window seems to resize now.

I still would like to know if it is now safe with v1.1.2 to remove the workaround and rely on the framwork itself?

Finally, we were able to add it to 1.1.2. Feel free to open it again in case it didn't work for you.

authors: Balkoth dotMorten marb2000


text:
PosPrinter.FromIdAsync() returns null in WinUI3 app

Describe the bug
Using XF/UWP, we are successfully using the Windows.Devices.PointOfService.PosPrinting API to connect to network receipt printers.
The PosPrinter.FromIdAsync() call will popup a dialog for the user to confirm they wish to pair with the printer. From there we claim the printer, enable, and send it a print job.
Using MAUI/WinUI3, the same code with the same 'pointOfService' capability set in the manifest returns null almost instantly. No dialog is shown. I know the printer is available because I retrieved the ID using:
DeviceInformation.FindAllAsync(PosPrinter.GetDeviceSelector(PosConnectionTypes.IP));
...and I can of course run the UWP version side by side and successfully get the PosPrinter handle using the same ID once I have confirmed using the pairing dialog.
The same happens on a vanilla WinUI3 app without using MAUI.
Steps to reproduce the bug

Ensure a POS printer (such as Epson TM-M30) is connected to the network.
Create a blank WinUI3 desktop app.
Add PointOfService capability to the manifest.
Add this method to  MainWindow.xaml.cs and call PosPrinting() in the myButton_Click listener.

async void PosPrinting()
        {

            DeviceInformationCollection deviceCollection = await DeviceInformation.FindAllAsync(PosPrinter.GetDeviceSelector(PosConnectionTypes.IP));

            if (deviceCollection.Count > 0)
            {
                DeviceInformation deviceInfo = deviceCollection[0];

                PosPrinter p = await PosPrinter.FromIdAsync(deviceInfo.Id);

                if (p != null)
                {
                    Debug.WriteLine(p.DeviceId);
                }

            }
        }

p will be null.
Expected behavior
Successfully retrieve a PosPrinter object using PosPrinter.FromIdAsync(deviceInfo.Id). If first attempt to connect to the PosPrinter, first show a dialog for the user to confirm pairing.
Screenshots

NuGet package version
No response
Windows app type

[ ] UWP
[X] Win32

Device form factor
Desktop
Windows version
Windows 11 (21H2): Build 22000
Additional context
Microsoft.WindowsAppSDK versions is
1.1.3
1.2.2.220902.1.-preview1

This is what happens using the same code on UWP:


text:
mimalloc.o not available in vcpkg

According to the docs for static override we should do
> gcc -o myprogram mimalloc.o  myfile1.c ...

I am using mimalloc from vcpkg. But the mimalloc.o file is not built by the vcpkg configuration of mimalloc as the target mimalloc-obj is also not built. In fact, MIMALLOC_OBJECT_DIR is not available which is supposed to be used for obtaining mimalloc.o.
How can we use mimalloc.o in vcpkg? Ideally I would want to be able to access mimalloc.o via CMake and then link it with the target. #532 seems similar but vcpkg build process for mimalloc doesn't make mimalloc-obj target available.

To use mimalloc.o with vcpkg, follow these steps:
1.	Install mimalloc via vcpkg:
vcpkg install mimalloc

2.	Build mimalloc.o manually:
•	Clone the mimalloc repository:

git clone https://github.com/microsoft/mimalloc.git
cd mimalloc
•	Build mimalloc and generate mimalloc.o:

mkdir build
cd build
cmake ..
cmake --build . --target mimalloc

3.	Link mimalloc.o in your CMake project:

In your CMakeLists.txt, add:

target_sources(my_target PRIVATE ${CMAKE_SOURCE_DIR}/path/to/mimalloc/build/src/mimalloc.o)

	4.	Build your project:

cmake --build .

This ensures you can use mimalloc.o with static overriding and link it manually in your project.

This summary highlights the main actions required and keeps it concise for easy reading.

To use mimalloc.o with vcpkg, follow these steps: 1. Install mimalloc via vcpkg:
2.	Build mimalloc.o manually:

This does not make sense. Why build mimalloc manually in step 2 when you already installed it in step 1?
This comment, like any of yours recently, look like it's copied mostly straight out of the answer from some AI.
What's the point here?
To me, the utility of those comments is, at best, doubtful - they typically contain a lot of explanation, which overshadows any useful answer, if there even is any.
I'm not really important here, but as someone who reads the discussions & issues around mimalloc out of interest:
Please Stop.

I'm not really important here,

But you are Frank :-)  Thank you for all your help and insightful comments over time!
With regards to vcpkg -- I am not maintaining this as those scripts are part of the vcpkg repo. It would be good though if it would build the mimalloc.o file too -- not sure why that would be disabled?
(ps. I am hesitant to start maintaining the vcpkg part of mimalloc but maybe someone can help out the current maintainer?  I recently updated the CMakeFiles.txt for windows as well to generate mimalloc.dll instead of mimalloc-override.dll to be consistent across platforms; that might affect vcpkg as well)

But you are Frank :-) Thank you for all your help and insightful comments over time!

Thanks for the kind words!

(ps. I am hesitant to start maintaining the vcpkg part of mimalloc but maybe someone can help out the current maintainer? I recently updated the CMakeFiles.txt for windows as well to generate mimalloc.dll instead of mimalloc-override.dll to be consistent across platforms; that might affect vcpkg as well)

While I'm not using mimalloc through vcpkg myself, I took a quick look at it's "port":

mimalloc-override.dll doesn't seem to be mentioned at all by name, so any change to it's name would probably not affect the port.
Generally, I think the version used by the vcpkg port has to be updated manually, so I don't think you have to worry about any git changes etc. surprisingly affecting the vcpkg side.
It looks as if the vcpkg package will be assembled using cmake install... don't know if mimalloc.o is included in the set of installed files, but maybe that's worth considering?

And judging from the git log for mimallloc in vcpkg (https://github.com/microsoft/vcpkg/commits/master/ports/mimalloc) there's no singular maintainer...
That said, it looks like the "organic" approach - someone has an issue with the port, writes an issue and/or provides a patch - seemed to work out okay in the past; maybe hope it continues to do so?
There's also vcpkg's own issue tracker, so if you think anyone needs a heads-up for the next port update, maybe that could be a suitable place as well to at least leave some info for whoever may pick it up?

repo: microsoft/mimalloc


text:
Monaco Editor doesn't trigger virtual keyboard on ChromeOS

Monaco Editor doesn't trigger virtual keyboard on ChromeOS,.
Steps:
Set focus in Monaco Editor using touch.
Result:
No focus or virtual keyboard is shown
Expected:
ChromeOS virtual keyboard to be shown

Closing due to inactivity.
If this bug still applies, please create a new issue.
Unfortunately, we don't have a chromeOS device, so it is difficult for us to reproduce/investigate this issue.

authors: auchenberg hediet

repo: microsoft/monaco-editor


text:
Fixture file import path error

Hi! Just trying to understand how to get monosize working.
The fixture file example in the README imports the dist code by importing from the package name itself. When I try running it, I get Module not found: Error: Can't resolve '[package name]'. I also tried switching that out with importing directly from '../dist` instead but get the same error about being unable to resolve the path.
Debugging it, when I console.log the webpack config (the config value in bundler: webpackBundler(config => {) , I see the following:
{
  name: 'client',
  target: 'web',
  mode: 'production',
  cache: { type: 'memory' },
  externals: { react: 'React', 'react-dom': 'ReactDOM' },
  entry: '/full/path/to/packageX/dist/bundle-size/TestComponent.fixture.js',
  output: {
    filename: 'TestComponent.output.js',
    path: '/full/path/to/packageX/dist/bundle-size',
    pathinfo: true
  },
  performance: { hints: false },
  optimization: { minimizer: [], minimize: false },
  stats: { optimizationBailout: true }
}

Note the extra "dist" in the entry path - that's incorrect. Any tips? I can override, of course, but presumably I'm doing something wrong.

@benkeen monosize expects to be executed against your build artifacts i.e. results of npm run build (yarn build of a package).
The typical package.json:
{
  "name": "@foo/react-pkg",
  "version": "1.0.0",
  "module": "./dist/index.js",
  "scripts": {
    "build": "..."
  }
}

The typical workflow (I will use yarn for simplicity):

yarn workspace @foo/react-pkg build
yarn workspace monosize measure

Bundler in monosize will bundle artifacts i.e. ./dist/index.js

The error that you're seeing might happen because yarn build was not called.

I prepared fully configured Stackblitz: https://stackblitz.com/edit/stackblitz-starters-qd5ddp
You need to run:

yarn workspace test-foo build
yarn workspace test-foo bundle-size

If build won't be called first:
ModuleNotFoundError: Module not found: Error: Can't resolve 'test-foo' in '/home/projects/stackblitz-starters-qd5ddp/packages/foo/dist/bundle-size'
error Command failed with exit code 1.

Thanks @layershifter! Yes it has been built. We got it to work by entering a (seemingly) invalid import path in the fixture file. So with this structure:
/dist
/src/components/MyComponent
/bundle-size/MyComponent.fixture.js
package.json

... we entered:  import { MyComponent } from "../components/MComponent"; in the fixture file - that relative path is actually wrong from the viewpoint of the bundle-size/ folder, (it should be "../src/components/MyComponent"). But it seems that monosize copies that into fixture file into dist/bundle-size/ before running it - and the build artifacts are correct relative to that location. So that allows it to work.
I couldn't get it to run using the package name in the import line. Presumably it requires a main/module property in package.json, but even that didn't seem to help. I'm going to look again today.
Anyway, thanks!

... we entered: import { MyComponent } from "../components/MComponent"; in the fixture file - that relative path is actually wrong from the viewpoint of the bundle-size/ folder, (it should be "../src/components/MyComponent"). But it seems that monosize copies that into fixture file into dist/bundle-size/ before running it - and the build artifacts are correct relative to that location. So that allows it to work.

I would expect to use import { MyComponent } from "my-pkg", then you won't need relative paths.

I couldn't get it to run using the package name in the import line. Presumably it requires a main/module property in package.json, but even that didn't seem to help. I'm going to look again today.

Please check main/module & exports fields, they control the resolution process.

@benkeen looks like that the issue was resolved, correct? Closing it then.

I actually haven't returned to this aspect yet, but if it's still an issue I can re-post. Thanks!

(Finally!) returned to this today. Just for anyone else encountering this, I spent some time experimenting and the only way I managed to get the package content to self-reference was to do what fluent UI itself does: adding in explicit exports, like so:
{
   ...
     "exports": {
        "./dist/components/subfolder/*": "./dist/components/subfolder/*"
    }
}

The main and module entries didn't pan out. Now in my fixture file I can reference the file inside the same package (my-package-name):
import { MyComponent } from 'my-package-name/dist/components/subfolder/MyComponent';

authors: benkeen layershifter

repo: microsoft/monosize


text:
Add Configurable IPv6 Support

A new connection property IPAddressPreference is added to specify the IP preference by the client application when doing TCP connection. There are three valid types:
• IPv4First
This is the default preference. The driver will traverse IPv4 addresses first. If none of them can be connected successfully, it continues to try IPv6 addresses if there are any.
• IPv6First
The driver will traverse IPv6 addresses first. If none of them can be connected successfully, it continues to try IPv4 addresses if there are any.
• UsePlatformDefault
The driver will traverse all the IP addresses in their initial orders from DNS resolution.

Hmm, for filtering of the addresses to either ipv6 or ipv4, possibly do it in one pass using 2 member lists instead of local lists? If it makes sense to do so with the implementation. Does the address list change often?

source: gharchive/pull-request

authors: tkyc v-zhangw

repo: microsoft/mssql-jdbc


text:
Small correction

Wanted to know how 'copyTables' works and what it does. Stumbled across the 'if'

Thanks

authors: Silentapproach freddydk

repo: microsoft/navcontainerhelper


text:
[Model Compression] auto compression

Depend on #3507

~AutoCompressExperiment / AutoCompressionExperiment ?~

~AutoCompressExperiment(auto_compress_module, config, training_service) / experiment.config.module_file_path = '...' ?~

Depend on #3507

AutoCompressExperiment / AutoCompressionExperiment ?
~AutoCompressExperiment(auto_compress_module, config, training_service) / experiment.config.module_file_path = '...' ?~

AutoCompressionExperiment is better

Depend on #3507

AutoCompressExperiment / AutoCompressionExperiment ?
~AutoCompressExperiment(auto_compress_module, config, training_service) / experiment.config.module_file_path = '...' ?~

AutoCompressionExperiment is better

Rename AutoCompressXXX to AutoCompressionXXX

authors: J-shang QuanluZhang

repo: microsoft/nni


text:
Create eager-mode evaluation of onnxscript functions

(a) We would like to be able to run onnxscript functions by calling ORT to execute each primitive op. This will allow us to debug function definitions more easily.
As an example, consider the following onnxscript code fragment, which defines a gemm followed by gelu in terms of more primitive operations.
import oxs

def gemmgelu(
        A: FLOAT[2048, 16],
        W: FLOAT[16, 4096],
        Bias: FLOAT[4096]
) -> FLOAT[2048, 4096]:

    a = oxs.Constant(value_float=0.5)
    b = oxs.Constant(value_float=0.797885)
    c = oxs.Constant(value_float=0.035677)
    one = oxs.Constant(value_float=1.0)
    P1 = oxs.MatMul(A, W)
    X = oxs.Add(P1, Bias)
    T1 = oxs.Mul(X, X)
    T2 = oxs.Mul(c, T1)
    T3 = oxs.Add(b, T2)
    T4 = oxs.Mul(X, T3)
    T5 = oxs.Tanh(T4)
    T6 = oxs.Add(one, T5)
    T7 = oxs.Mul(X, T6)
    Y = oxs.Mul(a, T7)
    return Y

print(gemmgelu(a, w, b))

We would like to execute this in a standard python debugger, by calling on ORT kernels to execute each op.
Finally, we would also like to be able to use test-cases defined for the function-op (eg., from onnx) to check correctness of function definition.

Looks like this is done.

authors: gramalingam justinchuby

repo: microsoft/onnx-script


text:
Image auth UI design

Introduction
Sub item of #206
Issues / Motivations
Proposals / Solutions
Work Plan
Process Check List

[ ] Item 1
[ ] Item 2

Test cases

[ ] Test 1
[ ] Test 2

repo: microsoft/openpaimarketplace


text:
[BUG] Playwright 1.37.1 can not init

System info

Playwright Version: [v1.37.1]
Operating System: [Windows 10]
Browser: [All, Chromium, Firefox, WebKit]
Other info:

Source code

[x] I provided exact source code that allows reproducing the issue locally.

Link to the GitHub repository with the repro
or
Test file (self-contained)
using System.Threading.Tasks;
using Microsoft.Playwright;

var playwright = await Playwright.CreateAsync().ConfigureAwait(false);

Steps

[Run the test]

Expected
CreateAsync does not raise an "IOException"
Actual
CreateAsync raises an "IOException" whose details are
/*
System.IO.IOException
HResult=0x80070006
Message=The handle is invalid.
Source=System.Console
StackTrace:
at System.ConsolePal.GetBufferInfo(Boolean throwOnNoConsole, Boolean& succeeded)
at System.ConsolePal.get_WindowHeight()
at System.Console.get_WindowHeight()
at Microsoft.Playwright.Transport.StdIOTransport.StartProcessWithUTF8IOEncoding(Process process) in /_/src/Playwright/Transport/StdIOTransport.cs:line 152
*/
Notes
Seems that this problem occurred in 1.37 and that it was fixed in version 1.37.1: see https://github.com/microsoft/playwright-dotnet/issues/2663

What I don't understand is that we catch all the exceptions for WindowHeight here: https://github.com/microsoft/playwright-dotnet/blob/2d7e517e796b77519cad76a48c21caf51bbcd737/src/Playwright/Transport/StdIOTransport.cs#L150-L157
so it should from my understanding never raise this exception.

Weird..... The details of error says "line 152". This seems impossible.
Can't you find another way to determine whether there's a console or not ? I means calling a property knowning that it will raise an exception in some conditions to determine whether conditions are fulfilled is a "last chance" solution
NOTE: this playwright test was working yesterday. I changed nothing to playwright installation itself since yesterday, but my OS (windows10) may have applied some updates during the night. So, perhaps it's the behavior of "Console" that has changed and it now raises some kind of "uncatchable" exception ? (don't even know if this is possible, it's just an question...)

Could you trying to reproduce on 1.38.0? and run dotnet clean before, thanks!
We might need to iterate on 44723ec094cabb5e4c96d40c20f53f480efb8a13 657f415d3eaa05df2d3dbff0a56526aad285d6f1 or need to revert.

Same problem with 1.38 with "dotnet clean" before.
But... I'll try to explain exactly the history of what happened it might help you understanding my problem.
I was working in a "test" environement on a "Proof Of Concept" project for enhance testing our websites, including the usage of Playwright C#. Everything was fine for a while until 3 days ago when I started to get the IOException and opened this issue.
Yesterday, the team decided that the concept was prooven, and, assuming that the IOexception problem will be solved quickly, we decided to start "for real".
I set up new .net6 assemblies in an existing solution. Note that this solution includes an .NET4.8 assembly  that uses playwright in javascript mode (using "npx.cmd playwright test "xxx.spec.ts" --headed").
I've added playwright NuGet (1.38) to one of the newly created assemblies, and after few hours I was able to run a first test with c# playwright. I was thinking that I will have the IOException and.... everything was fine.
I ran a test that involve javascript Playwright and it was also fine.
Both versions (JS/C#) were working for a while (may be one hour). Then I had a "freeze" using JS version, I killed the npx process (note that it has leaved firefox browser open) and after that I got again the IOException when using C# version.
Still having the problem this morning...
So, perhaps the problem is related to some kind of conflict between JS/C# installation ?

Same error here. Using Playwright as a DI for Azure Functions:
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
using Microsoft.Playwright;

var host = new HostBuilder()
    .ConfigureFunctionsWorkerDefaults()
    .ConfigureServices(services =>
    {
        // Playwright
        var playwright = Playwright.CreateAsync().Result;
        services.AddSingleton(playwright);
    })
    .Build();

host.Run();

authors: JojoShow hermesramos mxschmitt

repo: microsoft/playwright-dotnet


text:
feat: provide jbang-catalog to run playwright cli

current docs explains how when you have a maven project you can run the cli.
with this PR you can just use jbang.
if you don't have jbang installed already see jbang.dev/downloads or just run this first:
curl -Ls https://sh.jbang.dev | bash -s - app setup

then you can do:
jbang playwright@microsoft/playwright-java codegen -o Example.java

for now you can try it with the following which runs it from my branch:
jbang playwright@maxandersen/playwright-java/jbang codegen -o Example.java

I also opened https://github.com/microsoft/playwright/pull/7696 which adds small header to generated java code
that enables you to run the generated scripts directly. if that happens you can just do jbang Example.java
Thank you

I'm getting the following error while trying to run the command from the description:
$ jbang playwright@maxandersen/playwright-java/jbang codegen -o Example.java
[jbang] Resolving dependencies...
[jbang]     Resolving com.microsoft.playwright:playwright:RELEASE...[jbang] [ERROR] Could not resolve dependency com.microsoft.playwright:playwright:RELEASE

I wonder if it has something to do with multiple versions of playwright cached on my laptop.

I wonder if it has something to do with multiple versions of playwright cached on my laptop.

Yeah, looks so, deleting ~/.m2/repository/com/microsoft/playwright resolved the issue.

Interesting - haven't seen that error. It's a standard maven syntax so should work. Would have been great to have known what you had in your folder before deleting :)
We can also set the exact version in the catalog - but you'll then need to update it on release.

Let's keep it as is, if anyone else sees the same issue we can revisit it. Updating hard-coded version is worse IMO.

authors: maxandersen yury-s

repo: microsoft/playwright-java


text:
Assigning a sprite to a player multiple times results in multiple sprites on screen

This will result in two sprites on screen:

We probably want to destroy the player's old sprite when assigning the new one. Also, reassign "move with buttons", if in use.

I like swapping controls over to the new sprite but I'd wanna push against deleting it automatically, as that's a really aggressive / not reversible action, and it kinda just pushes the error along a bit and makes it harder to debug IMO -- if they are seeing a second sprite created and are confused on why that is occurring, it's a relative easy bug to seek help with / matches with something they'll most likely have already faced (with the normal set mySprite block), but if we just delete the old one it hides the error in the moment but the sprite will still be in the wrong spot, camera follow will stop following it, along with any other things they have set for that sprite in particular (e.g. maybe they're using sprite data and all of a sudden that's just gone) -- without any clear indication that sprite itself not being there anymore / being different is the issue
and re: the not reversible one, it's not too uncommon to have a place where the player changes sprites temporarily -- swapping pieces in a puzzle game, controlling an explosive or a drone like a bombchu in zelda, etc -- if we delete the old sprite it becomes impossible to use the blocks for that sorta scenario.

Makes sense!

authors: eanders-ms jwunderl

repo: microsoft/pxt-arcade


text:
[Bug] Duplicated suggestions, typehints, docs etc.

I'm not entirely sure if it's pylance or VSCode itself, but I suspect it's pylance and hence the issue here.

 Environment data

Language Server version: 2022.7.20
OS and version: linux x64
Python version (and distribution if applicable, e.g. Anaconda): 3.8.10
python.analysis.indexing: null
python.analysis.typeCheckingMode: strict

 Code Snippet
import logging

logger = logging.getLogger(__name__)

But in general any code can be used to reproduce the error.
 Repro Steps

Open a Python project with a python file and a notebook.
Open both.
Switch from Python file to the Notebook and back.
After some seconds the typhints, autocomplete suggestions, etc. are duplicated.

 Expected behavior
Normal suggestions, typehints, docs etc.
 Actual behavior

are you using "open folder" ?

Yes, it still occurs for me with a folder open:

work around for the double hint.  in settings.json
"python.pylanceLspNotebooksEnabled": true

work around for the double hint. in settings.json
"python.pylanceLspNotebooksEnabled": true

Setting it to true does indeed fix this issue, but it reactivates #3017 as the workaround for that requires the LSP to be set to false. I guess there's no good workaround for either of them right now.

https://github.com/microsoft/pylance-release/issues/3017 should be fixed now

Hi, I came here to report the same issue. If both a Python file and a notebook are open at the same time, everything is duplicated. This happens with the pre-release version of Pylance as well.
Setting python.pylanceLspNotebooksEnabled to true does seem to fix this, but I don't feel comfortable using a setting labeled as "experimental" for my important projects. Hoping for a real fix soon. Thanks!

As of Python extension version 2022.14.0, python.pylanceLspNotebooksEnabled is now true by default and no longer considered experimental. Since this issue only repros when using our old notebooks implementation (when python.pylanceLspNotebooksEnabled is false) and we will be removing that old implementation, we have decided not to fix this issue.
If you are setting python.pylanceLspNotebooksEnabled to false, we would like to understand why and fix those issues instead.

Problem still exists. See https://github.com/microsoft/pylance-release/issues/3042 Manual setting of <python.pylanceLspNotebooksEnabled: true> solved it for me.

Same story as @cyclux. VSCode indicates that the setting doesn't exist when I was editing my settings.json but it still resolved the duplicate suggestions.

This should be a problem with the jupyter extension. You can tell if that's the case by looking in the output window. If there are tabs like so:

Then that means your jupyter extension is old.

This is my current output:
[image: Screenshot 2022-11-11 at 2.03.03 PM.png]
On Fri, Nov 11, 2022 at 2:02 PM Rich Chiodo @.***>
wrote:

This should be a problem with the jupyter extension. You can tell if
that's the case by looking in the output window. If there are tabs like so:
[image: image]
https://user-images.githubusercontent.com/19672699/201412006-a6f0fe01-e0e4-470b-8601-45b47ffa569e.png
Then that means your jupyter extension is old.
—
Reply to this email directly, view it on GitHub
https://github.com/microsoft/pylance-release/issues/3027#issuecomment-1312076909,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEZ47USJZ3CM5KNYQHR3XYTWH2J23ANCNFSM53HICD2Q
.
You are receiving this because you commented.Message ID:
@.***>

--
Best
Jack

You may have replied through e-mail. The image wasn't posted to github.

The real thing to check is your version of the Jupyter extension though. Make sure it's the latest.

Running Jupyter v2022.9.1202862440
On Fri, Nov 11, 2022 at 2:34 PM Rich Chiodo @.***>
wrote:

The real thing to check is your version of the Jupyter extension though.
Make sure it's the latest.
—
Reply to this email directly, view it on GitHub
https://github.com/microsoft/pylance-release/issues/3027#issuecomment-1312113249,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEZ47UWLWZUVWNPCZDZVUY3WH2NUBANCNFSM53HICD2Q
.
You are receiving this because you commented.Message ID:
@.***>

--
Best
Jack

The bug is fixed in the latest prerelease version:
Name: Jupyter
Id: ms-toolsai.jupyter
Description: Jupyter notebook support, interactive programming and computing that supports Intellisense, debugging and more.
Version: 2022.10.1103011060
Publisher: Microsoft
VS Marketplace Link: https://marketplace.visualstudio.com/items?itemName=ms-toolsai.jupyter

Great! Thank you for the quick responses!

@debonte thanks for answering. I switched to pre-release version of Jupyter (v2022.11.1003301027), but the Python kernel is gone.

But in this version, the Pylance duplicate suggestion issue is fixed :)

So, in this case, I chose to go back to Jupyter version v2022.9.1303220346 because the python kernel works again

The problem is in the Jupyter extension. I think I'll wait for the next stable version of Jupyter to be released to update.

authors: 4phrs Nufflee alkatar21 bschnurr bshoshany cyclux debonte jackHedaya joel-kelly rchiodo

repo: microsoft/pylance-release


text:
pylance settings, moving root up one level for type definitions

How do I add an extra path for type definitions?
I see in vscode settings there are different options. None of them do what I am hoping. I don't want to overwrite the search path set but prepend to it.
Basically I have cd'd one level below my virtual env and that's why it's not finding the library types.
e.g.
fullstackapp*>backend**
*venv with typings lives here
** vscode is opened here
If I didn't want to move my virtual environment, is there a way to add the search path in .vscode/settings.json?
I'm using pylance 2022.5.1.
The difference is a sqlalchemy type that is returned.
When VSCode is opened at the fullstackapp level, it gives me the correct type for relationship: RelationshipProperty (or a constructor thereof) but when opened at backend level, it takes me to typeshed-fallback and describes relationship: Any
Inside .vscode/settings.json, I see different options from intellisense, including python.analysis.[typeshedPaths|autoImportCompletions|autoSearchPaths|extraPaths|indexing|stubPath|typeCheckingMode], and more for python.linting and other paths.
The app runs fine. What's the easiest way to point to the types at the top level, ideally to auto-capture the venv without specifically pointing to it but to its parent? Thanks

have you tried selecting an interpreter?
https://code.visualstudio.com/docs/python/environments#_select-and-activate-an-environment

you can also use this on status bar.

Closing old issue. If this is still a problem, please reopen with the information requested. thanks

authors: GeraldRyan bschnurr heejaechang judej


text:
⚡ Feature Request for auto-import libraries from outside current working folder (e.g. from python poetry environment)

When developing with python, I am using several different repositories inside my workspace, which are all part of a bigger project. I am using poetry to manage the dependencies between repositories.
When I try to use the auto-import feature (Ctrl+.) VSCode is unable to find imports from outside the current repository.
I would like to request support for imports which are part of the current working environment even if they are located outside the current working repository, something like pycharm does.

this looks like a dup of https://github.com/microsoft/pylance-release/discussions/2614
it sounds like you are working with multiple repos that has dependency each other. people usually use multi workspace set up for it and each repo become a root of the workspaces.
if it is the same case, please upvote the discussion. if not, please, reopen this issue.

authors: fcabrita heejaechang


text:
pandas groupby doesn't accept lambda functions

Environment data

Language Server version: 2020.9.6
OS and version: Windows 10
Python version (& distribution if applicable, e.g. Anaconda): Anaconda Python 3.7.5

Expected behaviour
No error
Actual behaviour
import pandas as pd
import numpy as np

arrays = [
    ["bar", "bar", "baz", "baz", "foo", "foo", "qux", "qux"],
    ["one", "two", "one", "two", "one", "two", "one", "two"],
]

index = pd.MultiIndex.from_arrays(arrays, names=["first", "second"])

df = pd.DataFrame({"A": [1, 1, 1, 1, 2, 2, 3, 3], "B": np.arange(8)}, index=index)

g = df.groupby("A").agg(lambda x: sum(x))

print(g)

reports
No overloads for "df.groupby("A").agg(lambda x: sum(x))" match parameters
  Argument types: ((x: Unknown) -> Unknown | int)

Following seems to fix it (the changes to _typing.pyi are borrowed from the pandas source):
diff _typing.pyi.ORIG _typing.pyi
57c57,58
<
---
> FuncType = Callable[..., Any]
> F = TypeVar("F", bound=FuncType)

diff core/groupby/generic.pyi.ORIG core/groupby/generic.pyi
189c189
<     def agg(self, arg: Callable[[], Any], args, **kwargs)-> DataFrame: ...
---
>     def agg(self, arg: F, *args = ..., **kwargs = ...)-> DataFrame: ...

This issue has been fixed in version 2020.10.0, which we've just released. You can find the changelog here: https://github.com/microsoft/pylance-release/blob/master/CHANGELOG.md#2020100-7-october-2020

authors: Dr-Irv jakebailey


text:
How to deal with second-level data？

When the frequency of my data is seconds or milliseconds, how do I support it with qlib？

Currently, Qlib supports data with fixed frequency  (including  seconds or milliseconds)
We just have daily and 1min examples, you can follow the examples.
https://qlib.readthedocs.io/en/latest/component/data.html#qlib-format-dataset

repo: microsoft/qlib


text:
Allow implicit top-level namespaces when parsing files

This PR allows for implicit top-level namespaces.
Prior to this PR, all Q# had to be wrapped in namespace declarations:
namespace Foo {
  operation Main() : Unit {}
}

Now, users can optionally omit the top-level namespace declaration. This is nice, because it removes a level of necessary indentation.
If the explicit namespace declaration is omitted, the file path is used to determine the namespace name. For example, in ~/code/qsharp/project_dir/src/Foo/Bar/Baz.qs, the file:
operation Quux() : Unit {}

defines a callable in the namespace Foo.Bar.Baz.
We detect the "root" of the project by calculating the largest common prefix of the file paths. This is the most versatile approach, in my opinion, without having to introduce project-based logic into the compiler itself (that is, add a qsc_project dependency to qsc_frontend -- which would be cyclical via qsc_lint). It allows us to have a perfect UX for the happy path following a canonical project layout, and reasonable UX for other situations (e.g., manually evoking qsc on two files in different parts of your computer -- what is the "root"?).

@sezna should we update our samples to eliminate namespace declarations, since that's the recommended syntax now?

@sezna should we update our samples to eliminate namespace declarations, since that's the recommended syntax now?

Samples are tricky, because they are effectively "live" in that we point people to them online as reference. Given that, I think it's better to have the samples match features that are already shipped. That way we avoid the user trap of trying the samples and getting failures until we officially release a new feature.

A few questions to the PR description.
"We detect the "root" of the project by calculating the largest common prefix of the file paths."

What if we are compiling just one file and have no explicit project?
What if we have a project, but ALL files happen to be in "src/they/are/here"?

manually evoking qsc on two files in different parts of your computer -- what is the "root"?

What if we invoke qsc on two files that are on different drives/shares?
If we use a file qs/x/y/z/a.qs in two qsc invocations - with qs/x/y/z1/b1.qs and qs/x/y2/b2.qs, the namespace assumed for a.qs will be different?

authors: DmitryVasilevsky minestarks sezna swernli

repo: microsoft/qsharp


text:
[Error Analysis]: X axis in data explorer missing for classification outcome

I believe this was already fixed with https://github.com/microsoft/responsible-ai-widgets/pull/322

closing as it was verified this was fixed by @nushib

authors: imatiach-msft nushib

repo: microsoft/responsible-ai-widgets


text:
metro-resolver-symlinks throws error because of excludeExtraCopiesOf

What happened?
Made a brand new react native project with the react native typescript template. Installed dependencies with pnpm and added some rnx-kit stuff.
Added the symlink resolver to metro.config.js.
First error I was getting was like
MetroSymlinksResolver is not a function.
This was from the example in the readme which I copy pasted. I had to use const MetroSymlinksResolver = require('@rnx-kit/metro-resolver-symlinks').default instead.
After that I started getting react could not be found.
I followed the exception down to around here:
 * @param {string} name
 * @param {string=} projectRoot
 * @returns {string | undefined}
 */
function resolveModule(name, projectRoot) {
  const { findPackageDependencyDir } = require("@rnx-kit/tools-node/package");
  return findPackageDependencyDir(
    { name },
    { startDir: projectRoot, allowSymlinks: false }
  );
}

where allowSymlinks is hardcoded as false in @rnx-kit/metro-config.
Affected Package
@rnx-kit/metro-resolver-symlinks
Version
0.1.2
Which platforms are you seeing this issue on?

[X] Android
[X] iOS
[ ] macOS
[ ] Windows

System Information
Error: Command failed: wmic os get Caption
'wmic' is not recognized as an internal or external command,
operable program or batch file.

Well, something is messed up here.

Steps to Reproduce
Repro repo
pnpm install -g
cd MyApp
pnpm install
pnpx rnx-kit --config ./metro.config.js
The repo is basically the react native generated template, with bits taken from the /test app package in this project.
Code of Conduct

[X] I agree to follow this project's Code of Conduct

Thanks for reporting this. I was able to repro, and will work on a solution.

repo: microsoft/rnx-kit


text:
Hiding the "I fixed this!!!!" menu option.

Currently the "I fixed this!!!!" menu option is confusing to users as it is unclear about the purpose and seems to do the same thing as the suppression menu item and so this PR hides it in the vsct file.
The "I fixed this!!!!" menu item allows for users to remove an item in the error list temporarily until the end of the VS session, where it will show up again the next time the user opens VS. This user can get similar benefits from the suppression menu item and so we decided to remove for clarity.

Updated text, keeping the functionality there

repo: microsoft/sarif-visualstudio-extension


text:
implement "GetBackupEnabledEntities"

Have something similar to “GetBackupEnabledEntities” in SFX as well which would display the entity details along with the backup policies listed for the cluster.

https://github.com/microsoft/service-fabric-explorer/pull/448

https://github.com/microsoft/service-fabric-explorer/pull/448

repo: microsoft/service-fabric-explorer


text:
Fixed typo in ServiceManifest file

Fixed typo in ServiceManifest.xml files: directoy => directory

Please consider approving this as it would resolve https://github.com/microsoft/service-fabric/issues/1080

authors: WhitWaldo agronompele

repo: microsoft/service-fabric


text:
Refactor MetaSlab / MetaCommon.

MetaCommon is now gone.  The back end must provide a BackendMetadata,
which must be a subtype of MetaSlab (i.e. MetaSlab or a subclass of
MetaSlab).  It may add additional state here.
The MetaEntry is now templated on the concrete subclass of MetaSlab that
the back-end uses.  The MetaEntry still stores this as a uintptr_t to
allow easier toggling of the boundary bit but the interfaces are all in
terms of stable types now.
Also some tidying of names (SharedStateHandle is now called Backend).
In a follow-on PR, we can then remove the chunk field from the
BackendMetadata in the non-CHERI back end and allow back ends that don't
require extra state to use MetaSlab directly.

Uh, what?  I didn't press a merge button here!

Oh, ooops.  Branch protection is not on for main branch.

repo: microsoft/snmalloc


text:
Using saliency with custom nets and grayscale images

Hi,
Currently the saliency method is not working for images with a single channel (ex (1,244,244)). At some point the code seems to require three channels. This results in shape errors, etc.
Could you please help me run the saliency code with grayscale images? Thanks.

Thanks for pointing this out! Are you using MNIST data? Also, is there a specific explainer you are interested in?

I am using a custom dataset. I'm interested in saliency approaches for a modified GoogLeNet architecture (with grayscale input and custom output classes).
Do you think this will be compatible anytime soon? What sort of changes will you have to make for this?
Thanks for the prompt reply.

authors: sytelus vedantbhatia

repo: microsoft/tensorwatch


text:
startingDirectory and high WSL CPU usage

Windows Terminal version
1.12.3472
Windows build number
19043.1466
Other Software
WSL
Ubuntu-18.04 (WSL)
Steps to reproduce
Set startingDirectory to /home/username or //wsl$/Ubuntu-18.04/home/username (tried via settings UI).
Expected Behavior
WSL sessions start in desired directory.
Actual Behavior
WSL sessions do not start in desired directory and sessions use 100% CPU (shows as init process via htop and windows task manager).
This documentation page suggests using the above formats for the WSL startingDirectory; I seem to recall the //wsl$/Ubuntu-18.04/home/username format worked fine in the past.  The starting directory is set properly without the high CPU usage if the slashes are changed to backslashes (\\wsl$\Ubuntu-18.04\home\username).
Solution discovered via this WSL2 issue.

For anyone experiencing the high CPU issue, a workaround is to use backslashes instead of slashes in startingDirectory.
If you use the "open windows from previous session" as your Windows Terminal startup mode, old sessions from prior to changing the starting directory will continue to experience this issue.  Sessions created after changing the starting directory will work correctly during later Windows Terminal startups.

@cmsavage does this issue repro for you on 1.13? There are some fixes in this area in 1.13, and I'm wondering if they might help sort this out too. Might be worth backporting them.

The long form (//wsl$/Ubuntu-18.04/home/username) works in 1.13 with slashes or backslashes.  However, the "linux style paths" that are supposed to be acceptable since 1.12 do not work either way: ubuntu fails to start with \home\username ("The parameter is incorrect") and the high CPU usage still occurs with /home/username, though I do end up in the correct directory in that case.  So some improvement in 1.13, but not fully working for all the path formats the documentation claims it should.

@craigloewen-msft / @benhillis any idea what this might be?

I am on Windows Terminal v1.11.3471 and I had my starting directory set to /mnt/c/myfolder and was getting high CPU usage on init process. I switched to C:\myfolder and no longer have high CPU usage. (Both /mnt/c/myfolder and C:\myfolder values worked and started up to the correct directory.)

I confirm the same issue using the Windows Terminal 1.11.3471.0.
As a workaround I temporarily removed the startingDirectory setting and then tweaked the .zshrc / .bashrc file to jump into the home dir... Something like this: cd ~
Hope it helps someone...

This method also works and its cleaner: "startingDirectory": "\\wsl$\Ubuntu\home\username"

Nice, this works for me! Thanks. 🥳
WT 1.13.10395.0

This is tracked by MSFT:38630955 internally.

@cmsavage If you can still reproduce this bug, would you mind sharing a screenshot of the Terminal process in Task Manager with the WSL process showing and with the CommandLine attribute visible like below? Thanks!

I cannot seem to attach an image at the moment, but here are the command lines (Windows Terminal Preview 1.13.10733.0).

When setting the starting directory to /home/username, which leads to the high CPU usage:
"C:\WINDOWS\system32\wsl.exe" --cd "/home/username" -d Ubuntu-18.04
When setting the starting directory to //wsl$/Ubuntu-18.04/home/username, which works correctly:
"C:\WINDOWS\system32\wsl.exe" --cd "\\wsl$\Ubuntu-18.04\home\username" -d Ubuntu-18.04

BTW, the ability to copy info from the task manager is a feature I never knew I wanted, but does not exist.  :(

Welp. Seems like this is resolved then. Glad it went away!

authors: calexandre ccfontes cmsavage maknapp owenschupp zadjii-msft

repo: microsoft/terminal


text:
文件夹下右键在终端打开，希望从当前目录下打开wsl，Ubuntu

Windows Terminal version
1.12.10982.0
Windows build number
10.0.19044.1682
Other Software
No response
Steps to reproduce

比如我在D:\test目录下右键点击在终端打开，

打开wsl Ubuntu后，是根目录，并非windows下的目录
Expected Behavior
No response
Actual Behavior
请问该怎么设置才能是当前目录下打开

Could you share your settings.json file/?
I suspect this is because you're using the Ubuntu profile that ships with the Ubuntu app, which uses ubuntu.exe as the commandline, rather than the profile that the Terminal auto-generates, which uses wsl.exe.

Could you share your settings.json file/?
I suspect this is because you're using the Ubuntu profile that ships with the Ubuntu app, which uses ubuntu.exe as the commandline, rather than the profile that the Terminal auto-generates, which uses wsl.exe.

{
"$help": "https://aka.ms/terminal-documentation",
"$schema": "https://aka.ms/terminal-profiles-schema",
"actions":
[
{
"command":
{
"action": "copy",
"singleLine": false
},
"keys": "ctrl+c"
},
{
"command": "find",
"keys": "ctrl+shift+f"
},
{
"command": "paste",
"keys": "ctrl+v"
},
{
"command":
{
"action": "splitPane",
"split": "auto",
"splitMode": "duplicate"
},
"keys": "alt+shift+d"
}
],
"copyFormatting": "none",
"copyOnSelect": false,
"defaultProfile": "{51855cb2-8cce-5362-8f54-464b92b32386}",
"profiles":
{
"defaults": {},
"list":
[
{
"backgroundImage": "E:/shuohao/Pictures/frame.jpg",
"backgroundImageOpacity": 0.5,
"colorScheme": "One Half Dark",
"guid": "{61c54bbd-c2c6-5271-96e7-009a87ff44bf}",
"hidden": false,
"name": "Windows PowerShell",
"opacity": 80,
"useAcrylic": true
},
{
"guid": "{b453ae62-4e3d-5e58-b989-0a998ec441b8}",
"hidden": true,
"name": "Azure Cloud Shell",
"source": "Windows.Terminal.Azure"
},
{
"guid": "{e636fd95-8db6-56fc-969f-5647553fa92b}",
"hidden": false,
"name": "wsl-vpnkit",
"source": "Windows.Terminal.Wsl"
},
{
"backgroundImage": "E:\shuohao\Pictures\ubuntu-logo32.png",
"backgroundImageAlignment": "bottomRight",
"backgroundImageOpacity": 0.20000000000000001,
"backgroundImageStretchMode": "none",
"colorScheme": "Ubuntu [Dark]",
"cursorShape": "bar",
"guid": "{51855cb2-8cce-5362-8f54-464b92b32386}",
"hidden": false,
"name": "Ubuntu",
"opacity": 100,
"source": "CanonicalGroupLimited.Ubuntu_79rhkp1fndgsc",
"useAcrylic": true
}
]
},
"schemes":
[
{
"background": "#0C0C0C",
"black": "#0C0C0C",
"blue": "#0037DA",
"brightBlack": "#767676",
"brightBlue": "#3B78FF",
"brightCyan": "#61D6D6",
"brightGreen": "#16C60C",
"brightPurple": "#B4009E",
"brightRed": "#E74856",
"brightWhite": "#F2F2F2",
"brightYellow": "#F9F1A5",
"cursorColor": "#FFFFFF",
"cyan": "#3A96DD",
"foreground": "#CCCCCC",
"green": "#13A10E",
"name": "Campbell",
"purple": "#881798",
"red": "#C50F1F",
"selectionBackground": "#FFFFFF",
"white": "#CCCCCC",
"yellow": "#C19C00"
},
{
"background": "#012456",
"black": "#0C0C0C",
"blue": "#0037DA",
"brightBlack": "#767676",
"brightBlue": "#3B78FF",
"brightCyan": "#61D6D6",
"brightGreen": "#16C60C",
"brightPurple": "#B4009E",
"brightRed": "#E74856",
"brightWhite": "#F2F2F2",
"brightYellow": "#F9F1A5",
"cursorColor": "#FFFFFF",
"cyan": "#3A96DD",
"foreground": "#CCCCCC",
"green": "#13A10E",
"name": "Campbell Powershell",
"purple": "#881798",
"red": "#C50F1F",
"selectionBackground": "#FFFFFF",
"white": "#CCCCCC",
"yellow": "#C19C00"
},
{
"background": "#282C34",
"black": "#282C34",
"blue": "#61AFEF",
"brightBlack": "#5A6374",
"brightBlue": "#61AFEF",
"brightCyan": "#56B6C2",
"brightGreen": "#98C379",
"brightPurple": "#C678DD",
"brightRed": "#E06C75",
"brightWhite": "#DCDFE4",
"brightYellow": "#E5C07B",
"cursorColor": "#FFFFFF",
"cyan": "#56B6C2",
"foreground": "#DCDFE4",
"green": "#98C379",
"name": "One Half Dark",
"purple": "#C678DD",
"red": "#E06C75",
"selectionBackground": "#FFFFFF",
"white": "#DCDFE4",
"yellow": "#E5C07B"
},
{
"background": "#FAFAFA",
"black": "#383A42",
"blue": "#0184BC",
"brightBlack": "#4F525D",
"brightBlue": "#61AFEF",
"brightCyan": "#56B5C1",
"brightGreen": "#98C379",
"brightPurple": "#C577DD",
"brightRed": "#DF6C75",
"brightWhite": "#FFFFFF",
"brightYellow": "#E4C07A",
"cursorColor": "#4F525D",
"cyan": "#0997B3",
"foreground": "#383A42",
"green": "#50A14F",
"name": "One Half Light",
"purple": "#A626A4",
"red": "#E45649",
"selectionBackground": "#FFFFFF",
"white": "#FAFAFA",
"yellow": "#C18301"
},
{
"background": "#3C0315",
"black": "#282A2E",
"blue": "#0170C5",
"brightBlack": "#676E7A",
"brightBlue": "#80C8FF",
"brightCyan": "#8ABEB7",
"brightGreen": "#B5D680",
"brightPurple": "#AC79BB",
"brightRed": "#BD6D85",
"brightWhite": "#FFFFFD",
"brightYellow": "#FFFD76",
"cursorColor": "#FFFFFF",
"cyan": "#3F8D83",
"foreground": "#FFFFFD",
"green": "#76AB23",
"name": "Raspberry",
"purple": "#7D498F",
"red": "#BD0940",
"selectionBackground": "#FFFFFF",
"white": "#FFFFFD",
"yellow": "#E0DE48"
},
{
"background": "#002B36",
"black": "#002B36",
"blue": "#268BD2",
"brightBlack": "#073642",
"brightBlue": "#839496",
"brightCyan": "#93A1A1",
"brightGreen": "#586E75",
"brightPurple": "#6C71C4",
"brightRed": "#CB4B16",
"brightWhite": "#FDF6E3",
"brightYellow": "#657B83",
"cursorColor": "#FFFFFF",
"cyan": "#2AA198",
"foreground": "#839496",
"green": "#859900",
"name": "Solarized Dark",
"purple": "#D33682",
"red": "#DC322F",
"selectionBackground": "#FFFFFF",
"white": "#EEE8D5",
"yellow": "#B58900"
},
{
"background": "#FDF6E3",
"black": "#002B36",
"blue": "#268BD2",
"brightBlack": "#073642",
"brightBlue": "#839496",
"brightCyan": "#93A1A1",
"brightGreen": "#586E75",
"brightPurple": "#6C71C4",
"brightRed": "#CB4B16",
"brightWhite": "#FDF6E3",
"brightYellow": "#657B83",
"cursorColor": "#002B36",
"cyan": "#2AA198",
"foreground": "#657B83",
"green": "#859900",
"name": "Solarized Light",
"purple": "#D33682",
"red": "#DC322F",
"selectionBackground": "#FFFFFF",
"white": "#EEE8D5",
"yellow": "#B58900"
},
{
"background": "#000000",
"black": "#000000",
"blue": "#3465A4",
"brightBlack": "#555753",
"brightBlue": "#729FCF",
"brightCyan": "#34E2E2",
"brightGreen": "#8AE234",
"brightPurple": "#AD7FA8",
"brightRed": "#EF2929",
"brightWhite": "#EEEEEC",
"brightYellow": "#FCE94F",
"cursorColor": "#FFFFFF",
"cyan": "#06989A",
"foreground": "#D3D7CF",
"green": "#4E9A06",
"name": "Tango Dark",
"purple": "#75507B",
"red": "#CC0000",
"selectionBackground": "#FFFFFF",
"white": "#D3D7CF",
"yellow": "#C4A000"
},
{
"background": "#FFFFFF",
"black": "#000000",
"blue": "#3465A4",
"brightBlack": "#555753",
"brightBlue": "#729FCF",
"brightCyan": "#34E2E2",
"brightGreen": "#8AE234",
"brightPurple": "#AD7FA8",
"brightRed": "#EF2929",
"brightWhite": "#EEEEEC",
"brightYellow": "#FCE94F",
"cursorColor": "#000000",
"cyan": "#06989A",
"foreground": "#555753",
"green": "#4E9A06",
"name": "Tango Light",
"purple": "#75507B",
"red": "#CC0000",
"selectionBackground": "#FFFFFF",
"white": "#D3D7CF",
"yellow": "#C4A000"
},
{
"background": "#2E3436",
"black": "#2E3436",
"blue": "#3465A4",
"brightBlack": "#696B67",
"brightBlue": "#729FCF",
"brightCyan": "#2EC3C3",
"brightGreen": "#79C32E",
"brightPurple": "#AD7FA8",
"brightRed": "#F49797",
"brightWhite": "#EEEEEE",
"brightYellow": "#C4A000",
"cursorColor": "#FFFFFF",
"cyan": "#06989A",
"foreground": "#B5BBAE",
"green": "#4E9A06",
"name": "Ubuntu [Dark]",
"purple": "#75507B",
"red": "#AE5E5E",
"selectionBackground": "#FFFFFF",
"white": "#B5BBAE",
"yellow": "#8A7000"
},
{
"background": "#EEEEEE",
"black": "#EEEEEE",
"blue": "#729FCF",
"brightBlack": "#B5BBAE",
"brightBlue": "#3465A4",
"brightCyan": "#06989A",
"brightGreen": "#3B7505",
"brightPurple": "#75507B",
"brightRed": "#AE5E5E",
"brightWhite": "#2E3436",
"brightYellow": "#8A7000",
"cursorColor": "#2E3436",
"cyan": "#2EC3C3",
"foreground": "#696B67",
"green": "#79C32E",
"name": "Ubuntu [Light]",
"purple": "#AD7FA8",
"red": "#F49797",
"selectionBackground": "#B5BBAE",
"white": "#696B67",
"yellow": "#C4A000"
},
{
"background": "#300A24",
"black": "#171421",
"blue": "#0037DA",
"brightBlack": "#767676",
"brightBlue": "#08458F",
"brightCyan": "#2C9FB3",
"brightGreen": "#26A269",
"brightPurple": "#A347BA",
"brightRed": "#C01C28",
"brightWhite": "#F2F2F2",
"brightYellow": "#A2734C",
"cursorColor": "#FFFFFF",
"cyan": "#3A96DD",
"foreground": "#FFFFFF",
"green": "#26A269",
"name": "Ubuntu-ColorScheme",
"purple": "#881798",
"red": "#C21A23",
"selectionBackground": "#FFFFFF",
"white": "#CCCCCC",
"yellow": "#A2734C"
},
{
"background": "#000000",
"black": "#000000",
"blue": "#000080",
"brightBlack": "#808080",
"brightBlue": "#0000FF",
"brightCyan": "#00FFFF",
"brightGreen": "#00FF00",
"brightPurple": "#FF00FF",
"brightRed": "#FF0000",
"brightWhite": "#FFFFFF",
"brightYellow": "#FFFF00",
"cursorColor": "#FFFFFF",
"cyan": "#008080",
"foreground": "#C0C0C0",
"green": "#008000",
"name": "Vintage",
"purple": "#800080",
"red": "#800000",
"selectionBackground": "#FFFFFF",
"white": "#C0C0C0",
"yellow": "#808000"
}
],
"theme": "dark",
"useAcrylicInTabRow": false,
"windowingBehavior": "useExisting"
}

Could you share your settings.json file/?
I suspect this is because you're using the Ubuntu profile that ships with the Ubuntu app, which uses ubuntu.exe as the commandline, rather than the profile that the Terminal auto-generates, which uses wsl.exe.

Another problem is I didn't find this option in regedit

Okay yep, this is because the Ubuntu profile from Canonical doesn't actually respect the startingDirectory setting. We're tracking that in #12961. Sorry about that!
/dup #12961

I use this "C:\Windows\system32\wsl.exe -d Ubuntu "  it's worked

this works forme： C:\Windows\system32\wsl.exe -d Ubuntu-18.04

this works for me：
C:\Windows\system32\wsl.exe -d Ubuntu-18.04

authors: YanqingWu shuohao zadjii-msft


text:
Terminal opens new windows which can not be closed

Windows Terminal version
1.18.2822.0
Windows build number
10.0.19044.0
Other Software
nothing special I suppose
I have some custom script that run on logon, which might explain why there are more terminals opening.
Steps to reproduce

Open Terminal
Lock Windows
Unlock Windows
==> One Empty Terminal Window with no content

Expected Behavior
Terminal does not open more windows (or if it is actually my script that opens the terminals it should display them like any other window)
Actual Behavior
Each Lock/Unlock Cycle one (or more) Terminal windows are spawned.
The new Terminal window is not closable via the close button, but have to be terminated via Task Manager.
(or I just found another way: one has to open a new tab and then it can be closed like any other window)

This is kinda like #15936... you know what this is most definitely close enough to that.
/dup #15936
Thanks!

Yes, that pretty close.
Now I know why I was not finding it with my search keywords.

authors: DanielHabenicht zadjii-msft


text:
Terminal window titlebar is too big compared with console and other native windows apps

Steps to reproduce

Expected behavior
The Terminal titlebar size should be the same as that of other windows apps. Currently, Windows Terminal feels like a UWP app.
Actual behavior
Windows Terminal titlebar size is too big and feels like a UWP app.

I mean, the Terminal is an application that's using UWP XAML 😉
You could also try
"showTabsInTitlebar": false,
"alwaysShowTabs": true

to force the Terminal to use a standard windows titlebar.
Largely, I'm gonna close this as a /dup of #1375, as that thread has much more discussion of the design in it

to force the Terminal to use a standard windows titlebar.

The problem is not about whether or not it has tabs.
The problem is that the tabs make the titlebar frame larger and it looks odd. If it had tabs, but with a smaller titlebar frame, and with a smaller default window size, it would absolutely not be a problem.

@zadjii-msft And it's not a dupe of #1375 insofar as that issue seems like a ignore dump of complaints about terminal. None of the issues mentions the titlebar height and scaling, and this is also not acknowledged in there as well.

to force the Terminal to use a standard windows titlebar.

The problem is not about whether or not it has tabs.
The problem is that the tabs make the titlebar frame larger and it looks odd. If it had tabs, but with a smaller titlebar frame, and with a smaller default window size, it would absolutely not be a problem.

You chose not to compare the Titlebar with Google Chrome or Microsoft Edge, despite the tabs being in the titlebar...

When comparing these, Windows Terminal is actually shorter

You chose not to compare the Titlebar with Google Chrome or Microsoft Edge, despite the tabs being in the titlebar...

That's not how chrome looks like on my computer, and as far as I know, for lots of people as well, search for discussions about the flag /force-device-scale-factor=1. On a 15 inch, fullhd notebook display, which is configured by default to run at 125% scaling, UWP apps look odd, and Chromium based browsers look giant as well without the flags.
Chrome usually runs maximized. Terminal doesn't. When chrome is maximized, the tabs gets smaller.
You're right, Terminal is indeed shorter than these browsers when they aren't maximized, and when they aren't launched with the flags /force-device-scale-factor=1.

I've attached a screenshot comparing Chrome on my machine with windows terminal.

I've also attached a comparison with windows explorer, chrome with the flag, and terminal.

And as a side note, for Microsoft Edge, making the UI smaller or giving users to option to change the scaling is in actually in discussion.

I did not realise you were comparing scaled UI to 100% dpi UI.
When running at 100% dpi scaling, Chrome and Edge are still larger than Windows Terminals however.  So I don't think it is right to expect a standard height TitleBar, with tabs in them.

I did not realise you were comparing scaled UI to 100% dpi UI.

Yes, but at 100% DPI everything else on windows is then too small.
Currently, my choice is to break everything else, or to break UWP apps and run Chrome with the scaling flag.
That's why I avoid UWP apps. Is there a way to change the Terminal UI scaling only, without affecting the rest of the OS, or should I not use Windows Terminal instead?
I really don't think this issue should be closed.

I think what you're really looking for is #5911.
As soon as apps start customizing the titlebar, all bets are off as to what size the titlebar is.

Or take Spotify for an example, which doesn't even really have a titlebar:

So there's already basically no consistency here.
We've made a stylistic choice to make the titlebar of the Terminal as big as it is, because it fits the tabs we have rather nicely. Though, I acknowledge that this might not be everyone's preference, so let's make a setting for it. We're already discussing a huge number of "theming" properties in #3327, so this seems like it would be a nice fit.

@zadjii-msft Yes, #5911 is the issue. It would be interesting to have one setting to force the entire scaling as well. This is really important for me, and Windows Terminal, as all well as any other UWP app, can't be used without it.

Teams UI kind of sucks, office has gotten much worse in recent times - it used to be more compact, and windows terminal also sucks.
I won't really comment on Spotify. But at least teams and Spotify both provide a zoom option that affects the entire UI.
AFAIK both terminal and office do not provide that option.

I found this thread due to feeling that the title bar was way too big as well. I would love to be able to specify the size in px or something similar. I realize it has tabs, so it is bigger. It would be ideal if the tab size would just scale with the size of the title bar. It just feels like wasted space

I found this thread due to feeling that the title bar was way too big as well. I would love to be able to specify the size in px or something similar. I realize it has tabs, so it is bigger. It would be ideal if the tab size would just scale with the size of the title bar. It just feels like wasted space

authors: MostHated mdtauk phgmacedo zadjii-msft


text:
Transparency not passing through when using git

I'm having a hard time localizing if this is a git or windows terminal or neovim issue. But alas, here's the problem. Perhaps git for windows is setting something that it shouldn't.

nvim --version:

> nvim --version
NVIM v0.5.0-709-g4f8d98e58
Build type: RelWithDebInfo
LuaJIT 2.1.0-beta3
Compilation: C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.16.27023/bin/Hostx86/x64/cl.exe /DWIN32 /D_WINDOWS /W3 /MD /Zi /O2 /Ob1 /DNDEBUG /W3 -D_CRT_SECURE_NO_WARNINGS -D_CRT_NONSTDC_NO_DEPRECATE -DWIN32 -D_WIN32_WINNT=0x0600 -DINCLUDE_GENERATED_DECLARATIONS -DNVIM_MSGPACK_HAS_FLOAT32 -DNVIM_UNIBI_HAS_VAR_FROM -DMIN_LOG_LEVEL=3 -IC:/projects/neovim/build/config -IC:/projects/neovim/src -IC:/projects/nvim-deps/usr/include -IC:/projects/neovim/build/src/nvim/auto -IC:/projects/neovim/build/include
Compiled by appveyor@APPVYR-WIN

Features: -acl +iconv +tui
See ":help feature-compile"

   system vimrc file: "$VIM\sysinit.vim"
  fall-back for $VIM: "C:/Program Files/nvim/share/nvim"

Run :checkhealth for more info

Operating system/version: Windows 10, Version 20H2 (Build 19042.546)
Terminal name/version: Windows Terminal v1.3.2651.0

Actual behavior
** Note the black background which should be transparent ** when using normal git operations

Note the black background surrounded by the transparent border (which should be the actual background)
Expected behavior
Normally using nvim (no issues w.r.t background transparency)

This is another instance of the color banding issue described here. Specifically, it looks like Vim for Windows is explicitly requesting a black background.

@DHowett just checked the troubleshooting docs and that color banding and I'm not sure if it's really related. Whatever, I couldn't get it to work with my use case:
I am using neovim/nvim and face a similar issue. Windows Terminal seems to respect a set bgcolor and treat it as opaque instead of setting all defined backgrounds as transparant.
So is this intended by design? If yes, what would be the motivation behind that. Should be open a new issue or what are the next steps?
For other driving by, I could fix this by just turning off the set bg color and redefine on Windows Terminal level but this is just a very hacky work around no one should aim for.
Here the issue: https://github.com/neovim/neovim/issues/13065#issuecomment-753789430

@DHowett just checked the troubleshooting docs and that color banding and I'm not sure if it's really related. Whatever, I couldn't get it to work with my use case:
I am using neovim/nvim and face a similar issue. Windows Terminal seems to respect a set bgcolor and treat it as opaque instead of setting all defined backgrounds as transparant.
So is this intended by design? If yes, what would be the motivation behind that. Should be open a new issue or what are the next steps?
For other driving by, I could fix this by just turning off the set bg color and redefine on Windows Terminal level but this is just a very hacky work around no one should aim for.
Here the issue: https://github.com/neovim/neovim/issues/13065#issuecomment-753789430

authors: DHowett desmap musm


text:
Settings dialog

Description of the new feature/enhancement
Instead of spending time creating settings in json, documenting settings, fielding bug reports from people who can't find settings in json, and describing how to use the settings in json, how about creating the json file ONCE in entirety, and (optional) using it to create a settings dialog?
Proposed technical implementation details (optional)

Instead of shipping a json file with like 2 out of the hundreds of options and then spending time documenting the possible options and values, put all the options in the json with descriptions of the values.

Having created the json, second phase is to use it for populating a settings dialog in the program.

Please search before filing new issues.
/dup #1564
/dup #6800

authors: aybiss zadjii-msft


text:
Add adjustOpacity action

Adds an action which can be used to change the opacity at runtime. This is a follow up to some of the other work I had been doing around opacity and settings previewing at the end of the year.

edit: pseudo-spec

adjustOpacity:

"opacity": (required) an integer number to set the opacity to.
"relative": (defaults to false)

If false, set the opacity to the given value, which should be between [0, 100].
If true, then use opacity as a relative adjustment to the current opacity. So the implementation would get the current opacity for this pane, then add this action's opacity to that value. Should be between [-100, 100]

This would allow both setting exactly 25% opacity with an action, and binding an action that increases/decreases the opacity one {amount}

It's preview-able too, which is neat.

[x] Closes #11205
[x] I work here
[x] Docs updated: https://github.com/MicrosoftDocs/terminal/pull/477

Specifically that adjustFontSize with delta:5 is a relative change, whereas adjustOpacity with opacity:5 is a "set" change. Maybe relative should default to true?

That's the one I'm most amenable to here.

can we update adjustFontSize to operate the same way?

Already planning on it - I want a bunch of actions that are good for previewing, so I'm thinking of adding a pile of adjustFontSize(8), adjustFontSize(12), adjustFontSize(16), adjustFontSize(24) (etc) entries to a "Set Font Size..." menu in the command palette

Already planning on it - I want a bunch of actions that are good for previewing, so I'm thinking of adding a pile of adjustFontSize(8), adjustFontSize(12), adjustFontSize(16), adjustFontSize(24) (etc) entries to a "Set Font Size..." menu in the command palette

hmmmmmm
when I see things like this, i feel like we're missing a layer of abstraction -- each one of these is an individual action, each one shows up in the list of bindable actions, and each one is a bit more cognitive overhead.
Are we doing that just to make it previewable?

discussion: we're defaulting to relative:true

Want to file a follow-up for updating adjustFontSize? Ideally, that change would be released alongside this one imo.

#9818 notes this. I suppose I can work on that. Easy enough.

authors: DHowett zadjii-msft


text:
Replace casting 0 to a pointer with nullptr.

Summary of the Pull Request
When I did my last PR that was merged, the PR #4960, there were two more cases I forgot to include, so I included them here, for the sake of consistency and completion

References
PR #4690

PR Checklist

[X] CLA signed. If not, go over here and sign the CLA
[X] Tests added/passed

Detailed Description of the Pull Request / Additional comments
Replacing pointer casts to 0 with nullptr in two tests.

Validation Steps Performed
Manual Testing
Automated Testing

100% sure


text:
Spec for Improved keyboard handling in Conpty

Summary of the Pull Request
We have a number of bugs in the Terminal that all have the same singular root cause - VT input does not carry the same fidelity that Win32 input does. For Win32 applications there are certain keystrokes that simply cannot be represented with VT sequences.
This is my proposal for how we'll handle all these cases. I'm proposing a new VT sequence, which will enable the Terminal to send input with all of the information that an INPUT_RECORD might have, to conpty. There, conpty will be able to send input to the client application with the same fidelity they're used to, enabling these keys to work for those applications once again.
PR Checklist

[x] Specs #4999
[x] I work here
[x] is a spec

Detailed Description of the Pull Request / Additional comments
read the spec

Uhm I really really don't know if this is any good input but...
I personally feel like for purposes like this a protocol akin to Protobuf (or similar protocols with tagged fields) might be best suited here.
This proposal involves the transmission of 6 positional arguments as the serialized form of a struct.
But technically we're not dealing with C here, but a text protocol instead. As such we're not constrained to something like memory layouts etc., leading to situations like "CreateFile2" being necessary. Positional arguments could lead to exactly such a situation though.
Using tagged fields the wire format might look like this then:
  BOOL  bKeyDown;          // => 0
  WORD  wRepeatCount;      // => 1
  WORD  wVirtualKeyCode;   // => 2
  WORD  wVirtualScanCode;  // => 3
  union {
    WCHAR UnicodeChar;     // => 4
    CHAR  AsciiChar;       // => 5
  } uChar;
  DWORD dwControlKeyState; // => 6
} KEY_EVENT_RECORD;

^[[17;29;0;1;8;1_ --> ^[[0:17;1:29;3:1;4:8;5:1_
^[[17;29;0;0;0;1_ --> ^[[0:17;1:29;5:1_

Fields that are "empty" (e.g. 0) can be left out.
Fields that are unknown to the receiver can be ignored.
The benefit is the easier addition of new fields and deprecation of old ones.
For instance I'm not super stoked about UnicodeChar being a wchar_t. It'd be great if we could get rid of surrogate pairs by only transmitting full graphemes. If we decided to implement that we could safely add field "7" and allow supporting applications to support them.
Maybe this idea is totally overkill though, but Protobuf and friends have made my work as backend engineer a lot easier in the past and I kinda felt like this might apply to text protocols too.
It's fine to ignore this. 😄

I personally feel like for purposes like this a protocol akin to Protobuf (or similar protocols with tagged fields) might be best suited here.

I'm not sure what I think about the proposal in general, but I just wanted to point out that our parser doesn't yet support sub-parameters, and that's likely to be a bit of pain to add. We'll probably get there eventually, but I wouldn't want to hold up the keyboard work while we're waiting for that support.

@j4james Aww that's unfortunate. 😞
The parser is implemented in OutputStateMachineEngine right? I can see it uses basic_string_view<size_t>...
I imagine in the distant future this class might take a text parser instead of the readily parsed parameters. That way it could "pull" the data it needs (even with colons) instead of getting it pushed. Should be easier to extent for such purposes too. 🤔 But... Eh. ¯\_(ツ)_/¯

The conflicts shouldn't be hard to resolve whitelist was renamed to expect -- If you need help, I can help on Sunday.

regarding:

I don't know how I feel about the "_" terminator to the CSI. I don't have a better idea, let's say that, but it feels weird to be claiming one. I wish there was something a bit less... scarce... than single-ASCII terminators to be laying claim to.

I don't love it either, but on the bright side, it seems like as far as input is concerned, there aren't that many in use currently. There's A, B, C, D, H, F, P, Q, R, S, (from our own parser) and then I think they decided that wouldn't scale well, and decided to start putting everything else on just ~. So only those seem used currently.

@j4james You're not technically one of the team members, but as far as our VT support goes, I consider you a core contributor. I want to make sure this definitely gets your sign off as well before I go shipping the implementation PR ☺

I don't like us inventing a proprietary format, but if it has to be done, this seems OK to me. The format is bandwidth heavy, but I suppose that's unavoidable given all the info you want to send. I also have a suspicion that passing an INPUT_RECORD from one machine to another might not work as well as you imagine, but that's just a hunch. If it's a problem we'll find out soon enough.
Regarding the _ final char. it's worth noting that it is actually used in one of the SCO keyboard modes (Ctrl+Shift+F10 is CSI _), so if you're worried about that sort of conflict, then maybe we'll want to come up with something else. Realistically, though, if you want to avoid every possible conflict you'll probably need to add an intermediate char, or otherwise switch the CSI to a DCS or APC. I'm not sure if this is worth worrying about.

In my comment above I mentioned an issue with future compatibility, as I perceived it, for instance if you ever intend to add new fields (or new meaning in general). May I humbly ask if this will be an issue with this new sequence? What would happen if you have an SSH connection and either side sends an older or newer sequence? Does this spec thus (theoretically) require some kind of backward/forward compatibility? Or is that a non-issue? 🙂

I also have a suspicion that passing an INPUT_RECORD from one machine to another might not work as well as you imagine, but that's just a hunch.

That's a very valid concern. I guess I hadn't considered that the receiving and processing machine might have a different keyboard layout then the sender.
This sequence is primarily being designed to support the Terminal<->ConPTY on a local machine scenario. That being said, it definitely could be used by arbitrary client apps as well. At the bare minimum, with the current implementation, there needs to be some sort of disclaimer that these sequences reflect the input from the machine they're being generated on.
I'll noodle on this for a bit, but I'm not sure how we could go about resolving this. Adding a query/response to ask the terminal for whatever keyboard layout it has? I'm not even sure that's the only thing that would affect the input records generated.

it is actually used in one of the SCO keyboard modes

Yikes, looking at this doc, it looks like they just about claimed every final char in there. I'm not sure this is super worth worrying about. The situation this would be a problem in is if a hypothetical terminal was connected to conpty that sent input to conpty in SCO format. If that terminal was only sending input to conpty in SCO mode, it's going to have much worse problems than just Ctrl+Shift+F10 not working. If we did want to support SCO mode in the future, I'd even go so far as to say we could maybe treat a win32-input-mode sequence with no params as Ctrl+Shift+F10, considering that KEY_EVENT_RECORD{0} isn't really valid anyways.

if you ever intend to add new fields (or new meaning in general).

IMO this is a non-issue - the INPUT_RECORD format hasn't changed since before I was born, and there's NO intention by anyone on the console team to make further changes to the Win32 Console API. So I'm not worried about this :)

In case you were waiting for an official approval from me, I have nothing left to complain about. 😄

I wasn't sure the bot would let me request you as a reviewer, but I absolutely was waiting on your official approval on this 😄 I'm glad I have it! Now lets go hope this actually works over in #6309

authors: j4james jsoref lhecker zadjii-msft


text:
Improve clipboard handling in "drag and drop" scenario

Summary of the Pull Request
This PR improves the clipboard handling logic of "drag and drop" in TermControl, making it more useful and less likely to crash.

Added support for two more categories of content, ApplicationLink and WebLink.
Reordered the ifs, making StorageItem the last clause. With WT being a text-oriented application, I think we can safely assume that the content being pasted is likely to be text/links.
Catch possible exceptions during e.DataView().GetStorageItemsAsync().

PR Checklist

[X] Closes #7804
[X] CLA signed. If not, go over here and sign the CLA
[ ] Tests added/passed
[ ] Documentation updated. If checked, please file a pull request on our docs repo and link it here: #xxx
[ ] Schema updated.
[ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx

Validation Steps Performed
Manually tested.

During the development of this PR, I found that simply putting Text before StorageItem would fix the crash described in #7804, although the content being pasted isn't really useful. This is what I got which seems like a internal URI used by VSCode:
walkThrough:/c%3A/Program%20Files/Microsoft%20VS%20Code/resources/app/out/vs/workbench/contrib/welcome/page/browser/vs_code_welcome_page?%7B%22moduleId%22%3A%22vs%2Fworkbench%2Fcontrib%2Fwelcome%2Fpage%2Fbrowser%2Fvs_code_welcome_page%22%7D

But just in case there is any other possible exceptions, I added the catch anyway.
For WebLink, you can drag a hyperlink in Firefox and drop it in WT, it should work.
For ApplicationLink I didn't find an application that actually produces this kind of content, but I assume it should be the same as WebLink, so I added it alongside WebLink.

Yes! The comment is exactly what I want to add but failed to compose. You have read my mind 😄

😎


text:
Add animated shader samples

Summary of the Pull Request

Adds two simple animated shaders to the pixel shaders sample folder
Updates the readme in the pixel shaders sample folder to add a section explaining the animated shaders
Modifies some comments in existing shader samples

PR Checklist

[ ] Closes #xxx
[x] CLA signed. If not, go over here and sign the CLA
[ ] Tests added/passed
[ ] Documentation updated. If checked, please file a pull request on our docs repo and link it here: #xxx
[ ] Schema updated.
[x] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #8994

Detailed Description of the Pull Request / Additional comments
The two shaders I wrote are not especially pretty or interesting, but they should hopefully serve as simple examples for anyone looking to do animated effects. One simply draws a line of inverted pixels that scrolls down the screen, and the other fades the background back and forth between two colors.
I've added a new section to the readme explaining how the shaders work to achieve animated effects.
I've also updated the comments on the existing shaders to clear up a couple of things:

Be more explicit that Time represents seconds since the shader loaded. Though obvious in hindsight, this was not clear to me when I was first learning/experimenting
Explain that tex ranges from 0,0 to 1,1. This is important because, when trying to port GLSL shaders from shadertoy, I at first assumed fragCoord and tex are the same thing but the former actually ranges from 0,0 to the resolution of the canvas, so some of the math doesn't work out if you just substitute it with tex.

Any and all feedback welcome.

Validation Steps Performed
I ran the shaders manually in a dev build of the Terminal. I auto-spellchecked and manually proofread my additions to the readme and verifed the markdown rendering on github.

@jsoref slightly worried about the spellbot flags on this one!
hlsl and rgb are in the expect document-
(Terminal\dhowett-sl) ~\src\terminal-3.github % rg hlsl #(also rg rgb)
actions\spelling\expect\expect.txt
84:argb
1993:rgb
1994:rgba
1995:rgbi
988:hlsl
Is this a branch merge issue since the PR doesn't have 0.0.17 in?

Oh, yikes. I can't help but notice it's tried to spell check a png file, too. Should I have merged main back in to my branch before posting the PR?

Merging main would definitely help :smile: it should be an easy merge fortunately, and you're welcome to do it even after submitting!

I did consider merging from upstream but it's been a while since I've done it and I figured there were no conflicts with what I was working on and GitHub gave me a big green checkbox and everything. Lesson learned, I guess! 😬

I meant to suggest that you're going to want to force everyone with open PRs rebase onto main.
It looks like the bot is happy. And now you even have a shiny :heavy_check_mark: visible here in the PR.

@Nacimota: sorry about that. It's rare that I do something like this. The last time this would have happened here is probably when the tool was first added, and I think it actually handled that case better...
I'll have to think about how to handle this when offering this upgrade to other projects. I'll probably just leave the custom path in place instead.

@jsoref no worries! I think it's mostly just laziness on my part not merging/rebasing as a matter of course.

authors: DHowett Nacimota jsoref


text:
Unknown property: 'speak'

css attribute 'speak' is unknown.
References:
https://www.w3.org/TR/2018/NOTE-css3-speech-20180605/
https://www.w3schools.com/cssref/css_ref_aural.asp
https://www.cssportal.com/css-properties/speak.php
https://caniuse.com/#feat=speech-recognition

Closing as this package has been deprecated in favor of the official styled-components/typescript-styled-plugin fork
After updating to that fork, follow up in the styled-components repo if this is still an issue

authors: devalnor mjbvz

repo: microsoft/typescript-styled-plugin