I have seen the proposals to replace the default Kickoff menu with Lancelot on a quite a few places now (the latest, which triggered me to write my stance on the subject, was a proposal on the (K)ubuntu brainstorm site).

In a nutshell, I’m against the idea. I was since the start (see for yourself in earlier blog posts and comments on commit-digest), and I don’t see I’ll change my mind in the foreseeable future.

There are a couple of reasons for this, some of them technical, and some personal.

The main personal reason is the fact that if Lancelot became the default menu, I would have to give up the absolute control that I have over it at the moment. It would have to fit the rest of the desktop in ways I don’t want it to (for example, the current resize-by-dragging-any-border-or-corner would have to be changed to resize-by-dragging-the-one-corner like the Plasma applets and the present Kickoff menu).

The second is that the development would be significantly slowed down because everything would have to pass a discussion whether it should be changed, and then whether the change is correctly implemented…

And the last, but not the least, I don’t consider L to be mature enough, and I don’t think it will be until KDE 4.3 (or maybe even later).

So, the point is that I’m very glad most of you like Lancelot, I’m more than glad that many of you are using it, but making it a default has absolutely no benefits at the moment. I would rather have it used by a smaller percentage of users whose choice was to use it, than to have it imposed onto the whole KDE user base.

The most annoying (and at the same time thrilling) thing in developing Lancelot compared to developing normal Plasma applets/applications is the fact that everything has to be done from ground up. I have to reimplement every widget, and not use a QWidget through QGraphicsProxyWidget because the widgets I need either do not exist (Extender buttons), or don’t fit the no-click idea. The notable exception is that I do use Plasma::LineEdit.

In 1.0, you had the evil scroll buttons which were used to scroll the lists. Those things had a more than few usability issues which I’m not going to list here now (see the past posts, comments, and bugs at bko).

That is changing now. There is a lot underground work going on at the moment in Lancelot since the old list widgets are being split into a more than a few separated classes, or to be more exact, a completely new set of classes were developed that will mimic the behaviour of the old one. The new implementation is even API compatible with the old one at the moment, altohugh API will need some cleaning later on.

Why am I reimplementing something if I just want to mimic the old behaviour? The main reason was that the old ActionListView was hard to maintain, and it was even harder to add new features to it. There is no chance that keyboard support (for example) could be added to the old implementation.

Tech

Now, the Lancelot framework has something new to brag about.

First, there was a ScrollBar. And the ScrollBar worked well.

Then, there was ScrollPane that could hold in its arms classes of Scrollable type. It showed 0, 1 or 2 scrollbars depending on the size of the Scrollable. And it worked quite well with some glitches.

After that, CustomList came to this world. CustomList was made to be able to show CustomListItems produced by the CustomListItemFactory, one item below another. It could also squeeze or expand the items to fit them inside, behaving like its old brother, the old ActionListView.

Then, the CustomList implemented the rules in the book of Scrollable, and showed itself as a CustomListView.

This was only the beginning. Somebody had to use the power of CustomList to display the data models of Lancelot. And then came the ActionListView2.

So, as you can see instead of having just one class, which would be too obvious and simplistic, we now have a dozen (not all classes are mentioned here :) ).

Conclusion

