Posted on

QML saved KWin Scripting

Over the last half year I blogged several times that I would drop KWin’s scripting component if nobody takes over the development of the code. Unfortunately up to now we have not seen any improvements. So keeping to my words I would have to drop the code.

Instead I decided to do a last try to get some work done and created some Google Code-In tasks and thanks to that the Tutorial and API documentation got imported to techbase. Example scripts are ready to be imported into kde-examples repository and we have received a KCM for managing the scripts. This is what I consider the minimal requirements for keeping scripting. Without an API documentation it’s just useless.

At the same time I have started to do my planing for the next development cycle. The main task of my work will be in the area of QML (surprise, surprise) with the aim to drop all custom GraphicsView code in KWin and replace it by QML. These are:

  • Remaining clean-up of TabBox: Desktop Switching needs to be ported, old code needs to be dropped
  • Aurorae is completely GraphicsView based and should be possible to be ported to QML. It will not just be a port of the theme engine, but will allow to write decorations in general using QML. One of the QML based decorations will then be an Aurorae theme interpreter. The long term plan for this is to get it into a state that it can replace the existing decoration API. Will need some time and some work together with Thomas and Fredrik – our decoration experts in KWin. The long term goal is to have it ready for the scene graph in Qt 5 and hopefully be able to integrate this very well with our compositor.
  • Desktop Change OSD: rather simple. Help more than welcome 🙂
  • Desktop Grid and Present Windows: our effects which use widgets. Now this is the really interesting part of my 4.9 work. Desktop Grid and Present Windows will be ported over to QML and won’t be effects in the classic sense any more. I have been dreaming for years about having effects in a state that our UX designers could do them without hacking C++. Finally we are at the state where this is possible 🙂 As a nice side effect that will make it possible to use Present Windows even without compositing – an idea Lubos told me at my first Akademy in 2008.

All those areas somehow have to access KWin Core and at the moment all have different approaches. Decorations use a “bridge” between the Client’s and their decorations and partially direct function calls.

Effects have an EffectsHandler and EffectsWindow interface representing the Core functionality and working as a proxy. So very similar to the decoration bridge but with much more functionality.

Scripting on the other hand uses a “Wrapper” to export JavaScript functions and calls then the underlying Core objects.

For QML we would have to add Properties to all the functionality which we want to have exported. Which would be the fourth technology and one to many.

Yesterday I started to add the Property definitions to our Client class and ported KWin scripting to use the properties instead of the Wrapper for Client. It breaks existing scripts, but works quite nicely so far 🙂 For me this brings scripting finally in the area where it becomes useable to me: an easy way to test my property definitions.

So we can expect that scripting will get quite some love over the next development cycle. It will be tailored towards my developer needs which will help everyone.

But not only that. Given that we now have the properties, we can also base our Effect system on them. And Thomas did some great work on a generic effect implementation. So expect a second JavaScript API to write effects 🙂

Exiting times are before us simplifying our development work and getting KWin ready for the next big step.

As I expect this to be my last blog post before Christmas I wish everybody a Merry Christmas and relaxing holidays. Thanks for using KWin and all the support I got this year for my work 🙂

Posted on

What bug statistics can tell us

Over the last months I got the feeling that lately my mail folders related to “user issues” are not getting flooded any more. Now feelings are always very subjective, so I wanted to check whether there is some truth in my feeling. Over the same time I noticed that there is much more trolling against KDE for example on the dot.

One of my mail folders is for new threads about KDE in the German ubuntuusers forum. I have received notifications for new threads for quite some time, but the mails get deleted automatically. So I asked Christopher Grebs whether he could provide me the required information. So here is a plot showing the number of new threads per month over the last few years. As it is an (k)ubuntu related forum we can expect higher number of threads in April and October.

I included the year 2007 as it was the last year with only KDE 3.5 which many users seem to praise as the best desktop environment ever without any problems. What we can see here is that the number of new threads in 2007 (average 154) is similar to the one of 2009 (average 168) while 2008 was clearly a year causing trouble to our users. Kubuntu shipped 4.1 with 08.10 and there is a huge increase in November.

