Announcement: Proposed approach for windowing in Project Reunion

Windowing in Reunion
We are excited to share some news with you today around the future of windowing for Windows developers. We have been listening to your feedback and concerns for this space over the years and we believe the approach we have chosen will address these in a positive way. This area has a lot of history (some of the features you use today, such as sizing and positioning windows, has been around since the first version of Win32) and a lot of investment in the developer community (your multi-windowed apps, your customized title bars, your customized dialogs and tool windows to create unique experiences, etc.) - we want to acknowledge and honor that as we go forward.
This post will outline our approach from a high-level perspective, our guiding principles, and our goals for the windowing space for Project Reunion. We are eager to get your feedback here, and we are open and ready to adjust our plans based on what you tell us. Nothing is set in stone - we are starting this journey here today, together with you.
A unified windowing space
In the past we have had two very different ways of "doing windowing" for Win32 and UWP - one very powerful but complex to work with even for basic windowing scenarios; one very limited in capabilities but easy to achieve the basics with.
For UWP we have been in a constant state of "catching up" on core functionality, and never being able to. While for Win32 we have been in a state of non-innovation, leaving developers behind because we have focused on bringing new features only to UWP where we can guarantee that guardrails are in place.
We heard you - this situation is not making anyone happy and moving between the two worlds is hard.
With Project Reunion we are taking a bold stance - we want all Windows developers to have the power of Win32 windowing at their disposal, but we also want to provide easy to adopt APIs that can provide consistent experiences across apps, as well as easy to use APIs that lower the bar of entry for new developers.
We also want the windowing model to be fundamentally the same, so that we create a familiar way of working for developers regardless if you chose UWP or Win32 as your application model.
Our approach in order to achieve this? A layered set of APIs.
Layers of APIs
We acknowledge that if you started with CreateWindowEx and used HWNDs for your app, you want to be able to continue to do so going forward. A re-write of your main window proc is just not going to be feasible. Therefore, we are bringing most of the windowing primitives from USER32 to Reunion. This gives you access to powerful APIs when you need them.
We also acknowledge that some things are really hard to do, or to get right for all situations, with the USER32 APIs, so we bring you AppWindow - a high-level windowing API surface that gives you access to a modern Windowing Model with an easier to use surface for areas where we have gotten a lot of feedback in the past, or where we want to help drive innovation, consistency in experience, or make it easier to adopt new features.
How is this different from the old Win32 vs UWP situation?
First, all these APIs are accessible to you regardless of process model - both UWP and Win32 have access to all the layers of the APIs. There might be some behavioral differences when calling the low-level APIs due to the security context of your app and whether it is running in a container or not. For example, the fact that we give you access to
lower level APIs from UWP does not mean we give you access to other processes or their windows, you’ll only be able to modify your own windows - the security context for UWP is not changed.
Secondly, we are giving you the ability to freely move from one layer to the other regardless of where you started from.

Started out by calling CreateWindowEx and got an HWND, but now you want to go into CompactOverlay? No problem, get an AppWindow object for your HWND and use the high-level scenario APIs!
Started out by creating an AppWindow, but now you want to tailor your experience beyond what the high-level API allows you to? No problem, get the HWND for your AppWindow and pass it to the lower-layer APIs.

Existing apps and their adoption to Reunion
For Win32 we touched on the approach already, by moving most of USER32 to Reunion we hope that you will have a straight-forward and easy path to adopt Reunion. Note that we are not saying that everything in USER32 will be available in Reunion and that there will be no work needed to move your Win32 app to Reunion - there will be parts of USER32 that will not being carried forward, but we will try to keep this to a minimum and limit the apps impacted.
For UWP the story is a little bit more nuanced. UWP have multiple windowing currencies, each with different limitations and life-time management. We are not going to preserve them all and move them to Reunion. As we mentioned earlier we are unifying the windowing model, this means changes to UWP that will require work. We are working through the details of the migration story for UWP depending on where you start from (CoreWindow, ApplicationView, AppWindow), and will start sharing that with you over the coming months. Our aim is to make it easy to migrate most UWP projects to Reunion for the windowing space, and we will do everything we can to help you come with us on the Project Reunion journey. If you have worked with AppWindow in UWP, you should be familiar with what we have in mind.
More details please!
We know that this post is light on technical details and completely lacks API shape information. This is intentional. We first wanted to share our approach for this space with you, to allow you to give feedback on this and influence it. As we align on the approach and start to move forward on the details, we want to design the APIs in the open together with you, not hand down a ready-made solution that we've designed in a vacuum. We hope you agree that this is the right approach, and we look forward to work out the details together with you for the initial release and for many years to come as Reunion grows.
Starting the journey together with you
Over the coming months, we will create functional and API specs here on GitHub and we are looking forward to a great partnership with the community. As a first step of this partnership we'd like to share our guiding principles and high-level goals for the windowing area as these will help inform everyone where we're coming from and what we're aiming for.
Guiding principles for Reunion windowing
We will support developers "where they are" – we will aim to support existing Win32 app developers with limited rewrite
of their existing code; we will aim to support existing UWP developers with an easy transition from AppWindow and
ApplicationView to Reunion windowing APIs.
We will design our new APIs with existing developers in mind, such that we do not leave existing Windows developers
behind or alienate them with "yet another solution"; for developers new to the Windows ecosystem we will strive to have
a low barrier of entry.
We will provide a full stack of APIs – powerful low-level primitives, targeted at expert developers that allow them to
innovate and create experiences beyond our own roadmap and imagination; high-level scenario APIs that allow for any
developer to light up our new features and take advantage of new form factors at a low cost.
Goals

We will provide a global windowing currency across Win32 and UWP.
Win32 apps shall be able to recompile to Reunion with only limited code changes for the windowing space.
The windowing API for new projects, whether they be Win32 or UWP, will be a high-level, easy to use, API that follows
modern development principles and patterns.
We will provide a migration path from UWP AppWindow API onto the high-level Reunion Windowing APIs that is mostly automatable.
Developers shall have access to the full spectrum of windowing APIs (both high- and low-level) with as few restrictions as possible. Ex. there may be a need to avoid certain window messages, events, or calling patterns when mixing between APIs of different "levels".

Non-Goals / Negative Goals

It is not our goal to bring the current versions of UWP AppWindow and ApplicationView APIs to down-level OS versions past where they were introduced.

Open Source
It is our goal to provide as much of the windowing stack for Project Reunion as Open Source as possible. We will listen to your feedback on what you need in this space and adapt as we move forward.

Is there a plan for handling the pain (for Microsoft) of eternal backwards compatibility? As developers opt-in to Reunion it would be good to embrace the idea of deprecating functions in future versions, in order to provide the best APIs possible. Though I appreciate you probably don't want to think about past v1 release, I just wanted to point out how bonkers it is that Win32 still has support for 16-bit APIs (and even in UWP e.g. LocalAlloc and co).

New APIs making use of LocalAlloc have been added as recently as Windows 8. LocalAlloc being present in UWP also hurts no one and makes porting old code easier, so it's a positive.
However I agree that we could drop some APIs like SetWindowLong (which is 1:1 replaced by SetWindowLongPtr)

Questions:

What is a "windowing currency"? (Please use plain English in all outward facing comms.)

What do you want from us? I presume this thread will just fill up with random complaints and feature requests. Is that what you want? Do you have any questions you need answers to?

I'm just advocating for allowing old APIs to be removed, or updated, and for new APIs to be added. I guess if Reunion is shipped with the app, that would be reasonably trivial to achieve.

I'm just advocating for allowing old APIs to be removed, or updated, and for new APIs to be added. I guess if Reunion is shipped with the app, that would be reasonably trivial to achieve.

As Raymond Chen keeps reminding us, source compatibility is important to adoption. There is code out there that started with Win16 and is probably still with us today.

Win32 apps shall be able to recompile to Reunion with only limited code changes for the windowing space.

Regarding this goal, I noticed that Win32 was explicitly mentioned. For clarify, can someone confirm if UWP will also recompile to Reunion with limited code changes for the windows space? I apologize if the question doesn't makes sense, I'm still wrapping my head around Project Reunion

Win32 apps shall be able to recompile to Reunion with only limited code changes for the windowing space.

Regarding this goal, I noticed that Win32 was explicitly mentioned. For clarify, can someone confirm if UWP will also recompile to Reunion with limited code changes for the windows space? I apologize if the question doesn't makes sense, I'm still wrapping my head around Project Reunion

We will provide a migration path from UWP AppWindow API onto the high-level Reunion Windowing APIs that is mostly automatable.

Great questions Rafael! I'll try to address them as best I can.

What is a "windowing currency"? (Please use plain English in all outward facing comms.)

The object/construct you use to reference a window. In Win32 this is HWND, for UWP it is CoreWindow, ApplicationView and AppWindow depending on what APIs you are using. We want to make sure you can reference a window in the same way across the different app models, and also make sure that as a developer you don't have to think differently about a window based on what API created them.

What do you want from us? I presume this thread will just fill up with random complaints and feature requests. Is that what you want? Do you have any questions you need answers to?

I know that this announcement is light on technical details that may be needed in order for you to give deep and meaningful feedback on how this approach for windowing will work, benefit, or impact each of you and your specific app needs. But in general I want to bring windowing to top of mind of the community in order to set the stage for the specs that will start to show up for this space in the near future.
A couple of questions I want you to think about and try to answer as we continue the conversation (some of it on this post, some of it on new posts about specific features):

