Floating Dialogs & Plasma Ink

Hello my dear KDE fans. I've missed you. Did you miss me? I'm sure you did. Anyway. This is a type of video I haven't done in a while: a devlog! As you know I do kde devolpment and now I'm here to report to you what's up.

So, of course, the big thing is floating dialogs. I've talked about them already and the very weird thing is that, well, they're already done. And it has been really easy to implement them: I just told the dialogs to believe that the screen is a bit smaller than it actually is, and they automatically avoid to touch it. Easy peasy.

So, nicco, you have some explaining to do. Why isn't there a merge request from you to KDE that pushes those changes? Well, funnily enough the issue here is how to turn this feature on and off. Because, obviously, we can't ship this feature enabled by default or with no way to turn it off, so there has to be some kind of UI to switch these on and off.

Firstly, there was a thinking stage. How to enable this? The thinking stage eventually ended with this idea: currently, the panel settings allow you to switch between "floating" and "not floating". I want to change that to three options to choose from: "nothing is floating", "dialogs are floating" and "both panel and dialogs are floating". Generally speaking I wouldn't want to have more than three options and "panel is floating but dialogs aren't" doesn't really make sense because it sadly leads to visual glitches.

So, that's the idea. Issue: how do I implement it? Well, simply adding the button is really easy. I just copypaste the code for the previous buttons and that's it. Of course, I do have to, you know, make the button do something. Luckily, this is easy as well: I can add a property to the panel, called "dialogsFloating" or something, and then switch that property between true and false depending on what's selected on the settings. Easy enough!

Of course, there's still a piece of code left: making sure that dialogs are able to read this setting and know whether they should be floating or not. But that must be easy, right? Right nicco? Right nicco? Why are you crying inside, nicco?

Things are never that easy. Namely, the dialogs of the applets know almost nothing of the panel itself, given that they could be used anywhere really (you know, you can put widgets on the desktop too, or in even weirder places). Soooo, what do I do? Well, there is an standardized API that allows applets inside the panel, or the desktop, to know something about their containers - or, rather, containments, as they're called in the KDE code.

So, just use that, then! Well, that's what I currently do for transparency. You'll notice that applets will be transparent or opaque depending on whether the panel is transparent or opaque. How that works is that one of these API properties contains a flag that tells the applets whether to be transparent or not. You might expect this flag to be called, I don't know, "appletOpaque" or something. But it isn't. It's actually called "DesktopIsCovered" and, according to the documentation, it should tell widgets whether there's a maximized window or not.

But it doesn't do that. It tells applets whether they should be transparent or not, which is completely different. In fact, there basically no relationship whatsoever between maximized windows and a transparent panel, except for maybe the fact that maximizing window is one of the ways which could make your panel opaque if you have adaptive transparency on. That's it. Now, clearly, that flag has a pretty bad name, and we should change.

Here's the problem: we can't. It's a public API, and once you do a mistake in a public API, you cannot fix it. It's there, forever. Or, at least, it's there until the next major version, which could be years and years in the future. I mean, how long until KDE Plasma 6, right? Decades right? Surely it's not the very next release of KDE Plasma, isn't it?

Irony aside, this is our one chance to fix the name. I don't know if we'll do that, I asked other devs, but yeah, we can. The other thing I need to do, once that is addressed, is to add a new flag for the floating applets. Adding things to the API makes it more complex and harder to maintain so it always gets - rightfully - some skeptic eyes but it shouldn't be that controversial. As soon as that is done, which hopefully is soon, I'll make sure that the buttons in the panels settings also uses this "floating applets" flag in the containment API to tell the dialogs they should, indeed, be floating.

Isn't it ironic how it's harder to implement the on/off button of a feature compared to implementing the feature itself? I guess that sometimes, it happens.

