Month: November 2011

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:

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!

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 🙂

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