Swagger is Going Away in .NET 9!
ฝัง
- เผยแพร่เมื่อ 15 พ.ค. 2024
- Until the 20th of May, get our new Deep Dive: Microservices Architecture course on Dometrain and get the Getting Started course for FREE!: dometrain.com/course/deep-div...
Get the source code: mailchi.mp/dometrain/8xekvmqlr4i
Become a Patreon and get special perks: / nickchapsas
Hello, everybody, I'm Nick, and in this video I will talk about Microsoft's decision to remove Swagger from .NET's built in templates for the upcoming .NET 9 release.
Workshops: bit.ly/nickworkshops
Don't forget to comment, like and subscribe :)
Social Media:
Follow me on GitHub: github.com/Elfocrash
Follow me on Twitter: / nickchapsas
Connect on LinkedIn: / nick-chapsas
Keep coding merch: keepcoding.shop
#csharp #dotnet
Microsoft libraries are of high quality and stability, so as a developer I welcome them. But I would prefer if Microsoft looked less to replace great free libraries, and looked more on typically paid products, like PDF and text document creation and conversion tool.
Looking for:
- Azure docker emulator, to stop creating Service Bus with my name for local development.
- Azure alternative for AWS CDK is done?
- Replacement for paid nuger packages are all done already?
And many more areas that really need attention, but nuh. Yet another open and free library has to be copy-pasted under a different name.
because the point is that you have no alternative and will have to pay for it in 10 years
@@panbotukHuh?
I think as said in the video it looks like the team was concerned they were including an unmaintained project in templates. That also invites criticism.
The reality is it's still just a template. You can add swashbuckle right back or use something else.
Sure the templates make a huge impression on the developers, but in the end it's your code.
Paid packages are maintained at least. We have seen so many supply chain attacks popping up lately. Was it x something, that barely missed going into Linux core. But was found out by one curious Ms employee that noticed it took a few Ms longer than usual.
This is a very serious threat, also look at what moq did.
I welcome this change. Less dubious dependencies means more certified companies get to use the features.
Nick: Get ready to be blinded
Also nick: gives us 5 microseconds to prepare
Any more latency we're gonna have to bring out the span.
Hello everybody I'm naked and get ready to be blinded
Honestly, Scalar feels like a fresh air, so I would use an approach shown in the video
The project is indeed active, raised an issue a couple of weeks ago and got a response from the dev within a couple of hours.
I never understood why it was part of .NET anyway. If I want API documentation I should just have to download and set it up like any other library. Making it a build in library and providing it like it's something special is weird.
I had the same though back when .NET5 was released.
But the thing is all APIs should have documentation, it would be a special case to not want it.
@@RandallEike the OpenAPI json should be industry standard - yes. But which HTML renderer you use should be up to you.
@@RandallEike OpenAPI is a perfect solution for that. I don't see what Swagger contributes specifically that makes it part of the pipeline.
Swashbuckle has multiple components, they're literally called out in the issue that Nick is showing on screen for a 1/3 of the video. The UI generation is JUST ONE one (albeit visible) of those components.
Are you complaining that the mentioned swashbuckle packages were added to the web api templates?
What do you mean by "making it a built in library" or "part of .NET"? It's a package like every other .net package out there, but it was added to the web TEMPLATE.
It's essentially the same functionality, just a separation of concern that sits better with MS, i.e. you can use any UI generator you want and that's as far as core responsibility lies. Thanks for the video
For something this fundamental, API metadata - deffinitely it should be built into the web framework itself. Outsourcing the UI is a perfect border.
I think the open source projects could just provide UI. You download a package, let's say swagger UI, add that as you do jow with app.AddSwaggerUI and bam, you have the current UI, but it would use the new Microsoft created OpenApi stuff. I think that's a decent compromise
Does the OpenApi package support extension, like Swashbuckle filters? Do you know about YAML output?
what do you think about video explaining how to generate client side (angular) request and response models and api calls
but what about nswag code generator? is there already a way to generate typescript APIs that are reflecting .NET API calls?
It is as much a logical discussion as an emotional discussion. Both perspectives are valid. For me, at the end of the day as long as it’s done thoughtfully and over time proves to add more value to the ecosystem, language, and dotnet as a whole, it is ok. Progress requires change, and change is always hard and uncomfortable.
I also can’t imagine Microsoft wants to take on a bunch of additional code and maintenance responsibilities and then kill their own ecosystem. So I’m sure they are indeed doing it thoughtfully.
Personally I've never really liked swagger, but that aside, I'm fine with MS bringing things in house. Ideally, the MS version will be super-simple and feature-lite, maybe not even have a UI, which will force you to install the tool of your choice if you want one. If you like swagger, then go for it!
EDIT: I was also happy when they excised newtonsoft.
I'm guessing there will be some way to include generating a client side library as part of the build process? Currently I do this using swagger command line.
Thank You Nick
Only been using something like that for local development. In a large org, well at least my one, we build the YAML Documents ourselves and they usually get hosted by an API Platform which also may configure proxies, traffic behaviour etc, an example of this is Googles APIGEE X solution. However, I do like the idea of having a .NET API generated Spec and have it compared against our YAML Documents Pipeline (because we build shared yaml components for Error models, and Common filter components, which is where the power of building the OpenAPI YAML Specs in tooling specific to building APIs is preferred. You can handle and better create those documents with a more rich experience. But would like to still compare endpoints, HTTP Response codes with the generated .NET one maybe as a sanity check.
Plus, the company I work for has teams who work in different languages, not a polyglot company but we share Spec Pipelines to Publish the OpenAPI documents... so we need to be language agnostic in some places to maintain consistency across APIs that may be developed in go, .NET, java
I wonder why there is no mention of AsyncApi, I mean we are long past the days of HTTP 1, REST. Streaming messaging APIs should be a common thing, what need is there to change swagger if not for AsyncApi?
This seems like the right direction for Microsoft and dotnet. We should get better documentation now. I support it and look forward to seeing what the community can do with the new way of doing things.
They can implement function to Mege two System.Text JsonObject, which was available in Newtonsoft instead.
Also alternative for Merging , Please let me know?
Thanks
Scalar looked quite nice - can it integrate OAuth2 authentication, such as Azure B2C?
Not yet but they are working on it
I think its good to have first class citizen experience. Worked out pretty well for json so far (and many other things)
I mean there are smart ways around those integrations by providing standardised interfaces (#ilogger) that allow a 3rd party ecosystem to co-exist with a bare-minimum built in solution maintained by microsoft.
Hence why there is no need for a MS-swagger-UI, who ever needs/wants this can use swagger ui or any of the other libs out there but having native open api support in .Net is the right step forward 🙂
I would like to hear your thoughts on API first vs API generated and how there could be a happy middle ground. I see the advantages to both.
I am relatively new to your channel. Did you say you were making this code available? If so, where would I find it? Thanks!!! :)
It's in the description of the post under the Get source code option.
@@emmanuelgenga7421 thank you for this. I thought that was a typo... I was looking for a github link. lol
NSwag is broken since v14 & net8. I think Kiota could have more attention as well, looks nice. Scalar on the other hand will be probably most common replacement, seems very simple and easy to replace swashbuckle.
You can also just put in the static library for the UI if you want. Also NSwag is deeply behind as well and doesn't support basic things like enums done properly, generics etc. so claiming that it isn't being worked on because of this decision is a little dishonest since these tickets have been open for years.
Sad to hear. Won't give up on using Swagger, the interface is much more user friendly, everything is on one page and it's also easy to call requests sequentially. I'd prefer if Microsoft acquired Swagger in one way or another and improve on it instead of giving it up.
It would be great if you could make a video on breaking changes of graph service client upgrading from v4 to v5
Honestly I could see this coming from the moment I saw an update to visual studio that incorporated endpoint testing… I guess it was just a matter of time
Where are all the DI frameworks? Well, Autofac is still lightyears ahead.
Swagger has some minor issues like client modal generation and security, but it's still a good tool. Now it depends on how well of a job MS does trying to replace it.
Regarding OpenAPI and the recently sensational Microsoft proposal regarding working with events, I am more for than against. Because in the microservice architecture, these are necessary things that are now implemented in a million different ways. I personally would like more unification, so that there is one industry standard (for each of the areas), and not 50 different options.
In addition, given that Microsoft is now actively promoting NativeAOT, which, for example, does not support Swagger right now, and the probability of its support, in my opinion, is not so great, I think Microsoft is going in the right direction.
IMHO
IMO, you need to think of ANY changes as to how it might fit in MS's AI strategy. Are they setting up for co-pilot to automatically create integration tests?.. maybe...
I've always used Postman and I can't imagine developing an API without it.
I don't see a problem in "competion" or maybe I did not get a point - Microsoft has maintained the most popular swagger lib, now they don't, but have (maybe) the lib built in. Othe third party libs existed previously in the same situation almost
With DI libs it's other topic - there was no Microsoft realisation of the pattern in-built (how ever they did have public interfaces for it from the 4.x versions, I believe) and they just added (or made public) there version witch happened to be very fast and very convenient - this I can say as a long time user of third party DI conteiners, I have only once used better code-generated solution for DI (using Fody, I believe) that can compete or be even faster than Microsoft one
It's sad but also it makes sense. It allows for more modularity. But I'd rather it didn't change since I think swagger is sufficient.
Swagger has had a nice run. I wish that MS had chosen to include a default viewer in the new template.
Swagger-UI is separate from Swashbuckle, no? You should be able to use it, as long as you can provide it an OpenAPI JSON file, which Microsoft will support generating.
Please keep making content on the relationship of .NET with its community. It's critical that the .NET team fundamentally changes the way it interacts with well established libraries, but they have to start with their own internal teams. Worst example is the Azure team that does not contribute a single useful library to a "cloud-native" .NET ecosystem while fully contaminating an amazing open source framework with an SDK that makes .NET seem like a Customer Acquisition Platform and us .NET Developers to be sales agents of Microsoft's rented machines.
I will miss it.
To be honest the first time I heard of what-buckle(??!) - it just felt out of place for a new project. Open-source projects have their risks as well as we discovered recently. Barebones is the way to go for new built-in projects... IMHO
Maybe they're also afraid of liability surrounding something they don't control, say for an incremental long term attack along the lines of what happened in ssh. If you include the package yourself, it's your problem.
I would hope that Microsoft reached out to the Swashbuckle team to see if they could move their project under the umbrella of the .NET Foundation before developing their own. At least that would have been a decent thing to do. If they did and somehow they couldn't make it work, assuming they really tried, then I don't see this move as a problem. Generating Open API specs for your API is almost a must-have, and, by doing this, Microsoft ensures that you will almost certainly always have this capability, without taking the risk of having a dependency on a third party. The Swashbuckle team might have the best intentions, but sh*** out of their control happens, license terms change, people just disappear for a wide variety of reasons, etc...
getting microsoft support means better documentation and all that, totally like this thing
When swashbuckle was abandoned we found some problems and couldn't get it fixed. The issue is that we HAD to have a swagger UI (internal requirement) but the issue raised was a blocker. The end result was to ditch it, to be honest I'd prefer to have first party support Microsoft than any thrid-party library.
I hope MS will integrate all the features of swagger like automatic import from xml documentation etc.
It makes sense for Microsoft, they are foreseeing changes to their API structures, swagger wasn't being supported. So they roll their own. If I understand correctly their offer will be open source too.. so swagger will absolutely survive as there are enough "anti Microsoft because Microsoft" people. Also if swagger are back up. It's good for Microsoft competition.
Uhhh I will have to reimplment something that already works and does what I need during the upgraded process for a project with 15 dependent projects!
You can just keep using the package. It's actively maintained and all. It's just not part of the official template, you don't have to remove it or stop using it.
I think you have misunderstood, you don't have to do anything. Swagger just won't come out of the box in new projects anymore.
MSFT should stick to publishing the specification from the API host easy and let others create tooling around that and a UI that sits on it. Most of the existing tooling already supports importing a spec file.
My thoughts exactly. Swagger (or any other OpenApi UI Provider) can still handle the presentation based on the spec file.
Maybe I'd misunderstood the video, but that's excatly what is going to happen, isn't it?
Let's hope so. If they don't stay in their own lane they're going to annoy some more OSS devs.
With the OpenAPI documentation it’ll be easier to integrate it into Azure API Management.
Where are the built-in pdf, image, video file manipulation libraries Microsoft provides? All they do is going after free industry standard libraries.
I like the .NET dev, but can they please make Authorization endpoints easier. It’s a total nightmare having a .NET Web Api then using something like NextJS with the app router on the frontend and handling JWTs back and forth. MSAL doesn’t have the best documentation.
Was waiting for Microsoft to take over the OpenAPI generation and leave the UI side to the community. It's a natural step and one that should sit nicely with community.
A very good choice. The framework should indeed be able to produce the metadata but should not come with a third party UI of the box. Official .NET templates shouldn't have third party dependencies at all.
Swagger was just the de facto package for that purpose. It wasn't anything great, and definitely not related to Microsoft. All Microsoft did was help users that were already defaulting to Swagger default to it, while they would plan into adding their own solution for that.
"This is the way" :)
A new video from Nick Cage, fantastic
In my humble opinion, it's not a bad idea for Microsoft to implement its own solution, and I believe it's also OK to leave the choice to developers. It would be great if future versions of IDEs included an "Add OpenAPI implementation" option, allowing us to choose implementation from existing options.
If microsoft would not include a lot of things into asp net core we might end up in JavaScript npm dependency hell
Nobody is forcing you to use Microsoft’s (built in) packages, but if they are high quality, well supported and work for most usecases I welcome it and it makes it so much simpler to agree as a team on which library to use.
I just had to revive a dotnet framework 3 ASP project and with their migration tools it was so easy, I only had to re-do the views in razor and fix some odd issues and that was it. That project was done the „Microsoft“ way with EF etc and most if not all functionality and tests worked without touching a thing.
Nick: You can call this document anything, like SWAGGER
Nick: But Don't call it SWAGGER!!! 🤣🤣🤣
Nick: "You can have a blind mode",
Me: "Lost my eyesight so now it turn this into a podcast ". lol
I prefer Microsoft focus on smth that has not been covered by 3rd party developers already.
This is good. But swashbuckle and nswag are good enough too. It is not a kill-feature. MS just building their own bicycle. May be it will be a better bicycle, but we have already some and this is just another one. How many bicycles do we need?
Sounds like a good decision. I feel like the UI wasn't really useful. The openapi is usually just generated and then goes straight into a generator or into Postman, because let's be honest, Swagger "try out" was always hard to get right with jwt tokens etc
I use the UI a lot. It integrates fine with OpenID, specifically with Microsoft Entra (former Azure AD), so the authentication part is just clicking a button.
As a dev that's working with 3rd party APIs all the time I like the simplicity of typing /swagger and getting the complete documentation, examples and ability to do a quick and dirty test without any other tools. For a well commented API you don't really need actual docs to understand it and use it and swagger is frictionless and beter than mucking about in intellisense of a generated client or firing up yet another app like Insomnia.
UI is plenty useful. Mostly to see what kinds of requests and responses are valid.
Wym it's really easy to get it to work with jwt
@@CabbageYe Once you got a token, it's easy. But other api client tools also offer built in ways to get to the token in the first place, which always feels more useful since the token is short lived usually
Microsoft supporting a community project like swagger as much as they did was surprising. It's not a terrible idea to encourage the use of alternative options. In the future, many popular projects may become abandonware and may have to be replaced by newer libraries. I'm not saying swagger is abandonware. I'm sure many Rest developers would have a panic attack and would require immediate therapy if that ever happened. But it will inevitably happen, it's just a matter of time. Lol...
Swagger is one of the features I always removed because I, and many other suers, do not need it. There are plenty of (subjective) superious solutions to test an HTTP api.
They really need to consider their original desire to have a frictionless developer experience for new devs. If it releases without a default front end to try the API out, this feels like a huge misstep.
I won't miss this package :)
Import the json on a ckient it's enough
The spoken ad is no longer synced with the video
I see what you did there 👀
Top Notch job baiting that click
Microsoft should implement replacements for key free libraries. They often do them very well, fix problems with existing projects, and provide a better and more supported solution in the long run. While I feel bad for those library developers, they can know that they did something that turned out to be important. They can be relieved of their burden of maintenance and go off an do something new.
I think Microsoft should provide as much as possible out of the box because then the expectation that things work and are nicely integrated together should be there. It would be great if they hired or funded these developers to assist with these packages because they have a lot of knowledge in those domains.
.NET should go more in Laravel's direction. Provide as much useful stuff out of the box to build actual proper modern applications. Also provide actual nice looking UI templates as defaults when starting a web project. This default Bootstrap counter + weather data stuff is useless crap. First impression matters.
If you work in an environment where every package needs to be scrutinised, it’s a lot easier to get an out-of-the-box Microsoft package approved.
The UI looks a lot better. Swagger will eventually become unmaintained and we will have to eventually switch over to this new thing which is a pain in the arse frankly. We will be moving from one thing that was working fine for us to something else that will also hopefully work fine, so really just a bunch of work across a number of APIs for no great benefit.
Swagger is some kind of non-official standard, so, I think that in first place, you should respect it and then, if you are trying to catch it up, you should provide at least the same functionality. Untill then, no need to break something that already done and works just fine
Nothing is going to break. You can still use Swagger as much as you want.
@@spacemanjack777 Sorry, if I have to make additional effort to achieve already existing features, then this is degradation anyway.
@@SeymourRu Nah, you only think that way because you like Swagger. As of now you'll have to do extra work to get rid of it. It is wrong on so many levels that an official framework template depends on a random third party library (that could be abandonded at any given time). The correct solution would be for you to set up your own templates with your favorite go-to libraries.
@@spacemanjack777
>because you like Swagger
Well, why should I not? It provides required functionality without additional fuss, so, I see nothing wrong with it here.
>It is wrong on so many levels that an official framework template depends on a random third party library
This is not really important, unless the source code of framework becomes closed. Oh, wait...it was once already. I think you know, what happened next
>that could be abandonded at any given time
Anything can be abandonded at any time, this does not matter at all. Just count how many times Google\MS\whatever company abandoned something that was `official` and `original`.
If you will check my initial comment, may be you will catch up an idea that before removing anything it is always expected thar something equivalent in return will be given, not only provision of basic stuff. Way more better idea is to do some kind of customization process during project initial creature. May be just add one another template with pre-configured swagger - it is still much better than just remove something good. Then, one who does not need it - will not get it, one who require it - will not spend time for this preparation stuff. Ofc you can not customize everything, but some things could be just like this.
I have no idea why started this NSwag is better maintained thing goin, but it is just stupid. It tooks them months to add .net 8 support after .net8 release. NSwag litterellay has 1700 open issues and 100 PRs noone ever looked at.
Wooowwww!
"We have a dark mode or like a swagger a blind mode"🤣
I’m in the camp of writing the openapi spec yourself. I found that, once you get serious about openapi and want to produce comprehensive docs with markup, images, etc, the code you have to write to get Swashbuckle to generate the corresponding openapi quickly explodes, if you can get there at all.
In my opinion things likes Swashbuckle are only viable if nobody really cares about the docs.
Interesting take. What's missing that you needed to add manually?
I’m not OP, but I like to write the spec myself and use it for code generation.
I really dislike Swagger's UI and UX. I did some research in the past to find an alternative.
BUT Scalar is not an alternative. Scalar is not free.
MS definitely should stop us from pushing paid tools.
This is a deal breaker for small companies like software houses or startups.
Having the OpenAPI definition autogenerated is essential and relying on 3rd parties is a not a long term safe bet.
I have no problem with Microsoft creating their own in-house libraries. And, as for what the author's of alternative libraries should do? They should write, and release high-quality alternative libraries. Just as they should be doing now.
Can't compete with Microsoft though if their in-house package is any good.
@@marcotroster8247Then stop treating it as a competition. Just produce damn good software... as they should be doing anyway.
why??? If something works why change it?
The video explains it pretty well IMO.
They always liked to copy and paste, it's in their culture...
This shouldn't be controversial at all. It's welcome change
I trust Microsoft and I'm sure we will get facilities more than the swagger made
I love when MS gets rid of these kind of things and bring it home. Loved it when they did it with DI, love it again when they did it with Text.Json.
In this case, I don't care. LOL I never liked polluting my code with OpenAPI metadata. I prefer to build my own YAML/JSON.
I only used Swashbuckle for the built in SwaggerUI. And when I saw this a few days ago I quickly removed that last reference and included SwaggerUI on my own. I even included ReDoc which is another OpenAPI UI.
all my homies export json from swagger into postman. And swagger seems more convenient for me (backender) to fast test my endpoints
I already moved away from using the Swagger UI in favor of .http files and Rider's built-in API endpoint browser.
I honestly never cared for Swagger anyway, I prefer to use Postman, it is much easier for me, no need to carry around a test tool, when I have one just for that, that don't need me to make a mess in my code to start it. 🙂
you are missing the point of Swagger.... The idea of Swagger is that it is used by outsiders, people learning what your API is and how it works.
@@quelqunderandom6143 I still don't care about it, I don't need that, theres a lot of other ways to do that same thing, and even better. Sorry but I am not sad with it going away. I didn't miss the point about anything.
@@quelqunderandom6143 Don't assume that only because I talked about what matters to me about it, means I don't know it, I didn't miss the point about anything, I don't like assumptions, so refrain from doing so. Theres plenty of better alternatives out there that does the same thing, it being forced on you with a Template makes no sense and I am glad it is going away. I never liked the idea of Microsoft packing things in by default to begin with, and yes I know there are templates without it (before you jump to new assumptions).
Forced by a template? You can just remove the Swagger stuff from the template. It takes less than a minute. Jesus people are so winy.
never liked Swagger UI. It's ok for small API, but when you have 100+ endpoints, using it is a huge pain.
"We're removing Swagger so that you can choose your own UI for your api".. First thing people will do is add Swagger Nuget Package 😆Thanks for NOT saving us time
I dont like the model where we generate the spec from the code, feels like the spec should come first, then generate plumbing to back it, like we do for client code.
Swagger isn’t a design specification it’s an as built document for your api consumers.
It doesn’t stop you from writing a spec before coding, it just generates docs for your api consumers from your code… which is honestly more important than writing a spec in the first place as often user documents match specifications but not what’s really implemented in an api.
Often times specs are written before the true requirements of an application are fully known, when reality disagrees with them, the api is unceremoniously forced to meet reality and diverges from the spec, then often no one goes back and updates the spec, and the api documents that were generated from it are thus faulty.
To be honest detailed specs are problematic, usually there are only a few things that are truly critical, after that they often tie your hands preventing good api design that requires the ability to be flexible especially in the initial release (before you have a bunch of api users). You could argue that the spec writer should be a good api designer in the first place, but even in that case, they have much less time to write the spec than the api and they still know less than they will during implementation. Repeatedly iterating on overly detailed spec wastes time. It’s better to stay generic and let a tool like this generate detailed docs.
They did this with Newton, but they just hired him and brought the code into the ecosystem. I am not clear why they are doing it, but now seems we have to do a lot of work to achieve something that’s already done. But overtime they will catch up quickly and I think it’s a good decision in the long run.
"do a lot of work" you want to be replaced by AI that can do your job in 5 seconds? stop complaining about having to do just a tiny bit of work, when you risk losing it all together. 😆
Looks like in near future putting /swagger after a 3rd party API BaseURL won't always give you all the info you need to interact with it, that sucks. Now everyone will have their own little path convention and we will go back to sending openapi jsons and pdfs with actual documentation over emails. Or more likely scenario - Microsoft removed a nuget package and we just add it back and call it a day.
I didnt like the Microsoft decision. Yes, it was so good to have a UI for default.
I'm used to work with Postman when the work is huge, but for small work I loved to use swagger.
As far as I understood, you can just add the nuget package and configure it manually. It just won't come in the template.
@@FelipeV3444 but I prefer remove by default the UI, that add by default.
It is just my personal opinion, that doesn't need to be right decision.
I just realised your intro is a nod to the Simpsons, right! 'Hello everybody' - Dr Nick (which of course is also your name)...
Video title a little click baity isn't it? Since it is factually wrong. :) But I fell for it too, haha.
I always thought of it as "falling into the pit of success" (one of Scott Hanslemann's favorite sayings back around those days) - it's a super useful piece of tooling and came plugged in by default so no-one's likely to rip it out unless they were replacing it with something else as a specific choice. While it is definitely "more pure" to not have these frameworks plugged in by default - especially in the days of pay-by-the-cpu-cycle cloud headless hosting - I don't think this benefits anyone that isn't near to or at Senior level, i.e. there's about 5% of Devs that will think this is a great thing and lose less time plugging their framework of choice into new projects, there's 10-40% of developers who will now swear loudly every time they start a new project and need to remember to plug a documentation framework in (likely Swagger anyway as that's what they know/is consistent with the rest of their estate) and there's everyone else who will now stop documenting their API's (again).
Personally - I like the change.. It gives flexibility of what you want to use..
I'm sure that Microsoft will just buy out one of the other ui programs and implement it into later versions..
Hello everybAdie :)