However, all of this is not that hard to implement. But there still was one thing to address before working on all of this. Because, see, I could add a button to the "more settings" section of the panel settings, but look at it. Seriously, look at this super tall dialogs that screams "help me please". Is it just me? It can't be just me. It is screaming "help me", right? So, on my to-do list I've had, for a good year, to finally revamp this poor thing.

In fact, it's been on my "to-do list" for so long, that somebody did it before me. That's what it means for me to be productive: procrastinate for long enough that somebody does the stuff for me. I'm talking about this merge request, opened roughly one month ago. This is the proposed new des-- WAIT. I have to do warnings. THIS IS JUST A MERGE REQUEST. IT DID NOT LAND YET. THE DESIGN WILL CHANGE. In fact, as we'll see, it already did. Anyway, now, look at it. Looks pretty, doesn't it? In fact, I thought it looked phenomenal, and sadly the MR has been completely inactive for super long because nobody was reviewing it.

So, you can guess what I did: I tried it out, I did a code review, I noticed a couple of thing were missing - namely, the labels colors on dark mode and the plasmoid heading - but everything else was practically perfect. One complaint stuck in my mind, though: it's still... tall. It's, like, very tall. In fact, it requires some special code to become less tall on 720p screens, otherwise it would overflow. So I just thought, okay, what if I tried to do a design that's... less tall?

So I made a merge request on top of their merge request, using their code to just tweak the design a little into this. Which to me looks better. So, happy I was able to give at least a little contribution to this menu, I sent my design to the KDE visual design chat. And they did not like it. In fact, it sparked a suuuuper long discussion, and after a lot of back and forth we kind-of decided to go with something more like this design. Again, none of this actually landed yet, this is just how things are now.

And since now things look frigging beautiful - not thanks to me, but who cares - I can finally add my little button for floating dialogs. If everything goes well, which it won't, but if it does, in a couple of days all of this will be over and I'll have three plasma merge requests pending review: the floating panel improvements, the floating dialogs, and the redesigned settings UI that's actually not me but the other contributor. I'll then be able to focus on some different stuff entirely, like finally upstreaming some icons I've talked a bit of time ago.

But, see, that's not everything I've done in the past week or so. Not at all. You often hear me say that I'm supposed to be doing something about Plasma on E-Ink devices, especially given that, you know, I was sent a PineNote from Pine64 to do stuff with Plasma on E-Ink devices. Thanks Pine. Soooo. I was super busy in the last months so I just procrastinated that as well, and yet again somebody did very cool stuff and PineNote improvements; just, not to Plasma, but on GNOME and such. So I started feeling super guilty again and I decided to resume my E-Ink work.

I had to start a new plan, from scratch. First thing I did: I pinged one of our best KDE designers, Aron, and I asked him to plis update their mockups for a Plasma Ink shell. After a bit of feedback and such, this was the design he came up, and - well - it looks gorgeous. So, I jumped to the implementation. I started thinking about what to start with, and I noticed that a very important part of this design is the ability to show you all of your EPUBs and PDFs. And I already knew that this was going to be a very complex thing to implement, so I decided to start with that.

Now, hear me out. This is the part where you make fun of me. I promise. The thing is, listing files in your home folder is not something you can do in pure javascript nor in QML, which is the markup language of Qt. It requires writing C++ code, writing a cmake file, compiling it with the correct libraries, and so on.

And I'm bad at that. So bad. So so bad. In fact, I thought I'd start with just writing hello world in C++ and compiling that. And I failed. This is actually the moment of last week where I had a complete breakdown and my impostor syndrome went over the roof. I wasn't able to compile hello world. Like, seriously. See, compiling is not my thing. At all. I'm a python, QML, interpreted guy.

See, this exactly the type of task that would take any developer, I don't know, 10 minutes. It took me a week. A week. Eventually, by copypasting a lot of code from Plasma Nano and Arianna, two other KDE projects, I was finally able to compile a little library, called plasma ink, that exposes being able to search for EPUBs. Now, for some reason, potentially related to the fact that I copypasted the code from an EPUB reader, the code only search for EPUBs. I'm not sure why. But hear me out: it's a proof of concept. What I can now do is start working on the stuff I actually know how to do, that is, the user interface.

