 Hello and welcome to the very last episode of Floating Panels. Hopefully this feels like it's not the first time I say this. So anyway, I managed to finish off my Floating Panels patch and I'm also working on a new one for Floating Dialogues, which should be also pretty cool. So just to recap what was not working with Floating Panels. There were mainly two issues. The first one is that shadows couldn't be drawn on Floating Panels, so it was just, you know, without any shadow. And also whenever you maximized a window or a window touched the panel, the panel would defloat, which made it much thicker and added some margin on the top and on the bottom. And people basically said, you know what, this is ugly. So, okay, for enough, let's try to address those issues. So let's start with the very first one, which should be a bit easier to understand, which is the shadowing. So what's the issue with shadows? Why couldn't I just put shadow as we already had anyway? So the thing is, the thing is, the window of the panel, when it's floating, it doesn't, you know, it's not the actual same size as the panel. Because if you click anywhere near the panel, like between the panel and the window, then that click gets redirected inside the panel. And this is for usability, you know, if you just miss the panel for one pixel, you still want that input to be redirected inside of it and still work. So in order to do that, in order to still get the mouse events, I needed the actual window to be bigger than the panel itself. And that way, I can actually redirect mouse input in. However, the shadow by Kevin can only be drawn at the border of the windows, which basically means that you would have the shadow and then you would have the panel margin. And then inside you would have the actual panel. So it would look like, you know, the shadow is floating into mid air, which is incorrect, I think. So I had to try something else, which is giving up the first time. I just thought, okay, you know what, this cannot be implemented. And I'm just gonna say I'm implementing floating panels, but without shadows, I think that is fine. And honestly, that was until I realized that there's actually a quite easy way to implement the shadow. And I don't know how I didn't think of it. So yes, if I want Kevin to draw the shadow in the correct place, I would have to do a lot of CSD stuff, like asking Kevin to have the shadow in a different position. I wasn't going to do that because it's quite complex. I think Latte maybe does that, but no way I'm going to do that. Well, the thing is the shadow is a part of the plasma theme. How it works is that you have the plasma theme with the shadow in it. And then you have Kevin. Kevin, I think, I think takes the plasma theme, sees the shadows and draws the shadow on, you know, at the border of the panel. Maybe it's not Kevin. It could be a different component, but we don't quite care. This is like the workflow. Plasma theme, Kevin or whatever. And then that draws the shadow around the window. But here's the fun thing, which I totally forgot about. We can actually see the plasma theme access it without having to go through that middle step at all. We can actually go ahead and say, Hey, Plasma theme, I want a shadow in this particular position in this particular size. And why the reason we don't usually do that, by doing that, we can only draw inside of the window. And usually the shadow should be outside. So we have to rely on Kevin to draw things outside our window, such as the shadow. And if we want to draw something inside, well, obviously, there's no point in asking for a shadow from the plasma theme directly. But in this particular case, because the window is bigger than the panel itself, I could actually go to the plasma theme and say, Okay, I want to draw a shadow. And I can, because that shadow is going to be within the window, it's going to be inside. So I can actually draw it myself, just like, you know, client side decoration. And I don't have to go through any additional step. I just literally have to say, Plasma theme, I want a shadow in this position this size, that's it. And that almost worked. I just had to make the window a little bit bigger to actually fit the shadow, otherwise it gets, you know, cut off. That was easy. However, there is an issue. And that is, by making the window bigger to accommodate the shadow, when the panel deflots, it's even thicker, thicker, thicker, more thicker. So what's the issue there? Why does the panel get thicker when it deflots? And it's not like it's a choice I've made. It's something that I yet to do. And why is that? The thing is, if you have a panel at the top, which is, you know, this tall, and you maximize a window, then obviously that window is not going to be above the panel, unless you want to, it's going to be below. To do this, Kevin has this idea of some struct or reserved area at the edges. And you just take that edge and the panel says, you know what, I want this much to be reserved just for me. And if any other window tries to maximize it on top of that, don't, just don't even allow them. It's going to be stuck here. And that makes sense. But here's the issue. The panel is not actually, when it's floating, the panel is actually not this tall, but it's taller because, you know, I'm pretending that the window is actually bigger than the panel itself. So the panel looks like this, but the window is actually, you know, much taller. So whenever a window maximizes, then it stops sooner than you would expect because the window is bigger than you would expect. So you could say, okay, no issue. Whenever we have to deflate the panel, just make the window smaller. And here's the thing. You should never, unless you know what you're doing, which is not my case, you should never try to change dynamically how much space you're reserving, especially if you do that whilst a window is being maximized. Because what would happen is that you would have this much thickness. And then there's a window that got maximized. So it's now like this. And then it's touching the panel. So the panel tries to deflate. So it becomes smaller. And then the window goes bigger, then this smaller, this bigger. And that doesn't happen at all in a nice way. It jumps forth and back. So it just looks bad. So I actually found no way to make it look decent, you know, make the animation look decent whenever a window was touching the panel. I just couldn't change dynamically how much space I was reserving. So I thought, okay, let's try to fix this. What's the alternative? The alternative is for the panel to just take, always take the space it actually requires. That is only the space of the actual thickness of the panel, not the window that contains it, but just the panel. So how could you do that? Okay, so this is actually different for X11 and Weyland. X11, you do this through struts and it's actually easy enough. Instead of saying, hey, K-Win, I want a strut on the top, just as an example. That is as thick as the window. You just say, hey, K-Win, I want a strut at the top, which is as thick as the actual panel thickness. And that was it. Pretty easy. But what about Weyland? Well, Weyland, it's not so easy because it's not actually the panel asking for a certain, you know, reserved space. It's K-Win just saying, okay, this is a panel. I'm going to give it some regard space regardless of whether it's asking or not because, you know, it makes sense. A panel should always have some reserved space. However, since K-Win is doing its magic, K-Win doesn't actually know the thickness of the panel. There's no way for K-Win to ask the panel how thick it is because it's the window manager. It just knows that there's a window and it knows basic properties of the window. So I couldn't just change the thickness it was using to use the actual thickness of the panel because K-Win didn't know about the actual thickness of the panel. Nice. And this is where I spent a month. Well, basically, there is a plasma surface API that allows plasma surfaces, just like the panel, to tell K-Win some information about themselves. And as an example, this info includes whether the panel is auto-hide or not because K-Win has to treat it differently depending on whether it's auto-hide or not. So I thought, okay, easy enough, I just have to take that API and add a way for the panel to request a specific amount of reserved space. And that is the correct approach, I think. But the thing is that just this thing requires changes in the K-Win repository. Obviously, the Plasma workspace repository, where the panel code is, but also in the Plasma API repository, which is different, and also in the K-Wailand repository, which is another one. And all of these steps have to be right and I have to write specifications and I have to write documentation. I'm not good at that. But eventually, I did. So it worked. I gave finally the permission for the panel to say its actual thickness to K-Win. I plugged everything in and it wasn't working. So I thought, okay, that's weird. Everything is working correctly. By the way, I just debugged everything. My code was working, but something wasn't. And I spent another two weeks on that. The thing is, it actually got worse. Like it was flickering. Like if you try to maximize a window, it would actually spend like 30 seconds flickering up and down, like it didn't know whether to deflate or not. That was actually pretty funny. I'm going to tell you why that was happening. But before that, let me tell you that all this development work that I'm doing is thanks to the sponsors, which by the way, thank you so much for supporting me. I'm actually doing a lot of expenses for the channel lately, a lot of them. So if you're able to chip in something that would be awesome, as always, my monthly goal is 700 euros. And we're at the beginning of the month. But hopefully we can hit that. So if you can chip in something that would be awesome, otherwise, let's actually tell you what the bug was. Funnily enough, there's also no way for a plasma panel to tell Kiwin, which side of the screen are you reserving space to? Like, if it's at the top, you know, it should be a reserving space at the top. But Kiwin doesn't know that. Kiwin doesn't know whether the panel thinks they are at the top or at the left. So what they do, which is pretty easy and reasonable, they just check what side of the screen that particular window is, you know, touching, touching. And if it's touching like the top one, the left one and the right one as an example, then it's going to just check whether it's larger or taller. And if it's larger, then they're going to pick the top one, obviously, because it's more likely to be a top panel. This is probably correct most of the times. I actually found a very edge case. If you put a panel at the bottom and you make that panel taller than it is wider, so it's going to be like a very tall thing. Then Kiwin is actually going to go crazy because it doesn't actually know it's attached to the bottom because Kiwin just thinks that panels are wider than taller when they are at the bottom. So that wasn't my case, but something was going wrong with that. And that is when the window is actually deflating. It means that the window is getting, you know, smaller because it's deflating. Whilst doing that, there are, you know, some running errors when doing this kind of stuff. And sometimes just sometimes the panel wouldn't be exactly attached to the top border to make an example, but sometimes it would be just one pixel off. And as soon as it is one pixel off, then Kiwin says, oh, wait, this panel is not attached to anything. It's not attached to any screen border. So what I'm going to do is that I'm not going to give it any resolved space at all, which means that a window that is currently maximizing, you would go like, oh, so I can just take the whole screen and become bigger. But then the panel would go attached to the border again. And then Kiwin would be like, oh, now I can give you some reserved space back. And then the window would go, oh, so I have to give some space and go bigger. But then the panel whilst doing this animation would just become one pixel off the edge again. And this just repeats and repeats. And it's a bit of a mess. So the solution is actually pretty easy. And that is, you know what, I added an API for the panel to tell how much space to reserve. I'm just going to add another API to tell which side of the screen I should be reserving space. And that's gonna just fix everything. Why would Kiwin try to guess which side that window is on? Like the window can just tell Kiwin. So I did that and yay, it worked. Which means that now everything seems to work on my machine at least. And I'm just waiting for, you know, reviews and feedback. And then I'm going to address feedback. And, you know, that should be it. That should be it for the floating panel number two version. So when is this going to land? Well, obviously it's going to land in Plasma 6. So you will have to wait a little bit. Let's talk about the second exciting thing, which is floating dialogues. So finished off with floating panels, I started working on floating dialogues. I actually had a little patch already to do that. But it had an issue. So basically how it works is that you have dialogues. And dialogues are things like the widgets and the sidebars and the key runner. And, you know, I actually only wanted the widgets to be floating. Like if you open the system tree in your panel, or kickoff in your panel, those things should be floating because that makes sense. Or at least you should have the option to have them floating. That was the idea. But sidebars shouldn't be floating because it makes no sense for sidebars to float. And also key runner should always be attached to the top. And it should float, but only if you enable that option in the settings of key runner. So how do you do that? Well, the actual implementation is pretty simple. I just went to the dialogue file and I said, hey, dialogues, you know what, if you should be floating by some margin, then whenever you check the size of the screen, just pretend that it's smaller by that margin. So my screen just thinks it's a bit smaller. And it's floating, obviously. I also have to say, you know, don't draw the borders. Like, I actually do draw the borders. Just pretend that you're floating. And that works. Except it works too well. This is the issue I had last time. This would make everything float. Sidebars, key runner, everything would just start floating, which is incorrect, sadly. Now that I tried it again, I actually know more stuff. And I know that each dialogue also has a type. And one of the type of the dialogues is applet popup, which is exactly what I'm looking for. It's, you know, when you click on a widget and you have that popup, that is going to be an applet popup. So I can say, hey, only do this if you're an applet popup. That works. I've got widgets, they're floating. It works. Everything is perfect. So where's the issue? There's none actually. It actually works. It should be pretty easy to pull this off. The only thing that I haven't yet implemented is, okay, but when should dialogues be floating? So my personal take would be that dialogues should probably be floating whenever the panel is floating. So if you set up a floating panel, then automatically, all dialogues should also be floating, all applet popups at least. I think that's reasonable. And the thing is, there, there's no way to turn that off. So hopefully it's reasonable. At the same time, personally, I feel like having floating dialogues whenever the panel is not floating also looks super duper awesome. So I would like to give that option as well. And there also should be a way to customize by how much the dialogues should be floating. And that's surely gonna hand in the plasma theme hands. So that's a lot of things to take in account for. So right now, I'm just wondering what the API for all of this should be. I just want to make something that is reasonable. And that's easy to turn on. That was everything. Floating panels, then floating dialogues. I'm not doing anything else really, because I've got exams and I'm super duper busy. But you know, I'm trying my best. So yeah, if you're able to support a channel like there's links in the description to donate anything that also helps with me developing for KDE as much as I can do. So if you're able, that would be nice. But don't stress over it. Drinking game one shot for each time I said panel.