 Hello and welcome to yet another episode of Stop Seeing That Using JavaScript to build the entire desktop is not a good idea. It is, it is, we'll get to it. So today we're talking about all the languages that Keri uses to build, you know, Keri, which is not just the desktop that is Keri Plasma, but Keri as a whole, so the frameworks, the applications, everything. Also, I will try to give you some examples of the code because I bet that there are some programming languages that you might not know. And I'll give you also some comments on why I think they are such a nice language to work with. So now the entirety of Keri is actually written in Scala. If you don't know Scala, it's a functional program and just kidding. There's no Scalimbo. We do need to make a bit of a difference, differences, different categories. We do need to distinguish between the frameworks and the applications and the desktop, that is, between the core stuff that is like behind the scenes with which you interact, but they don't have like a graphical user interface because there are libraries that are used elsewhere. And, you know, the actual GUI and the graphical user interface, the things you do interact with. These are very different things and usually you do need the core stuff to be like fast and reliable, whereas for the UI, you kind of preferred it to be easy to maintain, easy to develop that kind of stuff. So that is how I personally see this balance to be. So starting off from the frameworks. This is the webpage that you get if you search for the Keri frameworks. And, well, if you look closely, then you already kind of have the answer to this video here. Could an application in C++ with QT and QML? Of course, that's not the entire story, but we do need to give a little bit of context here. So what is QT? If you know, you can skip this part. If you don't know, QT is the graphical toolkit that Keri uses to pretty much throw anything on the screen. So it's pretty important. It's a big toolkit which is used not just by Keri, but also by lots of other companies and organizations. And of course, what languages Keri uses depend heavily on what languages does QT work with. If QT doesn't support a programming language, then that's, you're not going to find it in Keri for sure. You wouldn't be able to draw anything on the screen. So QT originally started with C++ and as far as I know, Keri also started with C++. And in fact, if you go look at most of these frameworks, most of, if not all of the stuff that goes behind the screen and that don't have a UI is in C++ because it is probably the most used like static and compile programming language, I think. You do want the frameworks, the stuff that goes behind the scenes to be stable, do not crash. So you do want to be type checking and you do want it to be compiled so fast. So you do want it to compile rather than being interpreted. I think that's how I see it. So it's all C++ really. Now, if you do start scrolling the list of frameworks, you will get to stuff like KoriGami. Now, KoriGami is completely different because it is meant to make a UI. So it's a completely different use case. So what do we use in this case? Well, again, here, the choice wasn't really kiddies, but rather it was heavily influenced by what QT decided to do. That is QT decided to do QML. QML stands for QT markup language. It is a markup language. And I will also show you how it looks like. This is a QML file. And QML is interpreted, not compiled, currently. And it does have some very nice things. First of all, it's actually, in my opinion, very easy to learn and use. And also to read, I think, from some point of view. So in this case, you can see that there is an application window inside of this application window, which is called root. We have that the title of the application is Ariana. We have the width and the height of the application. And we also have the minimum width and minimum height if you're resizing this application. Now there's a bit of logic stuff, but we can jump through it. And here we have an important property, which is the page stack. All of this, by the way, is implemented through KoriGami. QML is just the markup language. So the page stack is the list of pages that your application has. So it is just an application page, a KoriGami page. So it's just one page. The title of the application of the page, sorry, is ebook title. And it has F2 actions that is buttons, one that is called next page with an icon whose name is arrow right. The shortcut is just the left arrow. And when it's triggered, you switch to the next view. And these kind of things, like this is just an example. I won't start like explaining what, how QML works, but you get the idea. And I think it's very easy to read and write. So it is a very nice language. And this is very important. Basically, all of Kedi's UI is made using QML. Not everything. Some things still use the QT widgets, which is the stuff that QT was doing and is probably still doing. But that was before QML. Before QML, everything was QT widgets. So there has been effort to port everything that's QT widgets to QML roughly. Some things were easy and fast to port. Some other stuff weren't. As an example, system settings, there is an ongoing work to refactor a lot of system settings pages because some of them are QML. Some other are still in QT widgets and should be ported to QML to QML. There are also some applications like gate and Dolphin, who to the best of my knowledge are entirely made using QT widgets. And it's not really easy to port such a big application to QML. So they will probably stay QT widgets forever. And that will only change if a new application is done from scratch using QML. All of the latest newest KDI applications do use QML, as far as I'm aware. So that is clearly the direction forward, I think. And also the desktop is entirely made of QML. So it's a pretty important language. Now, here's the controversial thing. It's always funny to talk about this. QML, of course, is just the markup language. But you do want to have some sort of logic inside of QML. And that is why QML integrates JavaScript. Like, you might have noticed from my previous example that that QML file was full of JavaScript. And yeah, since QML is interpreted, it uses JavaScript inside of it, which is also interpreted. And this means that there is a lot of logic in KDIs that is written in JavaScript inside of QML files, or in JavaScript files that are then imported by QML files. So QML is the markup language. And inside of it, you find JavaScript, similarly to, you know, HTML. But in this case, JavaScript is like embedded inside of it. And it's really handy because JavaScript, personally, I hate the language with all of my heart. But if you're doing some scripting, okay, you can use it. It works nicely. It does its job. So if you're doing some like fast prototyping, I bet I pronounced that wrong. It's nicer to use JavaScript for quick scripting parts rather than like C++, I think. And if you add that to QML, which is a markup language, pretty easy to learn and use. Altogether, I think it makes maintaining and, you know, writing applications or UI in general, very easy. So I'm actually a big fan of QML. And I think we'll just use it for whatever project I will have from now on. Now we might ask, okay, but doesn't JavaScript bring a lot of issues to the table? Okay, not a lot. So let's start with performance. So I do not think that JavaScript has a significant impact on performance in KDE, because it really depends on how you use it. So if you're doing everything in JavaScript compared to C++, I do think that you will see a performance or memory hit, but we are not doing everything in JavaScript. You saw that the frameworks like the core frameworks is C++, and you also, if you go to check out the code for the desktop and for applications, yes, there's the UI in QML plus JavaScript, but the core stuff is always usually C++. Some applications do use different languages, but it's very rare. As an example, I do know that AudioTube uses a little bit of Python, maybe a lot of Python, I'm not sure how much. There was once an application that uses, used Rust, I think, but it was just one. We also add another big Python application subsurface for a bit, but then they left KDE. So it's more like one of project. Almost all KDE projects use a combination of C++ and QML. So you do have the core stuff, the stuff that your performance depends on, that is written in C++. So JavaScript is not going to affect that. Another thing is that JavaScript's a bit messy when it comes down to managing errors, in my opinion. That's my personal takeout. I think it's much easier to write bad code in JavaScript compared to many other different languages, personal takeout. And that is a bit of a downside. You do have to balance these things. You do want to have something that's easier to use and faster to maintain, to make maintaining easier. At the same time, you're giving something away. That's a balance you can avoid. The scripts, as far as I know, are also JavaScript. And that is actually a really big benefit. And the reason for that is that the keywind scripts, I'm talking about keywind scripts, you're able to install them just using system settings. You just go to install new scripts, you download them and they work. Now, that can only happen if you're downloading something that's interpreted. If you need to compile something to use it, that's not going to work. And system settings can also not install packages from your package manager, obviously. So system settings, downloading stuff from system settings only work if it's something that's not to be compiled. So in order for you to install keywind scripts, it has to be JavaScript. Could be some other language, but JavaScript is the one supported. Same thing for plasma themes. You need a plasma theme. It's in SVG. So you don't have to compile anything. If you need an application theme, that's a bit more complex, because most application themes are actually C++. And that is why you cannot download them. If you go to the application theme part of it, you don't have a download more application themes. That's because they're usually C++ and you would need to compile them. And you cannot do that. In order to have them, you need to either build some projects lightly, or you can use a project like Kevantum, which again, you have to install from the package manager because it's C++. And then Kevantum downloads SVGs. So that's the idea. I think I covered everything. So thanks for watching and see you tomorrow.