It's going to be a very weird user interface where it only shows you EPUBs, yes, but here's my devil plan. I'm going to do the whole UI, actually implement everything that should be implemented; then, I'm going to show my project to other KDE developers, I'm going to upload my code to gitlab, and then I'll say "sike, it doesn't actually work" and start running straight in the opposite direction until I cannot see any KDE developer around. I'll wait, I don't know, a couple of weeks, and then I'll get back and I bet that somebody will have fixed my code by then. It's basically a given. Then I'll say, I don't know, "sorry I just subscribed to a mathematics of relativity exam and now I'm lagging behind the homework of differential geometry and functional analysis". Which, by the way, is completely true. If any of you is a functional analysis expert and feels like explaining to me why I would care about weak star topologies, reflexivity of banach spaces and such, feel free. I'm basically burning out over just how much I hate dual spaces of infinite dimensions.

KDE. I was talking about KDE. See, that's not everything I've done this week. I've worked on yet another thing. Whiiiich I'm not sure I can talk about, but it's all stuff that will be open sourced anyway. Basically, there's a company paying me - which is extraordinary, not even KDE does that - to implement a KDE Plasma on yet another different kind of device that's not a laptop, not a tablet, not a smartphone, not a TV, not a smartwatch, and not what you're thinking about.

I won't talk much about it since it's not KDE work, it's that company's work. However, the cool thing is that, whilst doing that, I found a but in KDE Plasma itself. A pretty big one too, by the way: when you first start using KDE Plasma (Desktop) there is a javascript script that's run and that sets up your panel layout, your wallpaper type, your desktop widgets, and so on.

Now, the Plasma Desktop javascript script is pretty simple, it's only about your panel, because the wallpaper is the default one anyway and KDE Plasma Desktop doesn't have any default desktop widgets. However, if we did have widgets, then they wouldn't be correctly created. If, right now, you change the javascript to have a default clock - as an example - on the desktop, it won't actually be created at all. We don't notice because we don't have any widget anyway, but the bug is there. It's only on X11, not Wayland, but still. It's a pretty big bug.

So I spent a couple of days, with the help of another core KDE dev, to try to track this down. And I did! Basically, the issue is that when the script is run the first time, the data about your monitor doesn't exist yet, meaning that if the javascript tries to say "add a clock to the desktop on all monitors", well, "all monitors" is going to be no monitor at all, so no clock will be added.

So, I did a pretty simple MR that says: before executing the javascript, please wait until monitors are loaded up and ready. I was really happy of this MR. I was really happy. I was really happy. was. As soon as I created the merge request, a more expert developer than me replied that my approach was actually incorrect and that there's a better way to do it. So now I have to do another merge request using the better approach, which will require actually understanding even more code that I usally don't even touch. Which isn't a problem usually, but as you might've noticed by all the floating dialogs stuff, and all the plasma ink stuff, and all the math rambling and so on... I'm clearly overloaded right now. And I haven't even told you about the other big secret development project I'm working on. And you know, I have a youtube channel to keep alive.

In fact, I've written these twentifive thousand words of a script yesterday evening at eleven PM with a terribe headache. Which is why it's particularly rambling and stupid script, sorry about that. But you get the point: I'm trying, really hard, and I'm managing to do some cool stuff.

Which is a perfect, beautiful way to switch over to talking about all the people who allow me to actually do all of this KDE development and scripting and video recording and paying an editor. And, yeah, it's you. There's all the people on patreon, liberapay, ko-fi, and paypal backing me up and there's the sponsor, malubul, all of you are helping me out in this exciting but sometimes extremely hard to keep up with ... journey. Patrons do get benefits too, like a sort-of podcast every morning and secret blogposts and such. But even if you're not a patreon... Thank you.

Thanks everybody, and yeah, I think I'll go to sleep now.