This post is a response to a comment by bleh2 to my last post

In all pre-Vista Windows and KDE1-3 the menu expanded when it needed more space. Short distances for the most common tasks, lots of space if needed. Why did suddenly everyone decide that it’s better to either make your most common apps unreachable or to cram 1234 menu entries into a postage stamp sized menu while wasting 95% of your screen real estate? Lancelot’s got by far the best navigation of these menus but I don’t understand the basic rationale of having it fixed size. Have it start like it is now, but when you click a sub-menu it just expands horizontally and vertically until everything fits or until it runs out of desktop.

The /expanding/ menus versus the fixed size ones is a war that will not be ended soon I think :)

One of the things that Kickoff uses in its defence concerning its way of application browsing is that if the user has to browse the applications often, then we are doing something wrong.

I agree with that statement. (What I do not agree is the conclusion drawn from it - that the browsing can be sidetracked)

I tried to make L in a way that you really don’t need the application browser (Favourite applications, places and device management, PIM aka Contacts section, and Office applications, and KRunner enabled search) almost at all, but when you do, that you have mostly unimpaired experience.

Now to the actual expanding menus vs fixed size ones. Both have advantages and disadvantages.

1. Expanding > Fixed

1.1. broader view of items

This is the only advantage of expanding menus that I can think of. But even when you get the lengthy list, can you tell the instant it opens where is the application you’re searching for is located? Most (> 90%) humans can’t. You’d go from a fixed point and then scan up or down until you reach the desired application. So, the only disadvantage of fixed-size menus it that while scanning the list you need to scroll it.

Most people can process around 5-7 items at once, and that is the number of items that L shows by default in scrollable lists. While, if the list has only 9 or less items, it shows all of them at once (the many times covered squeezing feature of L’s list views)

2. Expanding < Fixed

2.1. Accidental closing

You browse through the list and open a couple of submenus, then you accidentally hover one of the formerly opened menus, and every menu you opened after that one closes.

2.2. Predictability

When you reach the right end of the screen, the menus all of a sudden start going in the opposite direction, thus breaking the flow, and increasing the chance of 2.1.

I’m bored :)

There really is no point in making the above list. If you keep your applications organized, which is out of the scope of any particular menu, most disadvantages of any approach mostly fade away. Well, it is too large post to delete it now, and replace it only with the last sentence. :)


You can support my work on , or you can get my book Functional Programming in C++ at if you're into that sort of thing.