There are a couple more feature requests marked as FINISHED in Lancelot’s TODO file.

1. Wasted space

In previous versions of Lancelot, when using the no-click activation, there was some space between the lists while browsing the applications. The space was needed because of extenders and scroll-bars. Scroll-bars, obviously, still need the space like before, but the extenders don’t.

The initial proposal was to make the extender inside the list item itself, so it would be an /intender/, and not extender. :) This wasn’t that great idea since that would induce a lot of accidental activations - you hover the end of an item, the /intender/ pops right below the cursor, and since it is hovered, it activates.

The alternative was to allow the extenders to go outside the list, and that is exactly what is going on now. The extenders now can overlap the space of the neighbouring list. So, in a nutshell, the extenders from one list, and the scroll-bar of another are sharing the same space.

2. More than breadcrumbs

The second requested feature that was implemented today was to show the trail in the application browser, not only in the breadcrumb bar, but also in the lists. This worked before when using keyboard for navigation through the application browser (aka PassagewayView), but not when using the mouse. It now works for mouse too.

3. Why do I search for empty strings?

This one is the smallest change for today - instead of showing you the message ‘Search query is empty’, Lancelot returns to the Applications section.

UPDATE: I was too lazy to create another post… and not enough news for one.

4. I want to hide my tracks!

It is now possible to right-click and item in Recent Documents, and remove it, as well as to clear the whole document history.

5. Race the Dolphin through the hoops

There were a few requests to make Lancelot use Dolphin’s places. I thought it will be tricky to do that since L separates devices from places, but fortunately it was not the case. Dolphin stores the places information in a XBEL formated file (bookmarks format) and provides a nice distinction between the devices and places. Note that the places are not automatically reloaded. I could do that easily, but IMHO reserving an iNotify slot for just that would be a waste.

This also means that there is now a XBEL-based model for Lancelot. It doesn’t support bookmark folders, but it will eventually.

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. :)

New system buttons

One of the first requested features, even before the Lancelot brainstorm thread on KDE forums was to change the system buttons from Lock Session, Log Out and Switch User to something else because some users don’t use some of the buttons. Radically changing the Lancelot behaviour this late in its age of existence is something that can not be considered. But the users should have some freedom.

The point is that the buttons are now configurable. Open the configuration dialogue, and you’ll see a new section. Click any of the three buttons you see, and you’ll get a list of possible actions to assign to it.

Theme improvements

While developing the Spoons Lite theme, I realized that it is hard to make a transparent theme for L because the text becomes almost unreadable.

It was the same with Plasma panel befire, so the Plasma guys and gels made the text on the panel to have a shadow which improves readability. Now, all Lancelot widgets support this as well. It is off by default, unless the theme authors want to turn it on. The cool thing is that the theme authors can be selective and add shadows only on desired elements.

For example, in Spoons Lite (shown in the screenshot above) the shadow (or in this case a white glow since the text is black) appears only on system and section buttons, and not in the main part of the menu.

That’s all for now. There is another theme improvement, but we’ll talk about that later.

Hi all!

First I would like to point out that there are two new Plasma themes on kde-look. Well, at least two my new themes. Or to be even more precise, there is one new theme and one old that is new. Or new that is old. Or one theme… OK, I’ll stop now.

One of the themes is Spoons, which is now named Spoons Original, and is currently the oldest Plasma theme in existence (that’s why I couldn’t really say that there is a new theme on kde-look).

http://www.kde-look.org/content/show.php/Spoons+Original?content=77690

http://www.kde-look.org/content/show.php/Spoons+Lite?content=99442

The other one is a sibling, possibly the younger sister of the aforementioned. The reason I have never used Spoons as my theme (as my Plasma theme, that is - it serves perfectly as the theme for my blog) is that it is too bold and eye-poking. So, the slimmer one was born. This is the first theme that I think could replace Slim Glow on my computer.

The main difference between Slim Glow and Spoons Lite is that the former helps the widgets on the desktop to be placed on the sidelines - not to draw attention, while the later helps them to be in focus, but still not to be too invasive.

Qt 4.5 and Lancelot

There have been issues when running Lancelot on systems with Qt 4.5 (or 4.4.4 snapshots) installed. Mainly, the Applications section was empty. Or, rather not empty, just appeared as it is - you could use the keyboard to /blindly/ browse the applications. It is now a thing of the past (at least when 4.5 is concerned - haven’t tested 4.4.4). It is now fixed in trunk and it works for all testers at bugs.kde.org.

The interesting thing is that L behaved differently when compiled against 4.4 and ran under 4.5 than when compiled under 4.5.

Qt bug

Fortunately enough, while fixing this, I’ve found a hack that I made a long time ago to bypass a Qt bug that I forgot to report when I initially encountered it (before KDE 4.1 was released). So, I’ve sent the report to the Trolls and I hope it will not go in the ‘we intended it this way’ pile.

Lancelot news

Apart from fixing bugs related to the Qt 4.5, there are some new cool things in Lancelot and its theming mechanism. I will leave it for some other time since this post is already a long one. And I need to make screenshots first.

So, stay tuned.

p.s. And merry new Lenny

I haven’t been looking at the PowerDevil+Plasma related news with enthusiasm before (or, tbh, I haven’t looked at ’em at all). And now that I need it, the battery applet and all that, I’m just astonished how well it performs. And how many options it has. Kudos for all involved!

then there is kde bluetooth stack. Again awesome, cell-to-laptop-to-main-computer…

KWin is fast, plasma also, everything is just… awesome!

BTW, this is the first time I don’t use self-compiled KDE4 packages, and it’s not bad at all. Debian’s KDE team made very good packages of 4.2, and even though 4.2 is in experimental repo (I’m using Sid on this eee), it behaves better than kubuntu installations on my familie’s computers.

So three times “hurray” to all mentioned above!