☂ Add support for UWP

Latest status update: https://github.com/flutter/flutter/issues/14967#issuecomment-1016072160

Is there any plan to add support for Windows 10/UWP? The reason I ask this is because there are almost 1billion windows 10 devices on the internet now and more that are not even on the internet.

Probably not for now, see #10881.

I would like to include myself to this feature request, it would be awesome that Flutter supported Windows 10 UWP.

This should cover Xbox One as well, which you can target in Xamarin/UWP

Yes please. Windows support would definitely be a game-changer.

this is not official, but you can check this project. https://github.com/google/flutter-desktop-embedding I think glfw is also available on windows so you can try :wink:

Man... I want real xplat :)

I was just typing up the same feature request 😉... I hope this gets some traction!
As a user with several Windows, MacOS, and Chrome OS devices in my home... the latest model Surface Pro consistently ends up being my daily driver each year; ever since the release of the SP4. Seems to be extremely popular on campus and at work now as well. However, the scant selection of high-quality UWP apps continues to be the largest sore spot for me.
I believe the elegance & ease of Flutter could potentially provide the incentive devs/corps need, to include Win10 in their multi-platform strategy... and in the process, hopefully promote Flutter to as similar a status/popularity as Java; for IT exec consideration, when selecting tools & platforms for product development.

Xamarin, Ionic etc. include UWP, so why Flutter?

Removing assignment, since this is a very broad umbrella bug. Specific subtasks are tracked in individual bugs, which will get specific assignees and milestones as usual.

Removing from the Window MVP project. We're still evaluating UWP as a target, and will likely support it eventually, but the initial focus is on enabling Win32 to limit the scope.

I think this is a mistake.  All platofrms that don't support uwp are unsupported as of January 20th 2020. Ie by the time this is ready.
It's pointless to support a legacy platform when you don't have to because the mass migration is occuring right now aggressively.
The sole focus should be uwp and wpf should be ignored.

All platofrms that don't support uwp are unsupported as of January 20th 2020

The decision to focus on Win32 APIs first are technical, not based on target platforms.

wpf should be ignored

There are currently no plans to use WPF.

Sorry, win32 should be ignored.
Why?
Because win32 limits flutter on windows platforms.  Uwp does not because by the time you have this out there will be no windows platforms supported that don't support uwp, yet there are platforms on windows that do not support win32 (arm64 which would require a rebuild entirely)

To be clear, anyone interested in contributing effort towards UWP support is still welcome and encouraged to do so.

yet there are platforms on windows that do not support win32 (arm64 which would require a rebuild entirely)

Windows 10 on ARM supports Win32, you only need to compile the application under ARM64, as is the case with UWP.

All platofrms that don't support uwp are unsupported as of January 20th 2020. Ie by the time this is ready.

Support for Windows 8.1 ends in 2023. It does not support UWP.

@stuartmorgan Hey I am interested on working on UWP support.
You mentioned above "We're still evaluating UWP as a target" - I'd like to know what you have discovered.
Thanks,
-Jake

@Kapranov98 I just finished experimenting with porting flutter to Windows 10 ARM. Win32/UWP is the least of the issues. Dart itself requires substantial changes to run on WinARM. The ARM specific code in dart was never designed to run on anything but posix'ish systems (ios, android, linux, etc). Not to mention WinARM only supports the Thumb-2 instruction set, and as I understand it the dart jit uses the ARM instruction set (although I need to get official verification of this). Getting the port to work will be a fairly substantial effort.

@Jakesays did you try enabling /appcontainer as part of your experimentation?

You mentioned above "We're still evaluating UWP as a target" - I'd like to know what you have discovered.

I'll start an initial document to collect information soon and link it from here. There aren't a lot of specifics at this point though (and once the initial document exists, things like the results of your ARM investigation would be very welcome as additions). When I say "still evaluating" I mean that we still plan to support it in the future, and as part of that will evaluate what all needs to be done. Since it's not our focus for an initial MVP, there isn't a lot of active current investigation.
Part of that will involve breaking down specific aspects, since as the comments above point to there are a number of different elements, each with their own challenges.

My ARM is healing slowly. I need to see a pysician. Mentally ready for the next steps to proceed.

Does this conversation change now that Windows 10 X is a thing? Win32 will be able to run on Windows 10 X but I think UWP will be a much better fit. Is Flutter plan to support dual screen device at all? Surface Duo and Surface Neo?

@nerocui As I understand it the Duo is an android device so I imagine Flutter would work just fine (at least on one screen). I'm not sure which CPU the Neo is running, but if it's ARM then Flutter is pretty much dead in the water. Dart currently doesn't generate compatible assembly code for winarm (winarm uses thumb-2 instructions exclusively, and IIRC Dart uses both thumb-2 and arm instructions). It would be a non-trivial undertaking to make it  work.

@JakeSays Neo use Intel Lakefield so it's x86. I'm more concerned about the UWP part of the story. On a mobile device like Neo, managed life cycle from UWP app model will come in handy. Win32 will not be ideal for battery life. Also, win32 apps on Neo will be running in a container, which is bad for performance. Targeting UWP is actually a really smart move. Both Android and iOS run managed app model, UWP should bring more consistency. Windows 8 can pretty much be ignored, none of the statistics show any meaningful market share.

@nerocui Ok then getting flutter to target UWP should be possible. The biggest issue is the lack of OpenGL support in UWP, but that should be solvable by using ANGLE underneath flutter.
I was looking in to UWP but my target was ARM/WinIOT.

@JakeSays UWP should be ok for most devices, but it's a headache for Windows on ARM. As ironic as it is, UWP(if ever comes) flutter will have to remain emulated on ARM based Windows devices. What level of completion did you achieve for the flutter/uwp port?

@nerocui I stopped working on it once I discovered the Dart issue.

While UWP is definitely desired, Win32 is definitely not going anywhere. Microsoft announced recently that they are adding Win32 support to Windows Store. Also, many games continue to be developed under the Win32 platform.

Yep, Microsoft accept Win32 app on Store and it use widely in the world than UWP. Win32 app has best performance but it has a limit in battery consumption. Win32 has only 2 states Running or Not Responding (Freeze), but UWP has more states (more friendly with mobile devices) such as Running in background, Suspended.
https://docs.microsoft.com/en-us/windows/uwp/launch-resume/app-lifecycle

Nah, something I should tell when read comments above.
Application meaning:
Win32 app is old classic app. It has best performance because it run with hardware level but it lack of new features (not relate ARM64 here)
UWP app is new style app. It not good as Win32 because it run on container for more security so it worse performance than Win32 (running more managed code than native code like Win32) but it has more new features.
https://docs.microsoft.com/en-us/windows/apps/desktop/choose-your-platform
Hardware meaning:
Microsoft call different than Google:

x86 is x86

x64 is x86_64

ARM is ARMv7

ARM64 is ARMv8

So some guys here misunderstand: ARM64 can't run Win32 app. ARM64 can run Win32 app in emulator but performance is not good, it need recomplie for better performance.

This should be a simple conversation:
As of January 14th there are 0 supported versions of windows that don't support UWP.
There is major versions of windows that don't support win32 apps being deployed to them in the store or otherwise.
Win32 is a legacy platform. If you were maintaining an older system, sure, win32 is it.  But flutter is all new code. There is 0 reason to write it for an API that is legacy and not supported on arm, when it can be written for UWP and supported everywhere where windows is supported.

But flutter is all new code.

This is not actually the case; I have spoken to people interested in add-to-app scenarios to allow adoption of Flutter in existing Win32 applications.

There is 0 reason to write it for an API that is legacy and not supported on arm, when it can be written for UWP and supported everywhere where windows is supported.

Comments above have already explained that supporting those devices is not a simple matter of Win32 vs UWP. Similarly, sandboxing restrictions that are needed for some deployments or distribution models would apply to the engine, which is a large, existing codebase, not green-field development, so there are complexities there as well.
This argument also ignores the fact that there are many people developing new code who care about install base, not supported versions. The reality is that Windows 7 is still a very substantial portion of the install base, and that's unlikely to change dramatically in the immediate future.
There are good reasons to support UWP, and as I've said several times we do plan to support it in the future. Significantly oversimplifying the tradeoffs involved in order to claim that the decision is simple won't accelerate that process, however. Again, anyone who feels strongly about UWP support is certainly welcome to contribute to the development of a UWP embedding.

@stuartmorgan are you aware of any discussions about a solution to the thumb 2 only restrictions of winarm?