But what is really impressive is the decrease in 2010 and even more in 2011. So my feeling was right, there are less new threads. In fact in 2011 (please note that there is still half a month to go) the average new threads are just 63, which is less than half of what we had in 2007.

There can of course be many reasons for that. Maybe ubuntuusers is not any more so popular, maybe users go to forum.kde.org which did not yet exist in 2007, maybe Kubuntu is no longer a popular distribution for KDE users.

But it could also show that either KDE lost many users recently or that our software became much better, much better even than KDE 3.5 has ever been.

Now I thought how can I verify that this is not related to the forum in question and for that I wanted to look at our bug database and wrote a small tool to generate some statistics (if anyone is interested in the raw data please send me a mail). So here I present the number of opened bugs per month for KWin. As opened bugs I mean bugs which are either still open or have been fixed. Duplicates, invalid bugs, etc. are ignored.

Here we have a slightly different picture. Given our release schedule we expect higher numbers at end of year and mid of year. 2007 with KDE 3.5 hardly had seen any new opened bugs till the beta of 4.0 came around. Unlike in the forum 2008 is not the year with most reported bugs. KWin did not enable compositing till 4.2 (January 2009), so it was for most early adopters just the same as the 3.5 version. We can clearly see the enabling of compositing starting at end of 2008 with the high peak after the release in February 2009 and constant high values throughout the year. But already 2010 showed less newly reported bugs and in 2011 again my feeling is correct. Currently the curve is below the one of 2007 and the average is close to 2008 again (16 compared to 17 reported bugs per month).

Now this are two datasets validating my assumption. So let’s have a look at a third one: the number of opened bugs per month for Plasma. Here it is important to know that Plasma’s bugs are not as nicely triaged as KWin bugs, so it is likely that the number of bugs is just too high.

Here we can see the same as in the KWin case: 2009 was the high bug year and 2010 and 2011 much less new bugs. In 2011 we have an average of about 82 bugs/month compared to 80 bugs/month in 2008. This is an even more impressive trend than for KWin given that Plasma is much bigger and new concepts such as Netbook shell and many more applets were added.

Now given these datasets we can clearly say that our users find less bugs in our software. The only remaining question is whether this is caused by less problems or less users. For a source-code only distribution project such as KDE it is difficult to know how many users we have and we have to notice that very often the only feedback we get is the negative one. So it is difficult to say whether there are users with no problems or no users. But also for that question we can ask bugzilla:

This graph shows us all reported bugs against KWin including duplicates. The interesting value is the “Intel Peak” in May 2011. This driver bug affected Kubuntu users with Intel GPU and enabled unredirection of fullscreen windows. So although it only affected a subset of users and DrKonqui recognized the duplicates it’s the fourth highest value for the complete data set resulting in 2011 seeing almost as many bugs reported as in 2010 (832 vs 806) with still a big chance of 2011 surpassing 2011 as in each year more bugs have been reported in December than in November. We also see the problem of the Intel bug going away with the Kubuntu release of 11.10.

Now I generated some more graphs which show us some more data. Here we have a complete graph for all bug data of KWin over the time.

Again we clearly see the Intel Peak both in the reported Bugs and Reported Crashes. In general we see very nicely the DrKonqui induced bug reports. Whenever there is a peak in the reported bugs, there is also a peak in the reported crashes.

This we can also see in Plasma. It is quite clear that very few crashes affect a large userbase. As with the case in KWin these can be upstream. E.g. I’m quite sure that the last peak in the graph has been caused by a change in Qt 4.8.

Impressive is the beginning with all bugs being more or less fixed instantly during the development. There is one more interesting thing to be seen. Twice a year Aaron starts to panic about the number of opened bugs in Plasma and I think we can see this here as well. Let’s have a closer look at the fixed bugs:

Quite an impressing work the Plasma devs are doing there. Overall I think these graphs validate that there are less bugs and it shows how our software has matured over the years.

Posted on

Experience from Porting Kickoff to QML

As mentioned last week I started to port Kickoff to QML as a training project. Now I am happy to announce that Kickoff with QML is functional and can already be used. If you want to give it a try, just checkout the kickoff-qml branch in kde-workspace and rebuild the kickoff applet. It does not overwrite the existing applet, but adds a second one called “kickoff” instead of “Application launcher”.
Kickoff QML Application View

