Submind YouTube summaries
Thumbnail for Modernizing KDE Print Manager for the Future of Linux Printing

Modernizing KDE Print Manager for the Future of Linux Printing

Watch on YouTube

Video summary

The video discusses the modernization of the KDE Print Manager to align with the future of Linux printing, specifically focusing on the transition from CUPS 2.x to CUPS 3.x. The primary driver for this update is the industry shift toward driverless IP printers, which operate using standard protocols and no longer require traditional drivers or PPD files. Consequently, the Open Printing project aims to phase out classic printer drivers in favor of a new architecture centered around these modern devices. This transition necessitates significant changes to the desktop environment, particularly within KDE's print setup tools and dialogues, which must be adapted to support the new CUPS 3.x standards while maintaining compatibility with legacy systems where necessary. A key part of this initiative involves the collaborative effort between developers Mike Noi and Till to migrate the Print Manager from Plasma 5 to Plasma 6 and prepare it for the upcoming CUPS 3 release. The project has evolved through community contributions, including a volunteer who joined via a bug report and later participated in the Google Summer of Code program. Technically, the migration involved rewriting components like the KCM and Plasmoid using QML instead of legacy Qt widgets, cleaning up internal models, and integrating new features such as marker level monitoring for consumables. The team also established a testing infrastructure that allows developers to emulate printers using tools like the IP Server, enabling them to simulate firmware failures and test scenarios without needing physical hardware. The architectural changes in CUPS 3 introduce a split between a local server for non-shared printing and a root-level sharing server for network visibility and accounting. To support legacy printers that are not driverless, the project introduces "printer applications," which act as daemon processes emulating driverless IP printers to communicate with older hardware. This approach ensures sustainability by avoiding the obsolescence of older devices. The migration plan includes building support for both CUPS 2 and 3 libraries simultaneously during a transition period, with the goal of fully switching over by late 2027. Additionally, the project aims to eventually remove dependencies on external tools like System Config Printer by integrating their services directly into the new architecture. In conclusion, the modernization of the KDE Print Manager represents a significant step toward a more streamlined and future-proof printing ecosystem for Linux users. By leveraging driverless technology and introducing printer applications, the project ensures that both modern and legacy printers can coexist seamlessly within the CUPS framework. The speakers emphasize the importance of community involvement, highlighting how new contributors can engage with various components ranging from QML interfaces to C++ libraries. With a robust testing environment in place and a clear roadmap for the CUPS 3 transition, the KDE community is well-positioned to handle the complexities of this evolution while continuing to improve usability and functionality for end-users.
Read the full video transcript
Okay. So yeah uh thanks for thanks for waiting and this will be our and be well our last talk in this room about the plasma printing major and until compet is here and Mike no will be joining remotely right. >> Yes it is correct the stage stage is now yours. >> [snorts] >> So back in 200 uh yeah in in the last years on at open printing our main concern was that we prepare everything to this for the switch over of into the new generation of cups as the old cups 2.x X was uh was there. You usually created a print Q with with a driver and with a PPD file postcript printer description file which describes the capabilities of a printer and and then the cups 2.x automatically without creating uh print explicitly also supports driverless IP printers. These are printers, modern printers which do not need a driver because they work totally with standard protocols. And due to the fact that nearly every printer you can buy nowadays is a driverless IP printer, the next generation of cups will do away with classic printer drivers and PPD files. And this and this lead has the consequence that several things needs to be modified in the in the environment of the system in the desk on the desktop especially. And on the desktop we have printer setup tools and uh print dialogues and these need need to be adapted and so I told about this in open printing news posts. I tal I told about this in many talks on conferences and so and back in 2024 Mike Noi back in 2023 Mike Noi started into Ka into the maintenance of the KDE print manager and started working on it on the development maintenance on it as I think it was his first KDE project and so his start into KD de [snorts] and in two in April 2020 24 [clears throat] he sent me an email and asked me about the and told me about that he's maintaining the KDE print manager that he wants to improve it wants to to uh port it into plasma 6 and also his concerns about the cup switch over what what exactly changes and so on. And so I started um an email thread with him explaining everything to him. [gasps] And with this we started the our collaboration for the switch over the KDE print manager to cups 3. And so uh Mike Noi started working on it. And later two two months later [snorts] in in June showed up a volunteer some somebody for somebody has has reported a bug on open printing and he told in the bug report that uh he's interested in contributing to open printing and then I have seen this in this comment in the bug report which had nothing to do with the with the actual bug and gave him some uh uh sent him the onboarding email with everything about open printing and our videos and so on. And I also asked him then uh from three areas what uh and uh what he wants to what he prefers to work for open printing. What he who prefers to contribute. And one of the three areas I offered was was the KDE print manager and he opted for that. And so I introduced him to uh Mike and then they too were working on the KDE print manager and uh and I also suggested to and when the volunteers started working. I suggested him to continue his work as Google Summer of Code project in 2025. And he actually and he liked the idea and actually wrote a proposal. And so he he continued as Google summer of code contributor [snorts] and he continued also voluntarily afterwards and I suggested him to do Google summer of code in 2026 and at least for the first half of the Google summer of code preer period he continued contributing and so he contributed a lot and we had a nice volunteer and and Mike and also all this motivated Mike Noi to get into to to continue working on the on the uh improvement of the KDE print manager and the transition to uh to cups 3.x and to the newest plasma. And this talk will be about this work. And we start as it goes now more in to the KDE side. We start now with Mike Noi uh telling about what he has done and he will do. Mike. >> Okay. Thank you so much till I hope everybody can hear me. Okay. Uh let's go ahead and start. I I'd like to just give a quick overview. We will probably discuss uh you know kind of a little bit of the transition into Plasma 6. I won't spend a ton of time on that. I'll talk about my involvement early on just because I think it might be a pretty good story for any uh new contributors or anybody that's um coming into KDE Plasma and is interested in contributing in different ways. And then we'll talk uh Till will talk a little bit about CUPs 3 uh architecture in in specifics in detail. And then we'll finish up with a just kind of a quick overview of what we've done and what we're doing uh for the 2x to cups 2x to 3x migration because we do we do have a lot of prep work that's been done already and uh we'll we'll outline that. So very quickly, I when I first came into this, I I had some experience with KD4. I didn't really have much experience with uh C++ and very little experience with the details of plasma, but I had been working with some QML. I'd been wor I've worked with a little bit of the uh case uh KCMS in the early migration from five to six, plasma 5 to plasma 6. And uh it was made known to me by I think Nate at the time, Nate Graham, who I'm sure everybody knows um that the print manager was maybe a little orphaned and uh maybe needed a little love. So I kind of looked into it and thought, "Hey, this is kind of neat." Um, I have really at the time had no knowledge at all of cups, of really any of the KCM uh architecture, but it looked interesting. And um, I had also had a sort of a side I had a a side contact, a very one of these, you know, uh, you know, serendipitous things. It was I I I had a friend at a at a local office, a very small office, and a couple of the people in their office were actually using Plasma 5 um on their desktops. And I just thought that was really, really cool, very, very, very neat. And they were using Print Manager to do to manage their job cues, print job cues in a very uh a very interesting way. I won't go into all the details. They were just doing something that was somewhat non-standard, but but they were making it work. and they had they had an administrator that knew Plasma 6 was coming and he just kind of was asking me if I knew anything about it and I was like well by the you know as as chance would have it I'm sort of looking into this a little bit. I'm interested in helping and that's kind of how I got into this. Um so let's talk a little bit about print manager components. Um it's it's really it print manager is not really responsible for the printing per se. That's the job of the applications and the cups. What print manager is responsible for is the configuration of the printing devices. Uh handling different options of the printing devices. And then uh there's a a plasmoid component that has seen a lot of love recently since the plasma 5 conversion as well into the plasma 6 uh version that is uh that offers some some basic job cue management and um so you can see here we have really you know five six main components and again all of them fairly small uh not terribly complex. uh the we have the libk cups which is our you know internal core library which is basically a wrapper around the cups API. The Cubs API is essentially a C API and it offers the the lib our lib kups offers various models that can be uh consumed by for example the KCM for example the plasmoid there there were there were in the 5x uh time frames um I call them legacy but they're basically just QT widget apps if if people are familiar with the difference between the the uh the widget apps and the um you know the Kiraami or the uh the QML apps. Uh we so there's still uh one actual uh widget app left in print manager as we've moved forward into six. We also the print Q app, the KCM and have both been migrated to Kiraami QML and that happened during essentially the KCM was migrated during the Plasma 56 transition and the print Q app was was I believe we released that as the new app for plasma 66 or 67 maybe it was 67. 7. And then of course there's a Damon module that does different things. The Damon module originally uh listened uh on some uh interfaces for handling um driver installation errors and things like that, things of that nature when it came to um new printers being detected on the network or on the system. And that feature comes from a product or a basically a tool called system config printer which if you've got any exposure to printing in in Linux or on the desktop Linux you probably have experienced or seen system config printer. System config printer offers a a UI a user interface for configuring printers, but it also offers some services other than that that can be used by different um that can be consumed by different uh applications and such. And in our case, we are consuming their two services from them. One of them is the physical device grouping when we search for new devices on the network. And the second one is um driver matching where if a new device is discovered, we can take some characteristics of that device, send it off to the um the uh the driver matcher, it comes back with some drivers and we and we pop that in a list and let the user choose as as new print cues are added. So those are the main components of the print manager. So during the transition we basically standardized on the plasma repo. Uh uh print manager used to have its own release cycle and and during the transition from 5 to six we then integrated the release cycle for print manager into the regular plasma release cycle. Um so all that is is is basically under the plasma umbrella. We basically it's, you know, I made a note here. We ported Lib K Cups, but I'm not sure we ported it so much as we just added some things to it. We didn't do a lot um to the internals of lib K cups as it relates to its connection to to cups. But what we did do is clean up the models. There are, you know, four main models in the in the um in the in the library. We have the printer model. We have the job cube, the job model. We have the PPD model. The PPDs are basically printer drivers to keep it simple at this point. And we have what's called a device model, which is really a new device discovery model. Uh the PPD and the new device discovery models will probably be going away. Uh well, I know the PPD will and we'll talk about that later when we get to some of the details on the 2x to 3x migration. Uh so the KCM and the apps, the KCM when we went to the uh Plasma 6 was basically a a complete rewrite. I borrowed a lot of code or copied a lot of code, made it fit into the into the KCM. Um, and we uh we cleaned it up and we at this time we also had the capability of deprecating the the old legacy or or widgets app called uh ad printer because that was now integrated into the KCM and the the Plasmoid got a nice little faceelift. uh it just cleaned up cleaned it up and and what it was doing using the models and it was cleaned up and plasmoid has received um in more recent releases even even even more facelift and even more love uh to make it a little more usable for some basic job cube management. So, for Plasma 6, we've we've here's the pro kind of where we are, I guess, current um we done a lot of cleanup. We've deprecated pretty much all of the all of the widgets apps. There's one widget app remaining, which is the media settings, which allows you to change globally uh settings for a printing device. uh that is still as a QT widget app and I we've got it on the list and it would be a great little first project for somebody new. However, it's things are going to change with that as we move into Cubs 3. So, there's there's a little bit of there's a little bit of that that's up in the air. So, we've kind of left it as it is because it works and um and we'll see what happens with that as we get closer to to the migration to 3X. We've um cleaned up the models even more uh recently to be a little more QML friendly since our UI is you know is is in QML now pretty much everywhere except the the legacy app I just mentioned the widget app and and so from a you know under the cover standpoint that's that's the those are the biggies. We as far as new features goes we we have had the ability to add quite a bit quite a few new features to the print manager. um as we've transitioned into six and then six has moved forward uh we've just kind of made it a lot easier to to add printers and to pick drivers we've really focused on making the IP everywhere option which uh Till alluded to earlier uh as as kind of a front and center main thing because most printers most modern printers are going to uh are going to support this. So if you are setting up a print Q for a particular device, uh it's pro it's really going to want you to try to do IP everywhere as the sort of driverless option, the driver driverless option, if you will, at this point. Um and of course we hope to, you know, hopefully that becomes ubiquitous. I I believe it's really close to becoming uh uh really ubiquitous across the board with with printing devices. We've added uh marker level checking and that's just kind of a you know a kind of an old phrase for really we we we um we check consumables and receptacles. So some printers have consumables, toners and inks. We we monitor those. We warn the user when they when they reach a certain threshold. We also monitor the um uh the receptacle devices. These are devices that uh receptacle components. These are things that the printing devices will then send waste material to. uh and they and those devices actually fill up. So we we monitor those and warn on those as well. And that's all fairly new stuff uh within the last few uh last three or four uh plasma releases. Um we we are in the process of [snorts] not to go too far with this but we have some things that we have developed to take the place of what system config printer is doing for us for driver matching and physical grouping. We're unsure if that's going to be needed with um when we get to cups 3 and that is probably because uh of of a concept called printer applications and I think till might talk a little bit about a little bit more about that when we get to the cups three but printer applications may allow some of that um dependence that we have on system config printer to be removed at least deprecated when we we think so. Um, another biggie I think in my mind that we were able to add was for the first time and I think we just added this in 67 or maybe 66. We have our first real testing infrastructure in place. We have some auto tests that do, you know, some basic smoke testing for the models that that are currently in use on the 2X on the CUPS 2X side. And uh I've been experimenting with some local testing using the IP server, which is basically a a tool that allows you to emulate printers, IP printer devices. Uh and and the and the really cool thing about it is is that you can you can create your uh own printer to have any characteristics you want. You can have you can fake firmware failures. You can fake firmware bugs. You can do anything you want with these mock printers uh mock printer configs using the IP server tool. Our goal is eventually to get that into the CI and and that would be um that would be a fantastic thing. Okay. So, what's next? Well, you know, we the big thing next is really the Cubs 3 transition, the Cubs two to the Cubs three transition. And a lot of work has been done to, you know, to to kind of lay the groundwork for that already. Um, Till alluded to the to a resource that um that volunteered. His name was Torin. Torren helped helped out quite a bit in the um in the uh identification and the uh actual coding of of um getting you know a translation layer ready for us to uh convert um you know our our cups 2x and our cups 3x constants and APIs and all that and all that. Um, we as part of that, we hope I guess I'm kind of backing up here a little bit, but you can see plasma 6.7. Uh, we introduce some some new components. 6.8, which is I guess in the works right now. We've got a couple of new features. It's it's really 6.9 where we see kind of the what's next um steps happening. Uh and that's the um the work that has been done to uh to make use of the new undeprecated or the new cups 3 um command codes and constants and specifically the APIs. We I've actually smoke tested the build. We we have build support already in the system for cups 2 versus cups 3 and we'll talk about that in a minute. But um so there's some preparation work that's got to be done for the um you know the consumer apps our our front end our our KCM our plasmoid our plasma print q uh for cups 3 6.9 might be ambitious I'm thinking it it might be 610 or whatever comes next seven I don't know how that's going to work out but the biggie one of the biggies I think that's going to be a bit of a j a game changer to us is what I'm calling the IP direct to device feature and this feature is actually ready to go right now. It's just waiting. But basically, this allows us to kind of go around Cups and go right to the device to to query very specific capabilities that that maybe Cups doesn't provide to us necessarily right off the bat or even at all. Um and uh there are different things like for example marker level you we can get instant marker level checking without having to to depend on cups to have have print something already. just one advant example. I believe this is going to be um one of a a really useful tool for us when we get into the cups 3 area because of all the changes that are coming to the architecture on the cups 3. So that's kind of the next phase of what we're doing. Um take a a little break here and and I have an ulterior motive. I'm hoping that maybe anybody who sees this or or anybody uh who who will see this later uh can see maybe that print manager is a is a really really good um uh place to start if you're interested in contributing there. We it covers all the major components. We've got a KCM. We've got a a a C++ QML uh interop thing going on that's that's pretty extensive. We've got we've now have a testing infrastructure. It's basic and it's pretty simple right now, but we we see that getting uh growing and getting better into the CI. We have we have access uh to an external live cups to X3X. These are this is a C API we use directly. We have another external live system config printer that we use. We actually use its services via the DBUS uh and as rather than uh calling a specific uh uh lib. Of course, we have a plasmoid. Plasmoid is is probably the thing that most people see on a daily basis if they use if they print often or if they use the printer. And we do have one remaining um widget app. So I mean it may seem a little complex with all the moving parts, but each one in it in its own is is is really pretty straightforward and we we kind of cover all the bases w with um with with having all the different types of components. So hopefully that um piques somebody's interest out there a little bit. At this point, I will uh back off and and um turn it back over uh to Till and he will give us a uh an overview of what's coming with Cubs 3 inside the architecture. Till, back to you. Well, as I already told in the in the in introduction on on the switch over to cup from cups 2.x to cups 3.x uh the support for PPD files and classic printer drivers will be dropped because most printers are just driverless IP printers. And now you see the uh diagram and on the left hand side you see cups 2.x and an application sends a job and the cups can when the printer is a dry wireless IP printer. It can just pass it it can just handle the job by itself without any external software and pass it to to the printer. This is this we see on the very left. And then another possibility the the which which the cup which all with the cups 2.x only the cups 2.x can do and the cups 3.x X not anymore is that we we create in cups a Q with a PPD file which describes the printer and a driver filter which converts the print data and through these means and this was a classic way how we always configured printer for all the 25 years of cups. this and this way we generate the data the printer needs the data format the printer needs and send it to the printer. This is in the right and another thing is we when we see the cups 3.x X on the right hand side. Then we see that the that the possibility to use a printer to use a PPD file and a driver filter is gone. But we need a way how we can still support legacy drivers. Windows does the same thing but Microsoft tells throw away your old printer. And we at open printing we do not want to do this. We want to be we are sustainable and therefore we have we have introduced the concept of uh printer applications. A printer application is a demon process which emulates a driverless IP printer and on the other end talks with a physical legacy or specialty printer. Internally the internal code of the printer uh printer application is is the driver. And so this is a new format of printer drivers and these printer application emulating uh uh a driverless IP printer. They work like a driverless IP printer itself with cups 3.x with cups 2.x and also with windows. And so we have we you see in both both sides on the left hand side in the middle uh print the the gray legacy printers are connect can also be connected by means of a printer application. So cups talks like to a dry wireless printer to a printer application and the printer application talks to the printer and this method we have also with cups 3.x X as we see on the very right and and there the cups can only talk with driver wireless IP printers and it can be a physical printer left or it can be a printer application right and so the gray the legacy and specialty printers are also served. Uh Mike can you part got get to the next slide? Thanks. And another thing is which we also pro will have to be take care of in in the printer setup tool but this will be a second step is that we have two cup stmons now in cups three. In cups two we had one cup stmon whens root was listening on the network so that that it could could share printers was listening on uh uh unix socket for local printers and without need and and when not sharing printers not needing to to hassle with the network. And now in cups three we will have two demons. One is a local server. It is lo only for local printing. It does not listen on any port and it has only a unique socket for receiving the jobs. Also, one cannot create manually. Quinn cues on it because it is just just seeing the the driverless IP printers can be physical, can be printer applications, can be remote cups is is uh just seeing these printers and making them available. Print jobs are sent through the through the Unix socket. And the local server is also a debus service which does nothing more than telling the path of the LO of the of the the path of the Unix socket so that clients find it so that nowhere something need to be configured. So in the in the usual case the local server of cups is completely stateless. No configuration file sees the printers which are available makes them available and the print dialogues display them and you can print on them. And then there's the sharing server and and it and this local server runs as normal user. It's a user demon. And the sharing server is the other cups demon. This this is running as root as a system demon. and its uh purpose is to actually share print cues on the network. So it opens port 631. So it has to run as root and makes shared print cues available as the old cups demon and as cups is working all IP. These shared cups are working as a driverless IP printer. So the things so that other local so that other local diamonds and uh other that other local cups, diamonds, other every type of clients, windows and so see these printers and the the share and you you will think a network printer is directly visible. The sharing server does not have to share it. But the sharing server has extra functionality. Once it can can uh uh scan remote networks and and relay printers from remote networks into the local network and it can also you can it can also apply page accounting. You can set your network printer that only your print server is allowed to print on it. And on your print server runs a sharing cup server and this sharing cup server is configured for page accounting. So this means also that the sharing cup server needs a configuration file. So this is these are the main new things of cups 3. There are several other things we do not have time to describe it and these other things also do not affect much printer setup tools. [snorts] And this is now the base. This is now what we have and where we have to uh adapt the printer setup tool to. And so next slide Mike. Now we are at the uh transition caps 2.x to caps 3.x and this we need to take this we need to uh to cater for with a printer setup tool and and the cups 3.x is coming close. Lip Cups 3 which is the cups library needed needed for it has already a stable release and the the underlying library for the for the cups 3.x Xdemons pap which is also the underlying library for the printer applications. So it will get the universal IP server. This this library is also approaching it the its 2.x version and when we have the 2.x of this library this will be the base for the two demons. I would suspect that up to the end of 2027 we will we will probably have uh we will probably be ready for switch over at least from the cup side we also need to take care with the desktops and as as I'm as we are doing here with KDE and and uh so also the the printer setup tool. We have already merge requests for the printer setup tool for the KDE print manager. So, Tarun's and Mike's work are all are nearly complete. So that that from the KDE side when in in one year we we are we are landing the cuts 3.x I think we can be very confident that KDE is ready for that. The other thing is the QT print dialogue which is really not cute. No one has touched it in the 25 years of cups when it was created for cups. But that's another thing. It's not scope of this talk and yes yes and so this is and and in the in in the printer setup tool what we have actually to do when we want when we have the cups 3.x X which does not have uh which does not have uh classic cups anymore. In the main view, we show the IP print destinations which are discover discover discoverable on the network and we give them a button for for example that you can open their web admin interfaces to configure them and we also will have an add printer button and the add printer button is also discovering printers legacy printers which are not driverless but it does not assign yes it does not assign drivers and PPDs it assigns printer applications to them so and that's that is what we need to change and back to Mike >> okay thanks till I would just like to say one more thing about our current progress I'll I'll elaborate just a bit on the build system we do have build system support in place already for lib cups 2 and lib cups They currently build mutually exclusive. You can install you can build and install lib cupcups 3 with a lib cups 2 install. It's not I mean it works and I've got it going here for testing but I don't really see that being an option uh when when dros get there. So at this point it's for dev only. Um eventually it will you know there will be one or the other and and and we'll we'll be ready for that. Um let's go next. So for the next cycles as part of our our movement to three, we'd like to build out the testing uh especially the CI. I mentioned earlier the IP server tool till mentioned how it's going to be in uh integrated or provided with the uh the PAPEL PAPL components that are coming with the new uh cups. We need to support the printer applications. We currently have have no support for those at this point. We have a fairly complete migration already for the cops edom destination family of or familility family of uh of APIs. We have the translation layer that allows our our um our uh consumer code to be totally transparent whether it's using cups 2 or cups 3 because we do have commands uh command constants and APIs that have changed. Um we do not currently have temporary Q support that would have to be added uh to the um to the consumer apps the KCM the plasmoid and the print Q. We have some prototypes in place we've been playing with there. Um eventually I I guess we will we will probably bring those into uh and I believe there's probably going to be some design involvement. In fact, I would I would argue that we'll probably have to turn over a lot of this UI stuff and UX u uh decisions to the design group, design team because it's going to it's going to change some things and of course we want to want to make it as easy as possible. And then of course the idea that we can remove dependency on system config printer uh specifically the driver matching and the device grouping. These these are items that will be worked on in the next few cycles. And finally to to wrap it up I I personally would just like to offer a special thanks to these folks. There's probably a couple of others that I've that that I've I've not listed here, but very specifically Nate um back in the days of the five to six transition, he was uh he was instrumental in in in pushing me in the right direction and I hope I pushed him a little bit as well. Really appreciate his help. Kai has been uh helpful all over the QML side, the C++ side. uh he's done a lot of work in the plasmoid recently uh to make it just a little bit more usable and he's been helping me he's helped me in the past with the QML Nicholas with just looking over my MRS my merge requests and helping with approvals uh till of course the uh the source of all knowledge uh when it from my standpoint when it comes to uh to to working with lib cups cups in general and whether it be general information or very specific He's been instrumental and Tyrone for his his work um on the uh uh the completion of the um uh you know the translation from cups 2 to getting us ready for the cups 3. Uh his work was is is now invol in in at least one or two of the major merge requests that we'll be uh we'll be pushing for next cycle next few cycles. And also real quickly, I didn't list his name, but Michael, who's I guess he's the creator of cups from way back whenever, um I've just over the over a couple years, >> he's the creator of IP, and so he is really the root of everything. >> Yeah. Yes. >> Yeah. He he um so I you know, I've uncovered I uncovered a few pretty glaring bugs bugs, but I guess it's just because of the way we were doing things. uh and and Michael and I've reported them and I hopefully I did a good job at giving him um you know good use cases for repro and whatnot but I gotta say that you know I know his he's you know I know his schedule's got to be crazy but he was very very responsive. We fixed I don't know three four bugs that were instrumental in getting us moving forward with some of our refactoring and working with our printer models and whatnot. So again, thanks to Mike and again, a special thanks to all these folks here. And with that, I will thank you all for your patience. I hope this was somewhat informative. I I feel like, you know, it's kind of a black box. If it prints, if printing works, it does. If it doesn't, people wonder why that hopefully we've we've explained a little bit about what's going on behind the scenes. And and at that point, at at this point, I'll u I'll bring it to an end. >> [applause] >> Thank thanks a lot Mike that you have uh connected to us and to create and to to create this great talk so that our KDE community knows that printing is in good hands. >> Let's hope so. Yes. [laughter] >> Thank you. And anyone who has some questions to me just come to me and yeah because we are we have started already late and we are actually running out of time and there is also a lightning talks going into the into the room one so unfortunately there's no time for catch now and please also give a hands to CC cruise for for their services for two days of online streaming. [applause] Yeah, [cheering] >> thank you very much. >> Thank you very much everyone and yeah, see you in the See you in the next room. >> Have a good evening folks.