Do you think this we are taking the right approach for this space? If not - what are we missing?
Do you believe that a full layer of APIs is truly needed? (Or do you perhaps think one part or the other of the layers are not needed (I don't want to put words in anyone's mouths, so I'm being vague here)
Does bringing a lot of the user32 APIs to UWP mean that you are more likely to adopt UWP for future projects?
Does having access to a high-level windowing construct from the platform itself (AppWindow) add value to your existing Win32 app(s)? (this may be hard to answer until we share more of the feature details)

Is there a plan for handling the pain (for Microsoft) of eternal backwards compatibility? [...]

We are thinking hard about this one. As I wrote above we are targeting "most" of the windowing primitives, not all. This is intentional - we will weigh app compatibility and usage against "cleaner platform" and potential tradeoffs of not bringing an API forward. As part of the next steps we will be sharing what we believe are a good "first set" to bring forward and have a communication with you to align and adjust as needed.

From an appearance standpoint, my hope is that I can still use the best of what CoreWindow offers, but with the flexibility of some Win32 window features.
For example, the most asked for things for UWP CoreWindow has been things like custom window geometry and real transparency.
Easy Acrylic is still amazing so we don't want to lose that, so imagine being able to combine Acrylic with custom geometry without needing to write a custom graphics pipeline.

Am I right in thinking that the initial version of this, when it is added to Reunion, will take us all back to the current windowing offered by Windows?
Are there plans and thoughts for adding new innovation to windows and windowing?
There was talk at Build 2018 I think, about actual new modern windowing concepts there were to come to UWP.  Will these come for all Reunion apps now?  And how far back will these innovations be supported in?

Does bringing a lot of the user32 APIs to UWP mean that you are more likely to adopt UWP for future projects?

@rkarman
When working on UWP apps specific pain points, compared to Win32 apps, for me have been so far:

The UWP titlebar reserves some non-clickable space to the left of the min/max/close buttons. This makes it impossible to re-create custom Win32 titlebar experiences in UWP apps in certain cases. See issue for https://github.com/microsoft/microsoft-ui-xaml/issues/1888 for more details.
When writing an app which will be run in the background most of the time, Win32 apps allow the running app window to be hidden from the taskbar. This is currently not possible for UWP apps. Some months ago, an API like AppWindow.TryHide(Boolean shownInSwitchers)` was spotted in an Insider SDK release which seems to be what I'm looking for here. Being shipped in an Insider SDK only for now though, the fate of this API is unknown to me (it might be shipped at some point, altered, or even removed - never to be released). Will this API be shipped and when?

Being able to handle more than one window from the same thread / message loop is key in Win32 and is really missing in UWP (unless I missed an API).

one very limited in capabilities but easy to achieve the basics with

I always found the UWP windowing options to be more complicated than I would have liked. I would never have called them "easy". Making them ever "easier" in the future would be great.

The explanation of laying of APIs isn't clear. It sounds like all APIs will be available everywhere and does not explain how they will be layered.

How does https://github.com/microsoft/microsoft-ui-xaml-specs/pull/71 relate to this?

Being able to handle more than one window from the same thread / message loop is key in Win32 and is really missing in UWP (unless I missed an API).

AppWindow allows that, but ContentDialog can only be opened once per thread at a time. Which means if you use that you're forced to use threads anyways.
Worse even, XAML islands in a thread currently leaks if I just exit the thread after the window is closed, so I had to implement my own thread pool to keep the message loop running once the window is closed (because the Windows thread pool doesn't do that) to allow the cleanup to be performed correctly. Fun times.

Trying to reply to a couple of items in one go since this is not a threaded forum... I will also incorporate some of the feedback into the original issue so that new readers don't have to spelunk through the comments to get the some of the clarifications made here.
@LanceMcCarthy -

From an appearance standpoint, my hope is that I can still use the best of what CoreWindow offers,
but with the flexibility of some Win32 window features.

This is right at the core of what we are aiming for with this strategy.

Easy Acrylic is still amazing so we don't want to lose that, so imagine being able to combine Acrylic with custom geometry
without needing to write a custom graphics pipeline.

I can't yet detail the specific feature that can be mixed and matched between the layers here, but our goal is to limit the restrictions. So that, yes, if/when you are able to change the shape of your window with the lower level APIs you can do so even if you used a higher level API to say apply Acrylic.
@mdtauk -

Am I right in thinking that the initial version of this, when it is added to Reunion, will take us all back to the current
windowing offered by Windows?

Not sure I parse this the right way, so please be patient with me as I try to answer it.
Will you be able to do a lot more with windowing from UWP? Yes. With the initial version you will be able to do a lot of what Win32 apps can do today in terms of window customization and manipulation. But not to windows outside of your own process.
Will the high-level Reunion AppWindow object be more powerful than what is available in UWP today through CoreWindow/ApplicationView, and UWP AppWindow? Depends. We are working on the roadmap and engineering plan, but our intent is to make it available as early as possible and that might limit the amount of features we include in the first release. But we do have ideas and plans for more, which leads me into the next part:

Are there plans and thoughts for adding new innovation to windows and windowing?

Yes, there are. 😀 We have some interesting features that we want to bring to the world, but we are not yet ready to talk about some of them. As for the 2018 //build/ talk - yes, that was me doing that talk and that was the plan we had at that time. The high-level goals are still there in that we keep seeing innovation in user interaction and device types, and we want to make sure that our windowing model is capable of handling this.
But will all the features we talked about back then come to Reunion? Yes and no. Some feature are no longer relevant, some are being satisfied by access to the lower-level APIs, some are still on the roadmap though and when we are ready to we will bring them to Reunion. More details on the specifics as we start to publish specs and along with them a roadmap - which we will adjust based on feedback and needs of the community.

And how far back will these innovations be supported, Windows 10 Threshold / Windows 8.1 / Windows 7?

I am truly sorry to not be able to talk to this part in details just yet, but this is something that is being worked on across the Project Reunion as a whole. What I can say is that we will do our best to align with the larger project's goals to the extent that it is technically feasible. I hope to have more details to share during fall.
@Felix-Dev -
Regarding the Title Bar customization - this is great feedback and something we will make sure is covered in the specs for that feature area.

When writing an app which will be run in the background most of the time, Win32 apps allow the running app's window(s) to
be hidden from the taskbar. [...] Will this API be shipped and when?

This API will be part of Reunion. Not necessarily with that specific shape, but it is part of the requirements I have for the Reunion AppWindow, yes. There should be more info coming with that feature spec.
@mrlacey -

The explanation of laying of APIs isn't clear. It sounds like all APIs will be available everywhere and does not explain how they
will be layered.

The higher-level APIs will all be built using the lower-level primitives. There will be no "black box" and completely different stack powering the higher-level APIs like today with the difference between CoreWindow and HWND.

How does microsoft/microsoft-ui-xaml-specs#71 relate to this?

XAML is a framework that builds on, and sometimes abstracts, platform constructs. As such it will in some cases provide it's own version of similar objects in order to provide developers with a familiar programming/object model. XAML is building on top of what we provide at the platform layer, and we are working across the teams to align between the different layers and make sure we can support each other's roadmaps and visions.
some general closing comments for this reply
For everyone on this thread - thank you for your comments and feedback so far, I really appreciate this.
If I've missed answering a question it is not on purpose, so please forgive me and let me know so that I can try to answer that too.
If there is something that is still unclear, please do not hesitate to tell me and I will do what I can to bring clarity (and again, I will update the original issue with some of the details from the comments here).

Sorry to say, but I got even more confused how things will shape up with Reunion.
Before Reunion's announcement it seemed that UWP adoption was in a slow and steady rate, but now with Reunion, replacement of C++/CX with C++/WinRT (with related productivity drop), uncertain future for .NET AOT with WinUI, alongside other attempts to drive UWP adoption, it seems to me that most of us are better off with outdated Win32, Forms and WPF until everyone at Microsoft can finally make their mind what Windows development should be like.
As for the proposal, it looks good, assuming it gets delivered and doesn't get dropped like many other Windows 8 - 10 related stuff.

@rkarman will any new API additions be added to the OS as well as Project Reunion, for those of us that don't need to consider backwards compatibility?
An area that I would love to see made simpler in Win32 would be custom title bars. In our apps we render 100% of the UI including the title bar and whilst we've already done it, it just seems like a hack (we have to process all mouse input by returning HTCLIENT because Windows prevents WM_LBUTTONUP for anything which isn't the Close button).

Is this part of the effort @marb2000 was doing for windowing with WinUI?  For example, I recall there being some sort of proposal over on https://github.com/microsoft/microsoft-ui-xaml-specs.

This document has hard line breaks at the end of each line which makes it hard to read when it wraps at larger font sizes. IMO this is always the way we should have done it - providing a glide path from Win32 so folks can make incremental progress on their giant Win32 apps. Big thumbs up.

I have some questions on the scope of this plan (which, by the way, I applaud). Will this mean that I can place arbitrary HWNDs in my AppContainer window, or arbitrary WinUI controls into my HWND? Will this mean I will be able to take an HDC from GDI+ and use APIs like those in Windows.UI.Composition on it?
Most importantly: Will there be a way to write drawing code under the assumption of 100% DPI, and have it automatically scaled up (locations, thicknesses, corner radii, everything) to look exactly the same at higher DPI settings without my having to do math with my locations/thicknesses/etc? WPF does this for me, but that technology has stagnated. While Windows Forms is much more active and lightweight, which is why I prefer it, high-DPI drawing in GDI+ is squarely the responsibility of the developer, and it’s hard.
Finally: You mention lifting some of the APIs in user32.dll into Reunion. Does this actually mean we will be (hopefully) seeing code in this repo that was once in user32.dll, gdi32.dll, or other files? If so, I can’t wait for the day when that code arrives. Thanks so much!

Does this mean we'll finally have the ability to place a window where we want on the screen in UWP? And set its state (minimize, restore, maximize)? That would be insanely awesome!

I want to know if this "new Windowing system" will provide a way to create transparent borderless windows or custom chromes.

I feel I need to chime in here, although I'm not optimistic about the outcome. I also feel like I should be dishonestly strongly biased towards Win32, in hope that a proper middle ground were to be achieved, but I will try to refrain from it.
Also note that this all is written from point of view of a programmer, who writes Win32 apps that reguarly run on Windows Servers with PS/.Net/WoW uninstalled, in nano containers, and on old versions of the OS. I also might not be completely up to date with current development of Windows internals.
Subjective
The biggest problem of UWP windowing is that it's apparently done by young, passionate and optimistic people, who wanted so much more, much better windowing system than Win32 offered, but were (understandably so) scared away from expanding on Win32 by existing complexity. Who decided they could do better starting from scratch, but ultimately weren't able (for reasons irrelevant) to exactly and correctly duplicate the vast array of existing features and functionality.
As an user, if main window of the UWP app is sluggish, feature incomplete, and feels different then I'm going to be unreasonably critical to the rest of the App. And that doesn't even touch controls, buttons, etc.
Take a lack of Clear-Type text rendering as an example. On High DPI displays it's not that bad, yet usually still perceivable; but not everyone has those. On a simple app, with a few buttons, who cares, but it becomes issue if it's something you need to stare at longer or often. I mention this because for two decades, text rendering is/was something that greatly differentiated Windows from other OSs for me, especially as a workhorse system that I have to stare at for 12 hours a day.
Speculative
That's why the whole thing failed. It's irrelevant if the underlying technology is great. Although it's not; simplest UWP apps still randomly crash, often from immediate unavailability of GPU memory, and you can't program reliable OOM behavior. It's also irrelevant if UWP is only way to access new APIs. That results in nobody using them; thank God for WinRT, but even that still seems like a band-aid in my scenario.
Constructive
I understand noone wants to touch USER32, but in order to move forward, you'll need to bite the bullet. And to make people like Raymond Chen or Larry Osterman do it. Or heavily review and supervise it. Perhaps also modernizing it by splitting USER32 to client/server, due to the way w32k is built is a source of continuous flow of security bugs, but that's not point of this topic.
My basic tl;dr would be: MERGE. Merge all windowing into USER32 (meaning the client part in regards to the previous paragraph) and merge all rendering to DWM.
Remove all the dozen of different window border/titlebar/sidebar types and reimplementations from UWP, and move them to USER32/DWM. Merge all similar. Where possible make those things a Common Control. Where not possible (titlebar styles) make those available under new window exstyles. OK, the bits are probably all used up, so through SetWindowLongPtr, it's not that hard to add a few DWORDS to WND struct, and branch in xxxDefWndProc.
Make this support granular. Not just single flag. Add simple API abstracting typical use cases for WM_GETMINMAXINFO, slighly more complex for WM_NCCALCSIZE ...and here, ffs finally after all those years fix window border rendering. It even affects File Explorer of all applications. I'll gladly provide guidenance and screenshots if it "Doesn't look like anything to you." ...hell, I'd probably work for free on anything I mention in this diatribe.
Next, move background brushes support to DWM, again make it accessible to everyone through DwmSetWindowAttribute. It's just combination of blending bitmaps and blur shaders. There's no legitimate technical need for UWP App model in this.
DWM really could use some work anyway. E.g. improving DWM composition to handle transparency on more than single layer. Since Window 8.1 we can have nested layered windows, so update DWM so that children windows too support no redirection bitmap and can be rendered by other means (accelerated DirectWhatever).
Next thing for DWM, to catch up to the other significant OS manufacturer, is support for (can't recall the proper term) flattening of all semi-transparent layers. I.e. DWM sending notifications (if registered for) to a window whenever the content behind changes, including the final bitmap, so that the application can render Clear-Type text (or any sub-pixel anti-aliased content) over it. There's of course a lot of space for optimization here, like not providing this during animations (where those parts would use grayscale AA), or if it's determined that the part of the backing texture for the window that will contain antialiased pixels is already opaque.
I might have been overthinking the above a little, but the point stands.
This Reunion initiative can be really great thing if it starts addressing one of the major discontent of people, who work with Windows and stare at applications for long hours. Inconsistency. Introduction of UWP (Metro, Modern, ...) style GUI added a huge amount of inconsistencies. Inconsistencies, even not perceived, increase mental strain put upon the heavy users. Focus on unifying GUI/UX and the positive response from public will surprise you.
Start fixing small stuff, basic stuff that's broken for years and should not be. Like window borders: breaking top border, bad transparency at 200% dpi, losing borders when extending client are to titlebar (the Explorer issue mentioned above). Fix default minimum window size so that minimize button isn't pushed out of bounds. Fix braindead resizing of taskbar icon, especially pinned, and add API to query proper size. Drop all those reinvented custom menus, merge them to CreateMenu API, merge the functionality for all to use, or at least work hard on unifying the design. Right now you can get 5 different menu designs within 10 clicks from desktop from freshly installed Windows.
Okay, I'll stop now, it's already way too specific when you were calling for high-level feedback.
Concluding
Start doing the above, and you'll be on the right track.
Don't add Reunion as another windowing target. After plain Win32 we had MFC, WinForms, WPF, flavors of UWP, now WinUI. Nobody will bother to even try to learn another.
Otherwise, well, the in-browser apps and Elektron-style abominations will take over the application ecosystem. It will became irrelevant what OS the regular user is running. Nobody will be actively choosing Windows, nor any other OS, they won't care which OS they use. Pretty logon screen won't change that. The legacy apps will start disappearing faster, rendering major selling point of backward compatibility irrelevant. And Windows-exclusive productivity, work and content-creation is only a small part of the market.

Thank you for sharing your plans. We have a UWP app in the store. We are beginning migration out of the store due to lack of third party tooling support for UWP. In defence of UWP, we have been able to offer our customers a brilliant look and feel that we were unable to achieve with our Win32 apps.
We are beginning our port with WinUI Preview 3. We expect the port to be a 6-9 month journey. Should we start building our new UI with Window or Page in order to make the Project Reunion journey easier for ourselves over this term?

@rkarman I have removed some End-of-lines in your post so people can wrap the text. I hope you don't mind :)
About the WinUI's Window work.
Basically, the Microsoft.UI.Xaml.Window (MUX.Window) exposes a high-level Window APIs specifically to consume XAML. For example, this is the reason why there is a Content property of type UIElement. It uses the UWP or Win32 windowing APIS depending on the execution environment. For example, this code:
Window window = new Window();

internally does a Win32's CreateWindow call, generates the message loop, instantiates the XAML host,  and so forth when WinUI 3 is running in Desktop.
Project reunion will improve these underneath windowing APIs, so MUX.Window will be able to make use of it. It will simplify the WinUI's windowing code, or even we could deprecate WinUI's APIs if they don't make sense anymore.
Does this make sense?

@marb2000 Are you saying start with Window, not with Page as Page might go away?

Since everybody is commenting :)
I don't have any particular opinion about "Project Reunion", all I wanted to mention is that 100% of my application on the Windows platform are written 100% using the Win32 API, and I don't have any plans to change that any time soon, even for new projects, and the reason is that as far as I'm concerned this is the best API to use on Windows:

It is stable
It is extremely well documented (despite all MS efforts in destroying the MSDN and associated blog posts by moving things around and never fixing the links)
It is consistent in appearance and design, with well documented visual language (order or menus, behavior and meaning of controls)
It does everything you want
It does behave (mostly) predictably in the way error and success conditions are processed
It does not throw exceptions or garbage collect by default, you can if you want, but by default it is reliable and can run unattended on a server without crashing
It can be statically linked so you get one single executable without any external dependency so you can just share the .EXE around and you know it will most probably run fine on any Windows machine around, from Windows 95 to Windows 10, without having to install any pre-requisite or runtime modules

So yes, the API is not super pretty, it's not "modern" or "fancy", but it just works, and for somebody like me who write tools, it's what matters, because that means I spend more time on actually doing my work than in doing support.
I don't think people keep using Win32 because they are back in the past, they just use it because it's a sane choice that get the work done and will not be deprecated two, five or ten years later (I'm still actively supporting some tools that has change history that go back to 1997).
Side notes:

MFC is an abomination, don't use that, it's like the worse possible way to abstract a UI :D
COM is a good idea, but it's horrible to use, so I avoid using it if I don't have to
MSHTML is horrible, but I'd rather using that to provide some HTML support to a pure Win32 GUI application than using 70 megabytes of Electron

@Dhebug Actually, given the current state of C++/WinRT tooling, you would be surprised how much productive it is to use MFC instead.

I can agree to the sentiment: I've been trying to adopt WinRT APIs in my Win32 application and each time I've been severely burned by cryptic errors nearly impossible to diagnose, for example #101.

@VagueGit

Are you saying start with Window, not with Page as Page might go away?

Sorry, I didn't mean this. Page won't go away. Page is placed as a Window.Content in UWP and you can use it in Desktop as well. Page is a great pattern for Single Page Apps or scenarios that requires navigation history.
I was talking about the hypothetical case of MUX.Window having an API that is a dupe or subset of a new Reunion's Windowing API. Then, WinUI could consider mark it as deprecated (if possible).

@marb2000 Thank you for the clarification regarding Page/Window. Tools vendors who do not currently support UWP (particularly report writers) may have more work to do to support embedding a control in a Page, where they might already support a WPF Window. For us there may be greater chance of finding 3rd party tooling support for tabulated reports in the near term, if we migrate from Page to Window. Does that seem a reasonable reading?

@VagueGit

Tools vendors who do not currently support UWP (particularly report writers) may have more work to do to support embedding a control in a Page

Thinking aloud, they can expose the report as a UserControl or Control and this control can be hosted via Page or Window or other UI element, right? But I'm guessing because I didn't use a report component in years, so I'm not very up-to-date. I will let other coworkers chime about it.

Yes @marb2000 typically a Control, but the range of 3rd party controls for UWP is a subset of those available for WPF. It may well be a sandbox/permissions thing in UWP, but there was clearly a deterrent of some sort blocking tools vendors. There may well be a perception among tools vendors that the road to a WinUI Window is easier than to a WinUI page. Perhaps there should be a discussion/guidelines for tools vendors as part of the process.

Currently Win32 apps need to handle full screen manually while UWP apps get it for free. Please provide a full screen API for Win32 apps since many implementations are bad. Similar to UWP full screen where you can hover on the top or bottom to see taskbar of titlebar, Win32 apps should also do that. Also all Win32 windows should support Shift + Windows + Enter by default without any dev work.

win32 apps don't have access to the UWP's CompactOverlay. win32 apps can keep their windows on top but they have issues with virtual desktops:
https://bugs.chromium.org/p/chromium/issues/detail?id=841152
https://bugs.chromium.org/p/chromium/issues/detail?id=1016848
It defs aligns with Project Reunion's goals but then again, y'all also rejected updating those styles 🙄

@Poopooracoocoo Since you just mentioned, I was thinking if #166 could also draw things like the UWP full screen button and handle full screen just like UWP.

win32 apps don't have access to the UWP's CompactOverlay. win32 apps can keep their windows on top but it's not as easy to implement and they have issues with virtual desktops :

One of the main goals of this approach is to give Win32 apps access to CompactOverlay

@sylveon sorry, that comment was copied and pasted from a duplicate issue I made

Does bringing a lot of the user32 APIs to UWP mean that you are more likely to adopt UWP for future projects?

Yes, for me. I've had a few projects I've started in UWP simply because it's a modern platform and it looks better. Somewhere down the line, I realized I didn't have the APIs or capabilities I needed.
Does this question imply that UWP is "here to stay"? If UWP apps do get support for a ton of missing APIs that have hurt WinRT since the beginning, it would be a much more viable platform. One would be able to use powerful APIs and still keep all the other innovations that UWP has - like sandboxing, app lifecycle, power management, security. Once Reunion is in a usable state, is Microsoft going to market UWP as the first choice platform for new Windows apps?
My concern here is - is Microsoft looking to modernize Win32 and sprinkle in innovations from the UWP world on to it so that UWP is no longer needed, or is Microsoft looking to make UWP powerful enough that it stands on its own? Currently, it seems like the answer is both - but I'm wondering long term when something new and not-widely-adopted like UWP could be possibly deprecated in favor of a better Win32 stack.

@prayaas-a If your projects are internal then you can already use User32 APIs with some hacks.

would be nice if caption buttons in title bars faded on hover like win32 buttons: https://github.com/microsoft/terminal/issues/6293

My concern here is - is Microsoft looking to modernize Win32 and sprinkle in innovations from the UWP world on to it so that UWP is no longer needed, or is Microsoft looking to make UWP powerful enough that it stands on its own? Currently, it seems like the answer is both

One concern I think devs share is choosing the wrong option and having to start again. Like I think @prayaas-a is saying. We would like a single model which combines the power of Win32 with the gloss of UWP. Where we develop a store app we get a subset of functionality. Where we develop for desktop we get a different subset. But both should be from the same superset of capabilities so we can easily move from one to the other without learning a new tech.

@VagueGit You can actually publish desktop apps to the store not just UWP apps and can use all functionality.

@prayaas-a For me it looks like cleaning up the attempts done with WinRT, UAP, UWP, iOS/Android integration projects, bringing the improved COM model from WinRT into Win32 and pretend Windows 8 - 10 never happened.
Basically Reunion seems to target what Windows 8 should have been all along, just after so many years pushing UWP, it seems to be a very long roadmap to get everything done.

@pjmlp No it doesn't. Windows 8 is an OS and WinRT is just a small part of it. There a lot of things that have changed not just WinRT.

WinRT is just a small part of it

WinRT is Windows 8.

@jtorjo Windows NT 6.2 is Windows 8 not WinRT. WinRT is just a technology inside Windows 8. Windows 8 brings a lot of improvement other than WinRT. They did use WinRT technology for Metro but Metro isn't WinRT and Windows 8 isn't WinRT.

@Jaiganeshkumaran @jtorjo Please take your discussion elsewhere, you're spamming folks with notifications that aren't relevant to this thread.

@pjmlp No it doesn't. Windows 8 is an OS and WinRT is just a small part of it. There a lot of things that have changed not just WinRT.

Feel free to be pedantic, I am pretty sure everyone else got my point.

The recent posts not revelant to this issue should be at least marked as off-topic or really just deleted (including this comment). @rkarman to look over that.

As you are evoluting the whole UI layer, I really want you to rewrite Visual Studio with it, to prove its functionality, and improve Visual Studio's performance.
UWP was bound to a security model that's unsuitable for VS. But since you are going to decouple them, I want VS to be a real-world sample of best practices.

I know this is about the API, but I'm wondering to what degree the API changes will involve implementation changes for UWP.
There is still a lot of jank with the UWP windows that causes problems that Win32/WPF/etc. apps don't have:

Apps don't always respond to Window size changes; unique to UWP and affects even built-in apps like Bing Maps.
UWP apps depend on explorer.exe running in order to function properly (e.g. respond to Window size changes). This is a bizarre dependency for modern apps
Built-in window components (e.g. dialogs) don't handle mixed-DPI well; I'm not sure if that's due to the component implementation or the windowing system, but I haven't seen anything like it in Win32 apps.

1
2
3

Will UWP/WinUI windows under project reunion be built on the same foundations as the more reliable Win32 APIs?

@nCastle1 Regarding item 1: That's a long standing compositor bug. Microsoft is very aware of it, and I always remind them of it.

have they also seen the issue of https://github.com/File-New-Project/EarTrumpet/issues/349 and https://github.com/sourcechord/FluentWPF/issues/42 (among many others) or the 1903 snap bug?

See this comment: https://github.com/File-New-Project/EarTrumpet/issues/349#issuecomment-647871336

Adding #203 to this thread. We will incorporate this into the requirements for window positioning and behavior for FullScreen for Reunion windowing.
Also an update on this thread in general:
Thank you all for the valuable input and feedback on this topic. We are now working on incorporating this and writing up the initial API proposal for this area.
Next step will be to get the feature specs in order and post them here in GitHub (they may end up coming from other PMs than me, so I'll make sure to update this post with links to PRs). As part of getting the specs in place we will continue to monitor this thread, but once the PRs are out we hope that you will engage there on the particular feature areas as well.

Is there a compiled list of windowing problems from Win32 to WPF and UWP?
Can Reunion offer fixes to long standing windowing and window painting problems?
Reunion is essentially opt in, so if some of these fixes require code alterations - that is a sensible time to introduce it.
Rather than just using Win32 as a baseline, and not trying to build on what is already there.

@mdtauk We should make one. We can start with things like WPF's & UWP's incorrect handling & drawing of the nonclient-area, WPF per-monitor v2 dpi, WPF's incorrect WindowChrome default values, UWP's missing window borders, Win32's very inconsistent window border(s) (for some strange reason this doesn't happen in dark mode), and add to the list.

but will microsoft actually do anything about those issues?

After all the code rewrites we went through since Windows 8, and .NET Core introduction, I am very much opposed to anything that Microsoft ask us to rewrite, unless it is for a 100% from scratch application.
So however these bugs get fixed, hopefully it isn't by asking us to do yet another rewrite.

I'd like to draw attention to a flaw in the implementation of some of the existing ApplicationView APIs. I don't entirely understand the reasons why, but apparently some of the APIs can cause a nested message pump, which has the potential to cause all sorts of problems - see this comment for details https://github.com/microsoft/microsoft-ui-xaml/issues/3297#issuecomment-694646359. It would be good if the new implementation avoided this if possible, or if not possible perhaps it could provide both sync and async alternatives for such APIs (where the async version would not have this problem).

Reentrancy is normal and expected in Win32

Reentrancy is normal and expected in Win32

Reentrancy is something way different from a nested message pump. Nested message pumps in general are evil because they can silently drop messages. Also, the huge majority of the win32 API will just do some computation and return a result, not call back into user code, and certainly not run a message pump. You probably had some specific scenario in mind, but as a statement about "the win32 API" this is simply wrong.
As far as the topic of nested message pumps is concerned, some applications have the requirement that the message pump be consistently provided by the hosting application, for example because it uses WM_APP style messages (sent to the application message loop instead of targeting a HWND) or does other processing before blocking for the next message. For example WPF interop also requires cooperation from the message loop, as do many low level frameworks, requiring a way to peek at messages - local message pumps usually don't provide that and cause lot of annoyance in interop scenarios.
Async APIs are the proper way to implement this because they allow the caller to decide whether he needs a message pump, and if so, how to implement it. Feel free to provide a "DoEvents until the IAsyncAction completes" style message loop for convenience for people who do not care, but if Project Reunion is serious about bridging different frameworks it should avoid nested message loops wherever it can, the only cause problems.

I've seen re-entrancy in desktop apps, but it was because .NET synchronization primitives (e.g. Monitor / lock) will start pumping the message queue so that inter-thread COM marshaling doesn't get starved (which can result in deadlocks). This can be solved with a custom SynchronizationContext that can be told to disabled pumping for certain regions of code. I was getting reentrant WM_PAINT messages which was not working out well, especially when mixed with stateful Direct2D render targets (you can't nest BeginDraw).

COM is full of inner message loops and it has caused me a lot of trouble in development. Never had dropped messages but it caused me unexpected reentrancy (which lead to use-after-free in some scenarios) I had to guard against.
SetLayeredWindowAttributes has also triggered an inner message loop.

Not to mention that dialog boxes, file browsing dialogs, OLE functions, etc. also all have an inner message loop

COM is not the win32 API, it is beyond that, and yes, often reentrant. However it also has API to cooperate with the hosting application, should it need to. Just like rickbrew above mentioned that .NET has SynchronizationContext to opt out of nested message loops. Naive nested message loops often do not provide something to work around the shortcomings of nested message loops.
Some win32 APIs around modal dialogs may have message loops, but they are either isolated or provide ways to work around them.

SetLayeredWindowAttributes has also triggered an inner message loop.

Thats the first I hear of that, maybe you just mean reentrancy (it may very well send window messages, which does not require a message loop, these are entirely different things! message loops are bad, sending window messages is normal callback behavior, which can cause reentrancy but doesn't cause all the bad stuff nested message loops do)
From your response I see you are mixing up a few things, which are conceptually clearly separated in the implementation of Windows. Sending window message doesn't require a message loop, it is equivalent to what modern languages use events or callbacks for. This can cause reentrancy but is not equivalent to a message loop. Message loops wait for something and are used for modal behavior (like a message box, task dialog or resizing behavior - which are all very isolated scenarios and not arbitrary win32 APIs, often with dedicated ways to work around them - for example you explicitely call the message box or task dialog yourself and could provide your own implementation if you have to; for resizing there are dedicated messages to warn you about it; COM has a dedicated API, etc.)
What I'm saying is that future design should not just stick a nested message loop somewhere waiting for some condition and assume its fine because everyone else is doing it - because everyone else is not doing it - its very specialized behavior, which needs dedicated API to work around its shortcomings (like COM provides with IMessageFilter or .NET provides with SynchronizationContext). For new APIs the simplest and best solution is just not doing it, returning an IAsyncAction or semantically equivalent, leaving full control at the application to provide the message loop.

My bad, it was SetWindowLong, and not actually an inner loop, but that was still very much unexpected since the message I was receiving from that is entirely unrelated to the operation I was doing (it triggered a map clear, but the caller had an iterator to the map still, leading to use after free):

I am not a .NET programmer, so can't "just use" a SynchronizationContext. Async APIs are a pain in C++ (ignoring lack of IDE support), because you can't inspect local variables with the debugger (neither VS nor WinDBG), and stack traces with them are essentially useless. At least inner message loop stack traces make sense, and you can use regular debugging features.

Thats actually not a "message loop" - there is no waiting for an exit condition. It is just sending a window message, aka callback or event. Yes this is reentrancy, but this is not a message loop or message pump. No other messages will be delivered besides the ones being part of the implementation of SetWindowLong.

I am not a .NET programmer, so can't "just use" a SynchronizationContext.

Then it wouldn't help you anyways, it only suppresses the message pump in the .NET framework, nothing in the win32 API. And it wouldn't save you from reentrancy present in the win32 API.
I'm standing by my point, implicit message pumps which deliver arbitrary queued messages (and drop/delay some others) while waiting for an exit condition to become true are a bad thing and should be avoided in any framework wherever possible, to save people having to work around them.

This whole battle comes down to: will each framework's controls respect each others' airspace?

The earlier disucssion of unexpected reentrancy raises a good topic, what threading model should the reunion windowing design support? ASTA, STA, BSTA, all 3?

The current Sticky Notes app is pure UWP with no full-trust but still can draw custom title bar without system icons and can also disable the system title bar context menu yet still works on 10x and non-Desktop platforms. Microsoft should open up this functionality to other developers.

The current Sticky Notes app is pure UWP with no full-trust but still can draw custom title bar without system icons and can also disable the system title bar context menu yet still works on 10x and non-Desktop platforms. Microsoft should open up this functionality to other developers.


PrecomputedDescriptorFromFile doesn't accept stereo smiles?

Hi
I'm not sure, here, but after spending some time and not understanding why my file was failing but test in data was, I used
Function to remove stereochemistry from SMILES
def remove_stereo(smiles):
    mol = Chem.MolFromSmiles(smiles)
    smiles_no_stereo = Chem.MolToSmiles(mol, isomericSmiles=False)
    return smiles_no_stereo

Then save the files with fp column and I could run the study; otherwise I got error with descriptors can not be calculated.
I have no idea why because other functions like "UnscaledPhyschemDescriptors" worked without any issues.
Another problem with the function, if the column we want to add is recognized as integer by pandas then it fails because the code is looking for float (I used value + 0.000001 to get around it)

Thanks @jeremycheminf, I do not understand why the Unscaled or Scaled would fail either. Please could you share an example of the config json? I just wanted to check that the deduplication etc are the same between the runs that work and that remove those molecules?
I also just pushed https://github.com/MolecularAI/QSARtuna/commit/aacc080dfce77e92aeb02021b78866f9f6c492e1 which I hope should fix the specific issue wrt the datatype used in the precomputed descriptors

Hi
I managed to get this example using some smiles from the data folder and creating 2 compounds with stereo.
Running with stereo and precomputed fails, saving file with @ removed works, even if now 2 compounds in training don't have extra info. (notebook zipped so I can upload it)
Copy_Stereo.zip
Example_file_Qptuna.csv

@jeremycheminf I suspect that PR https://github.com/MolecularAI/QSARtuna/pull/18 fixes this issue as part of 3.1.1.
Please can you let me know?
Many thanks

Hi Lewis
Yes, the code now run with both stereo and external descriptors. Thank you!


WP 8 support

Hi !
Great plugin, thanks for sharing it !
No chance to get it supporting WP8 as well ?

Hi!
Thank you!
I'm sorry but there's no chance at all for now... I'm not a Windows guy :)


Filter related PageExtension items following page language

Feature Request
Is your feature request related to a problem or unsupported use case? Please describe.
Currently we don't bother of languages in manager methods to get PageExtension draft or published items, we just get the PageExtension, no matter the parent is translated in different language from the default one.
I just tested to fill draft and published versions of Organizations in french and it almost works when listed from a Page course in french.
I mean almost because french version is showed instead of english one when it exist (draft or published) but if an organization item does not exist in french, the english version is showed anyway. I think it should not display.. no ?
Describe the solution you'd like
First, ensure we don't want to display PageExtension items from default language when querying from another language. If we want to keep showing the default language items, this is issue can be closed.
If we don't want to display default language items, we have to find a way to filter items depending from current Page language.
Describe alternatives you've considered
Keep showing default language items as a fallback when there is no translation available, but it seems troubling for users.
Discovery, Documentation, Adoption, Migration Strategy
First we should try to find a query selector to filter from sql schema.
It seems extended_object__languages is relevant but it's a comma separated list of language codes (aka en,fr) so we will have to make a complex query to perform accurate selection, remember a language code can be something like fr or fr-be.
Finally we may filter item from a Python loop looking at available language for the item through Page model method like get_title. But this will trigger an additional query for each loop item.
Do you want to work on it through a Pull Request?
I may be able to make at least some R&D on this.

@sveetch can you confirm whether this PR has fullfilled your request or what is still not working as expected:
https://github.com/openfun/richie/pull/304

Closed since #304 has fixed this issue.


Old saves can't complete certain researches fully

In my world from one of the earlier betas, I have a couple of researches that are at the last stage (where they should be complete) but still marked as incomplete. Worse, this prevents me from completing a later research which has one as a prerequisite. It seems this happens when the player is in one of the middle stages of a research, but then everything after it is removed in an update, making it the final stage.
Here's a picture of the research in beta17, before the bug:

Here's a picture of the research in beta19, after the bug:

I can click on the research which depends on it and access its page:

However, trying to complete it gets me stuck like this.

Another reseach seems to be bugged like the first one, but nothing appears to be locked off as a result.

Duplicate of #1187


Create changeset snapshot workflow

Snapshot workflow that works like the one from astro's repo (its copied from their workflows and made to work in our CI)

!coauthor


SwiftUI Example

Platform

[ x] iOS
[x ] macOS

Describe the feature that you would like added
would love to see SwiftUI example as most new development is done on this platform.
What component or utility would this be added to
All controls and examples
Have you discussed this feature with our team, and if so, who
no

We have a SwiftUI Test app for macOS :D

please take a look at the vnext-prototype branch for lots of swiftui example which are coming soon!


Migrating to Heroku

Codecov Report

Merging #339 (86c1530) into master (6bc095a) will increase coverage by 0.06%.
The diff coverage is n/a.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 6bc095a...86c1530. Read the comment docs.


Adding configuration to send edX logs and metrics to Grafana Cloud

Add Vector configuration for sending edxapp logs and metrics to Grafana Cloud
Adding configuration in cloud-init to populate credentials for Vector to use when sending data
Updating edx-username-changer version

👍


Stop bundling dependencies in the published package

At the moment all of this package's dependencies are bundled inside the lib/draftjs-utils.js file which is shipped on npm.
This is terribly wasteful – the package takes up ± 370kb in my Webpack bundle because of this. Here is an illustration with other packages next to it:

The solution is to only compile to ES5 without bundling dependencies. There are many ways to do this, one of the simplest is to use babel-cli to run the babel compilation and no bundling.
In this PR I've also moved the other bundle to the browser field meant for bundled JS.
Edit: with this work, the package's size shrinks to ± 28kb. Further work could be done to publish this as ES6 modules instead of CommonJS, so we can leverage tree shaking and only include the functions that are used, but I'll leave this for a future PR.

Hi @thibaudcolas ,
Thanks for nice work, few days back I made some build changes. I have moved some dependencies as external dependencies - now bundle size is already about 10kb, the trouble was mainly coz of immutableJS.
To me it looks good now, do you still see any issue. Plz share ur feedbacks.

I see your point in using ES6 modules to help in tree-shaking. I will try that out soon. Thanks.

👌 looks like the changes you made fixed the problem. Thank you!


changes based on collaborative review

reintroduce copy_to 'n stuff
utils/check_port: remove default from "host"
documentation updates

jenkins/superCI comment

Status: failure, return code = 1
Result url: https://da.gd/gxGYf
Comment: See details for logs

jenkins/superCI comment

Status: success, return code = 0
Result url: https://da.gd/Wtg8I
Comment: See details for logs


Elevate third layer of turtlebot3 waffle

ISSUE TEMPLATE ver. 0.1.0

Which TurtleBot3 you have?

[ ] Burger
[ ] Waffle
[ x] Waffle Pi

Which SBC(Single Board Computer) is working on TurtleBot3?

[ ] Raspberry Pi 3
[ ] Intel Joule 570x
[ x] etc (PLEASE, WRITE DOWN YOUR SBC HERE) Intel Upboard squared

Which OS you installed in SBC?

[ x] Ubuntu MATE 16.04 or later
[ ] Raspbian
[ ] etc (PLEASE, WRITE DOWN YOUR OS)

Which OS you installed in Remote PC?

[ x] Ubuntu 16.04 LTS (Xenial Xerus)
[ ] Ubuntu 18.04 LTS (Bionic Beaver)
[ ] Linux Mint 18.x
[ ] etc (PLEASE, WRITE DOWN YOUR OS)

Write down software version and firmware version

Software version: [x.x.x]
Firmware version: [x.x.x]

Please, describe detailedly what difficulty you are in
I want to elevated the third layer of the turtlebot 3 what files do i have to modify so that the data of the lidar sensor still is fine? Or is there no information stored regarding the coordinate system of the lidar sensor?

Hi :)
You can find pose of the lidar sensor in urdf file. Follow attached link and modify it depending on your turtlebot3
https://github.com/ROBOTIS-GIT/turtlebot3/blob/master/turtlebot3_description/urdf/turtlebot3_waffle_pi.urdf.xacro#L160
Moreover, I give you a reference which is example of multiple layer
Hardware : http://emanual.robotis.com/docs/en/platform/turtlebot3/locomotion/#turtlebot3-friends-carrier
Software : https://github.com/ROBOTIS-GIT/turtlebot3_deliver
Thanks

Thank you alot for your fast and detailed answer!
So to get things right this file needs to be modified on the sbc as well as on the PC running roscore?

No, you just modify URDF file in Remote PC. Because robot_state_publisher is launched in RemotePC.
http://emanual.robotis.com/docs/en/platform/turtlebot3/bringup/#bringup-a-turtlebot3-waffle-pi

Okay perfect thank you very much

Nice, if you have any inquiry about it, please feel free to open issue :)


feat(): update to v4

By using next tag, This plugin can try to test on Capacitor 4.
% npm install @capacitor-community/camera-preview@next

https://github.com/capacitor-community/camera-preview/releases/tag/v4.0.0-0
However, this update was done automatically by @rdlabo/capacitor-plugin-to-v4 ,and has not been confirmed to work.
https://github.com/rdlabo-team/capacitor-plugin-to-v4
If you have any problems using it, please comment on this thread.
@maintainer Released with next tag to make the world compatible with Capacitor v4. Please check out this pull request and decide if you want to merge or not. Thanks for all your great work, and we look forward to working with you in the future.

Hi @rdlabo thanks for the pull request. I'm not understanding this - if I merge it into master, how does that make the plugin available with @next rather than be the main version?

fyi: i will test this on monday and let you know if it works. Code  changes looks good so far

@pbowyer test with Capacitor 4.0.1 and works fine, guess this can be merged 😊

Thanks for testing @EinfachHans, much appreciated!


[Feat]: Browser extension of the website

What feature?
This website can be extended to an browser extension and  there user can list the website he wants through a search bar
Add screenshots
this is a sample view of the feature

user can select the desired type of the website he wants in the search section

Code of Conduct

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

Looks amazing. create a PR tomorrow


Code?

Hi! I've just read your paper and really enjoyed it - novel/zero shot keypoint detection could be a viable way of formulating a problem that I'm thinking about just now, and I'd love to try it out. I was wondering if you'd be able to release the code any time soon? Feel free to send me a message/email (stfr  di.ku.dk) if you're willing to share it privately.
Thank you so much!
Stella

Hey Stella,
Thank you for your interest. I plan to release the code in next month and then it will be publicly available. Regarding zero-shot keypoint detection is indeed a interesting idea and I encourage you to explore it. Moreover, we can co-work if you need help.
Best regards,
Changsheng


Primer on efficient Web Font Loading

@notwaldorf wrote up an excellent piece on this a while back https://meowni.ca/posts/web-fonts/ and was down for writing up an up to date article on this topic for /web.
Ilya has previously written up a Web Font optimization guide at https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/webfont-optimization so we'll need to make a call on whether this is expanding that guide (preference) or introducing something significantly new.
If we were updating the existing guide, it would be great to capture recent progress on guidance around ideas like using font-display: optional

I think we should just expand on Ilya's. I just re-read it, and it's so good

It will be super cool 👍
I've been using @notwaldorf's article for perf audit vuejs docs site.
I'm sure guys, you will write solid stuff!
Waiting for it 😍

This was fixed in #5302


add mobility.ch

Mobility is a Swiss carsharing cooperative. Unfortunately, their member's account security seems to rely solely on blocking the account after too many failed attempts, since they restrict the possibilities for passwords to an exactly 6 digits long numerical PIN.
Also, I fixed the order of text and pictures of the 2 entries directly above mobility in the README.rst file

Thank you for the contribution!


Allow jitpack to use JDK 10 when building lombok

Subsequent to #1780
Sample build outcome:
https://jitpack.io/com/github/mmoayyed/lombok/jitpack11-v1.18.0-gcf9f25a-152/build.log

The last line is No build artifacts found. But I expect that we can instruct jitpack to rin ant install-maven instead ant that that would solve the problem. Is that correct?

We surely could yes, but that bit is very strange. It looks to me as if, once the artifact is built, jitpack is trying to get it installed in their own local repository and is looking for a pom.xml to do that.
I'll tweak the build command to see if it can use the new ant command.

I merged it to get the jdk10 in.

FYI, jitpack is too unreliable and slow. In the meantime, and as a result of the lessons learned from trying to get jitpack to work, we have decided to host the snapshot releases on our own website.
Thanks for helping us get to that stage.

https://projectlombok.org/download-edge
You may need a reload to get the latest css, fixing alignment problems of the maven/gradle examples.

That is excellent. Thank you for taking care of this.


⚠ Bofrost.be has degraded performance

In 7ddf2b4, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 1698 ms

Resolved: Bofrost.be performance has improved in 15d6e44.


Support for Apex Domains is not discussed

The automatic failover with traffic manager scenario section of this document does not clarify whether apex domains are supported with DNS/Traffic Manager.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: e1fca0e3-fec9-2c72-63a3-a2e1b0a7aad8
Version Independent ID: 1e80ea20-77d6-1ecd-76cd-224438972648
Content: Disaster recovery using Azure DNS and Traffic Manager
Content Source: articles/networking/disaster-recovery-dns-traffic-manager.md
Service: dns
GitHub Login: @KumudD
Microsoft Alias: kumud

Thanks for the feedback! We are currently investigating and will update you shortly.

@allanalewis you can use Apex Domains with Azure DNS. Could you be more specific on your question?

@allanalewis We will now proceed to close this thread. If there are further questions regarding this matter, please tag me in your reply. We will gladly continue the discussion and we will reopen the issue.


changing BatchErrorException to be an AzureError, then changes in tes…

…t to reflect that.
BatchErrorException isn't an HttpResponseError, instead inheriting from AzureError. The tests reflect this change (with a few small tests changes that I made because I noticed them while fixing the others).

Addresses #14713


Gradio web demo

easy to use web ui in gradio for mobilestylegan

@AK391 hey, nice demo. However, this repo is for development tools only. There is another repo (https://github.com/bes-dev/random_face) for demo applications. Could you please move this pool request at that repo like https://github.com/bes-dev/random_face/blob/master/random_face/demo.py?

@bes-dev Hi sure, I think its more clearer for users to access the project from this repo as it shares the name for the project and also links to the other repo, I can move it though if you think it should be there

@AK391 yes, I think it will be better to move this demo to the  https://github.com/bes-dev/random_face.
There is link to random_face project in README as refer to production-quality demos. Thanks! :call_me_hand:

@bes-dev ok I have opened a PR there https://github.com/bes-dev/random_face/pull/2


Support selecting a backend explicitly

Also brings in couple of commits from the maint_v3.x branch. The goal is to build an apk that includes all possible backends and be able to select any of them via a system property.

GearVRf-DCO-1.0-Signed-off-by: Mihail Marinov<EMAIL_ADDRESS>

Ready for review

If there are no comments will merge on Thursday.


Migrate T08, adding RHF, removing toggle to React core

See the T09 ReadMe for info. T08 is getting pushed back onto main as rhf00 and development will continue here.

Squashing. History of commits can be seen up through T08 and T09


Update vue docs

This PR updates the docs as follows:

updates Vue usage docs with information and examples on component data variable tracking
adds NodeJS to the installation docs TOC
adds Typescript and NodeJS to list of supported languages in the intro docs.

Thank you!


Swapped dimensions in preprocess?

I'm confused by these lines in the dataloader.preprocess function:
    aspect_ratio = DATASET.INPUT_SHAPE[1] / DATASET.INPUT_SHAPE[0]
    if w > aspect_ratio * h:
        h = w / aspect_ratio
    scale = (h * 1.25) / DATASET.INPUT_SHAPE[0]

It seems to me that DATASET.INPUT_SHAPE[1] and [0] are swapped. This code would only make sense to if the dimensions in the coco.py config file are given as (height, width) which would be a strange departure from convention. Is there a mistake here, or am I misinterpreting something?

Solved - of course tf is using standard matrix conventions of rows before columns which (got stuck on the graphics conventions, which are the real anomaly here)


Expose settings functions externally

- What I did
Refactored so that settings and metadata can be accessed programmatically when docker/app is used as a library.
Note: Before we didn't enforce validation on commands other than validate so it's possible that this will break existing invalid Application Packages (see ./e2e/list_test.go for example).
- How I did it

Moved the ./internal/settings code to ./types/settings
Moved settings and metadata validation to be run on load
Moved tests around to where they make sense
Added JSON annotations to metadata struct

- How to verify it
Existing tests should pass.
- Description for the changelog
There shouldn't be a user impact.

Please rebase 🐯

@silvin-lubecki rebased!
Note that the e2e list test is gone because of the changes made in https://github.com/docker/app/pull/314.


fix terrafrom config bug

Codecov Report

Merging #14362 (93bdb74) into dev (4d798e7) will increase coverage by 0.04%.
The diff coverage is 28.77%.

:exclamation: Current head 93bdb74 differs from pull request most recent head 014f12b. Consider uploading reports for the commit 014f12b to get more accurate results

@@             Coverage Diff              @@
##                dev   #14362      +/-   ##
============================================
+ Coverage     38.44%   38.49%   +0.04%
- Complexity     4501     4559      +58
============================================
  Files          1235     1237       +2
  Lines         42989    43490     +501
  Branches       4766     4782      +16
============================================
+ Hits          16529    16742     +213
- Misses        24632    24897     +265
- Partials       1828     1851      +23

Impacted Files
Coverage Δ

...hinscheduler/plugin/alert/script/ScriptSender.java
70.58% <ø> (-1.64%)
:arrow_down:

...uler/api/controller/ProcessInstanceController.java
65.30% <0.00%> (-4.26%)
:arrow_down:

...low/instance/pause/pause/PauseExecuteFunction.java
0.00% <0.00%> (ø)

...or/workflow/instance/stop/StopExecuteFunction.java
0.00% <0.00%> (ø)

...api/service/impl/TaskDefinitionLogServiceImpl.java
7.69% <0.00%> (ø)

...uler/api/service/impl/TaskInstanceServiceImpl.java
51.79% <0.00%> (ø)

...cheduler/common/constants/CommandKeyConstants.java
0.00% <ø> (ø)

...e/dolphinscheduler/common/constants/Constants.java
75.00% <ø> (ø)

...che/dolphinscheduler/common/enums/CommandType.java
0.00% <0.00%> (ø)

...cheduler/common/enums/WorkflowExecutionStatus.java
0.00% <0.00%> (ø)

... and 97 more

... and 23 files with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Exclude default values from serialization

Hello,
In order to spare bandwidth and to have the same behaviour as Json.NET DefaultValueHandling.Ignore attribute, it would be great to have the possibility to remove default values from serialization.
I've worked on it for the types I'm using (bool, int, double, decimal, enum) in this commit, but I think a general solution would be a nice feature for your library.

It's a very handy feature, indeed.


upgrade path for mosquitto bridge configuration files across thin-edge.io releases

Is your feature improvement request related to a problem? Please describe.

When mosquitto bridge configuration is changed in a new version of thin-edge.io, then the bridge configuration will not be updated until a manual tedge reconnect c8y (or disconnect, connect) is done. This leads to potential non-optimized bridge configuration from being activated, such changes include:

clean session default setting (see #2159)
updates to default configuration subscriptions (see #2168)

Describe the solution you'd like

The mosquitto cloud bridge configurations which are managed by thin-edge.io should be automatically updated in case of any changes to the thin-edge.io default settings.
Currently mosquitto bridge configuration can not be updated dynamically, so it is likely that a full mosquitto restart will be required for the new settings to take effect.
Describe alternatives you've considered

Additional context

Here is how we are planning to address this:

Extract the bridge creation logic out from the tedge binary into a common lib, so that it is accessible to the mapper as well.
Add this bridge creation functionality into the mapper's --init option (or a new option, if --init is not appropriate).
tedge connect command will use this --init option to get the bridge created before starting the mapper service.
The mapper will call this --init option and restart mosquitto from its postinst script as part of the upgrade as well, if the bridge config already exists.

By making the bridge creation logic common, and making it accessible from the mapper, we avoid the dependency of the mapper on executing a tedge command to get the bridge created from its postinst script. This way, even if the tedge is on an older version, while the tedge-mapper package is upgraded, it won't cause any problems. Otherwise, we need to make sure that tedge is always upgraded first, before the mapper is. This may be acceptable in the current scheme of things, but making the mapper more independent is definitely better for future.

Add this bridge creation functionality into the mapper's --init option (or a new option, if --init is not appropriate).

Though I'm not sure if I agree with this point. As how do we make sure that the mapper init is run at the correct point in time (e.g. after the c8y.url is set by the user etc.)...this would introduce more problems if both the tedge-mapper c8y --init and tedge connect c8y ... command would be capable of creating the bridge file.

Part of the motivation behind this approach is to move establishing the connection out of tedge and into the related mappers. Of course this won't all be done at once, but this is good opportunity to move the mosquitto bridge configuration generation.

As how do we make sure that the mapper init is run at the correct point in time (e.g. after the c8y.url is set by the user etc.)...this would introduce more problems if both the tedge-mapper c8y --init and tedge connect c8y ... command would be capable of creating the bridge file.

I'm not sure where the problem is. If the bridge file is already there, then c8y.url has to be set, so we can update. If the bridge file is not present, then we haven't yet connected and generating the configuration is a fallible operation, which we can report back to the user.
In this proposed solution, the bridge configuration generation would only live in the mapper. tedge would invoke it by spawning a new tedge-mapper-c8y --init process, or by calling into its API.
I'll think more about other possible solutions and describe their advantages and disadvantages in another comment.

Though I'm not sure if I agree with this point. As how do we make sure that the mapper init is run at the correct point in time (e.g. after the c8y.url is set by the user etc.)

Just to be clear, the --init option call from the postinst maintainer script would be called only when the bridge configuration exists (i.e, only during upgrades and not on the very first installation). The initial creation of the bridge config is controlled by the tedge connect c8y command itself, which just internally uses the tedge-mapper-c8y --init option for the same.

Related issues

bridge definitions part of main tedge package

it should be the responsibility of the mapper to handle its bridge
it makes it harder to develop bridges, because each has to be handled by tedge in a custom way
does it cause any issues right now though?

mosquitto is restarted too early

because other packages depend on tedge, and newer versions of tedge-* components depend on newer versions of tedge, we have to upgrade tedge first
tedge manages system services like mosquitto, we shouldn't interact with system services in other packages
for this reason, the latest mosquitto can be restarted is in tedge postinst script, which is executed before any other components are upgraded
after mosquitto is restarted, old components can connect to newer bridge
ideally, we would start mosquitto back up after all the clients are upgraded as well

different components being online/offline at different times, which may produce race conditions/inconsistent data
Are there any other things that are impacted by upgrading that may need restarting or any special handling?

Desired properties
Properties we want our solution to have, from most to least important:

resilient: minimise room for weird errors/misconfigurations, have as few dependencies/assumptions as possible
automatic: there should be no need for manual intervention from the user side
atomic:

vertically: we don't want users to see partial/inconsistent state between cloud/broker/tedge clients, e.g. we don't want to see old clients using new bridge (topics might've changed so what clients published won't be sent to remote broker) and we don't want new clients using old bridge (vice versa)
horizontally: when we're connected to multiple clouds at the same time, we should additionally take precautions to make sure that due to upgrading different mappers at different times, there is no scenario where telemetry data is sent to a subset of clouds we're connected to, due to some mappers being up and some down

backwards compatible: we don't want to change any established behaviours that users may rely on
minimal: minimise the amount of new (possibly user-reachable) commands and features, reduce scope creep
implementation simplicity: it should be simple to implement

Ideal implementation
After thin-edge is upgraded, we have to perform the following steps in order to fulfil all the requirements and not have any old leftover configuration:

Disable mosquitto and mappers
Upgrade thin-edge packages
Update relevant bridge configuration files
Restart mosquitto
Start any clients that were stopped before the upgrade

However, due to different parts of thin-edge being split in different packages, the upgrade is made more difficult because packages are upgraded serially. It's not possible to stop mosquitto once, upgrade all the clients, and start mosquitto once after all are upgraded, because we don't know which package is upgraded last (but we know tedge is first)
The best would be to have a way of calling tedge reconnect CONNECTED-CLOUD automatically after update, but for that:

all the packages would have to already be upgraded. tedge would be most fitting to put this reconnect logic into, but as it's a dependency of other packages, it will probably be upgraded first, but reconnect should be done last
how to know to which clouds we're connected? We can look at which bridge conf files are present

Currently mosquitto and bridges are managed by tedge alone, and other packages are just clients connecting to the broker.
Possible solutions
Below are some possible solutions, ranging from the simplest and most immediate, to the more complex, but addressing more upgrade issues long-term. The solution we decide on for this ticket doesn't need to fit completely in any of the below, it can be some combination of them.
Just run tedge reconnect CLOUD on upgrade
Run tedge reconnect aws/c8y/az as part of tedge postinst. All 3 of them would have to be run to cover all the possible clouds. Alternatively, plain tedge reconnect could be added which only reconnects only to the clouds we're currently connected to.
Currently, running reconnect when we're not connected just does the same as connect because disconnect does not fail when we're not connected, so it effectively acts as a no-op. If we were to make disconnect fail when we're not connected:

it would make it more predictable and consistent with connect which does fail if we're already connected
reconnect, as just a sequence of disconnect and connect would be sufficient

reconnect would then have 2 failure modes:

we were not connected in the first place, so we won't try to reconnect. This is expected most of the time, so failure there should be ignored

we were connected, but there was a problem when we tried to reconnect, this should fail and be reported to the user
that could be distinguished by the return code, but it may be a little clunky

resilient: ? what should be done if there's an error when trying to reconnect?

automatic: ✅ done as a tedge postinst

atomic:
vertically: ❌ tedge is upgraded first, after it finishes and new bridge is established, yet unupgraded daemons use the newer bridge. It may cause bugs if bridge changes are not forward-compatible (usually they're not)
horizontally: ❌ tedge reconnect takes at least 5 seconds, so restarting 3 different clouds comes out to at least 15 seconds, which is plenty for differences to come up in telemetry data sent

backwards-compatible: ❌ possible semantic change of reconnect command to handle when we're not already connected

minimal: ✅ doesn't add any new commands (or only minimally extends current commands)

implementation simplicity: ✅ simple to implement

❌ upgrade can take a lot of time because we're running up to 3 reconnects separately, each of which restarts mosquitto and runs the connection test

Doesn't address the additional issue 1) and 2).
Add command to tedge which regenerates the bridge config and run it after upgrade
To go around the change in reconnect semantics from the previous solution, we can add yet another command to tedge like tedge connect update-bridge [CLOUD] which does not connect to the cloud, but updates the bridge for a given cloud, if specified, or any we're currently connected to. If no bridge is currently configured, then it's a noop.
All the bridge configuration files are updated at once, and then mosquitto is restarted. This doesn't run the connection test and only restarts mosquitto once, so time needed is shortened significantly.
Something else would then have to trigger mosquitto restart to finalize the reconnect.

resilient: / The connection test is not run, so failure to connect will be harder to report

automatic: ✅ done as a tedge postinst

atomic:
vertically: / mosquitto is not restarted during tedge upgrade, so it continues to run with the old bridge until it's restarted by mappers postinsts themselves or something after them. It's not ideal because it adds coupling between mappers and mosquitto, but it solves the problem
horizontally: / if mosquitto is restarted in each mapper postinst, then it's not solved. If mosquitto is restarted only after all the mappers are updated, then it would be solved.

backwards-compatible: ✅ behaviour of reconnect and other commands should stay unchanged

minimal: ❌ adds another user-reachable command

implementation simplicity: ✅

❌ exposed to users

Doesn't address additional issue 1).
Move generating bridge configuration into the mapper
Writing the bridge configuration would then be achieved by running tedge-mapper-c8y init command or similar. This would introduce a dependency in connect command to actually spawn the mapper process and wait for it to succeed.
This would require a lot more work than the minimal solution of just running reconnect in postinst scripts, but would would start removing the coupling between main tedge package and the mappers, and would move bridge configuration for a given cloud into its respective mapper - which would arguably make more sense. Because bridge configuration definition is part of the mapper, this would fix the problem of older mapper using newer not-forward-compatible bridge.
But we would have to restart mosquitto directly in the mapper, or something else would have to restart it every time after the mapper is upgraded. We could do it in a postinst for every mapper, but it would make the upgrade not atomic horizontally, because different mappers would be upgraded and downed at different times while the rest work as usual, leading to telemetry data from different times missing at different clouds.

we would have to restart mosquitto from tedge-mapper, which may be surprising to users

resilient: ?

automatic: ?

atomic:

vertically: ✅ fixes the issue, bridge is upgraded together with associated mapper
horizontally: ❌ different mappers are upgraded at different times, they come down and up at different times so sent telemetry data is inconsistent

backwards compatible: / this would introduce failures in scenarios where tedge connect c8y is used but associated mapper is not installed. Technically not backwards compatible but this scenario is unexpected and unsupported, usually the mapper should be installed.

minimal: ❌ This technically introduces an interface between tedge and tedge-mapper-* that we'd have to define and make sure to maintain as it would be a potential entry point for new user-made mappers.

implementation simplicity: / More process spawning API, but I don't expect any obvious immediate difficulties

Partially addresses issue 1) and addresses issue 2).
Move connecting to cloud to the mapper completely

resilient: ✅
atomic:

vertically: ✅ as before
horizontally: ❌ as before

backwards-compatible: / as before
minimal: ❌ as before
automatic: ?
implementation simplicity: ❌ Even more than in previous solution, dividing the connection process into mappers may be very complicated, there would perhaps complications, but it will have to be done eventually if we want to reach the level of extensibility that new mappers don't require changes to core tedge and can be developed in complete separation.

Addresses issues 1) and 2).
Summary
The issue provided an opportunity to think more about the whole thin-edge.io upgrade experience and directions where we can go with it. I expect the resolution to this ticket to be some sort of a combination of possible solutions proposed above, more of a 1/2 to address the issue faster, with 3/4 being considered as a follow-up as part of another update-experience focused ticket. But it's worth to mention that doing 1/2 requires adding some coupling that may become problematic if we stay with it for too long.
If atomicity of the upgrade isn't really a big problem, then we can go with 1/2 for a longer time. If it is a problem, then it should probably be addressed sooner rather than later.
Follow-ups

Ensure updates are atomic, old clients don't use new bridge and vice versa:

add version information to MQTT client id of tedge daemons
write tests that checks if no old daemons are connected before the update is complete

This would introduce a dependency in connect command to actually spawn the mapper process and wait for it to succeed.

I don't think that this is a problem because the tedge utility, especially commands like tedge connect, was designed as a facade to orchestrate the spawning and interaction between different tedge components and other services, to ease the initial setup process. It already does things like starting/restarting processes like tedge-agent and even external processes like mosquitto. So, the same command interacting with the tedge-mapper binary as well isn't an issue at all and perfectly fits with what that utility was designed for.
Even for the long term, as long as we don't add any hard dependencies between tedge and other components, where it would be still possible to orchestrate the spawning of all those components without using tedge at all, we are good. And this attempt to move the bridge creation logic into the respective mappers themselves is a right step in the direction.

different mappers are upgraded at different times, they come down and up at different times so sent telemetry data is inconsistent

On this point regarding horizontal atomic upgrades, this scenario is not gonna happen in the current scheme of things as the tedge-mapper is a single binary which encompasses all the cloud mappers. So, when we upgrade that package, we're essentially upgrading them all at once. And even during the mosquitto downtime caused by the restart, I don't think there's any possibility of telemetry data loss, as long as the clients don't drop the messages when the MQTT connectivity breaks as a result of the broker restart. Once the messages are delivered to the broker post-restart, they will be delivered to the respective mappers eventually, even if the mappers come up later, as their sessions with the broker are persistent.

Ensure updates are atomic, old clients don't use new bridge and vice versa: add version information to MQTT client id of tedge daemons

Here by clients, I'm assuming that you just meant the mapper clients, as the other clients are not even aware of the bridge's existence and should stay that way. The proposal to add version info to the client IDs have other consequences, because using the same client id even across upgrades, is used to maintain persistent sessions with the broker, to make sure that any data published even during the upgrade are eventually delivered to the upgraded client.

Given the long posts here, below is the decision about the direction of this ticket:
Decision

Create single command to recreate the bridge configuration files if necessary, and restart the mosquitto broker if at least one bridge file was updated
Don't move the bridge creation logic to the mapper. Reason: The mapper does not need to know all of the topics and is until now not used to configure things (only read).

QA has thoroughly checked the feature and here are the results:

[x] Test for ticket exists in the test suite.
tests/RobotFramework/tests/cumulocity/self-update/tedge_self_update.robot
[x] QA has tested the function and it's functioning according description.


fix: image registries with no credentials but with a CA

What problem does this PR solve?:
Passing imageRegistries with a CA but without credentials is still a valid configuration and should not error.
Which issue(s) this PR fixes:
Fixes #
How Has This Been Tested?:

Special notes for your reviewer:

Actually I don't think this is completely correct yet, I'm not seeing yet where a registry is skipped if it doesn't have credentials when generating the credential provider config files.

@jimmidyson PTAL again