As we can see in the screenshot Kickoff got connected to all the Models, so we can browse all the tabs, the applications and perform search.

The actual idea was to just do some QML training, but it turned out to be more a training on Qt Models. The Kickoff code is let’s call it interesting. All the tabs have an underlying Model, but what was really surpising is that all Models have a tree like structure. For the Applications Model this was to be expected, but why are the Favorites in a tree structure? As QML is still rather limited for Tree Views I changed the favorites and leave model to be a plain list model which makes it easy to use.

The systems model (applications, places and removable devices) turned out to be more challenging. It uses a QProxyModel instead of QStandardItemModels and merges the applications and places into one Model again in a tree structure. Changing this to no longer being a tree structure seemed non-trivial and I did not want to touch the C++ code. So I started to implement a Tree view in QML for the system tab. Finally I had the QML code to play around with to improve my skills.

After I succeeded in rendering a tree view I noticed a new problem: both places and removable devices showed the same entries and too many entries. It took me quite some time to figure out the problem: the Model is buggy. The proxying was not done correctly and the view so far filtered out entries not relevant to the current section – ouch. This I could not copy in QML as the row count of the Model would not match the count of shown entries resulting in wrong height calculations.

So I had to fix the Model and was back doing C++ programming. Now the Model correctly proxies the underlying Model and I can use the standard views in Kickoff as it is also no longer a tree structure. All my work on the tree view in QML was in vain *sigh*.

Last but not least I had to face the recently used Model. Like all the other Models it has a tree structure. After the experience with the Systems Model it was clear to me that I have to rewrite it as well.

After that the last remaining task was to integrate the search and finally a Model which worked exactly the way I expected it to be. Exported the Model to QML, connected the search field and there were search results. Thanks Ivan for the great job of providing a working Model without having to first fix it.

The results of the work look really promising. Kickoff is much faster, all Models are lazy loaded, that is they get only loaded if the tab is selected. So there is no delay any more when clicking the Kickoff button in the panel 🙂

Of course there is still lots of work left for me to train my QML skills. Drag’n’Drop support is missing, context menus are missing. We need some nice animations. But of course there is still lots of time till master opens up.

Posted on

Weekend Project: Porting Kickoff to QML

Last week I decided to do a small evening and weekend project to improve my QML skills. As I had worked on quite some QML already for the new screen locker and the window switching layouts, I wanted to do something more complex, but still something to work on in the evenings.

Given also Marco’s post we slowly have to transit the Plasma Workspaces to Plasma Components, so it makes sense to look in the Plasma area for a widget which could use a rewrite.

I decided to try to rewrite our application launcher Kickoff in QML. There are various reasons for it. First of all I am somewhat familiar with the source base as I have in the past worked at least a little bit with it. The code is nicely separated in core and ui parts and makes strong use of Qt’s Model/View/Controller Framework, which means it’s very easy to add a QML based interface to it.

But most important I think that Kickoff is an applet which would benefit most from a QML port. As Kickoff uses the Model/View/Controller Framework it is QWidget based and embedded into Plasma’s Graphicsscene through a proxy widget. If you are familiar with the differences you can spot where Kickoff just does not fit with the rest of Plasma. E.g. the white background or the blue highlight which just does not look and feel like Plasma. Given that Kickoff is one of the first visual elements new users will see it is rather important to present the UI in a consistent and elegant way.

While it is still a work in progress and more a draft, you can get a feeling of the differences in this screenshot:
Classic Kickoff vs. QML based Kickoff

Thanks to the possibilities of QML all the data presented in the QML based Kickoff is currently just mock-data and not yet connected to the real C++ based Models. This gives the possibility to concentrate on the UI without caring about the required changes in the underlying Models.

My expectation is that after the QML port Kickoff should also perform much better. Removing those proxy widgets is clearly a plus and QML allows us to lazy load the data and view components much easier. E.g. in the mockup I presented all the data is loaded only when needed. That is if you only use the favorite tab there is no need to load e.g. the data for the applications. So overall a worthwhile project for learning QML.