@stuartmorgan  UWP can be used in win32/Winforms/WPF applications. XAML Islands are straightforward and well supported.  Win32 doesn't work on winarm as oultlined by @JakeSays. Thus your argument makes 0 sense and is not justification for flutter targeting a legacy api for the case of embedding flutter in legacy apps.
Further for all NEW development:
Windows 7 install base is dropping like a stone.  WinARM is about to shoot up massively in the next year.  Windows 7 will be < 5% of Windows market (less than 50 million devices and none of those paying for software) by July at current rates) and right there bouncing on the bottom with Windows XP and Vista (almost solely due to embedded systems where they would never roll out a new Flutter based application without replacing the OS with it because of lack of support.
Your statements and this entire approach of Win32 demonstrates a failure to understand how Windows versions expand and then drop (before endless revisions of Windows 10, all of which have UWP so this flow is irrelevant):

New version released, very slow adoption on new devices only and only in the consumer space.
(Win 7 => 10) Consumer devices are updated more quickly and market share grows.
Growth is limited by tech geeks that don't like change claiming that new version is worse than old version even though it isn't.
Businesses continue to sit on sidelines as new version gains majority market share in consumer space.
Microsoft announces retirement date of support and patches for old version of Windows as consumers start ignoring tech geeks and realize new version is vastly better than the old one. Adoption reaches about 50%.
Businesses through pressure from users that like the new version way better; software that works better on the new version; and a looming deadline for obsolesce start deploying new version on replacement hardware. Adoption reaches about 60-65%
Forward thinking IT managers start doing controlled rollouts of new version on a group by group basis.
  Market share goes from 65% to 90% in 6-8 months as the rush at the deadline for support completes.
The only systems left are embedded who pay extra for security patches because of the high cost of replacing these systems that were hardware designed for the previous OS and generally require hardware replacement.
Embedded systems start getting hacked, so businesses do cost benefit and start replacing hardware.
Only people left using OS are 3rd world countries that can't use anything else and getting hacked isn't an issue.

We're at #8 right now. If developers are targeting Windows 7 for new software they are ignorant of history. Windows 10 rollout is exactly following Windows 7 rollout before it.  There is 0 reason to target #9 because they don't roll out major software updates even with incremental flutter in win32 apps between hardware releases.
Thus:

XAML islands address your incremental win32 apps with flutter inside of them argument.
There is no logical market for targeting Windows 7 for a new application. Absolutely no one with any understanding of history and how the desktop market works between consumer and business would write a new application in win32 unless there was an absolute blocker on an API (which is highly doubtful the APIs are largely mirrored now).

Thus the flutter decision to use win32 is ridiculous and shows a complete failure to understand the Windows market. (which isn't surprising coming out of Google sadly)

@JohnGalt1717 I may be mistaken, but my issue with winarm had nothing to do with win32. Also, and this is just a suggestion, but you may want to turn down rhetoric a bit. Using terms like ignorant and making broad, unsubstantiated claims really impede getting your point across.

@JakeSays WinArm doesn't allow win32 apps to be published to the store on Arm.  (other than Office)  Aside from the compile issues.
What part of my claims isn't substantiated?  The data 100% supports my position.  By the time Flutter for desktop is ready for release on Windows, there will be 5% or less of Windows machines that can't run UWP and a ton that you can't deploy a win32 app to. (i.e. all ARM devices including Duo or Neo or whatever one runs windows, and all of the 3rd party versions that are ramping up.)
Getting flutter to run under UWP which works on WinArm and WinX64 and WinX86 shouldn't be any more difficult than win32. It also gets you spell check in text boxes etc., proper scaling based on DPI without heroics, and better culture support out of the box. (not to mention media playing is vastly better and easier than win32. I.e. I can play widevine, playready, AES encrypted video trivially with 3 lines of code in UWP. To do the same in win32 is a massive endevor. To say nothing about captions.
There's no "low hanging fruit" with win32 versus UWP.  UWP is desktop. Everything else is legacy desktop. (other than Silverlight obviously)   They're back porting UWP and it's APIs for legacy platforms to support companies not rewritting their apps. They've added XAML islands for exactly the use case outlined of adding Flutter to existing applications (and anything else UWP).
"There are A LOT of win32 systems out there NOW".
Here's how the diagram looks in September:  5% of people running windows would be locked out by September. Of that 5% virtually none of them buy software based on historical data.  By October 5% of windows users will be using it on ARM of some sort and will be locked out of Win32.
So pick your poison.
Note however when you're doing so, that the number of people locked out of UWP will continually get smaller, while the number of people locked out of Win32 will continually get larger. So you're effectively guaranteeing a rewrite in 12-24 months if you go win32 instead of UWP all for a dying market that you can't effectively support anyhow, because Microsoft isn't going to be fixing bugs in Windows 7, only security updates for those that pay for them. (which won't be using an app with flutter anyhow)
It also ensures that the Windows version of the video player will always be massively limited because of the massive lift required to get DRM to work on Win32, there won't be an inline spell checker or auto-correct for those using a software touch keyboard, and culture stuff will be way harder to get right.
This is called backwards thinking.
If you don't like the word ignorant, that's not my problem.  If you don't know the facts and history, then by definition you're ignorant.  In this case harmfully so.  If you want to use a socially correct word that hasn't be banned so be it, tell me what you'd like me to use and I'll do a find and replace.
Tell me where I'm actually wrong. And even if my assumptions and projections are slightly off, tell me how my assertion over time isn't right and less harmful and less work than the alternative which is vastly more work, vastly more bugs, and a vastly more difficult time reaching parity with other platforms over time for things like video, spell check, etc.  No matter how you slice it, by this time next year virtually no one will be using Windows 7.  And that means that Flutter will be 100% available for virtually everyone in every situation if it's done in UWP and not win32.  Versus win32 which caters to a dead OS and locks flutter devs out of the new and growing market for WinARM.
As an example, I can, right now, in UWP create a video player with all of the functionality of the current video player, plus captions plus DRM in UWP in a few minutes with excellent documentation that can be consumed by Flutter as part of the flutter video library. I know for a fact that they're working on captions and DRM for the flutter video player right now.   And I don't need to know anything but UWP calls.   That means that it's trivial to provide full video functionality in Flutter with UWP and almost any C# can do it which is a huge group of people versus those that know how to use C++, create DirectX surfaces, and create media encoders/decoders/transcoders and hook it all up. (yes, in win32 you can't play lots of formats without custom libraries that are supported out of the box in UWP)  The effort to create the same product between UWP (even if written in C++) versus win32 is about 1/100th the amount of time.
The same is true for serial communications, bluetooth, location tracking, etc. etc. etc. (and location tracking and sensor APIs are just now, in Windows 10 2020/H1, coming to win32 and won't work in previous versions of windows 10 so you're relying on everyone using the very latest version of Windows 10 to even have access to this functionality, versus 100% of users in Windows 10 having access to UWP functionality for these apis.) Name your functionality that you take for granted with plugins for flutter for Android/iOS and you'll see the same thing: Implementing them is trivial in UWP versus win32 and thus you're far more likely to get them implemented in UWP than if you write flutter for desktop in win32 aside from all of the other issues.

@johngalt1717 ok well I'm done with you. I have no interest in dealing with disrespectful people.

@JakeSays Still waiting for you to demonstrate anything disrespectful (or wrong) with what I said. From what I can tell, you just don't like a word, which I used correctly.  And, most importantly, I used it in the abstract, not against you or anyone else personally. It was not an ad homonym attack.

@stuartmorgan are you aware of any discussions about a solution to the thumb 2 only restrictions of winarm?

@JakeSays I have not been following discussions at the level of the Dart compiler; I'm not aware of discussions around ARM support, but that doesn't mean they aren't happening. You should definitely file a Dart feature request if you haven't already.

The biggest issue is the lack of OpenGL support in UWP, but that should be solvable by using ANGLE underneath flutter.

The current Windows embedding already uses ANGLE, and James has been experimenting with UWP support since the early days of his work on that embedding, so that's already well underway.

@stuartmorgan I'll do that.
And yeah I had forgot that the windows embedder is using ANGLE.

@JohnGalt1717, please review our Code of conduct. Flutter's community standards require professional and respectful discourse, and actively doing our best to make people feel welcome.
There are a lot of passionate and talented people working on Flutter, and a lot of good reasons to pursue or not pursue a particular line of development. I can tell you're passionate about having Flutter work on UWP. So are others. Some are also passionate about getting it working on win32. This is an open source project, all it takes to make it happen are contributions. In the mean time, please avoid suggesting that contributors working on alternative paths are ignorant, wasting time, or engaged in backwards thinking.
If you cannot see why your last few posts fail to rise to the level of mutual respect we aspire to in this community, please take a less active role.

@dnfield given I did none of those things I fail to see your point. I outlined factual history, and a path being taken that ensures that this will have to be rewritten, and will not reach parity with other platforms.
If you read carefully, at no point did I call anyone ignorant (which litterally means unaware of facts and is not derogitory, itself a statement of fact), nor did I accuse any individual of backwards thinking. (Ie targeting a legacy platform that cuts you off from the future while embracing a dead and increasingly irrelevant past as of January 14th)
So I fail to understand how anyone would be offended unless they decided to identify with the generality I used and I can't control that.
If you feel offended by statements not made about you then I'm sorry you feel that way.  Maybe the solution is to take my position seriously and think about it logically and demonstrate that you did indeed take these facts into account and are not ignorant of them and you have some long term plan for how win32 is going to work on windows that requires the store and that store doesn't allow publishing win32 arm apps. And that the overhead of using win32 will ensure that windows is always behind other platforms as you're cutting your possible contributors by 90+% with this choice. Then it would be clear that you are neither ignorant nor backward thinking and thus what I said shouldn't offend you.
Instead, I get "I'm offended (about something not directed at me), thus you're wrong".  Which isn't an argument in any debate.
Given that none of my position has been addressed no matter how it has been phrased, it's clear that flutter is not likely to in any timely manner be a viable solution on windows and allow parity of an application written for iOS, android and windows. Which ensures that my team will not be using flutter as planned on our next project since you're forcing us to use at least 2 frameworks (and thus at least 2 programming languages) as a result of this decision so I might as well choose a path of excellence instead of compromise even if there is more overhead.

Hi, @clarkezone! Can I ask, is your work backed by Microsoft? Can we expect Microsoft to support Flutter to create Windows apps? If so, are there any plans of making UI Fabric available for Flutter?

Hi Lukasz.  My work is not backed by MS, it's done on a personal basis in my free time.  Agree on your other points for sure.  FWIW I've made some pretty good progress, I have prototype Flutter runner working end-to-end for output/rendering (no input yet), the big / next task I'm currently working on is to make everything link correctly without pulling in user32/gdi32 etc.. this step is required to be able to successfully see the prototype run on non-desktop devices such as  XBOX, Windows 10x emulator and is proving to be (another) yak shave :-)

PLease add Windows Store !!!!

@daniele777 that's what i've been working on;-)  Status update: down from 84 linker errors to 10

Can i help ?? to improove project ?? can do me task?

@daniele777 not at this point, still getting the basic PoC working.  Linker errors are cleared but there is a build issue in the invocation of Dart getting into an infinite loop in the build pipeline.  There are also other issues also.  I’m going to be on vacation for a couple of weeks hence no progress for a bit tho once I’m back and we’re through the PoC phase there may be parallelizable items which I’ll report on here in that eventuality.

all right all the best!

Can't wait for this to get here sooner. I tried the current win32 based flutter on windows. OMG the render is so pixelated that it looked like it's modern design but implemented using 10 year old framework. It's not something one would expected to see on a 4k screen. Being used to the smooth edges on text in UWP apps and modern web apps, win32 rendering looks extremely dated.

@nerocui - if you're seeing pixelated rendering on Windows that is very likely a different bug that will not be fixed just by migrating to UWP.  Could you file a new issue about that with steps to reproduce (and perhaps a screen shot of the pixelation)?

@dnfield It's not like images are pixelated. It's just the text and shape are rendered (seems like) without hardware acceleration so that the edges doesn't look smooth. This happens to a lot of win32 programs I see. There is no reproduction steps, as it's just the text and button on the default template page.

@nerocui It's because win32 apps don't have proper DPI scaling compared to UWP. It's POSSIBLE with a TON of work to get win32 text rendering working properly, but it's VERY difficult.

@JohnGalt1717 Thanks, that's exactly my point. Flutter should be about building beautiful cross platform apps, but win32 is the single thing that's making the apps ugly. It makes the flutter implementation on windows look inferior than the other platforms.

win32 is the single thing that's making the apps ugly

As @dnfield said, it's extremely unlikely that this is the case. Flutter text rendering is being done entirely by Skia, into a (properly scaled for DPI) GL context. Creating the GL context with UWP APIs isn't going to change the rendering.
Please file a bug with screenshots highlighting the issues you are describing.

It may be as simple as the embedding ignoring an anti-alias flag somewhere for example.  But without steps to reproduce we can't tell.

https://github.com/flutter/flutter/issues/53308
Filed issue. Please see if it's accurate/enough info.

It looks smoothly on 4k monitor

I'd guess that if you set your DPI to 150% or worse 175% and load up some text you'll see it.

Please stop posting here about details of rendering; it's unrelated to this issue, per my explanation above, and thus off-topic.

ready for pubblish on windows store? any news?

No, not ready to publish to the store.  Pixels and input are working on XBOX and Windows 10x.  Still iterating on the API.  Still a lot of work remaining.

I've been thinking about a slightly different approach - I haven't tried it yet but might do if I find some spare time - what about using Flutter for Web with Skia WASM on desktop (which could be backed by Blazor)? I can think of a limited access to I/O being one downside, but the actual UI rendering and event handling should work as expected. Windows appears to have a good support for PWAs (so does Chrome OS), and this approach might be easier to implement while still achieving good performance.

@lukaszciastko no, that will be one more Electron. Flutter should be rendered into a native Windows window(HWND), that in its turn could be embedded to any kind of native Windows app (win32, Winforms, wpf).
IMHO uwp shouldn't be considered as a main kind of Windows app. Even MS didn't it.

@clarkezone I can't wait to see your work rolled in to the project so we can apps that run on Windows

so we can apps that run on Windows

It's already possible to run Flutter apps on Windows, and has been for some time. This issue is now specifically about UWP.
I'll update the title to make that clearer.

so we can apps that run on Windows

It's already possible to run Flutter apps on Windows, and has been for some time. This issue is now specifically about UWP.
I'll update the title to make that clearer.

Stuart, I haven't seen anywhere in the documentation on how to build and run Flutter apps on Windows. Can you please tell me where I can find this info?

@steskalja  https://github.com/flutter/flutter/wiki/Desktop-shells#create
In resume, you have to be in the master branch and run:
flutter config --enable-windows-desktop
In the project you want to try it:
flutter create . //  Will add the windows folder, be careful with changes in android and ios folders,
flutter run -d windows

More specifically, my thought around this dev. is to hope that there is some relation with Project Union. I love flutter and so happy that this SDK is a thing. I am concerned on the future of Win32 apps in the Windows OS.
What is the knowledge base that the flutter team has?

When you get this finished, does it mean we can implement Flutter plugins in C# and use from plugins any .NET APIs available to UWP apps?

@kinex I am curious to know why you would think the two related. Adding .net support to flutter is a huge effort, and wouldn't require UWP.

Hmm. Come to think of it it wouldn't be hard at all.

@JakeSays From my understanding the execution environment (UWP in this case) defines how the plugins are created and what is available to plugins. So maybe the answer to my question is "of course", but I am not fully sure.
In Android plugins you can use Kotlin (or Java) and any Android APIs, SDKs and packages. In iOS plugins you can use Swift (or Objective-C) and any iOS APIs, SDKs and Pods. I would expect same with UWP and it would make this really awesome.

Making it easier to use C# in plugins is something we intend to do, but is orthogonal to UWP support.
A UWP runner would mean being able to use UWP-specific APIs in plugins, but my understanding is that very few APIs are actually UWP-specific (e.g., per this documentation "The general rule is that a desktop app can call a Universal Windows Platform (UWP) API.")

@stuartmorgan That isn't actually true.  Eventually with project reunion that WILL be true, but it isn't right now and even then it's for legacy software, not new apps as would be the case with flutter. There is a massive amount of stuff you can't do without UWP (i.e. accessing the plugins for various video codecs, the DRM video player, etc) still which is why I've always had an issue with the approach the flutter team is taking.  There is 0 operating systems supported by Microsoft (and thus secure) that can't run UWP on the market (i.e. targeting Windows 7 is ridiculous and shouldn't be a goal of Flutter, only Windows 10 should be a target). Thus, there is 0 reasons why this shouldn't be native UWP from day one.
Worse, all Windows 10 S and variants CAN'T run win32 apps so flutter will be locked out from those. They will also be locked out from ARM/ARM64 devices too unless they run on UWP and Windows X that runs win32 apps in a docker container using Remote Desktop will have a significantly worse experience than native UWP apps as a result, especially when it comes to graphics performance.
So if google/flutter were forward thinking with Windows support it would entirely be UWP from day one which allows C++ and .NET (the vast majority of Windows devs use .net, not C++) AND supports all current AND future windows devices with the best possible interactivity.  The current win32 approach is both short sighted and poorly researched (which indicates a really huge blindspot within Google which is concerning given the billion+ devices that run windows).
Given that Skia is already running on UWP there is very little reason why this wouldn't be the defacto environment and the focus of 100% of google's efforts on Windows. (and really, working with Microsoft to get the entire Xamarin remote simulators and direct deploy to iOS devices on Windows working too)

@JohnGalt1717 You've made this argument several times in this issue already; repeating it is not constructive. If you want to accelerate the development of UWP support, you are welcome to contribute to it.

@stuartmorgan You asserted incorrect facts that have obviously gone into the decision making for flutter on windows.  Obviously my statements needed to be repeated because you're operating under false assumptions and assertions that are detrimental to flutter on windows.  If I got an acknowledgement from the flutter team or people actually working on it and some sort of logical reason or mitigating actions you're taking to address those concerns then I wouldn't repeat them even if I didn't agree with your position. But I haven't gotten anything like that and have in fact gotten an assertion that is incorrect.
So correcting incorrect assertions by people making the decisions is constructive unless what you're saying is that you don't care that you're wrong and want to make short sighted decisions that limit your market reach?

@stuartmorgan I'd be curious to know your thoughts on using c#. I have some ideas on how to make that work.

@kinex actually flutter plugins are essentially just C code that interacts with flutter via a simple api. To write them in C# would basically require a ".net plugin" written in C that would host the CLR and bridge the flutter world and c#.

@JakeSays I filed https://github.com/flutter/flutter/issues/64958 with my current thoughts on C#, since I had apparently never filed it here. Anyone interested in C# specifically should follow that issue.

@JakeSays  Ok thanks for the clarification. Without better knowledge I assumed something like this: C# plugins (maybe implemented as .NET libraries?) would be loaded by the UWP runner and the Dart code could call them via the UWP runner process. In this imaginary architecture those C# plugins could access the same APIs, SDKs and NuGet packages as any .NET library hosted by an UWP app.
Anyway, good to know there are plans regarding C# support. I believe there will be more plugin authors (=more plugins faster) and more stable plugins if C# can be used instead if C++.

@kinex you're right in that c# plugins would have access to the full .net set of libraries, as well as nuget packages. When the c# code is executed it's running in a full .net environment (or .net core as the case may be).

FFI is a far more lightweight solution for plugins. See https://pub.dev/packages/win32, for instance. But this is far off-topic for an issue that is ostensibly about building a UWP-based runner.

@timsneath I think ffi and plugins solve two different problems. iirc there are a lot of limitations with what you can do with ffi (for instance it's synchronous).

Again, I've filed #64958 for C# plugins; please continue any discussion that's about C# but not UWP there.

nice stuff going on
somebody should tell Microsoft to contribute here too

@airbus5717 what do you mean? Microsoft contributes to the discussion here all the time.

I thought it would be worth sharing a September 2020 update on the state of the Flutter UWP experiment I've been working on.  Progress has been slower than I’d like as this is a spare time / best effort project that I've been working on only during evenings and at weekends.  However, I have been able to make a decent amount of progress over the last six months or so and get some scenarios working namely:

a proof-of-concept WinRT Flutter embedder using CoreWindow in conjunction with WinRT input APIs running in the AppContainer sandbox: https://github.com/clarkezone/engine
a corresponding test Flutter UWP runner (only 115 lines of c++!) with a demo Flutter experience using Flutter Gallery: https://github.com/clarkezone/fluttergalleryuwp
using these I was able to publish a MSIX packaged version of Flutter Gallery successfully to the Microsoft Store, passing the WAC API checks for store certification (finally :-))

Still a ton to do to get this to something production-ready and I have no clue how long that will take but it certainly shows that Flutter UWP is viable.
There are a few largish remaining issues to solve such as how to do tooling integration with flutter create, how to get hot reload and observatory support working and more.  More details here.
In the example below, I was able to take the source of Flutter Particle clock from https://github.com/miickel/flutter_particle_clock build it in release mode targeting Windows, take the resulting app.so binary, package it for UWP using the same Flutter Runner as used above for Flutter Gallery, publish to the Microsoft Store and install on my XBOX:

Latest prototype branch posted here: https://github.com/clarkezone/engine/tree/flutter-uwp-dec2020

The following capabilities are working as of December 2020:

Updated to Flutter master top-of-tree incl null safety
Flutter UWP Target change landed: https://github.com/flutter/engine/pull/21754
Dart UWP compatibility change landed: https://github.com/dart-lang/sdk/commit/50a2216b31cf7089802687d3b90878dd9497a248
SKIA UWP compatibility change in PR: https://skia-review.googlesource.com/c/skia/+/345219
Angle UWP compatibility change cleaned up and almost ready to PR: https://github.com/clarkezone/angle/tree/flutter-uwp-dec2020
Prototype branch rebuilt on top of the above and re-tested for UWP / Windows Store compatibility
Added support for proof-of-concept CoreWindow hosting mode where Angle takes care of the Swapchain binding

@clarkezone Thanks so much for your efforts on this! I can't wait to contribute code to the standard plugins using UWP/C#.

@clarkezone Thanks so much for your efforts on this! I can't wait to contribute code to the standard plugins using UWP/C#.

Latest prototype branch posted here: https://github.com/clarkezone/engine/tree/flutter-uwp-dec2020

The following capabilities are working as of December 2020:
...
[x] Added support for proof-of-concept CoreWindow hosting mode where Angle takes care of the Swapchain binding

CoreWindows checked!

Latest prototype branch posted here: https://github.com/clarkezone/engine/tree/flutter-uwp-dec2020

The following capabilities are working as of December 2020:
...
[x] Added support for proof-of-concept CoreWindow hosting mode where Angle takes care of the Swapchain binding

CoreWindows checked!

Angle UWP compatibility change cleaned up and almost ready to PR: https://github.com/clarkezone/angle/tree/flutter-uwp-dec2020

https://github.com/flutter/engine/pull/23999
Angle checked?

Angle UWP compatibility change cleaned up and almost ready to PR: https://github.com/clarkezone/angle/tree/flutter-uwp-dec2020

https://github.com/flutter/engine/pull/23999
Angle checked?

Angle UWP compatibility change cleaned up and almost ready to PR: https://github.com/clarkezone/angle/tree/flutter-uwp-dec2020

flutter/engine#23999
Angle checked?

Unfortunately, the change to Angle got backed out: https://chromium-review.googlesource.com/c/angle/angle/+/2638572 hence I need to figure out why that was crashing chrome and fix that.

Angle UWP compatibility change cleaned up and almost ready to PR: https://github.com/clarkezone/angle/tree/flutter-uwp-dec2020

flutter/engine#23999
Angle checked?

Unfortunately, the change to Angle got backed out: https://chromium-review.googlesource.com/c/angle/angle/+/2638572 hence I need to figure out why that was crashing chrome and fix that.

Last day of Jan, progress but the update here is blocked by one final issue related to resolving an erroneous SendKeys dependency that @gspencergoog is helping me to investigate.

Feb 2021 update: all Flutter engine work that was previously in my private UWP prototype branch is now either in engine master on in PR on the way there.  The PR to add Flutter UWP support to Angle landed but was subsequently backed out.   This is probably the biggest outstanding issue standing in the way of victory since it hasn't been possible to repro.  That aside, pretty good progress across the board, we are super close to having WACK-clean UWP binaries from engine master.

UWP embedder scenarios working against engine binaries from master with the following 4 cherry-picks:
bb6f3d330 Pickup correct Angle branch with UWP support
f71274b30 Fix fml::GetFullHandlePath for WINUWP target
ced1fb337 Windows UWP: Add support for emulated mouse cursor for use with gamepads on devices which do not have a physical mouse.
8dcd943dc Fix UWP build for UpdateCursorRect rename

Updated proof-of-concept embedder client with an updated build of Flutter gallery tested on XBOX and Windows 10x: https://github.com/clarkezone/fluttergalleryuwp

UWP plugin support!  A proof of concept file picker plugin is running, built using the WinRT FileOpenPicker API and verified on Windows 10 desktop, XBOX and Windows 10x.

WACK (Windows App Certification Kit) compliance for UWP engine binaries:

Next steps

Get outstanding Angle patch re-landed: (https://chromium-review.googlesource.com/c/angle/angle/+/2693639)[https://chromium-review.googlesource.com/c/angle/angle/+/2693639]
Land Windows: Fix fml::GetFullHandlePath for WINUWP target flutter/engine#24422
Close Allow building a skeleton UWP embedding · Issue #70196 · flutter/flutter (github.com) then celebrate 🚀
Get CI, unit tests set up, support most recent Windows SDK by leveraging generated C++/winrt headers
Complete embedder template and start working on tooling

There is still a fair bit to do to get Flutter UWP support fully working and the going is slow as this remains an evenings and weekends endeavor for me.  If you are a c++ developer interested in helping out please feel free to chime in in below and I can point you at issues that need working on.  Some are pretty easy!

March 2021 Update
As ever this is a spare time, best effort project which continues to make slow but steady progress on evenings and weekends.

Flutter Engine updates:

All changes to support the skeleton UWP embeding item (https://github.com/flutter/flutter/issues/70196) are now in Flutter engine master including dependent project changes (Angle, Dart etc).  Next step is to stand up CI builds so that Flutter UWP engine binaries are automatically generated.
Emulated mouse cursor support for XBOX has landed: https://github.com/flutter/flutter/issues/70196

Tooling work is now in progress with a bunch of great progress including

UWP runner template (https://github.com/clarkezone/fluttergalleryuwp) ported to CMake in readiness to integrate with flutter tool (thanks to @markingramuk for the help with this).
Skeleton support in flutter tool in place (thanks to @jonahwilliams for the help):

https://github.com/flutter/flutter/pull/78067
https://github.com/flutter/flutter/pull/78624
A basic flutter run experience works for the UWP target with a few manual patches / hacks.

Proof of concept observatory support is working for WinUWP target (thanks to @matthewige and @jonwis).
Proof of concept hot reload is working for WinUWP target (thanks to @cbracken for help with this).

Proof of concept hot restart is working for WinUWP target.
Proof of concept tool launch of UWP target experiment successful (thanks to @timsneath for the help with this)
Flutter tools investigation blocked on https://github.com/flutter/flutter/issues/79498
Solution for engine switches in flight: https://github.com/flutter/engine/pull/25412

Next step: UWP port of the following plugins path_provider, url_launcher, shared_preferences then get UWP plugin support integrated with template and tooling, continue standing up the end-to-end tooling.

As mentioned before, if you want to help LMK.

Any reason for those plugins in particular, or just that they're ubiquitous?

We need a simple example with a c++ backend to verify the tooling and UWP specific compilation which URL_launcher meets.  URL_launcher is also a dependency for Flutter Gallery.  We also need a simple dart-only example.  Shared_prefs meets that and is also fairly broadly used.  Path_provider is a dependency for shared_prefs.

Feb 2021 update: all Flutter engine work that was previously in my private UWP prototype branch is now either in engine master on in PR on the way there. The PR to add Flutter UWP support to Angle landed but was subsequently backed out. This is probably the biggest outstanding issue standing in the way of victory since it hasn't been possible to repro. That aside, pretty good progress across the board, we are super close to having WACK-clean UWP binaries from engine master.

UWP embedder scenarios working against engine binaries from master with the following 4 cherry-picks:
bb6f3d330 Pickup correct Angle branch with UWP support
f71274b30 Fix fml::GetFullHandlePath for WINUWP target
ced1fb337 Windows UWP: Add support for emulated mouse cursor for use with gamepads on devices which do not have a physical mouse.
8dcd943dc Fix UWP build for UpdateCursorRect rename

Updated proof-of-concept embedder client with an updated build of Flutter gallery tested on XBOX and Windows 10x: https://github.com/clarkezone/fluttergalleryuwp

UWP plugin support!  A proof of concept file picker plugin is running, built using the WinRT FileOpenPicker API and verified on Windows 10 desktop, XBOX and Windows 10x.

WACK (Windows App Certification Kit) compliance for UWP engine binaries:

Next steps

Get outstanding Angle patch re-landed: (https://chromium-review.googlesource.com/c/angle/angle/+/2693639)[https://chromium-review.googlesource.com/c/angle/angle/+/2693639]%5Bhttps://chromium-review.googlesource.com/c/angle/angle/+/2693639%5D)
Land Windows: Fix fml::GetFullHandlePath for WINUWP target Windows: Fix fml::GetFullHandlePath for WINUWP target engine#24422
Close Allow building a skeleton UWP embedding · Issue #70196 · flutter/flutter (github.com) then celebrate 🚀
Get CI, unit tests set up, support most recent Windows SDK by leveraging generated C++/winrt headers
Complete embedder template and start working on tooling

There is still a fair bit to do to get Flutter UWP support fully working and the going is slow as this remains an evenings and weekends endeavor for me. If you are a c++ developer interested in helping out please feel free to chime in in below and I can point you at issues that need working on. Some are pretty easy!

You mentioned plugin support. Is there an example of getting a UWP plugin to work anywhere on Github? The flutter create tool still doesn't create UWP plugins.

@mwdavis84 I do have some plugins in PR, from memory one example is in Dart using FFI, one is with a c++ backend.  For various reasons these haven't landed yet.  What's your scenario?

Does it support window webview now?

There is currently no timeline for platform view support (which is necessary for flutter_webview support) in the UWP embedding.

Apparently UWP is now deprecated, will Flutter similarly deprecate support or continue to support UWP?

I suppose it depends on the definition of deprecation...
"If you need to use .NET 5/6 in your UWP project type, we recommend you migrate your project to a WinUI 3 desktop project, since .NET 5/6 will not be coming to UWP project types."
-Exact quote from the link

It hasn't been all that long since many of the posts in this (and related) issues were heated arguments that Win32 was obviously effectively deprecated and it was therefore foolish for us not to devote all of our resources to UWP. I would encourage anyone tempted to make definitive statements about the future of UWP to remember that the way these technology stacks has evolved has not been particularly easy to predict.
There is plenty of time to see how things play out before making any final decisions about any one embedding.

Status update: There was some work done to support UWP, but the main person who was working on this is no longer in a position to contribute to it. At this point we're mostly waiting for clarity from Microsoft about the future of UWP apps before committing a lot of time and effort into something that might be end-of-lifed any day now. That said, if you are interested in picking up this torch, we would not object to further work being done in this area; the best way to get started would be to join #hackers-desktop and volunteer (see our contributing docs for a link to our Discord). There are some people who have contributed patches here and there.
If nothing happens (whether clarity from Microsoft, or someone volunteering to work on this, or some other event that compels us to work on the UWP port), the existing code will probably eventually be removed in the interests of focusing our repositories on the code we're actively working on.

@Hixie I'm unsure if I'm capable enough to pick up the torch but I'd be happy to try.
With regards to the "status of UWP," to understand what's going on you kind of have to break it down into individual UWP components.
The most-dead thing from UWP is .NET Native, which is why interest in UWP has fallen off quite so hard. AppContainer is alive and there's still work being done by Microsoft to work with it, including with .NET. WinRT APIs have mostly stabilized, though unfortunately without an improved file system scenario.
Given that Microsoft shipped brand-new UWP code in Windows 11 as part of core system components, and has made no effort to backport WinUI to .NET Framework, and has commented that .NET 5+ won't ship as a stabilized, global system component (as .NET Framework did), Microsoft would have to make a pretty significant change to its plans in order to EOL UWP in the short term. However, MS has set its own teams up for failure before.

@lukemcdo Here's how we're reading the tea leaves:

Microsoft is encouraging developers to migrate from UWP to WinUI: "as a developer with a Universal Windows Platform (UWP) application, you can make great use of your existing skill set, and your source code, by moving your app to the Windows App SDK". (source).
UWP will continue to be supported with "bug, reliability, and security fixes", but Windows App SDK is the "single path forward" (source)
The Windows App SDK is a "new technology" that is currently slower than UWP: "Today in version 1.0 of Windows App SDK, launch speeds, RAM usage, and installation size of WinUI 3 apps are larger/slower than seen in UWP. We are actively working to improve this. We will have more information to share in the future." (source)
The Windows App SDK is still quite immature, with a variety of features missing including camera and taskbar pinning (source).
Within the Windows App SDK, there is a new windowing API that is an "evolution of UWP's AppWindow" (source). This is compatible with Win32 HWND-based windows, but offers features that are probably not relevant to us for now (picture-in-picture) or available directly in Flutter (e.g. title bar customization) (source).
The Windows API SDK requires deployment to client computers (source), and is only available on Windows 10 v1809 or later (source).
The current stable version of the Windows API SDK only has a 12 month lifecycle from the date of release, meaning that it will be unsupported by November 2022 (source).

All this taken together suggests that we should abandon further development on a UWP embedder, instead investing all our efforts on the existing stable Win32 embedder that is fast, supports all Windows versions and requires no prerequisites to be installed.
At a later date, should we reach the point where we're ready to drop support for older Windows 10 versions, we might take advantage of the new windowing API if there is benefit to doing so, but that is likely an evolution of our existing embedder, rather than work that would start from the UWP foundation.
If anyone from Microsoft spots something we've poorly understood or misinterpreted here, we'd be glad to hear from you.

@lukemcdo If you are interested in contributing, please reach out on the #hackers-desktop channel on our Discord (see the contributing docs for details on getting to the server).

It's fair to put a relatively low level of value on a port that's pretty low interest at this point. From my perspective, it has some relevance for the future. Correct me if I'm wrong, but my understanding is that most of the biggest struggles for the UWP port have to do with either windowing, the sandbox model, or WinRT APIs.
WinRT APIs haven't been deprecated at all (except for windowing ones that don't map), sandbox support is an aspirational goal for WinUI 3 but it's on the roadmap, and windowing should be doable even if it's the least worth-it component. To me, that looks like things that will be relevant for the most part, and could be valuable bits for Windows development sooner than expected.

With UWP support dropped, targeting HoloLens and Xbox devices with Flutter would become impossible. I guess HoloLens is less of an issue since [rumour has it](https://www.businessinsider.com/microsoft-hololens-3-canceled-mixed-reality-product-roadmap-samsung-2022-2 Microsoft is replacing the OS of the successor of HoloLens 2 with something "different".
For Xbox we can only hope that MS will release an OS update and allow it to run win32 apps. It would be best if MS opened their cards and set things straight. This speculation happening is only hurting our trust in MS.

Correct me if I'm wrong, but my understanding is that most of the biggest struggles for the UWP port have to do with either windowing, the sandbox model, or WinRT APIs.

I'd narrow that down further to windowing (which is altogether different from Win32), the sandbox model (which makes it really tricky to run automated integration tests that interact with the VM service port we use to drive tests, collect benchmark data, etc.), and the deployment model.
Overall the WinRT APIs have been a joy to work with compared to stock Win32. I'd love for us to be able to make use of them in the Win32 embedder, but that would prevent us from delivering (best-efforts) Windows 7 compatibility.

Correct me if I'm wrong, but my understanding is that most of the biggest struggles for the UWP port have to do with either windowing, the sandbox model, or WinRT APIs.

I'd narrow that down further to windowing (which is altogether different from Win32), the sandbox model (which makes it really tricky to run automated integration tests that interact with the VM service port we use to drive tests, collect benchmark data, etc.), and the deployment model.
Overall the WinRT APIs have been a joy to work with compared to stock Win32. I'd love for us to be able to make use of them in the Win32 embedder, but that would prevent us from delivering (best-efforts) Windows 7 compatibility.

Why are you making efforts at all on an unsupported OS that doesn't get security updates and is dropping like a stone in usage? (now around 10%)  You've discontinued IE 11 support for this very reason.
To me you have the opportunity to be green field here and since ALL Windows versions that are supported support WinRT, it makes sense to only use Win RT.
Also there's serious doubts about Hololens continuing to exist shortly, so that leaves Xbox only. I would assume that Microsoft would be able to shed some light as to if UWP is going to continue to exist there at all soon. I would guess since UWP is DOA and Hololens is also DOA that it won't be long until that's toast too and it uses WinUI with WinRT as well.
 But putting resources into end of life stuff insetad of just supporting supported OSes seems pointless.

@timsneath will probably have better market data, but while Windows 7 has fallen out of MS official support, and while it makes up a small part of the overall market, it makes up a non-trivial chunk of some markets, China in particular. More importantly though, it's relatively low-effort to support.
As Tim points out, eventually we'll get to the point where that's no longer the case and we'll be able to fully drop support for it and be able to start making use of WinRT. Believe me, I can't wait for that day to come. As I say, WinRT has mostly been a joy to write against. On the assumption that we remove the UWP embedder, all that code will still be there in our commit history and we'll be able to resuscitate any useful bits we'd like to adopt.
Unfortunately the UWP embedder does have a very real non-zero cost to maintain -- every time we make API changes, we need to update the UWP embedder too, so as not to break the build, or add stub method implementations for new API, file an issue for someone to implement, and add the TODO pointing to that issue to the UWP embedder. Supporting Windows 7, on the other hand, is actually realtively low-effort -- you know, other than those rare occasions I accidentally break it.
That said, I'd like to keep this issue focused on the UWP implementation. It's entirely fair to have a conversation about when to end-of-life Windows 7 support and what the tradeoffs would be, but that's a discussion for a separate issue.

You have made your opinion about Windows 7 support clear many times; continuing to assert your view on it is not productive, nor is it on-topic for this issue.

So again, has anyone at google bothered to ask microsoft what they're doing with xbox and hololens? Because it sure seems like decisions are being made with (at best) incomplete information. (which has been the problem all along for the record)  I get MS isn't exactly enthusiastic about Flutter, but they've got to see that Flutter is in their interest and that sharing this information benefits them (and if they had Flutter ready to roll for Build to work on these platforms with the next iteration they'd have much more success...)

So again, has anyone at google bothered to ask microsoft what they're doing with xbox and hololens?

The Flutter team does not have any special knowledge about Microsoft's plans for these platforms. Many people have asked this question publicly, and we have not seen any official response.

Because it sure seems like decisions are being made with (at best) incomplete information.

We are making decisions based on the available information, just like the rest of the industry.

they've got to see that Flutter is in their interest and that sharing this information benefits them

You are welcome to make this case to Microsoft.

Both HoloLens and Xbox are drifting away from UWP XAML and WinUI, but accessing native hardware (without using a game engine and/or C++ only with special approvals) requires UWP on Xbox (and I believe OpenXR on HoloLens is done similarly). Xbox is expected to run everything in a sandbox for the foreseeable future.
However, both platforms also support modern Chromium-based Edge, so it's worth considering whether those platforms should instead be served by a UWP wrapper application hosting a WebView2 control, and shimming WinRT APIs to the Flutter Web app. As I understand it, neither platform supports complicated windowing anyway.

It seems like it'd be helpful to know if there's anyone actually using the UWP embedding. Perhaps such an entity would be interested in moving the UWP embedding bits out of the engine repo and into a separately managed one, along the lines of what's happening with the Fuchsia embedding currently. @cbracken or @zanderso is there anything that would block that technically?

@jhancock4d Please review our code of conduct, which requires everyone to be actively welcoming. Phrases like "it sure seems" and "decisions are being made" and "it would be very wise" and so on lead to other contributors feeling like they are not being respected.

@dnfield yep, we'd more than welcome interested parties taking up the torch here. There's nothing that would block forking it to its own repo. Our build recipes are specific to our own LUCI infrastructure, but those really just build targets and run CI tests and could easily be adapted to GitHub Actions or similar.

One technical impact of completely separating the UWP embedding out is that it would change the plugin design. The current plan of record has been to share the same plugin interface, and treat both Windows embeddings as a single platform for plugin implementations. The idea was that some plugins would be able to share significant code, while others would need largely different (via ifdef), but that the former group would increase over time due to Project Reunion (now App SDK).
That definitely wouldn't be a blocker though; common functionality could still be factored out and shared even if the plugin API surface were different.
(The embedding itself should be straightforward to manage out of repo since it is already built on embedding.h.)

As we continue to become confident that UWP has been abandoned by Microsoft, we've decided that we are going to definitely delete the current UWP codebase in Flutter (the exact timing will depend on when we have spare cycles to do so). As such we're not going to continue accepting patches to the current codebase. If anyone would like to implement a UWP port of Flutter, that's still possible, but it won't be able to share code with the win32 version (so as to keep the win32 version simple). If you're interested in owning the UWP support in the flutter org repos, please ping me and @cbracken in #hackers-desktop on our Discord. (Owning the UWP support will require a couple of people with contributor access so that code reviews can happen, as well as cycles to maintain the code and corresponding test infrastructure.)

I don't think there's much reason to aim for a native version of Flutter on UWP. The two beneficiary devices are Xbox and HoloLens (mostly the former), so honestly I'd be more interested in building a UWP WebView2 wrapper that exposes WinRT APIs, then making sure that the Win32 version (if/when it gets WinRT API access) accesses those APIs in a similar way. Native performance on Xbox is not essential and the HoloLens barely exists.
Is coordinating with a theoretical web wrapper project something the Win32 team is willing to do? Goal would be the option to write once use anywhere with WinRT APIs. Or are WinRT APIs not on the Win32 team's roadmap?

https://github.com/woodemi/quick_blue/blob/master/quick_blue_windows/windows/CMakeLists.txt
https://github.com/woodemi/quick_notify/blob/master/windows/CMakeLists.txt
It is possible to use WinRT APIs now in plugin. No need for support in Flutter framework/engine

@cbracken  , I think this might be closed as it collides with https://github.com/flutter/flutter/issues/102172

Yep -- was waiting to file that issue before closing this one out.
Closing this since our intent is to wind down development on, and remove the UWP embedder in order to focus on the Win32 embedder which, over time, will start to adopt Windows SDK support (once our supported OSes is a subset of those that support doing so).
See: https://github.com/flutter/flutter/issues/14967#issuecomment-1085490495

@cbracken
To be fair, UWP look like being slowly phased out.
Maybe just focus on WinUI+ Uno. That is basically open source. As Flutter is direct competition to Uno and Microsoft.
Its would be all community's work.
Regardless x86 architecture (Most the userbase, still be on Windows 10-11), and UWP still have year of support until end of Windows 11.

We are very proud to work closely with Microsoft to ensure Uno Platform can provide day-zero support for WinUI 3 and bring WinUI-built applications everywhere, including Web, Linux, macOS, iOS and Android.


Add functions to merge step/sidecar overrides

Changes
This commit adds methods to merge a slice of Step overrides with a slice of Steps.
This functionality is necessary for the full implementation of Step and Sidecar overrides.
It re-uses the merge process that is used to combine Steps and Step templates;
however, the Step is treated as the "template" so that the Step override takes precedence.
We do not attempt to validate the resource requirements of the resulting pod;
it's possible for the resulting pod to have resource requests > limits, which k8s will reject.
This is the same way we currently handle Step template.
Part 2 of #4326.
This is part of #4598, split out into its own PR.
/kind feature
Submitter Checklist
As the author of this PR, please check off the items in this checklist:

[x] Docs included if any changes are user facing
[x] Tests included if any functionality added or changed
[x] Follows the commit message standard
[x] Meets the Tekton contributor standards (including
functionality, content, code)
[x] Release notes block below has been filled in or deleted (only if no user facing changes)

Release Notes
NONE

/test pull-tekton-pipeline-integration-tests

/assign

/test tekton-pipeline-unit-tests

/test pull-tekton-pipeline-alpha-integration-tests

Awesome, cheers @lbernick !
/lgtm

/test pull-tekton-pipeline-alpha-integration-tests


fix: support multi level directory search mod

bug: unable to find the go+project source file for breakpoint, the source file path is relative
The solution to the problem of not being able to locate the go.mod file in multi-level directories has been solved by searching for the go.mod file level by level upwards

@xushiwei PTAL


Fix Issue 23194 - Add ucora to list of companies using D

@mdparker I think it's up to you to approve the addition of this company.

@dkorpel Once the Ddoc stuff is good to go, please do give it the greenlight.

If it helps:
"Ucora Corporation"
"GamePlanPro(tm)"
"GamePlanPro™ is a mobile workflow platform for businesses of all sizes and types.
Ucora is changing the way the world works."
The server platform is written entirely in D.
https://www.ucora.com/solutions/software/
https://www.ucora.com/clients
Thank you

Awesome
On Sat, 25 Jun 2022, 17:08 BCPaulPaul, @.***> wrote:

If it helps:
"Ucora Corporation"
"GamePlanPro(tm)"
"GamePlanPro™ is a mobile workflow platform for businesses of all sizes
and types.
Ucora is changing the way the world works."
The server platform is written entirely in D.
https://www.ucora.com/solutions/software/
https://www.ucora.com/clients
Thank you
—
Reply to this email directly, view it on GitHub
https://github.com/dlang/dlang.org/pull/3326#issuecomment-1166317023,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABLI75BI5FLRBJ2XDJUS6STVQ4VJJANCNFSM5ZSVGUHQ
.
You are receiving this because you authored the thread.Message ID:
@.***>

Ping @maxhaton

@maxhaton any updates on this?

@maxhaton can you take this to the finish line?

make -fposix.mak html
.generated/stable_dmd-2.088.0/dmd2/linux/bin64/rdmd --compiler=.generated/stable_dmd-2.088.0/dmd2/linux/bin64/dmd -conf=.generated/stable_dmd-2.088.0/dmd2/linux/bin64/dmd.conf tools/ddoc_xml_extractor.d -i .generated/dblog_latest.xml -o .generated/dblog_latest.ddoc
No GC was initialized, please recheck the name of the selected GC ('conservative').

can't build the website anymore

Superseded by https://github.com/dlang/dlang.org/pull/3402


Interval processing causes panics

Hello, i'm getting the following when trying to pass interval to postgresql stored function:
panic: encode []ProductIn: cannot convert {31207680000000 0 0 2} to Interval

I tried to debug and found that error happens here: https://github.com/jackc/pgtype/blob/master/interval.go#L45
Object that is passed there is of type pgtype.Interval, which can't be processed properly as you can see.
Could you please suggest how i can fix the issue and i will be happy to issue PR

Here is the schema:
schema.sql
CREATE TYPE public.test_in as
(
    sku              text,
    trial_interval   interval
);

create function public.test_in_fn(f_products public.test_in) returns void as
$$
begin
    select f_products;
end ;
$$ language plpgsql strict
                    volatile
                    security definer
                    set search_path to pg_catalog, public, pg_temp;

query.sql
--name: IntervalTest :exec
select public.test_in_fn(pggen.arg('test_in_arg'));

code that calls IntervalTest function
	a := ""
	NewQuerier(p.db).IntervalTest(ctx, TestIn{
		Sku:           &a,
		TrialInterval: pgtype.Interval{Status: pgtype.Present, Microseconds: microsecondsPerHour * 1},
	})

I can reproduce and looking for a fix.

The panic occurs because we're setting a pgtype.Interval to another Interval which should be supported by pgtype. The relevant code is https://github.com/jackc/pgtype/blob/d846dbcb75b2ac38a1c6fd0390cd18472fe72dee/interval.go#L35:
	if value, ok := src.(interface{ Get() interface{} }); ok {
		value2 := value.Get()
		if value2 != value {
			return dst.Set(value2)
		}
	}

I don't understand why pgtype only returns if value2 != value. Seems like we can return nil if value2 == value.

I see it's still not closed and i'm using my forked pgtype version which properly assigns passed interval. It's basic 2 lines change and i see you are participating in pgtype repo. Could you please create pr for that change?


view and selector based pageLoad option support

Coverage increased (+0.8%) to 93.014% when pulling cc487056e147492b4e97ec03f342c8eed2ac1d41 on develop into 41c3fbbf31011d2775362c75218c062f181c3845 on master.


Line breaks not working

or is it supposed to be like this?

Nope, it's not. Please give a line break or space in front of And

Probably that's because of bolding the links also?

@Bishwas-py

I think that's beacue of md: markdown reader, so double line break is required, can you check it out?

Figured out ... my bad .. Shift+Enter is not adding line breaks.


stuck on boot, it shows "USBToolBox: XHC: waitForMatchingService failed or timed out "

macOS Ventura


[VL]CI: Update mirror of CentOS 7

What changes were proposed in this pull request?

Change centos 7 mirror to https://mirrors.edge.kernel.org/centos
Disable yum plugin fastestmirror because it does not work properly on our server

How was this patch tested?
(Please explain how this patch was tested. E.g. unit tests, integration tests, manual tests)
(If this patch involves UI changes, please attach a screenshot; otherwise, remove this)

Run Gluten Clickhouse CI


TestMain injection with _test package suffix fails

As a minimum way to recreate, have these two files in a directory:
// add.go
package add

func Add(x, y int) int {
    return x + y
}

// add_test.go
package add_test

import (
    "os"
    "testing"

    "my-module/pkg/add"
)

func TestMain(t *testing.M) {
    os.Exit(t.Run())
}

func TestAdd(t *testing.T) {
    result := add.Add(1, 2)
    if result != 3 {
        t.Errorf("Got %d but wanted 3", result)
    }
}

The error is:
# Cutting out extra bits
$ gobco
./add_test.go:11:10: undefined: gobcoCounts

If I remove TestMain, it works.  Looking at gobco -keep, it looks like gobcoCounts is defined in its own file that would use package add, not package add_test.  We use the _test pattern to help enforce testing external behavior, and we can't move TestMain out because it also initializes some connections that are referenced in the actual tests.

Thanks for the detailed bug report. I already had all ingredients for fixing this use case, so the actual fix is quite small.

Awesome, thank you so much for an incredibly fast fix!  This has been a very helpful tool for us to deal with auditing.


"Roboto Thin" font-weight is 100 not 200

Hello,
As you can see here, there is only 100, 300, 400.. etc. There is no 200. So the font-weight set in this project 200 does not exist. https://www.google.com/fonts#UsePlace:use/Collection:Roboto:400,100,300,500,700,900

I changed it now to match what is specified on google fonts. c0d5a9f9b228841ac4db9a1532df11a2a4adbefd


How frequently does Tini reap zombies?

I noticed that one of the containers on my system has 13 zombie processes. The container was started with an init: true flag and Tini is running as /dev/init on it. I'm not sure whether this is concerning or not.
The readme says that Tini periodically reaps zombies, but what is the actual interval/period/frequency for the reaping?
root     105789  0.0  0.0 413060  2984 ?        Sl   14:52   0:01      \_ docker-containerd-shim d3dda1cbb59a084ecbfba7138b5d7c5a3ff105dbc6af5b4329f8a0f03a410e41 /var/run/docker/libcontainerd/d3dda1cbb59a084ecbfba7138b5d7c5a3ff105dbc6af5b4329f8a0f03a410e41 docker-runc
root     105829  0.0  0.0   1144     0 ?        Ss   14:52   0:00      |   \_ /dev/init -- /.r/r /home/jupyterlab/run.sh
root     105878  0.0  0.0  48024  2736 ?        S    14:52   0:00      |       \_ su jupyterlab -c bash -c "/home/jupyterlab/spark-${SPARK_VERSION}/bin/pyspark"
nfsnobo+ 105978  2.7  0.1<PHONE_NUMBER>88 ?       Ssl  14:52   2:03      |           \_ /home/jupyterlab/conda/bin/python /home/jupyterlab/conda/bin/jupyter-lab --notebook-dir=/resources --ip=<IP_ADDRESS> --port=8088 --no-browser --config=/home/jupyterlab/.jupyter/jupyter_notebook_config.py
nfsnobo+ 107908  0.0  0.1 1252872 70352 ?       Ssl  14:53   0:03      |               \_ /home/jupyterlab/conda/bin/python -m ipykernel_launcher -f /home/jupyterlab/.local/share/jupyter/runtime/kernel-13337ae8-2778-4cfb-80dd-b9cbc6912cd7.json
nfsnobo+ 107911  0.0  0.1 1252872 70232 ?       Ssl  14:53   0:03      |               \_ /home/jupyterlab/conda/bin/python -m ipykernel_launcher -f /home/jupyterlab/.local/share/jupyter/runtime/kernel-bf69dd38-67d9-4fa8-81a6-cda76cb7a5bf.json
nfsnobo+ 107912  0.0  0.1 1252872 69992 ?       Ssl  14:53   0:03      |               \_ /home/jupyterlab/conda/bin/python -m ipykernel_launcher -f /home/jupyterlab/.local/share/jupyter/runtime/kernel-2e9a3ad3-6897-4679-ab01-9efc2bec5ade.json
nfsnobo+ 107913  0.0  0.1 1254068 71172 ?       Ssl  14:53   0:04      |               \_ /home/jupyterlab/conda/bin/python -m ipykernel_launcher -f /home/jupyterlab/.local/share/jupyter/runtime/kernel-6f5443a0-e156-4922-a199-876974c1fa01.json
nfsnobo+ 108451  0.0  0.0      0     0 ?        Z    14:53   0:04      |               |   \_ [java] <defunct>
nfsnobo+ 107919  0.0  0.1 1252868 70184 ?       Ssl  14:53   0:03      |               \_ /home/jupyterlab/conda/bin/python -m ipykernel_launcher -f /home/jupyterlab/.local/share/jupyter/runtime/kernel-a637d94b-4527-47ce-b33c-ecefc7db5347.json
nfsnobo+ 107921  0.0  0.1 1252868 69436 ?       Ssl  14:53   0:03      |               \_ /home/jupyterlab/conda/bin/python -m ipykernel_launcher -f /home/jupyterlab/.local/share/jupyter/runtime/kernel-b744cc99-daf6-4ac7-aa02-274c80ccb512.json
nfsnobo+ 107923  0.0  0.1 1252868 69696 ?       Ssl  14:53   0:03      |               \_ /home/jupyterlab/conda/bin/python -m ipykernel_launcher -f /home/jupyterlab/.local/share/jupyter/runtime/kernel-b988d430-7eda-4a14-917a-55d7d066146d.json
nfsnobo+ 107930  0.0  0.1 1252872 69796 ?       Ssl  14:53   0:02      |               \_ /home/jupyterlab/conda/bin/python -m ipykernel_launcher -f /home/jupyterlab/.local/share/jupyter/runtime/kernel-ece40467-3f5d-4869-9148-c80476c4416e.json
nfsnobo+ 107934  0.0  0.1 1252872 70052 ?       Ssl  14:53   0:02      |               \_ /home/jupyterlab/conda/bin/python -m ipykernel_launcher -f /home/jupyterlab/.local/share/jupyter/runtime/kernel-c067c785-cd2a-4602-abb6-9ea4c4840978.json
nfsnobo+ 107936  0.0  0.1 1252872 70200 ?       Ssl  14:53   0:02      |               \_ /home/jupyterlab/conda/bin/python -m ipykernel_launcher -f /home/jupyterlab/.local/share/jupyter/runtime/kernel-c537648c-4476-44a7-a11d-3a84f3e305b9.json
nfsnobo+ 107937  0.0  0.1 1252872 69800 ?       Ssl  14:53   0:03      |               \_ /home/jupyterlab/conda/bin/python -m ipykernel_launcher -f /home/jupyterlab/.local/share/jupyter/runtime/kernel-9a4953fb-e606-4e9c-a971-371ce30e4285.json
nfsnobo+ 107938  0.0  0.1 1252868 69564 ?       Ssl  14:53   0:02      |               \_ /home/jupyterlab/conda/bin/python -m ipykernel_launcher -f /home/jupyterlab/.local/share/jupyter/runtime/kernel-f62f4ec2-4baf-428a-91d9-5572475afec1.json
nfsnobo+ 107940  0.0  0.1 1252872 70212 ?       Ssl  14:53   0:02      |               \_ /home/jupyterlab/conda/bin/python -m ipykernel_launcher -f /home/jupyterlab/.local/share/jupyter/runtime/kernel-68d9904a-32d1-4cb2-83a1-68a38cf04851.json
nfsnobo+ 107952  0.0  0.1 1253980 71400 ?       Ssl  14:53   0:03      |               \_ /home/jupyterlab/conda/bin/python -m ipykernel_launcher -f /home/jupyterlab/.local/share/jupyter/runtime/kernel-44c60ba8-f8b3-4cf5-9861-ab409b76ae6e.json
nfsnobo+ 110159  0.1  0.0      0     0 ?        Z    14:53   0:06      |               |   \_ [java] <defunct>
nfsnobo+ 107953  0.0  0.1 1253980 71248 ?       Ssl  14:53   0:03      |               \_ /home/jupyterlab/conda/bin/python -m ipykernel_launcher -f /home/jupyterlab/.local/share/jupyter/runtime/kernel-5e0437eb-9a4c-4fb4-9330-c274d6cc6c16.json
nfsnobo+ 109876  0.1  0.0      0     0 ?        Z    14:53   0:05      |               |   \_ [java] <defunct>
nfsnobo+ 107955  0.0  0.1 1320888 70236 ?       Ssl  14:53   0:03      |               \_ /home/jupyterlab/conda/bin/python -m ipykernel_launcher -f /home/jupyterlab/.local/share/jupyter/runtime/kernel-7eebbccf-db9a-4beb-9df0-9bc7fdcef166.json
nfsnobo+ 110240  0.2  0.0      0     0 ?        Z    14:53   0:11      |               |   \_ [java] <defunct>
nfsnobo+ 107958  0.0  0.1 1252876 70048 ?       Ssl  14:53   0:02      |               \_ /home/jupyterlab/conda/bin/python -m ipykernel_launcher -f /home/jupyterlab/.local/share/jupyter/runtime/kernel-3e06337e-ee48-48ce-a906-d6de24916354.json
nfsnobo+ 107963  0.0  0.1 1253980 70960 ?       Ssl  14:53   0:03      |               \_ /home/jupyterlab/conda/bin/python -m ipykernel_launcher -f /home/jupyterlab/.local/share/jupyter/runtime/kernel-9f3f37e1-fcde-4025-8279-ea2c2243c83d.json
nfsnobo+ 109609  0.1  0.0      0     0 ?        Z    14:53   0:04      |               |   \_ [java] <defunct>
nfsnobo+ 107966  0.0  0.1 1253980 71060 ?       Ssl  14:53   0:03      |               \_ /home/jupyterlab/conda/bin/python -m ipykernel_launcher -f /home/jupyterlab/.local/share/jupyter/runtime/kernel-9215a866-9173-40f2-a82b-8c3195afae0e.json
nfsnobo+ 110031  0.0  0.0      0     0 ?        Z    14:53   0:04      |               |   \_ [java] <defunct>
nfsnobo+ 107971  0.0  0.1 1253980 71132 ?       Ssl  14:53   0:03      |               \_ /home/jupyterlab/conda/bin/python -m ipykernel_launcher -f /home/jupyterlab/.local/share/jupyter/runtime/kernel-7eb07d35-022b-418a-8cf2-f898a80c841f.json
nfsnobo+ 110055  0.2  0.0      0     0 ?        Z    14:53   0:09      |               |   \_ [java] <defunct>
nfsnobo+ 107972  0.0  0.1 1320892 70624 ?       Ssl  14:53   0:03      |               \_ /home/jupyterlab/conda/bin/python -m ipykernel_launcher -f /home/jupyterlab/.local/share/jupyter/runtime/kernel-3a116401-bd8c-478f-b59a-3ea3bc977672.json
nfsnobo+ 110162  0.4  0.6 8114052 411128 ?      Sl   14:53   0:19      |               |   \_ /usr/jdk1.8.0_131/bin/java -cp /home/jupyterlab/spark-2.3.1/conf/:/home/jupyterlab/spark-2.3.1/jars/*:/home/jupyterlab/hadoop-2.7.3/etc/hadoop/:/home/jupyterlab/hadoop-2.7.3/etc/hadoop/*:/home/jupyterlab/hadoop-2.7.3/share/hadoop/common/lib/*:/home/jupyterlab/hadoop-2.7.3/share/hadoop/common/*:/home/jupyterlab/hadoop-2.7.3/share/hadoop/hdfs/*:/home/jupyterlab/hadoop-2.7.3/share/hadoop/hdfs/lib/*:/home/jupyterlab/hadoop-2.7.3/share/hadoop/yarn/lib/*:/home/jupyterlab/hadoop-2.7.3/share/hadoop/yarn/*:/home/jupyterlab/hadoop-2.7.3/share/hadoop/mapreduce/lib/*:/home/jupyterlab/hadoop-2.7.3/share/hadoop/mapreduce/*:/home/jupyterlab/hadoop-2.7.3/share/hadoop/tools/lib/* -Xmx1g org.apache.spark.deploy.SparkSubmit --name PySparkShell pyspark-shell
nfsnobo+ 107973  0.0  0.1 1253980 70968 ?       Ssl  14:53   0:03      |               \_ /home/jupyterlab/conda/bin/python -m ipykernel_launcher -f /home/jupyterlab/.local/share/jupyter/runtime/kernel-c582e8ed-fbb1-4962-89c5-6700cde82886.json
nfsnobo+ 110259  0.1  0.0      0     0 ?        Z    14:53   0:05      |               |   \_ [java] <defunct>
nfsnobo+ 107974  0.0  0.1 1253952 70964 ?       Ssl  14:53   0:03      |               \_ /home/jupyterlab/conda/bin/python -m ipykernel_launcher -f /home/jupyterlab/.local/share/jupyter/runtime/kernel-68cf3de6-38a1-4d0d-bc7e-acdf7f363e43.json
nfsnobo+ 109500  0.0  0.0      0     0 ?        Z    14:53   0:04      |               |   \_ [java] <defunct>
nfsnobo+ 107979  0.0  0.1 1252868 69880 ?       Ssl  14:53   0:03      |               \_ /home/jupyterlab/conda/bin/python -m ipykernel_launcher -f /home/jupyterlab/.local/share/jupyter/runtime/kernel-fa205be1-eb43-4113-9045-21d6d75ed212.json
nfsnobo+ 107982  0.0  0.1 1253708 71216 ?       Ssl  14:53   0:03      |               \_ /home/jupyterlab/conda/bin/python -m ipykernel_launcher -f /home/jupyterlab/.local/share/jupyter/runtime/kernel-8bb9f76a-0cdc-4a52-854e-632506a33ab0.json
nfsnobo+ 110164  0.0  0.0      0     0 ?        Z    14:53   0:04      |               |   \_ [java] <defunct>
nfsnobo+ 107989  0.0  0.1 1253976 71292 ?       Ssl  14:53   0:03      |               \_ /home/jupyterlab/conda/bin/python -m ipykernel_launcher -f /home/jupyterlab/.local/share/jupyter/runtime/kernel-9889ddce-fda3-4a82-a746-e748d5824882.json
nfsnobo+ 110088  0.1  0.0      0     0 ?        Z    14:53   0:05      |               |   \_ [java] <defunct>
nfsnobo+ 107994  0.0  0.1 1320896 70808 ?       Ssl  14:53   0:03      |               \_ /home/jupyterlab/conda/bin/python -m ipykernel_launcher -f /home/jupyterlab/.local/share/jupyter/runtime/kernel-9e30ed44-434a-4066-bdcd-cddb205e2f43.json
nfsnobo+ 110281  0.4  0.6 8114052 410988 ?      Sl   14:53   0:20      |               |   \_ /usr/jdk1.8.0_131/bin/java -cp /home/jupyterlab/spark-2.3.1/conf/:/home/jupyterlab/spark-2.3.1/jars/*:/home/jupyterlab/hadoop-2.7.3/etc/hadoop/:/home/jupyterlab/hadoop-2.7.3/etc/hadoop/*:/home/jupyterlab/hadoop-2.7.3/share/hadoop/common/lib/*:/home/jupyterlab/hadoop-2.7.3/share/hadoop/common/*:/home/jupyterlab/hadoop-2.7.3/share/hadoop/hdfs/*:/home/jupyterlab/hadoop-2.7.3/share/hadoop/hdfs/lib/*:/home/jupyterlab/hadoop-2.7.3/share/hadoop/yarn/lib/*:/home/jupyterlab/hadoop-2.7.3/share/hadoop/yarn/*:/home/jupyterlab/hadoop-2.7.3/share/hadoop/mapreduce/lib/*:/home/jupyterlab/hadoop-2.7.3/share/hadoop/mapreduce/*:/home/jupyterlab/hadoop-2.7.3/share/hadoop/tools/lib/* -Xmx1g org.apache.spark.deploy.SparkSubmit --name PySparkShell pyspark-shell
nfsnobo+ 107995  0.0  0.1 1252868 69940 ?       Ssl  14:53   0:03      |               \_ /home/jupyterlab/conda/bin/python -m ipykernel_launcher -f /home/jupyterlab/.local/share/jupyter/runtime/kernel-0c319028-252a-4319-8d3d-1904cd2d1a53.json
nfsnobo+ 107996  0.0  0.1 1253980 71188 ?       Ssl  14:53   0:03      |               \_ /home/jupyterlab/conda/bin/python -m ipykernel_launcher -f /home/jupyterlab/.local/share/jupyter/runtime/kernel-ffc5a0ba-17d6-4487-8a41-4666535fc8ed.json
nfsnobo+ 110218  0.2  0.0      0     0 ?        Z    14:53   0:09      |               |   \_ [java] <defunct>

These processes aren't zombies - they're defunct processes. These two concepts aren't really the same thing:

Defunct processes are processes that terminated, but whose parent hasn't reaped them yet (this means: their parent has not called wait on them to get their exit code). Those processes can only be reaped by their parent (i.e. Tini cannot do anything about them). These are the processes you have here.
Zombie processes are defunct processes whose parent exited (so they can never reaped by their parent), and which got re-parented to init as a result. These are the ones Tini handles.

That said, to answer your question, Tini reaps zombie processes once per second.


Bot User Can Not Authenticate with AccessToken

Describe the bug
Created Bot User with Access Token to post Mails to configured Channels. Configuration leads to Mattermost Error:
"caller":"mlog/log.go:174","msg":"Password field must not be blank","path":"/api/v4/users/login",
Bot User is valid and could be successfully tested via API Call:
curl -i -X POST -H 'Content-Type: application/json' -d '{"channel_id":"", "message":"This is a message from a bot", "props":{"attachments": [{"pretext": "Look some text","text": "This is text"}]}}' -H 'Authorization: Bearer ' /api/v4/posts
To Reproduce
Steps to reproduce the behavior:

Create Bot Account
Copy Access Token
Configure mail2most.config
mail2most.config Profile
#[Profile.Mattermost] contains the mattermost configuration
[Profile.Mattermost]
URL = "https://mattermost.example.com"
Team = "Team"
AccessToken = "14ou9rasdfasdfasfwefawefsfa"
Start mail2most: ./mail2most -c conf/mail2most &
See error mail2most.log

Expected behavior
Bot User should be able to authenticate with AccessToken only. No Username and Password is needed in configuration.
Release version
1.5.2
Architecture
Linux Ubuntu x86_65

Hi @Fmyschkin thanks for opening the issue. Can you provide log details for your case ?

Hi @cseeger-epages
Please find enclosed logs regarding this issue:
time="2020-02-10T10:37:55+01:00" level=debug msg=sleeping intervaltime=10 unit-of-time=second time="2020-02-10T10:38:05+01:00" level=debug msg=mailserver server="mailserver:993" status=connected time="2020-02-10T10:38:05+01:00" level=debug msg="checking folders" folders="[Inbox/Testing]" time="2020-02-10T10:38:06+01:00" level=info msg="unseen mails" ids="[4 5 6]" time="2020-02-10T10:38:06+01:00" level=info msg="processing mails" folder=Inbox/Testing time="2020-02-10T10:38:06+01:00" level=info msg="found mail" message-id=770 subject="neuer test" time="2020-02-10T10:38:06+01:00" level=info msg="found mail" message-id=771 subject="Test Email with Bot Account" time="2020-02-10T10:38:06+01:00" level=debug msg=mail message-id=770 status="already send" subject="neuer test" time="2020-02-10T10:38:06+01:00" level=error msg="Mattermost Error" Error=": Password field must not be blank, " time="2020-02-10T10:38:06+01:00" level=debug msg=sleeping intervaltime=10 unit-of-time=second

@Fmyschkin thanks for providing log details, i tested the AccessToken authentication and it works fine in my tests. What mail2most version do you use (there is no 5.19.1 yet :D) my test configuration looks sth. like this:
Username =<EMAIL_ADDRESS>Password = ""
AccessToken = "myaccesstoken"

please check if access tokens are enabled in your mattermost and the user has the correct token and permissions https://docs.mattermost.com/developer/personal-access-tokens.html
Can  you add a sample configuration your using maybe some configuration sideeffects happen that

Hi,
Thanks for your reply. Currently mail2most version 1.5.2 is used.
Please find enclosed our configuration files. We have SAML and LDAPSync enabled.
mail2most_issue35.zip
Kind regards

@Fmyschkin please uncomment the Password='' line and leave it empty and try again.

@cseeger-epages uncommented Password='' but same error appeared:
time="2020-02-18T14:33:46+01:00" level=error msg="Mattermost Error" Error=": Password field must not be blank, "

ah please use a newer version then v1.5.2, v1.6.0 added AccessToken support i would recommend to use the latest stable version v1.8.1

@Fmyschkin can you confirm it it is working ?

closed due to inactivity please reopen if needed

Hi,
installed Version 1.8.1 and currently enclosed Error has been thrown:
op.api2412@f1108:/opt/mail2most$ sudo ./mail2most -c conf/mail2most.conf
DEBU[2020-04-15T13:42:19+02:00] using logging method                          format=text output=stdout
DEBU[2020-04-15T13:42:19+02:00] mailserver                                    server="ex.rubicon.eu:993" status=connected
DEBU[2020-04-15T13:42:19+02:00] checking folders                              folders="[Inbox/Testing]"
INFO[2020-04-15T13:42:19+02:00] processing mails                              folder=Inbox/Testing
DEBU[2020-04-15T13:42:19+02:00] searching unseen                              unseen=true
panic: runtime error: slice bounds out of range [:4294967295] with capacity 2
goroutine 1 [running]:
github.com/cseeger-epages/mail2most/lib.Mail2Most.GetMail(0xc000027280, 0x9, 0xa, 0xc0000272a8, 0x5, 0xc0000272d8, 0x4, 0xc000027350, 0xd, 0xc000027320, ...)
/home/cseeger/go/src/github.com/cseeger-epages/mail2most/lib/imap.go:88 +0x24a2
github.com/cseeger-epages/mail2most/lib.Mail2Most.Run(0xc000027280, 0x9, 0xa, 0xc0000272a8, 0x5, 0xc0000272d8, 0x4, 0xc000027350, 0xd, 0xc000027320, ...)
/home/cseeger/go/src/github.com/cseeger-epages/mail2most/lib/mail2most.go:61 +0x57e
main.main()
/home/cseeger/go/src/github.com/cseeger-epages/mail2most/main.go:19 +0x19f
op.api2412@f1108:/opt/mail2most$ sudo ./mail2most -c conf/mail2most.conf
DEBU[2020-04-15T13:46:46+02:00] using logging method                          format=text output=stdout
DEBU[2020-04-15T13:46:46+02:00] mailserver                                    server="ex.rubicon.eu:993" status=connected
DEBU[2020-04-15T13:46:46+02:00] checking folders                              folders="[Inbox/Testing]"
INFO[2020-04-15T13:46:46+02:00] processing mails                              folder=Inbox/Testing
DEBU[2020-04-15T13:46:46+02:00] searching unseen                              unseen=true
panic: runtime error: slice bounds out of range [:4294967295] with capacity 1
goroutine 1 [running]:
github.com/cseeger-epages/mail2most/lib.Mail2Most.GetMail(0xc000027280, 0x9, 0xa, 0xc0000272a8, 0x5, 0xc0000272d8, 0x4, 0xc000027350, 0xd, 0xc000027320, ...)
/home/cseeger/go/src/github.com/cseeger-epages/mail2most/lib/imap.go:88 +0x24a2
github.com/cseeger-epages/mail2most/lib.Mail2Most.Run(0xc000027280, 0x9, 0xa, 0xc0000272a8, 0x5, 0xc0000272d8, 0x4, 0xc000027350, 0xd, 0xc000027320, ...)
/home/cseeger/go/src/github.com/cseeger-epages/mail2most/lib/mail2most.go:61 +0x57e
main.main()
/home/cseeger/go/src/github.com/cseeger-epages/mail2most/main.go:19 +0x19f

hi @Fmyschkin can you test this with the latest version of mail2most ?

closed due to inactivity, feel free to open again if nessesary.


I can not install on an old docker Docker version 17.09.1-ce, build 19e2cf6

Dear support ,
I have this Docker version 17.09.1-ce, build 19e2cf6
And I can not upgrade it since my box:
Linux server3.net 3.10.0-962.3.2.lve1.5.82.el7.x86_64 #1 SMP Tue Oct 31 10:15:24 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

CloudLinux release 7.9  (Boris Yegorov)
And once I want to install waha:
docker run -it -p 3000:3000/tcp devlikeapro/waha
Unable to find image 'devlikeapro/waha:latest' locally
docker: Error response from daemon: missing signature key.
See 'docker run --help'.

Please advice.

It's docker issue, not the project one. You can ask docker community but likely they'll suggest you to update docker engine


use  "shareNodes": true when creating pool members

BIG-IP version: v<IP_ADDRESS>
extension version: 0.1.0 b1
Descrition:
When you use a template, we don't use by default the  "shareNodes": true option for pool members definition
Example:
"members": [
{
"servicePort": 0,
"serverAddresses": [
"<IP_ADDRESS>"
]
}
]
Due to this, as soon as we re-use the same pool member, the declaration will fail.
We should consider either:

using sharenodes: true by default in the declaration
set it up as an option in the template.

Option1 is probably simpler and will be less prone to errors for customers

This sounds reasonable, tracked internally in Jira MYSTIQUE-87


Contains doesn't work correct with NTEXT and SQL CE

If generating a SQL query using Contains() on a db column of type NTEXT the query breaks on SQL CE using NPoco v4.0.2
Sql<ISqlContext> sql = Sql();

sql.Select("*")
   .From<ReviewDto>()
   .Where<ReviewDto>(x => x.StoreId == storeId);

if (!string.IsNullOrWhiteSpace(searchTerm))
{
    sql.Where<ReviewDto>(x =>
        x.Title.Contains(searchTerm) ||
        x.Name.Contains(searchTerm) ||
        x.Email.Contains(searchTerm) ||
        x.Body.Contains(searchTerm) // Body is of type NTEXT on SQL CE and NVARCHAR(MAX) on MSSQL
    );
}

sql.OrderByDescending<ReviewDto>(x => x.CreateDate);

var page = _uow.Database.Page<ReviewDto>(pageNumber, pageSize, sql);

which generate the following SQL query:
SELECT *
FROM [review]
WHERE (([review].[storeId] = @0))
AND ((((upper([review].[title]) LIKE upper(@1) OR upper([review].[name]) LIKE upper(@2)) OR upper([review].[email]) LIKE upper(@3)) OR upper([review].[body]) LIKE upper(@4)))
ORDER BY ([review].[createDate]) DESC

If I remove the wrapping upper() function around [review].[body] it works.
Alternatively cast the field, cast or convert on [review].[body] to nvarchar before using upper() function.

 And the fact you have to cast it, means if it really had ntext/nvarchar(max) data in it, it wouldn't work.


adds an entity provider for okta groups and users

adds an entity provider for okta groups and users
:heavy_check_mark: Checklist

[x] Added tests for new functionality and regression tests for bug fixes
[x] Added changeset (run yarn changeset in the root)
[ ] Screenshots of before and after attached (for UI changes)
[ ] Added or updated documentation (if applicable)

@kissmikijr should have addressed that now. :)


docker: Add portainer as service in docker-compose.yml

For the sake of simplicity and minimalism, this container will contain only the required tools.


"debug"dependency : Uncaught ReferenceError: exports is not defined

When running a basic SolidStart app (with-tailwind but also bare), pages are correctly rendered (and navigation works thanks to progressive enhancement :heart:) but the JS bundle fails to execute, rendering components useless.
Environment

OS : Ubuntu 20.04.4 LTS
Package manager<EMAIL_ADDRESS>(volta)
Node<EMAIL_ADDRESS>Dev dependencies:

{
    "@solidjs/meta": "^0.28.0",
    "@solidjs/router": "^0.4.2",
    "solid-js": "1.4.7",
    "solid-start": "0.1.0-alpha.98",
    "solid-start-node": "0.1.0-alpha.98",
    "typescript": "^4.4.3",
    "undici": "^5.8.0",
    "vite": "^3.0.4"
}

Steps to reproduce
mkdir solidstart-test && cd solidstart-test
pnpm create solid@next
    ❯   with-tailwindcss
    ? Server Side Rendering? › y
    ? Use TypeScript? › y
pnpm i
pnpm dev

Access localhost:3000 and see this message in the console :
Uncaught ReferenceError: exports is not defined
    <anonymous> http://localhost:3000/node_modules/.pnpm/debug@4.3.4/node_modules/debug/src/browser.js?v=3dab94c5:7
browser.js:7:1
    <anonymous> http://localhost:3000/node_modules/.pnpm/debug@4.3.4/node_modules/debug/src/browser.js?v=3dab94c5:7
    InnerModuleEvaluation self-hosted:2378
    evaluation self-hosted:2329

Yeah we are aware of this bug and should be fixed this week. Thanks for reporting!

Should be fixed in alpha.99

It works perfectly, thanks a lot !


Contact Info

Add link to footer or bottom of page linking to this github repo or the sponsorship page.

Resolved in release v0.0.9


[FEAT] Callback decorator (and related things) for modals

Is your feature request related to a problem? Please describe.
I'm always frustrated when no callback decorator for modals. In some cases it allows for cleaner code than usage of wait_for_modal
Describe the solution you'd like
Modals should have the same persistent callback system we use for components, including callback decorators.

Should we have a common callback decorator for both component and modal, or separate?

Imo separate is better UX