GSoC wrapup – Konqueror new bookmarks system

So GSoC ended already, as most of you already know. I haven’t been blogging as much as I would like, and I didn’t achieve to finish on time everything I wanted, but that’s not a defeat, only a delay – I will continue working on this bookmarks system until it can get merged into trunk. And then I’ll fix incomintheg related bug reports =).

So the state of the art is: we’ve got an akonadi resource for konqueror bookmarks which stores the bookmarks in nepomuk. We’ve got a bookmarks organizer, and we’ve got a bookmarks menu integrated in konqueror. The new location bar is however not finished yet, but that will be fixed within days.

A lot has changed since last report. I’ll try to explain here what’s the base structure of the new classes and what I’ve been doing, mainly related to the location bar, and why I followed that design decisions.


The current konqueror location bar uses a KCompletion class for autocompletion, which is mainly handled by KLineEdit. But how does it work? Let’s use a simple example. Imagine you are developing kmail’s new email dialog. For the line in which the user enters the destination email address, you could use a KLineEdit, but in order to easy the task of the user, you could use autocompletion like this:

KLineEdit* destinationLineEdit = new KLineEdit(this);
KCompletion completion;

You could of course get the list of items to add to the completion object from the address list too ;-). If you were developing instead the location bar for dolphin, you would like to have directories listed while the user is typing. Instead of adding and removing items manually yourself to the completion each time the user types, you can use a KUrlCompletion object that does that automatically.

But for konqueror location bar we have a problem: it needs to be able to use kurlcompletion for completing directories, but it also needs to complete from bookmarks and history. We need to work with multiple completion objects at once even though KLineEdit and similar classes can work only with one. Also, we need to do more complex completion A normal KCompletion object contains a list of strings and matches what you type with those, but for having an amazing location bar we need more power: if I type “work” and I have a bookmark tagged “work”, I want it to show up in the completion list even if its URL doesn’t contain the word “work” at all. And that’s only the beginning. I want to be able to set an order of the completed items depending on the relevance and type of the items, and more..

Enter Qt Model-views

I need to confess that I love Qt model-views classes. QAbstractItemModel, QAbstractItemView, QAbstractProxyModel, QSortFilterProxyModel, QTreeView.. They provide an standard convinient and flexible way to manage and display almost any kind of collections. Even collections of completed items. Actually, the completed items popup is in reality a QListWidget, which displays a model associated with the completion object..

But that is an internal model which KLineEdit doesn’t let me change. So the question that follows is.. why not use directly my own custom item models instead of a KCompletion object? And that’s what I did, even if it required a lot of work to be done.

First of all, I tried to outline in paper the master plan. What classes needed to be created for everything to work fine. Then I wrote step by step what needed to be done before what. Then I started following those steps one by one and it worked!

Places all over the.. place

The plan was that the location bar autocompletes places. A place could be:

  • a history entry from history entries model
  • a bookmark from bookmarks model
  • an url from a kurlcompletion model

I had already a bookmarks model and konqueror already has an history entries model, but I had no kurlcompletion model. I looked at the code of the KUrlCompletion class I decided that I didn’t want to rewrite it.. so I simply created a KCompletionModel which acts as a proxy and converts a KCompletion object in a QAbstractItemModel. So to create a url completion model, I do:

KUrlCompletion* urlCompletion = new KUrlCompletion();
KCompletionModel* urlCompletionModel = new KCompletionModel();

To do a completion, I connect the urlCompletion to the textChanged(QString) signal from the lineedit. And the completion objects reflects the changes which in turn instantly appear in the model. It’s not the best solution but hey it works.

Also, another problem was that the completion object of KLineEdit would be replaced by a model, not three. But now as you see I have again multiple completion objects, so what was the solution? creating an aggregated model created out of multiple models. It works like this:

KAggregatedModel* aggregatedModel = new KAggregatedModel(this);

