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.

62 Replies to “Experience from Porting Kickoff to QML”

    1. Yeah, I probably have to decrease the font size – have to check the existing UI code how it was done. But still, with translations it’s always possible that it won’t fit.

        1. Yep. We do need them. It takes time to user to learn what icon does what. And later it could be a configuration to allow user to turn labels off.

          1. Personally I think it’s better with labels for clarity. Can’t you make the tabs fit the text instead of vice versa? (Without diving into the code, this seems to be what the current Kickoff does.)

            On an unrelated note, I wonder if you saw my previous comment[1] about the back button, and if you would be willing to add it back or let someone else do it. I think it’s important from a usability point of view and may give it a try if I can find some time.


            http://blog.martin-graesslin.com/blog/2011/11/weekend-project-porting-kickoff-to-qml/comment-page-1/#comment-45223

            1. Personally I think it’s better with labels for clarity. Can’t you make the tabs fit the text instead of vice versa? (Without diving into the code, this seems to be what the current Kickoff does.)

              I just did the dive into the code and it seems to set a minimum size hint.

              and if you would be willing to add it back or let someone else do it. I think it’s important from a usability point of view and may give it a try if I can find some time.

              Let’s try the new breadcrumbs first 🙂 I think they are way better now. We have nowhere else such a button as it used to be in Kickoff. So I’m very unsure whether it is a good idea to add a UI element to our default launcher not used anywhere else.

              1. The breadcrumbs do look much neater now. They also seem easier to hit, which is a big plus. I still like the back button though, since it was incredibly easy to click on the left edge. I think such an element would be useful in other widgets, such as QuickAccess[1] (which isn’t official, but still… I remember another widget with a back button, but can’t remember which one now).

                Keep up the great work, and thanks for keeping us informed!

                1. The old “back” button on left edge was good, but only when the kickoff was at bottom left corner of screen.
                  Otherwise it became harder to click as horizontal movement is harder to do with mouse than vertical movement. Thats why KickOff has big buttons in horizontal size but smaller on vertical size.

                  The back button was terribly broken because that as KickOff could not be moved to any other location.

                  Now this new breadcrumb looks much better. I still would suggest to add a button effect for them so they would be clear they are pushable.

                  1. I just don’t see it doing any harm – the back button takes up some space and adds a bit visual clutter, yes, but I think the benefits greatly outweigh that. Kickoff is placed to the far left in most (all?) default setups (right for RTL languages). The hit area of the button is about the same as for scrollbars, which I assume most computer user can use.

                    Why can’t we have both?


                    @Martin: Either your blog indents comments too much, or I need a new monitor with higher resolution. 😀

                    1. Even that it is default now, it has been because the KickOff back button has demanded it.

                      The scrollbar size and back button size does not matter. As people learn to use mouse wheel to scroll, without need to aim a small target.

                      The only reason why back button works, is when it is on left side of the screen, the user can go back just by swinging mouse to left without aiming and clicking to get back.

                      But we need to have possibility to locate the KickOff to other locations or even have panels resized and moved. Currently those features are more or less non-working because KickOff back button gets broken if done so.

                      Breadcrumb is much better. Even that I would cladly take a always top located single big “Back” button whats size is like any other menu object.
                      And when scrolling, you would only need to move mouse up to get back. It would take one location space but it is already taken by breadcrumb so it would not change (much).

                      I really loved the backbutton. It was really easy to go back. But when me and others wanted to really locate KickOff other part of panel or even to resize panels, it came clear that it is impossible because the KickOff.

                      There were even a one version of KickOff what added a few pixel frame around KickOff and it rendered the “swing and click” feature unusable.
                      It made whole nice thing impossible to use without clicking frame and closing so on the whole KickOff.

                    2. @Fri13:

                      “Even that it is default now, it has been because the KickOff back button has demanded it.”

                      I don’t think that’s the main reason. “Start menus” are usually placed to the far left because it makes them easy to hit and users usually expect it to be there. The back button in Kickoff was designed with this in mind, not the other way around.

                      “The scrollbar size and back button size does not matter. As people learn to use mouse wheel to scroll, without need to aim a small target.”

                      A lot of people never learn that, and I think scrollbars are designed to work for those users as well.

                      I still can’t find any arguments why we can’t have both a back button and breadcrumbs. The back button works very well in the majority of setups, and even if Kickoff isn’t located to the far left, I don’t agree that the back button breaks it (as said, it’s as easy, if not easier, to hit as scrollbars). If you don’t like that, you also have breadcrumbs. The best of two world with very little drawbacks.

      1. Good work on doing the brunt work in the port.

        My advice when dealing with UIs, always expand the area to fit the text, don’t reduce the text size to fit the space – and for the translation reason you just said never fix sizes based on the text you do have.

        Weirdly it’s something no-one would dream about doing with a QLabel but often (hopefully not you) end up doing in QML.

        Keep it up.

  1. A lot of process has been made and I hope the bottom tabs are going to get polished so they look like the current KickOff itself. I mean the tab should be integrated to the view what tab shows. And other tabs being “at lower” (so tab has a shadows on side and bottom/top of it.)

    I would even make the tab area totally being a “lower” so there are no edges on right/left of them, like now on screenshot there is right side, just under a scrollbar a edge. I would take what is on left side (might be cropped image) but as there is no edge but the “lower” tab area just ends there, it looks better.

  2. Some points:
    1. Menu-like application starter would be better (say, WinXP-like). Why limit it to a fixed-size window? Why hide previous hierarchy level when showing current one?
    2. We really need a better default plasma theme. Current one sucked from day 0, and still does. Especially text. Text is almost unreadable (look at task bar in 4.7, you can’t read anything, and that’s default setup).
    3. Please, no animations. Specifically, in current Kickoff, there is an animation when you click on item, which introduces significant delay. Every user action should be instant. Or at least they should be a preference (and off by default).

    1. Menu-like application starter would be better (say, WinXP-like). Why limit it to a fixed-size window? Why hide previous hierarchy level when showing current one?

      I am porting Kickoff and have no interest into changing the way it works. If you want a different user experience, it is no longer Kickoff and has to be a different implementation.

      2. We really need a better default plasma theme. Current one sucked from day 0, and still does. Especially text. Text is almost unreadable (look at task bar in

      Completely irrelevant in the scope of this blog post – sorry. As well it’s personal taste.

      3. Please, no animations. Specifically, in current Kickoff, there is an animation when you click on item, which introduces significant delay. Every user action should be instant. Or at least they should be a preference (and off by default).

      Of course there will be animations and of course I have no interest in adding a config option for that. And (as probably the new maintainer for Kickoff) I would not accept patches to add a config option for it.

      1. As far as I agree on the content of your reply( Theme is cool IMO; Animations are okay; Changing UX is not your job), I strongly disagree on how you said it.

        The tone you used to talk to that guy was really rude. Just because you two have different opinions doesn’t mean you can behave in such way. One should cope with critics in a proper human way.

        I suggest, you work on your social skills, really.

      2. “Completely irrelevant in the scope of this blog post – sorry. As well it’s personal taste.”

        In scope of this post – sure. But this is Planet KDE post, relevant people may read this.

        “And (as probably the new maintainer for Kickoff) I would not accept patches to add a config option for it.”

        No, seriously, why? This is not constructive.

        1. No, seriously, why? This is not constructive.

          As the maintainer I have to consider more than just the option. I have to consider the costs of maintaining it, the costs of having an additional config option in the UI and so on. I have to weight the advantages against the disadvantages of adding that piece of code. Here it is quite clear that the costs are just too high by giving too less advantages. Disabling animations is only useful for very advanced users who are not the targeted user audience of kickoff. For those users Krunner or Lancelot might be better application launchers.

          1. There is/was/don’t know whether it works for Plasma Quick/… a global option to disable animations.

            I completely agree that it shouldn’t be a per-application configuration option.and that you shouldn’t deal with it in Kickoff.

      3. Here’s one more vote for allowing to disable animations, and from a KDE Developer at that.

        Animations should always be optional. They distract or annoy some users (e.g. I have all the animations I can turn off turned off, I really like it more that way!), they consume CPU resources and they’re just useless for productivity purposes.

        1. PPS: FWIW, I personally use the classic menu, which I find much nicer than Kickoff with its ultra-small fixed-size window and the vastly oversized items (with GenericName listed much more prominently than the actual name, even) crammed into it, to the point of having to scroll all the time to find anything. I hope you didn’t break the classic menu with your model rewrites!

          1. +1 for no animations
            +1 for classic menu

            whats the problem with a config option.. @martin.. you sound like customizing kde is not wanted anymore ^^ there already is a “switch tabs on hover” checkbox and a “show applications by name” option.. it would not harm to add a “disable animations” option…

          2. “its ultra-small fixed-size window”

            Well, you can resize it, but yes it won’t change size when you use it.

            “with GenericName listed much more prominently than the actual name, even”

            There’s an option to change that.

            “I hope you didn’t break the classic menu with your model rewrites!”

            Unwarranted and unnecessary comment.

            Regarding animations: I don’t care much myself, but for the general user I think animations can be nice touch if done right. Apple for example is usually good at that.

            I also wouldn’t want an option in every application/widget/whatever to disable animations (a global option would be OK I guess). Animations should be done in such a way that they appear pleasing, while not getting in the user’s way.

            1. > Unwarranted and unnecessary comment.

              The classic menu shares the models with Kickoff, doing major changes to those models definitely does have the potential to break it.

      4. A new default Plasma theme is too much, IMHO. There is code to force text to draw itself with a shadow sometimes, for readability. Why don’t you simply apply that code?

    2. “Why hide previous hierarchy level when showing current one?”

      Because it offers less mouse movements and less distraction and less possibilities to do mistake clicks what causes menu to be closed.

      If you want to spend some time, read the original Novell usability report of KickOff structure why it is better than old menu (Like XP styled).

      “Every user action should be instant. Or at least they should be a preference (and off by default).”

      I don’t agree at all. As some people want that there are no animations or effects at all. They don’t think the situation by the new computer or even this specific (KDE) GUI users.
      Example, seniors and juniors needs the visual effect when something happens. So it is not just something happened because they don’t understand it.

      Effects are very important usability feature. But they can be bad as well if they are too slow or too quick. So the timing is very important to get right.
      Example, for seniors a 2 second effect when window is minimized is much better than no effect at all.
      Same thing is with juniors. But after time when juniors gains experience, they want to make the animation faster, like 500ms. But still seniors want to keep the animation at 2 second as they do have time and they like that they can see what happens.

      Technical oriented people like to turn every effect off, as those are “just eye candy without real purpose”. They might have blazing fast mouse movement and god given accuracy with knowledge no one else has what is happening.
      But those people are minority of computer users.

      After all, KickOff is used less than applications itself. And its animations do not slow down the speed what is needed to move mouse cursor as the animation is done when mouse is on place, when user is starting application again and again and again multiple times a day.

      And my opinion for usability is that everything should be designed for basic user. So every default setting and configuration is for those who do not know how to configure software or how to use computers well, so it is easy for them.
      But then give a lot of configuration options for advanced and experienced users so they can tweak software to fit their needs.

      So good and great default settings, lots of configuration options.
      Those who do not need configs, dont care. Those who need, they can have what they need.

    3. I think The Air theme is a really decent and modern-looking one. I agree as the fonts a sometime hard to distinguish, but even that gets better with time. I think just saying that it sucks is pointless because that is a highly subjective comment as you do not argue or make some suggestions how to make it better.

      As for the animations I think it depends on the animation whether it underline the impression of a slow Programme or if it adds a certain value to the user experience. So your remark is too general.

      I would support the idea of a XP-like traditional menu structure, but I also think this doesn’t belong to this port. I would suggest to be test such a thing in a kickoff fork and then decide wether it improves the stock user experience. Thats possible because its opensource and everybody can change it the way he or she likes it.

  3. So, it will just be a port to QML 🙁 How sad …
    just because it would no longer be Kickoff doesn’t mean we have to annoy and confuse and make-people-tear-up-little-teddy-bears for another 3 years.
    (And don’t tell me there are alternatives to Kickoff despite KRunner: There aren’t. And yes: Lancelot is also no alternative)

    1. What is wrong with KickOff? This QML version already improves the current KickOff with better breadcrumb, better animations and faster use (I just have developer word from it).

      1. it’s really hard to pinpoint whats wrong with kickoff.. i just can say .. the first thing i do after installing a kde distro is configuring the desktop so i don’t have to use kickoff anymore to find my programs..

        i hardly use it (therefore there is not much i can say about it)

        but it’s good to know that martin tunes it a little bit 🙂
        thx

        1. right, I don’t use Kickoff either. It’s completely unusable to me. Even after my work is finished, I won’t use it. And that’s good that way. We are a different user group. We can use KRunner. And that’s the reasons why there won’t be an option to turn the animations off.

            1. SUch a requirement would render Kickoff unmaintained. I don’t have a problem with maintaining something I don*t use. In fact I wrote quite some kwin effects I don’t use.

                1. That makes me wonder whether it makes sense as a default at all. I’m a proud user of the classic menu. (I also don’t agree that KRunner is a solution for all power users, I like my menu!)

                  1. well that’s a general issue: we are experienced users and need other UIs than who we want as users.

              1. And what on all Earth made you guys decide to make Kickoff the default menu in KDE SC4? 😉

                I don’t use it either, I use Lancelot and Krunner. Why not thinking about another defalut menu?

  4. Real nice progression, Martin 🙂

    As for the “tab buttons” .. that seriously looks out of place :p Doesn’t the QML Components set have a tabbar that integrates nicely? http://quickgit.kde.org/index.php?p=kde-runtime.git&a=tree&h=77931f23b87410f8d145c7f09c7174b92dd45ed5&hb=822b06c740862be7c935295a0598dcdf377d6de4&f=plasma/declarativeimports/plasmacomponents/qml

    And if that isn’t working then we certainly have a tabbar in Qt Desktop Components.. http://qt.gitorious.org/qt-components/desktop/trees/master/components

    Just my 5 cents 🙂 Good luck!

    1. guess what I use? The Tabbar in the Plasma Components 😉 But I changed it to have larger icons

  5. Looks nice, but I’m still concerned with consistent ui guidelines,
    anyway, a feature I would love to see on plasma more, is more use of icon view, for example on the favorites tab of kickoff, there would be more space for shorcuts, while still looking good, (like iphone/android app menu).

    1. It is not wise by usability point.

      The current list is designed so it is easy to click wanted target without need to do horizontal mouse movements what is harder and less accurate to do than vertical movement.

      And having different UI order in same menu is terrible way.

      There have been suggestion to take a grid form (3×3 for 9 or 3xY etc) and all the same problems comes with it. The usability suffers.

      If user wants to have a grid, then user can add those to folder view widget and set it as icon to plasma.

      It is harder to read and find anything from such form than a list.

      1. “horizontal mouse movements what is harder and less accurate to do than vertical movement. ”

        Do you have some sources that explain this affirmation ?

        1. You can try out searching the original Novell usability report of KickOff. I couldn’t find it anymore but it was well explained there.

          The mouse movement is harder to do by human hand structure in horizontal direction than vertical because human fingers and wrist has not been evolved to side directions but grabbing and holding stuff. And when human moves mouse sideways, the cursor does not make straight line but a arch from side to side. While when moving up and down, motion is direct.

  6. Hey Martin.
    This one is a great improvement over the first prototype. However, the tabs really look disconnected. If I wasn’t already familiar, I wouldn’t have guessed how they work just by looking at the screenshot.
    “Classic” KickOff does a great job associating tabs with content.
    They should also scale with the label’s width as the classic implementation. Decreasing font size is no option because not all translations are the same width or shorter. Some people may also have bad eyesight and globally increase font size which KickOff-QML should obviously respect.

    What’s also missing is the user/login info. As someone who occasionally works on PCs which are used by several people, clicking KickOff is the easiest way to identify who’s logged in.

    Personally I don’t care much for the ‘branding badge’ to also appear on KickOff-QML but IIRC including that was a conscious decision to allow easy and standardized distribution customization.

    Since that applet is 4.9 material anyway and meant to bring it to current technologies, why not implement “Recently used” with Zeitgeist?

    1. What’s also missing is the user/login info. As someone who occasionally works on PCs which are used by several people, clicking KickOff is the easiest way to identify who’s logged in.

      Have not yet done that one 🙂

      Since that applet is 4.9 material anyway and meant to bring it to current technologies, why not implement “Recently used” with Zeitgeist?

      Because I don’t want to work on logic 🙂 If someone else does it I don’t care.

    2. “However, the tabs really look disconnected. If I wasn’t already familiar, I wouldn’t have guessed how they work just by looking at the screenshot.”

      I don’t like plasma’s tabbar too. It looks weird.
      It is the same kind of visual elements as the tabs of config panels.
      I think we can do better.
      A plasma tabbar could have a property defining the content location (right/left/top/bottom/disjoint) and plasma themes could be improved to display “classic” tabs using this parameter.
      About tabs in config panels it should be consistant with dolphin location panel.

  7. Hi Martin, I know it is not your goal but I would develop some ideas about the future of KDE’s menu:

    It should be related to the current activity.
    It should display different favorites for these activities: video activity, photo activity, developpment activity, gaming activity …
    I also think the KDE’s menu should be the starting point to manage (create/switch between) activities

  8. I see in the source code that there is still C++ being used in Kickoff-QML. I thought that the plan with QML plasmoids was to have the UI part completely in QML and the logic in DataEngines (correct me if I am wrong). Is there a plan to have this setup for Kickoff-QML?

  9. hi
    i would like to ttest kickoff qml but i can’t compile it 😀
    i am on kde 4.7.3 so maybe it’s that the problem ?

    git clone git://anongit.kde.org/kde-workspace

    then i did build

    cd /kde-workspace/plasma/desktop/applets/kickoff/build

    but ten cmake did this

    CMake Error at CMakeLists.txt:26 (qt4_add_dbus_adaptor):
    Unknown CMake command “qt4_add_dbus_adaptor”.

  10. there’s ROSAlab launcher as a really nice replacement of kickoff http://www.youtube.com/watch?v=8-qUtor42Ek

    my KDE 4.8 setup is something really refreshing: ROSAlab launcher, icon-only task manager, oxygen-transparent, Oxygen-Appmenu.. upstream to make people W-O-W! \O/ 🙂
    and on an atom n270 netbook how smooth it feels!

      1. @ martin:
        this is a nice mockup
        kde-look.org/content/show.php/Kickoff+Icon+View+Mockups?content=128619
        having apps and categories icon view browsing à la Apper allows more items to be displayed at once and at a bigger size. better!

      2. @ valueerror
        I use openSUSE 12.1, you’ll find all packages in KDE “unstable” repos (core,updates,extra,playground).
        in kde:ayatana user repo you’ll find kwin-appmenu package, but it doesn’t work to me. I compiled it, sources in http://kde-look.org/content/show.php?content=141254

        I think it will be easy too in arch using yaourt and kde-unstable repo, or even kubuntu: Precise will be a great kde release.

  11. Hi, great to head Kickoff receives a facelift 😀
    any chance to get the Breadcrumbs to look like actual breadcrumbs?
    like: http://blog.mozilla.com/devtools/files/2011/11/Breadcrumbs.png
    In 4.7.3 currently they feel like non existent / disabled: top right corner greyed out…
    I would expect working Breadcrumbs in the top left corner with > or » separators, or looking like buttons. (my text is LTR 🙂 )

    About that back button…: That button was really convenient because it was very close to the mouse position, now that it’s gone i always use the back button of my mouse, twice, until i realize it does not work… any chance to get that fixed?

    The back button could also work like this looks(I don’t have an iPad no idea how that actually works…):
    http://beatweek-com.wpengine.netdna-cdn.com/wp-content/uploads/2010/09/twitter-ipad1.jpg
    Remove that dark area thats left of it.
    then there is the Tweet stream, that would be the area to click to get back, showing the level you were on before but grayed out a little or so.
    The browser represents the level you are on and would work like the list now.
    upon a click a cool but fast animation could transition the current level to the “back left” and add the new one one top =)
    I hope you get the idea

    Thanks for your work on improving KDE!

Comments are closed.