Yet another KDE blog :)
This year i took part on the GSoC and i was being mentored my Martin Gräßlin. My project was to port the KWin Effects KCM to Qt5. After a bit of research we decide that it will be easier to rewrite them back from the scratch instead of trying porting them.
We wanted to have an application which is written completely in QML and we were able to do it because of the Qt Quick Controls. And in order to do that we had to make a lot of changes into the KWin Effects KCM, because it was based on Qt Gui so all the UI stuff needed to be rewritten from the scratch. So we came down to the conclusion that it would be easier to rewrite it. The name of the new application is KWincompositing. Also some of the KDE4 code did not make any sense on the world of Qt5. Furthermore, KWincompositing is using a more flexible model (QAbstractItemModel for those who are interested for the technical details) for loading the effects. The KDE4 model was coming out of a library which didn’t allow us to modify stuff. For example we didn’t had the ability to add an extra button for removing the effects which had being installed from the Get Hot New Stuff… And more cool stuff can be added, we might add an embedded video which will show the functionality of each effect.
What are the advantages of the new UI?
The new UI comes without any tabs, while the KDE4 version had 3 (General, All Effects, Advanced). The existence of the tabs was making some stuff harder for the user because he had to remember which option exists in which tab. On KWincompositing all the available options exist on one page. So you will no more have to navigate through the tabs. Also our new UI comes with more changes. E.X. the about information for the KWin Effect, the KDE4 version was opening a new windows, while the KWincompositing is showing you the information inside from a dropdown menu. At the moment the KWincompositing is under development and it is not consider to be stable.
This year I am going to the Randa meetings. Randa is a small village in Switzerland.
This is the first time that I am going to a KDE sprint and I am very excited about it.
This year it will be the fourth sprint that will take place in Randa.
I will work together with the Plasma team and mostly I will try to help with libplasma2 and Plasmate.
The later is also related with my GSoC project.
At this sprint we are all volunteers and as you understand there are some expenses like food and travelling.
There is a fundraising campaign for the Randa meetings and If you want to help with those expenses you can make a donation at pledgie.
On the fifth week of my GSoC, i have added support for CMakeLists.txt and for plasmapkg on the KWin Scripting.
Until now the user wasn’t able to install or create a CMakeLists.txt for the KWin Scripting packages. Now he is able
to both generate a CMakeLists.txt and install the package through the Publisher. Below i describe the main difference between the
CMakeLists.txt and the plasmapkg.
- Plasmapkg will install the KWin Script locally, so the other users will not be able to run your KWin Script.
- CMakeLists.txt will install the KWin Script globally, so the other users will be able to run your KWin Script.
The Plasmate’s Publisher
On the fourth week of my GSoC, i have add the KWin Scripting support to the startpage of the Plasmate. Until now the user had to write the structure of KWin Scripts manualy. So now he can do that inside from Plasmate. Also KWin Scripting support on Plasmate is coming with a template, which contains links to the KWin Scripting Api and to the KWin Scripting tutorial. (The links exist at the end of my report)
On the third week of my GSoC, i have added support for CMakeLists.txt and for plasmapkg on Plasmate. Besides from adding a new template for Window Switcher, i have fix a bug on plasmapkg.
The CMakeLists.txt and plasmapkg support is located inside the Publisher. So there are two ways to install your Window Switcher.
- The first one is with plasmapkg. Plasmapkg will install the Window Switcher locally, so the other users will not be able to run your Window Switcher.
- The second one is with the CMakeLists.txt, with this way your Window Switcher will be installed globally, so the other users will be able to run your Window Switcher.
The Plasmate’s Publisher
On the second week of my GSoC, i have added a previewer for the Window Switcher. With this previewer, you will be able to view your own Window Switchers but also you could refresh it. Also there are two ways to run the previewer.
- The first one is inside from the plasmate and it will only preview the current window switcher.
- The seconde one is to run the Window Switcher Previewer as a standalone application. If you run it as a standalone application, you will be able to load any Window Switcher, as you can see in the screen shots below. The standalone Window Switcher is named windowswitcherpreviewer
The Window Switcher which is embedded to Plasmate
The Window Switcher as a standalone application
This is the first time that I participate in GSoC. My project is to add KWin integration to plasmate and i am mentored by Martin Gräßlin.
Right now the plasmate doesn’t support any of the KWin features, so it’s been a pleasure for me to add those features. One of my tasks are to add Window Switcher support for plasmate.
This week my task was add Window Switcher on the startpage of the plasmate and to add a beautiful template for the Window Switcher.
Of course this feature isn’t ready yet, the next week’s task is to add a previewer inside plasmate for the Window Switcher. This previewer will help the developer to debug their code easier.
As you can see in the picture below, on the startpage of the plasmate there is a new entry below the “Theme” option, with name “Window Switcher” :)