Overall we still have plenty of Plasmoids which need a QML port, so get your hands dirty.

Before I close this part, I’d like to invite you all to Plasma Bug Days, which will be held this Friday and Saturday (December 2nd and 3rd), more info on Aaron’s blog. Come give us a hand if you want the 4.8 release to really rock!

Posted on

Work (not) done

Once again feature freeze came way too early and I had to decide whether I ship a half finished feature or delay it till the next cycle. This time I decided for giving the new screen locker half a year more time to mature.

In fact the feature was finished some weeks ago with a complete transition to KWin. Unfortunately it turned out that there is one possible situation for a race condition which could lead to a desktop being unlocked in the worst case if KWin crashes. Of course it would not be possible to trigger a crash when the screen is locked, but KWin relies and integrates libraries which are out of our own control (e.g. think of drivers).

The architecture I had in mind would let KWin restart and relock the screen immediately after a crash. Nevertheless there is a small timeframe in which the screen is unlocked and any other client grabbing the keyboard would render the screen unlocked. A limitation of the X windowing system. It is unlikely that KWin crashes while the screen is locked. It is even more unlikely that a client would be able to grab the keyboard just during the race. Being able to trigger a crash in KWin and prevent the screen from locking is most unlikely, but still there is the abstract possibility. Security is very important to me and I agree that such an architecture cannot be used. I am thankful to the fellow KDE developers who pointed out the possible race condition which I did not consider in my design.

Given that most of the work on the new lock dialog was already done I thought it would be easy to integrate in a slightly changed architecture. Unfortunately the problems of time constraints as a spare time developer hit me and I did not find time to work on it till this week – in fact I started on Wednesday evening.

I succeeded in getting the new locker to work but it was without any possibility to include the existing animations while screen is locked and I could not include the widgets on screen locker overlay. The first issue I hardly care about as the QML would allow new animations (though none is written yet) but the latter one would mean a clear regression. It is possible to integrate Plasma widgets with the new locker, but it required more changes than feasible on one day of work without a loss of quality. As this is security related code I decided that the feature needs more time to mature and will be made ready to be integrated as soon as the freeze lifts for 4.9 development. In fact I will concentrate on getting it ready for Plasma Active 2.

And just for the records there is another area of work which I decided to not merge into master weeks ago: the initial work on Wayland. Given that hardly any distribution is shipping Wayland libraries we cannot depend on it anyway and so it does not make much sense. Those who want to test have to build the code anyway and a branch is then as good as any other. Also there was not much work going on in the branch lately which is a short reminder to anyone that help is very much appreciated 🙂

Posted on

The Grass has Always been Greener on the other Side of the Fence

Today I read a news post about the KDE 3.5 fork Trinity and it was discussed that you should use it because of the bad performance of KWin:

the one constant is abysmal Kwin performance.

So to me it sounds like the author of said news article things it is a better idea to run the KDE 3.5 fork, because there KWin is without (OpenGL) compositing, instead of just turning off compositing in KDE 4. Well that’s interesting reasoning. (Btw. if you do not run at least 4.7.2 you should not complain about KWin performance).

Now to my actual blog post: I appreciate the idea of the Trinity developers to bring back the KDE 3.5 desktop experience to those users who really want it. This is a great offer. Personally I doubt that the Trinity project is doing the effort in the right approach. Instead of just porting Kicker and KDesktop to Qt4/KDE4 they forked everything and the kitchen sink. I rather doubt that a team which is smaller than the KWin team is able to maintain not only KWin but also every other part of KDE 3.5 and now also Qt 3.

The developers of Trinity offer the users something that their system cannot provide: a future for complete KDE 3.5. I did a lengthy analysis of Trinity for German readers in the freiesMagazin some time ago: Trinity – Desktop ohne Zukunft

Posted on

Window Switcher in QML

Yesterday I merged in the new Window Switcher Layouts implemented in QML. As before there are five available layouts but now it is easy to add further layouts. So I am waiting to see some new layouts. If a well-done layout is sent to me, I can include it in our default shipping till the artwork freeze. So use the chance to get your window switcher into our default offerings!

Thanks to the possibilities provided by QML we have now a layout configuration which shows directly a preview and not just a name as before:

For the old implementation I tried to provide a preview at least for the selected layout and it was never working properly and I removed it again in a later release. Doing the same in QML took just a few hours and I am still a QML beginner.

Posted on

KWin meets QML

Two years ago I started to re-implement the Window Switching capabilities of the KDE Plasma workspaces (also known as Alt+Tab or TabBox). The old implementation was based on a QWidget with custom painting which of course had some drawbacks. The new TabBox evolved into a framework around Qt’s Model-View concept to design your own window switcher.

Before I started to work on that area I did evaluate the existing Window Switching capabilities of the various desktop shells (both free software and proprietary solutions) and I noticed that all of them have drawbacks. None is the solution where I would say: that’s the perfect switcher.

The main issue is that depending on the user’s habits different work flows are required. A switcher optimized for users with few open windows fails for users with many open windows and vice versa. Especially thumbnails become useless for many open windows.

So I realized that we need something flexible enough to give users the possibility to use different layouts or to even define their own layout. This ended in a framework for window switching. The layout is described with an XML file and rendered through custom painting code in a Qt delegate.

When I implemented this framework I wanted to add a GUI to easily configure own layout. Unfortunately I never got around to implement this UI and I think there has never been any other layout except the default shipped once. It is a rather unknown feature and I’m quite unhappy that this great functionality never got implemented.

In the mean time the trolls did a great job to make UI development easier: QML. This makes it possible to do what I wanted to have for window switching: easy to design and exchangeable layouts. So this weekend I implemented the default (informative) layout in QML and plan to completely replace the existing View and Delegate code in 4.8. And this gives us the possibility to let users write their own layouts and to share and exchange them.

But this is only the beginning of usage of QML in KWin. I have many more ideas by making window thumbnails available to QML UIs in a limited way. This will allow us to even integrate the BoxSwitch effect into the normal window switching framework and replace the Window Strip in Plasma Active.

So great UI times ahead in KWin.

Posted on

KWin on Pandaboard

Thanks to Canonical and Linaro I received a Pandaboard some time ago. Finally I succeeded in building KDE on this device (I have never seen crashing compilers before). And I am proud to announce that kwin_gles (master) runs out of the box without any adjustments on this board.

As today is also KDE’s birthday I present the KDE Crew: All my devices running KWin on one photo (the next to be konquered device was involved by doing the photo).
KDE Decice Crew

The screen on the left is connected to the pandaboard between the right screen and the laptop. As you can see it is running Unity-2D with KWin. I tried really hard to show a real Plasma on the Pandaboard, but Unity did not liked to be killed 😉

We see KDE is prepared for the devices coming in the next 15 years. HAPPY BIRTHDAY!

Posted on

Results from poll about future of XScreensavers in KDE Plasma

Today ended the poll on forums.kde.org about the future of X Screen saver support in the KDE Plasma Workspaces. I want to thank everybody who participated in the poll. The poll and the thread clearly help us to see what the users need and want and what we need to provide.

Here are the results:

  • 153 (53.5 %): I don’t use screen savers, it doesn’t affect me
  • 92 (32.2 %): Finally new screen savers, thanks a lot
  • 22 (7.7 %): I would miss them but could live without them
  • 4 (1.4 %): I would complain
  • 2 (0.7 %): I would switch to another Desktop Environment
  • 13 (4.5 %): I don’t care

Of course the poll does not reflect the diversity of our users. We are not able to reach the Pennys out there who do not even know that they use the KDE Plasma Workspaces. But I am personally convinced that the Pennys do not use screen savers as we do not enable or even install screen savers by default and make it non trivial to configure them.

We always try to develop the software so that most users are suited well. The poll result shows that only a minority really wants the old screen savers, but that one third of our community is eager to get new and modern screen savers. But even more important is that more than half of our user base will benefit from the work on the new screen locker directly.

This confirms the plan we have to improve the screen locker for 4.8 and that keeping the screen savers as a fallback is an acceptable solution for 4.8. Given the results I will also look into getting the new screen savers ready for 4.8 and not only for 4.9.

Again thanks to everybody who participated in the poll to make the KDE workspaces better.