Now, those who know how an item model works will probably have a lot of questions about that. For example one could be.. Do all those models need to share the same columns? The answer is no. The aggregated model I created is quite simplistic in the way it works:

  • It assumes the source models have only one level of childrens.
  • It only shows one column, which is the default display column (
  • It shows the list of items as a list, showing first the items from the first item model, then the ones from the second, etc.

Places Manager

So far we have an aggregated model with completed urls, unfiltered bookmarks and unfiltered history entries. That’s yet not complete from being the amazing completer model. What we need to do is the amazing filtering and sorting. That’s done by the final completion model, the master of places..

It’s called PlacesProxyModel and inherits QSortFilterProxyModel. It takes a QAbstractIteModel and takes the Konqueror::PlaceUrlRole for each index, gets the URL, and obtains the corresponding Konqueror::Place for it. Then, knowing already all the available information for that place, tries to match it against the query the user entered in the lineedit and sets its relevance for sorting purposes. It also filters out duplicated entries. Quite an achievement, but how does all that work again?

First off, all previous models (url completion, bookmarks and history entries models) report their items to a Places Manager which keeps track of them and contains a Place for each relevant url. So for example, if the user has bookmark for and it’s been visited yesterday, there’s a place in the places manager with the information from both the bookmark and the history entry.

All those models also support obtaining the url related to each item by using the Konqueror::PlaceUrlRole. The aggregated model proxies calls to retrieve data from any role, including that. So in the end the information can be retrieved by the places proxy model. Then an algorithm that takes into account the number of visits, the last visit, if the user-written string matched the place’s url, title or tags, etc sets the relevance of the items in the proxy model.

The road to the location bar

The new location bar inherits from the modified KLineEdit which uses a QAbstractItemModel for completion, which I have named KLineEditView. An amazing location bar needs to be able to show an star that can be clicked to add/remove a bookmark, and the autocompletion needs to show for each place shown if it’s bookmarked, its tags, etc. Contextual information.

State of the art

What has been done? All the previous things I have mentioned are working. They can always improve, but the code is already there. The location bar widget is the last thing I started to write so it’s not finished: it has already plugins support so that new icons/sub-widgets can be shown inside the location bar. Now I need to write the plugin to let the user bookmark the current location, and I also need to write the CompletionPlaceDelegate to have a properly eye-candied completion list. And I’ll do it shortly.

Future and end

Unfortunately, a lot of things need to be done before this new bookmarks system ends up in konqueror trunk. Revamping such an integral part of Konqi is not a simple task. We also want to be sure that when the replacements comes into play the user doesn’t have to suffer it but to enjoy it instead, so I need to find fix and all the regressions. I need to write documentation and test cases too. I honestly don’t really know when the job will be done but I know I’ll continue working on it.

I want to thank specially my mentor David Faure for the support, for giving me a thumbs up even if I didn’t finish on time everything I wrote in my gsoc propossal. You rock david!

This is post has been too large I admit, so I think I’ll stop here :D. If you read everything yay you’ve got too much free time so go and do something more useful!

21 Responses to “GSoC wrapup – Konqueror new bookmarks system”

  1. 1 Zayed agosto 27, 2009 de 4:16 pm

    Great to hear that you enjoyed your GSoC !

  2. 2 Daniel agosto 27, 2009 de 5:43 pm


    just one idea from a non-developer: wouldn’t it be possible to also integrate the konqui-webshortcuts into this system?


  3. 3 Stephen Kelly agosto 27, 2009 de 5:53 pm

    This is great. I really like the idea of KAggregatedModel.

    Good to see AmazingCompletion getting a mention too. 🙂 I intend to return to working on that soon.

    Congratulations and well done on finishing your GSOC.

  4. 4 Haisen agosto 27, 2009 de 6:13 pm

    Konqueror must be killed.

  5. 5 fyanardi agosto 27, 2009 de 6:56 pm

    Seems very cool! It will be merged before KDE 4.4 right?

    And congratulations for passing GSoC 2009 🙂

    (Once I also read the KLineEdit + KCompletion source codes, I was wondering whether those codes should be refactored to be based on QCompleter (it was introduces in Qt 4.2) to reduce duplication. And QCompleter also can take in an item model, so it is Model-View ready. But well I just simply don’t have time to do it.)

  6. 6 Fri13 agosto 27, 2009 de 7:36 pm

    Wow, the bookmark system really comes handy with Konqueror.

    Is there any new screencast/screenshots from it?

  7. 7 Sepp agosto 27, 2009 de 7:56 pm

    Will this be in for KDE 4.4?

    I currently suffer from this bug, which no one is interested to fix:

    So, I don’t care wether your project is complete or not, I would just love to organize my bookmarks.
    Maybe I’ll even give Konqueror another try if bookmarks are usable again.

  8. 8 Stefan Majewsky agosto 27, 2009 de 8:57 pm

    @Haisen: Please write back when you have understood the open-source principle. (Tip: Who does the work decides.)

    @Eduardo: Does this mean that Nepomuk will finally become a required dependency of kdebase? (AFAIK it is optional up to now, and can be disabled.)

  9. 9 edulix agosto 27, 2009 de 9:30 pm


    Nope, if Nepomuk is disabled then the old bookmarks system will be compiled for konqueror.


    I would love that this could enter in KDE 4.4 but I’m not sure, we’ll see!


    I’m not sure how this could be integrated with web shortcuts could you give me some ideas? Start the brainstorming 😀

  10. 10 FiNeX agosto 28, 2009 de 1:21 am

    Good, so finally all the keditbookmarks bugs could be closed in favour of the new system 🙂

    🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂

  11. 11 Sebastian Trüg agosto 28, 2009 de 2:45 pm

    oh no, you created an aggregated model? I should have pushed the K3b one into kdelibs earlier… maybe we can merge the two?

  12. 12 Tony Murray agosto 28, 2009 de 6:40 pm

    Hey, this is great stuff. I was looking at this and basically drooling at using some of the things you written in the app I’ve been working on KRDC.

    @strueg: See above 😉

  13. 13 James Smith agosto 29, 2009 de 3:26 am

    Can I add as suggestion that you add a miscellaneous x-(.desktop)-like field by default and as a first option include for bookmarks in Places ‘Tag’ as autocomplete? Can we place a tag, and /or make some interesting use out of Nepomuk / Akonadi for say, Alexia-like Nielson / T.V. Guide ratings bonanza. Otherwise great for shortening and organizing bookmarks; it’s been a while, but, possibly folder / directory name as primary key and (first thing’s last) tag for each bookmark.

    I’m writing up a few reasons why Akonadi needs an orange layer (and /or purple AS orange layer)to handle stuff like kio / fuse access and authentication to web services like Google Bookmarks and IMAP / POP. Also for push and pull Kgetnewstuff and package management (but why?) and scheduled attribute updates like latest and greatest tags from Opendesktop with username in Plasma. Scheduled bookmark sync etc. as well.

    “a direct route for filesystem access via kioslaves allowing tagging from remote servers to propagate easily and less intensively with metadata easier to accumulate from remote fuse-akonadi bridges.” Patently deviant.

    ‘transmission storage layer’

    Guidance hooks for partial disabling of Akonadi when in low-power mode (for url / website streaming and parsing, bayesian tag matching and sharing) /var connector via SAP kernel for kde cache / socket files / url cache / konq history prior to Strigi index (konqueror pagecache index) commit on next battery charge.

  14. 14 James Smith agosto 29, 2009 de 4:08 am

    Ability to tag say, Decibel conversations in the bookmark system and maybe the ability to directly tag and bookmark, say, KRCD and Konsole with tags. DB designed with appname field allows some nifty things cleanly. Bayesian heuristics would be great then to add for tag parsing from directory entries and indexing for posting to opendesktop and reviewing in Zeitgeist / Dolphin.

  15. 15 James Smith agosto 29, 2009 de 4:08 am

    Bayesian filter for KIO http:// that scans history for tagability.

  16. 16 juli noviembre 25, 2009 de 1:43 pm

    es urgente que se ponga en contacto conmigo.


  17. 17 Jos Poortvliet diciembre 27, 2009 de 4:35 pm

    edulix, could you send me an email? I’d like to know what of these features made it in 4.4 for the feature guide… mail is my first name + last name on the server. Thanks in advance!

  18. 18 interested person noviembre 7, 2010 de 2:26 am

    now it is more than one year over. Is this project dead, or are still working on it???

  19. 19 adsum01nl noviembre 28, 2010 de 12:10 am

    Hi it would be great to get an update on this project good or bad as it relates to bookmarks for Konqueror in upcoming KDE releases. You are on to a much needed feature to keep Konqueror alive. Keep up the good work and all the best!

  20. 21 ICDL-Access Exam Questions junio 1, 2013 de 5:37 am

    An impressive share! I have just forwarded this onto a co-worker who was
    doing a little research on this. And he actually ordered me lunch because I stumbled upon it for him.
    .. lol. So let me reword this…. Thanks for the meal!
    ! But yeah, thanks for spending the time to talk about this subject here on your
    web page. ICDL-Access Exam Questions


Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de

Estás comentando usando tu cuenta de Cerrar sesión /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s

A %d blogueros les gusta esto: