 One year ago, the consistency goal was selected during the 2019 Academy in Milano. Abbas Karmi was invited on the stage to better introduce it. Now, Hemir, again, to talk about how is he going after one year of developing it with KD. To be honest, I'm still a bit scared, but at least I don't have to go on stage, because last year I was a bit embarrassed, as you can see here. Now, let's start immediately with what is consistency anyway. So consistency here means having a single solution for a particular problem, rather than many different ones. This applies to application design elements, feature implementation, website structure, and the style. And the KDE ecosystem has a whole that, unfortunately, obtains some burst from redundancy. Now, even though I wrote the above, it still feels a bit like jargon. So let's see an actual example of consistency. So the search bar. The search bar, it is a trivial task. So we have different applications that say, I need a search bar. That sounds easy. I'll just do my own implementation. What could go wrong? And it does go wrong. So we can see here that we have disabled buttons, and here they're active. We have no arrow here, and we have an arrow here. We have arrow here, no arrow here. We have defined as text here, and then it becomes inside the text bar. Here, the width is not filled. And in here, these are flat buttons instead of buttons. This is a whole mess of inconsistencies. So why does this happen? Next slide. We start with the attribute tasks implementing a search bar. There's no clear guideline, so the HIG doesn't specify how a search bar should be. We have slightly different use cases, a web browser, a text editor, and so on. So we end up with an inconsistency. Now, first of all, how can we avoid that from happening? But first of all, we talk about guidelines. We can have some clear and strong human interface guidelines. We could improve the work that was already done on hig.kde.org. The new stuff should be on the HIG before it lands. If I'm implementing a new component, it should be defined in the HIG before I actually land the component. This is very important. Then we can have a clear design direction. The VDG, mainly, should have an idea of what design we are moving to. Having mockups here is extremely important. So for this reason, I will have many mockups in these presentation slides. So also we need to let different developers talk to each other. Coordination between applications is essential when we are implementing the same feature. But what can we do with the inconsistencies that we already have? So first of all, we need to find them. I'd suggest to discover all KDE apps. What I mean with this is going to the KDE.org-slash-applications webpage, going through the list of the whole applications and trying them all out. This takes a lot of time. I did this when I originally proposed the consistency goal. And it really makes you have a feeling of what is consistent and what isn't. It's really an exciting experience that I would suggest everyone would do. So second, I'd suggest to design reusable components. This is something that we have done many multiple times, implementing a simple component that's reusable in different places. We'll see how we've done that. Finally, we cannot support for non-KDE application because most of the world is outside of KDE. We can make Firefox, GTK application and so on feel native in Plasma and that greatly improve the consistency feel of the user. But anyway, how does this improve KDE anyway? So first of all, we have better software usability. The users will recognize a pattern in one application and they will be able to use that pattern multiple times. Then we have branding. The user consistency visual elements will strangle it because one person will see one application and then we'll see another and they will recognize that both are done by the same person. So that will help branding. Then we have less code because by implementing the same component that's used multiple times, we don't have to implement new code each time and it's also easier to write apps because we can just use the reusable components that we have previously done. So sure, but how did it go? How did it work out? Did it actually improve KDE? So let's start with Plasma. Plasma as a whole, it doesn't have many issues regarding consistency. We can see a need of tree spacing, icon size and so on when those are using inconsistently throughout applets. There is work on going to fix those incrementally. We can see applets margins were fixed in 5.18, heading was introduced in 5.19 and so on. So we can actually see now the incremental updates that we have done. But first of all, the mockups. So these are the mockups done by Manuel. I think they are absolutely beautiful. And even though we are still missing a couple of things, I think we really got close to implementing them. We have here the notification mockup with the plasmoid heading that was actually implemented in 5.19. We can see it in kickoff, in the system trade, in the notification and finally in the new widgets sidebar. So this was done consistently throughout Plasma. If a theme was to change the look of the heading, it would apply immediately to all these places. So that's beautiful. Then consistent list in applets. So we had a consistent highlight item that was not used in places such as the Bluetooth applet. Now it uses the highlight thanks to the introduction of a new component that is the expandable list. The expandable list is a list where elements can be expanded. So this was quite important because when we decided to do this, we also thought, is there anything that we can add to this expandable? Yes, the comic sense was a joke. Is there anything that we can add to this list? So that the usability of it will be improved. So we actually added this button that makes the user understand that this list element is able to collapse and expand. So because we thought we need to do this consistently, we also thought, how can we improve this? So that's awesome. Then we also worked on the media player view, which is now, in my opinion, absolutely gorgeous. We made it consistent with our ELISA application. So that's very nice. What's next? We are working on panel icon sizes. Now this was absolutely not easy as it seemed. It generated a lot of discussion and we are still working on it. This is the latest proposal that you are seeing that hopefully will be implemented soon. So we've talked about Plasma. So we can try to see what is this situation in applications. So first of all, the application situation is a bit more complex. There are currently two visually different types of application. We have QVJets ones and the Qerogami ones. Editing a Q-style is tough. So it's hard to find people willing to make QVJets more consistent with Qerogami components. There has been a lot of work on creating new Qerogami application. Some fitting use cases are not covered by other KDE applications such as the dialers, the recorder, and so on. This is mainly driven by the development afford in Plasma Mobile. And some other might probably be the QVJets application. We have done Coco, which is an image reviewer. Calgebra has a Qerogami version and so on. There has also been a long VDG discussion in less than a year to decide how tabs and view navigation should look like in views and cyber views. We did eventually reach a consensus and we are now working towards a clear direction, which is defined by this mock-up. So what do we have here? First of all, we have a new tab look and then we have these. These are technically tabs as well, but we decided to have a different look using the headlight style because this one, the user can add them, can move them, can close them, but this one are defined by the developer of the application. The user cannot drag them around. So they have to have a different style so the user can understand that they are different. This style was actually implemented in Qerogami if I get to the next slide. Yes, as you can see here, we have it at the bottom when it's in phone mode and it's consistent throughout QD applications. These are not mock-ups, these are actual applications. So we also are working on the new tab style. We've added a blue line on the top and it's also important to notice that Kate now uses the Q-Style tab. So as soon as the new tab style lands, it will also be used by Kate automatically. So that's awesome. Previously, Kate used an inconsistent tab style. So that's a big win for us. What else? Next slide. We also made the scrub bus a bit more usable everywhere. They now no longer collapse automatically. They always stay there. So you can easily drag them with the mouse. They also have a separate line to clearly define them. And most importantly, this was done throughout QD application, Qerogami ones and both QWidgets ones. So this was done consistently. So this is great. We've also worked on GDK support. So now GDK application will follow shadows, resize errors, and they are not following the color scheme, which is extremely important and most importantly, very recently, the decoration. GDK application will now follow your decorations. So this will make GDK application feel very native and the user might not even see the difference between Qt and GDK application. So that's very consistency of us. Finally, we are porting KCMs that is system settings sections to Qerogami. So we have done online accounts, Windows rules, global shortcuts. Bluetooth has just landed and we are working on network manager. The hand aim is to make system settings pure Qerogami in order for it to be completely consistent throughout it. If that was too much stuff and you didn't listen, overall, how is the consistency going? So pretty good, thanks for asking. Many tasks in the original consistency proposal are already addressed, such as the list highlight. Some other tasks are being actively worked upon. Some other tasks are waiting for a developer to kick in, especially once related to QVJets. So if you are a developer who wants to help, this one is a great way. We'll see later how. Finally, some tasks are stuck as they are controversial from a community point of view, so I didn't talk much about those. So if you want to help consistency, first of all, thank you. That's very nice of you. You can give a look to the tasks that we have on the consistency work pod on Fabricator at this link or simply by searching for consistency in Fabricator. You will find it. And most importantly, you can join the VDG chat on Telegram at the VDG main room or on Matrix. Or you can also ping me personally on Telegram if you don't know what to do. I can help you and introduce you to the group. So if you do not know what to do, here are some ideas. First of all, we need more HIG pages. You have seen the new lateral navigation component. This is not yet on the HIG. This is very important that it gets there soon. So we also need to implement a sidebar component using QVJets app. This is also very important. We need to improve our new Keregamia application. You can try them out, report bugs and so on. We need more bug reports for inconsistencies. So you should try many KDE application and see what's inconsistent throughout them. And we also need more cooperation between application and the working groups. I'm not only talking about VDG, but often also the Chrome group. So you can just pick one and get started. You can write to me personally. I have free time usually. And this is pretty much it. So do you have any questions in the shared notes? Hi, yes, we have two questions. We have three questions. The first question is how do we convince developers to switch to standard components instead of using their own ones, especially in conflicts of design or lack of features in component? I think that the best way to convince developers to switch to a standard component is to make that component more both featureful. So you need to have all the features of the previous component. So otherwise it will both not be like by the developer of the application and the users. And another important thing is for it to be pretty because often we are deceived by the look of something. And if we see that it is prettier than our current implementation, we could also think that it works better. Okay. We have another question. How do you manage to strike a good balance between refreshing the visual identity of Plasma or the ears while maintaining visual consistency with all the other TV apps? This is done because in theory, Plasma applications don't implement their own styles, but they follow a general style, the Q-style as an example. So by changing the Q-style, such as the tabs, that change will take effect on all applications at once, such as Cade as we've seen. What happens sometimes is that single application do not follow these general styles as Cade was doing before the patches. So what we need to do is both make the Q-style better and make the application follow the Q-style. This is regarding Q widgets. Okay. The other question. Won't porting applications to QML or QRIGAMI hurt visual consistency WRT Q widgets apps? Yes, but the problem is we have to do it anyway because we currently have QML, QRIGAMI application. We cannot just say, okay, let's stop developing QML, QRIGAMI because QML, QRIGAMI application are strongly needed for Plasma mobile. And the fact is QRIGAMI was meant to be convergent. So application developed for Plasma mobile are to be also used on the desktop, which means that we are supposed in the future to use a convergent application than with QRIGAMI on the desktop. Given that we, given these, we will surely have some inconsistency between QML and QRIGAMI Q widgets. So we will have to address it and the best way is not to stop porting application to QML, QRIGAMI, but rather to try to choose one framework that we need to use and currently that framework is much closer to QML, QRIGAMI. QML is not really to support our application, of course, but we hope that in the future it will be maybe with the strict QML that should be much less RAM intensive and faster in QT6. Okay, so our last question is which framework will be favored in the future, QRIGAMI or QWidgets? QRIGAMI cannot cover all use cases. It's mostly a framework for convergent apps, so apps that should also be used on a tablet or on a phone. As an example, I do not think that KDevelop or Krita will ever be ported to QRIGAMI because that is not what QRIGAMI is made for. However, it could happen that a new framework specifically for QML desktop application could appear. So there's still a bit of uncertainty there.