As you probably don’t remember (it was a long time ago), I was inspired by one Qt Creator’s feature - namely the Quick Browser - which I wanted to add to Vim. I haven’t touched it in a while due to lack of time and the promise of Vim emulation in Qt Creator. Since I find the Vim emulation in QtC not mature enough (I’ll leave commenting the final QtC 1.0 for some other time), I decided to continue working on the Vim with Runners project, or VIDE, the Vim IDE.

Vim has many plugins available at www.vim.org/scripts/ but the thing that I find annoying is that most of them are not really meant to work well together. So, for example, the Project plugin and the tag browser plugin open separate panels instead of sharing the same one, thus using too much screen real-estate…

Before I begin, I would just like to note that Vide is still in its infancy and not all things are yet working properly, or at all. To see what does work, keep reading.

The point of Vide is to provide some standard framework for people who want to use it, so that a greater integration can be achieved. It is written in Python (so Vim with +python compile-time option is required) so writing new runners is a breeze.

The runners (the name is taken from the Plasma project) are meant to provide results for the entered query. The difference between plasma’s runners and the ones in VIde is that Vide activates only one runner at a time. Personally, I find that to be a better solution in this case. To choose the runner you want to use, just prefix the query with the runner’s key. For example, to find a file in the source tree that contains ‘vide’ in its name, just enter “f vide” as the query (“f” being the key of the Find runner)

Runners

To open the Vide panel, press Ctrl+A (this can be changed, but I’ll cover that later)

Quick Browser

The Quick Browser is invoked with the ‘qb’ prefix, but since it is the default runner, you can omit the prefix, and enter only the class name you are searching for. For example, if your query is “Butto” (or “qb Butto”), you’ll get all classes named Butto. The Quick Browser uses a CTags file to retrieve the list of matches, so you need to keep the ctags file updated.

Currently, the only way to recreate the tags file is to call :QuickBrowserReloadTags but that will change soon. Vide is going to provide a quick automatic regeneration of the tags file thanks to the iNotify (optional - set via the vide project configuration file).

Apart from CTags, QB runner supports PTags (for python). Note that you need to have the ptags.py in your path for this to work.

Find and Grep

The other two existing runners are Find and Grep, whose keywords are “f” and “g” respectively.

Project organization

In order for Vide to be loaded, firstly you’ll need to add it to vim’s plugins, or do a manual :source /path/to/vide.vim. You can freely do the former one since Vide will not bother you if you’re not working on a vide-enabled project.

To make a vide-enabled project, you’ll need to create a .videproject directory in the project’s root. There is no UI for this at the moment, so it needs to be done manually. You have an example .videproject directory in the SVN (Vide contains its own .videproject - it can be used for other projects aswell).

When you start Vim (and load vide.vim script) it will check for the .videproject directory in the current working directory, and if it doesn’t exist, it will not be loaded, and you’ll get your regular Vim.

If the .videproject is found, with all necessary sub-items, Vide will be loaded. The another thing that is important to mention is that you can place Vim plugins/scripts inside the .videproject/plugin subdirectory - if you need those plugins only for that project.

Well, that is all for now, the project is located at http://sourceforge.net/projects/vide/, so you can grab the sources from the SVN there. Just note that it is not finished - this is just a pre-alpha-tech-preview-release :)

If you have any questions, feel free to ask.

I just wanted to brag about my new blog theme. It was heavily inspired by the new DOT design (made by Philip Tyrer and Nuno Pinheiro), but is done in a bit /different mood/

The second thing is that Identi.ca is now my primary microblogging service which you can see in the box on the right. Twitter will be updated simultaneously because I’ve set Identi.ca to pass the posts to it, so there’s no need for you to follow me on both places (if you’re not already).

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.