 Okay, so today we will speak about system settings. So I'm Benjamin Port. I'm from Enochout OddCuture, a French development company that sponsorized my time to write the slides. That's why I use the system. So let's start. Are you smoking? So why we need system settings? As you know, Plasma is a powerful environment and there is lots of configuration. And so we need to let the user have a way to configure them. That's why we have the system settings. System settings is composed of many, many modules for Plasma, for example, for Plasma, but also for other stuff like sound with Pulse Audio or display or fonts and everything. Everything is a module on the system setting. So I guess everyone knows what is system setting, but yeah. So what are modules? In lower levels on a screenshot. So modules are QWidget or Qt QuickBuzz. In the future there will be all Qt QuickWidgets. It's a goal for KDParamorx 6 to don't have QWidget modules anymore. So mostly of them are based on the Kconfig framework. It's a configuration framework. I will tell you more about that in the next slides. And there is also some other configuration frameworks used there. Two settings, Chicov and some other for some modules. But when we were like one year ago, some stuff were broken. For example, we don't have the apply result and default button. Work is expected on all of the modules. Lots of times the state was not the one expected. And in many cases, visible feedback for the imitable entry was broken. I will tell you more about imitable entry in the next slide too. But basically we need to disable a widget if it's in the table. And that didn't work at all for all modules. So I will tell you a bit about Kconfig and Kiosk. So like I said, Kconfig is a framework for configuration. It abstracts the way we store data for configuration on the disk. It's a kind of unified with some specific stuff. And that allow cascading. What that means is we can have configuration at user level. But we can also have configuration at system level. And if there is configuration at user level, it will be took. And if not, we will use the one at system level. And if there is no configuration for this item at all, we will take one from the code. It's what do Kconfig basically, really basically. Kiosk is a framework based on Kconfig that allow administrator to create control on your environment for the user by automating and looking almost any aspect of the configuration. So basically you don't want the user to change the font. You can say, oh, I want the font to be in the table. You do that on the configuration file. And at the end, the user have a configuration module with font disabled. So they can change font but can't change that. It's really important for enterprise called university and lots of other like that because in some case we don't want to let the user block the setup. So what we see in the previous slide is we have problem with state of button not working and also imitability not working. So we needed a solution to fix that. So Kconfig XT was the chosen solution. It's allowed to use the XT system because Kconfig XT already exists and have lots of benefits for us. So Kconfig XT is based on Kconfig and it allows to automatically sync a widget and setting value. The configuration entries are declared on an XML file. I will show a bit of that work later. And with the compiler, you will generate C++ code automatically that you can use directly. In fact, you generate a Kconfig skeleton subclass that generate for each configuration key a Kconfig skeleton item. There is different kind of item for string, for color, for bullion and whatever. And that we manage all things automatically for you. So if you are using a newer file, so a bit old-fashioned nowadays we do everything in Qt Quick but at the time Kconfig XT was created it was not the case. If you name a widget starting with KCFG as prefix and key entry name as suffix, it will automatically bind the settings data and the widget. So it will be a bit of magic and everything will work. By everything I mean the dialog button state will work. So we will enable or disable the default result and apply button when it's needed. So basically if you didn't change anything, the apply button will be disabled and the result button will be disabled. If you change one setting, the boss will be enabled and if configuration are not like the default one, the default button will be enabled. And you don't have to do the logic for all your items. It will be unlocked for free by Kconfig XT. It's also taking consideration, immutability and will disable the binded widget. And also a nice thing it can be used to generate documentation of configuration option because like I said with Kiosk you can change the configuration file, mark some items as immutable but you firstly need to know the name of those items. And if you have all that on an XML file, it will be easy to auto generate documentation to show that. But in this case there was some drawbacks. We needed to put all module to it and yes there is tons of modules because Plasma is slightly customizable. And there was no QtQuick support and like I said earlier, the plan for the future was to have all modules on QtQuick. So it was a problem for us. So the idea was to bring Kconfig XT to QtQuick. I want to thank Kevin Attenz for that. He did the first work on this attempt. So basically QtQuick module are based on config module. So there was a creation of managed config module that will extend config module with Kconfig XT support by registering the skeleton automatically. This is a way to use the KCFG file again and manage config module, take care of default state and stuff like that. So at the end the dialog button will be on the good state for free for us. But for that we needed to port all modules from config module to manage config module and from Kconfig to Kconfig XT by that I mean don't choose Kconfig directly but use the class generated by Kconfig compiler. And at the end in the QML side add setting state binding for a graphical item it will bind it to a setting entry and that will allow it to handle the immutability so basically if the item say oh it's immutable we will disable the parent item. So with that at the end it was a huge work to port not all but a lot of them to manage config module and that brings us new idea. The first idea was oh new commerce can be a bit lost on system setting because you know there is tons of settings so allowing them to find what differ from the best configuration you know all that the best one is the default one can help them. So basically when you are in new commerce in lots of in general you play with settings because oh nice I can I can configure everything and at the end you say hmm I don't really like that it was better when I didn't change anything but you don't remember what to change because you are crazy and you click everywhere. So allowing user to know which module works change and when they are in this module which time or change can be really important and useful. So yeah I guess a screenshot can let you understand a bit better. So basically here we can see I change fonts I change startup and shutdown search and regional settings and fonts because there is an orange dot so you have a button to click to see that it will be available with Plasma 519 and on the module side you will see there is for example the general font change so it's in an orange and the anti-aliasing Oh yeah Plasma 5.20 sorry my bad. So this will be orange when there are not defaults one so if I hit the default button I know exactly which settings will be reversed to default value. So all that works so we have used setting state binding again that will allow it so I like it when needed. There is still some limitation because it's still not done for all modules. Major modules are done but still work on going. It works only for cac-config xtbase module. It's not exact but mostly. And work well with bridge time because we need custom support on the times so other time we need to support it to highlight key. And for the model list level we needed to load all modules when we start system setting not when we start but when we click the button to show to highlight defaults defaults module and the problem at this time it was if you want to load a module you needed to load UI too and it was not ideal. So we introduced kcmodule data that will handle settings and expose them to kcmodule. In fact in the past kcmodule used it directly. kcmodule or config manager config module on Qt QuickSight. And that will allow to split easily data and UI because in the past everything was declared in the same place more or less now it's split. So by regrouping all settings on the same place we can just load the settings without the UI and without the change that will be made if I change UI because I don't want to save it I just want to know what is on the disk. And now we can ask easily a module about a default state and there is no performance issue. In the future with this we can imagine some other use case like improving module searchability. So basically like I said we can improve system settings searchability. We can query information from KCFG using kcmodule data to have up-to-date data because currently search on system settings is done by looking at desktop file and if you add another field to a settings you will probably not update the desktop file. So it can be interesting to use it in the future and that can be used by Carbinar to improve the Carbinar discoverability too. And another idea can be to highlight corresponding field. So basically you see what we did with default. We can imagine the same thing basically I search a general font and it will allow general font so I know in which module is it and also which field is it because there is some module with tons of fields and it's hard to find them. But more generally we can imagine to interact with KCFG file data and have other idea global export or something else. This idea is not idea I think we need to do but was what go to my head when I wrote this slide. And yeah basically it's people idea we can think about it it's pretty new so let's see in the future what we can with it. So if you want to be a wizard too you can use it so basically you will need a full module data that will extend KCFG module data. This will register your full settings that was a class generated by your KCFG file that expose item properties and then we will have a full module that generates managed config module and have a full module data attribute and you will expose the config skeleton so the full settings from KCFG module data so also Q property so you can access it from QML and the QML code will bind item using setting state binding and you will do a bit of same aid. But I guess with a bit of code it will be more clear. So I took as example the desktop same setting because yeah it's an easy one there is only one entry. So basically for the KCFG side there is two files there is a KCFG C file it's a file that declare to the compiler which file to compile the class nine generated and some other extra data I will not go in details here and then in the KCFG file you can see you have a group name the file name is the configuration file on your disk the group name will be the group and the entry name and you can also have a label currently we don't choose them but I think in the future can be a good idea to use them that can be useful for stuff like search and there is also the default value so basically the KC module data it's a non-interesting file it's just here to collect all settings this is on the case you really use KACOFG XTF for example for Sony based on settings there is a bit more of code but for lots of cases there is no code and there is an ongoing effort to have a semi macro to generate it because there is no interest to write this code it was basically the same for all modules so basically we have settings and we call it auto-register skeleton to register all skeleton to have them when we query it there is also the managed config module nothing really interesting here just we use the desktop time data created earlier and we expose the other properties the desktop settings and on the QML side we can see here the QML item is a great view KACM is the great view for all time modules and we bind it with desktop time settings and the name is the name and we have an extra enabled condition is because setting state binding will do the imtable stuff but basically we will also want to disable if we are currently downloading a file but everything is not perfect all settings don't use KACOFG like I said we may use Q settings and also you will use GCONF so we can choose KACOFG file for them so cut property skeleton item was introduced it enabled us to declare skeleton manually and synchronize them manually with GCONF for Q setting it's a lot of work but it will allow us to have something more homogeneous and on the binding part there is also some difficulty but basically sometimes for I guess historical reasons we have one configuration key bind to multiple widgets or the other way one widget that will have multiple configuration case so I guess in the future we need to prevent that because it's hard to maintain and yeah we can have auto binding so I think we need to probably write configuration migration to avoid that because I'm not sure there is really use case where we can do those away so thank you for your attention and if you have any questions I guess there is because Cherno is right perfect time okay so it looks like we have three questions so far one is building type I'll give it a second or maybe we can have this question later so will these pages make it easier to make variants of the appearance of specific settings if desired I understand the question the question is still as I know for now we can't disable hide settings but yeah we can we can disable them I'm not sure there is plan to hide them perhaps someone else knows that but yeah not sure alright well let's go to the next the first question I suppose what should I do when I can't base my module on k config xt for example for highlighting change settings can I still use kc module data I'm asking for global shortcuts so don't know how I would use k property skeleton item so basically it's the case of something that don't choose the k config xt directly so yeah you can still use kc module data because it will be just more works because you will need to handle what is default and when you enter it provide a default method to highlight default settings also it's doable but it will need more work because you will need to do everything more or less manually and we have done that for some modules I don't remember which one but yeah we did that so I hope I answered to this question okay well next question then we can have when can we have a system that syncs all my plasma and kd app settings to the cloud so it gets recreated when I reinstall so when someone will do that I don't know there is no plan for that yeah a good solution is not to reinstall but yeah I know sometimes we change setup so it's needed you can probably already export your configuration file but there will be perhaps some stuff you don't want anymore but yeah there is no plan at all as far as I know to save stuff to the cloud now but it can be a good idea awesome okay last question and last one more trickles in will kconfig xt incorporate kiosk functionalities or kiosk will exist as an individual app so kiosk is not an application is a framework so basically is what enabled to put in the configuration stuff like immutability it exists I guess from decade now it's something used in the past sometimes it was not working anymore as expected because some stuff are broken but it exists and there is nothing new and there is no app for that I guess we expect system administrator to write the configuration on their favorite text editor