As of the last commit, the ActionListView2 is used by default in Lancelot. (you can still re-enable the old one if you use Lancelot’s trunk on daily basis by commenting out the ‘#define LANCELOT_ACTION_LIST_VIEW2_OVERRIDE’ line in the libs/lancelot/widgets/ActionListView.h)

There really are a lot of bugs in the new implementation, but those will be straightened up soon. So, don’t file bugs that are related to the new lists, since they are known.

Cheers

[caption id=“” align=“alignright” width=“450” caption=“Richard Wright”][/caption]Richard Wright, the self-taught keyboardist and founding member of Pink Floyd is no more :(

There is so much that could be said, but then, he was a musician, so here is … the music:

Here are the links to see the famous (possibly intentional) synchronicity of the Echoes to 2001: A Space Odyssey.

Part 1 : http://www.youtube.com/watch?v=cWOfVG4e8ek Part 2 : http://www.youtube.com/watch?v=dDhgkg2V3Jk Part 3 : http://www.youtube.com/watch?v=KJP7iqRZeXU

p.s. Sorry for the youtube links but… you know… where else would I find this…

Well, we are going to reach the final step in the evolution of Lancelot for KDE 4.1 very soon. Will it be called 1.1 or something else, it really doesn’t matter. What matters is the fact that Lancelot is more stable than ever, and even has a new feature.

Changelog since 1.0

• Feature update: “Reset the [application] browser to show Favourites on menu open” option, which is the default behaviour from now on.
• Installation fixed. Thanks to the bug or whatever in the new cmake 2.6, there were problems installing Lancelot - no binaries were installed in most cases. It even got a /quick fix/ in the FAQ section of the L’s website. Now, that is a thing of the past thanks to the Than Ngo who sent me a patch that mysteriously and miraculously fixes this problem.
• Crashes… no more. The 1.0 was stable enough in my opinion, so most of you haven’t had any problems with it. But then, there are those of you who were less fortunate. And those of you who had the 1.0.1 installed which had a really nasty bug. All reported crashes are now fixed. That doesn’t mean that it is impossible to crash Lancelot (for example it crashed to me today - some misunderstanding with KRunner and it’s code) but it means that it is harder to crash it than before :)

Media coverage

I am glad to see much more positive reviews on the internet than the negative ones (the negative ones being mostly forum posts). The coverage culminated by Lancelot’s feature at linux.com. The blogosphere was also kind to Lancelot, so I’ve encountered reviews on Spanish, Russian, French, Polish…

So, once again, thanks to you all for helping and supporting the journey Lancelot development was, and for making it such a pleasure. Now, we are going to go to the new heights :)

p.s. The cool thing is that when you search “Lancelot” on Google (just Lancelot, without mentioning KDE), you get this Lancelot two times in the first 10 results - one has the 3rd place, and the other has the 6th.

Hi all, long time no see.

I have been receiving the same questions over and over again, some of them even through the bugs.kde.org so I’ve decided to answer them for the last time here.

Why doesn’t Lancelot follow Plasma theme?

Yes it does. But your theme doesn’t provide the necessary files needed by Lancelot. At the moment the only theme that does provide the needed files (because those are shipped with Lancelot) is the default Oxygen theme. Standard Plasma themes are not sufficient simply because Lancelot has much more graphic elements than other Plasma applets. (and no, using the task manager’s buttons and dialogue background for Lancelot’s buttons and background is no option - it is even uglier than having a default themed Lancelot).

Scroll buttons should disappear when… should not cover the items… should… or should…

Scroll buttons should not do anything. Anything except be thrown out of Lancelot, that is. The scroll buttons and the old ActionListView (the widget that shows the lists in Lancelot) are being obsoleted and will not see the light in Lancelot again.

In a nutshell, the scroll buttons will be replaced by scrollbars as you can see in the screenshot (yes, it is a screenshot, not a mockup, thus the rendering glitches).

I want to be able to use Lancelot only by keyboard…

I do too! I really do. The thing with the old ActionListView is that it was not easy to add the keyboard support to it. Now, the new ActionListView (named ActionListView2 at the moment) is being developed on top of newly developed Lancelot widgets (ScrollPane, CustomList, CustomListView…) and will eventually provide all the fancy stuff you requested.

You can test the ActionListView2 right now, by just uncommenting one line in the ActionListView.h file (it is obvious which one). But mind that it will render Lancelot unusable since it is far from finished. But it does scroll using scroll bars. :)

These answers (not this detailed, though) are also added to the FAQ section of Lancelot’s website so they will never be answered by me again.