Kate: Fast backtrace navigation

I’ve added a new plugin to kdesdk/kate/plugin: a backtrace browser. It’s meant for developers and probably of no use for users. What does it do? It shows a backtrace delivered by gdb in a listview in a Kate toolview. Clicking on an item opens the selected file and jumps to the correct line number. It works for backtraces generated on your own machine, but it will also work for backtraces from other people, i.e. with /home/dummy/qt-copy/…/qwidget.cpp will still be found on other machines. For that to work, you have to index the directories where the source code is located.
Sometimes there are several files with the same name, e.g.

  • trunk/kdegraphics/okular/generators/dvi/config.h
  • trunk/kdepim/mimelib/mimelib/config.h

To pick the right choice, the plugin picks the last two parts of the url, in this case this would be

  • dvi/config.h
  • mimelib/config.h

and then usually finds the correct one. Indexing trunk/KDE and branches/KDE/4.1 of course will lead to a clash, now way to fix it. Maybe I could present a list of valid files to the user and let the user pick the right one. I don’t think that’s necessary though for now.

How to configure

  1. Enable the plugin: go to Settings > Configure Kate > Application Plugins and enable ‘Kate Backtrace Browser’
  2. A config page appeared, so click on it and add the directories containing the source code
  3. Clicking OK will start indexing. It will take some time (the index of kdesupport + kdelibs + kdepimlibs + kdebase + kdesdk + playground/plasma + plasma-addons + kdevplatform + kdegraphics is about 6MB)

When indexing is finished, open the toolview “Backtrace Browser”. Now you can load a backtrace from the clipboard (e.g. when you clicked “Copy to Clipboard” in Dr. Konqi) or from a file.

Hope it’s useful :)

Do you understand the word HTML?

During the Kate developer meeting we also thought about simplifying KWrite and how to make the decision whether KWrite should be launched in full featured mode or in a stripped version. …well, and we found a really funny idea:

Note, that this would even work, the question would be rather annoying, though :) The solution right now is to always start KWrite in a simple mode. Mostly only actions are hidden in the menus (@distributors: kdelibs/kate/data/katepartsimpleui.rc), but you can also change c++ code at Kate part level, as there are some functions:

  • bool KateDocument::simpleMode() (kate part internal), and
  • bool KTextEditor::Editor::simpleMode() (along with setSimpleMode())

This way config dialogs can be adapted depending on the mode as well. Ah, and if you want the normal mode back, go into the KWrite settings and enable [x] Enable Developer Mode. Then restart KWrite.

PS: Tackat, we came up with this image before our phone call. That’s why it was really funny when you said HTML is something that should not be removed. hehe… :)

Kate Meeting: Day 1 and 2

The Kate Developer Meeting was a productive weekend and once more shows how important the developer sprints are. The summary will be on the dot shortly. Work already started on several topics. As everyone want screenshots, here we go: The new annotation interface available now in KTextEditor can be use to e.g. show svn annotations directly in kate:
basysKom’s coffee maching is simply the best: It can do everything, you just have to press the right key combos:

Kate Developer Sprint 2008 Results

The below notes is what was decided at the development sprint in Darmstadt on April 11-13, 2008

Short term goals

  1. Scripting, part level QtScript
  2. API for indentation scripts
  3. Sessions handling
  4. make text completion work!
  5. VI-Modes (GSoC-project)

Long term goals

  1. Scripting at application level (Kate): Kross
  2. Combination of highlightings & indentations

Table of Contents

  • Scripting
  • Indentation
  • Kate Sessions
  • Extending the highlighting system (Highlighting combination)
  • Collaborative editing
  • Text input modes (vi mode)
  • Minor topics: Search & Replace, text completion
  • Interface Review
  • Simplifying KWrite


  • Use cases
    • indentation
    • helper scripts + assign shortcut
    • useful for vi-mode scripting
  • right now: kjs (barely documented, future uncertain)
  • choices: Kross, QtScript
    • Kross: language independent, depends on available bindings/plugins at runtime
    • QtScript, Kross: simply wrap QObjects (signals/slots, Q_SCRIPTABLE automatically exported)

Kate Part: QtScript

  • flexible integration possible
  • make it fast for specific use cases (e.g. indentation)
  • script header
    • meta information: key/value pairs (type, name, mimetype, wildcard, …)
    • contact i18n people: how to do translation
    • translation possible outside KDE?

Kate App

  • Kross


  • allow multiple indenters for documents with mixed languages (e.g. php and html)
    • document variables: e.g. indent-mode [ ];
    • document variables: allow different settings (indent-width, …)
  • remove option “Default Indenter”, it does not make sense (really?)
  • the script header should state which hl-modes it can indent (instead of mimetype/wildcard in the header)


  • build word completion plugin into kate part by default
  • fix implementation to actually complete stuff
  • simplfy the popupmenu (!), just as in KDE3
  • remove code completion config dialog, this must be implemented in the code completion model, as this is not applicable to any other than the cpp model. Better have something tiny working instead of a broken monster

Kate Sessions (profiles)

  • data stored:
    • application plugin config
    • file list (opened files)
    • window configuration
    • editor component config
    • ktexteditor plugin config (maybe kpluginselector problems)
  • session level configuration / document variables
  • kill default.katesession file, always use katerc
  • do not show the session chooser at startup, instead, make a good default (katerc)
  • clone session: “save as” opens a small dialog with line edit and options like window config, file list
  • remove option “restore view config” -> simply always do it
  • make sure kate part plugins can save data to sessions: fork kpluginselector, if necessary :)


  • extend highlighting system to allow combined highlighting
    • add e.g. “entercontext” rules
    • separate highlighting loader from hightlight class

Explanation: The purpose of this is to combine template languages such as PHP, EmbPerl, Mason etc with any other syntax highlighting on the fly, as opposed to the current practice which requires a combined set of files to be generated at build time. This is only done for the HTML + PHP combination, so with the new way a multitude of combination becomes available. In addition to that, nothing needs to be regenerated when a highlight is updated, makeing it much easier for users to keep their highlightings updated.

Highlighting / Modes

  • when opening the config page choose the current used entries (highlight and mode) in the combo box, so that it is immediately clear to the user which mode/hl is active
    • “Fonts & Colors” > Highlight Text Styles
    • “Open/Save” > Modes & Filetypes
    • -> implement in kate part internally: simply track an active view (the last that got focus)

Collaborative Editing

  • example: gobby
  • as KTextEditor plugin?
    • probably not completely possible right now, missing internal access
  • Decibel (realtime communication protocol)
    • move communication framework into separate process and use dbus interfaces
  • implementation postponed

Input modes (vi mode)

  • background: yzis
    • rewrite from scratch
    • idea of abstracting away “everything” to be flexible (e.g. to support different front ends)
    • development stalled 2 years ago
  • right now in kate part
    • command line already similar to vim’s “input mode”
    • keep this mode + extend, if needed
  • idea: integrate into kate part: extend/refactor kate to support input modes
    • make code reusable (in other modes)
    • extend KTE::Commands to support ranges (e.g. <1,10>)
    • add “normal mode”

Search & Replace

  • bar has big minimum width, works bad in split view
  • make it possible to embed widgets in the host application (KTE extension?)
  • search & replace over multiple buffers


  • Rule of thumb: Introduce interfaces only if usecase is known and best thing is always to have an implementation ready to get out the bugs before binary compatibility issues count

Annotation Interfaces

  • derive AnnotationViewInterface from AnnotationInterface
  • —> allow for KTE::Document and KTE::View
  • merge header files into one

Spellchecking Interface / Viewport Interface

  • both aim to support Kile doing spellcheck
  • conclusions
    • spellcheck should be first integrated in katepart
    • on-the-fly spellcheck support
    • highlighting should feed info which parts are able to be spellchecked (extend highlighting system)
    • after this is done, an interface can be invented to help Kile to enrich the spellcheck with meta-info like languages, additional spellcheckable ranges, …

Message Interface

  • implement a way to show messages in a non-intrusive way in the view bar
  • avoid message boxes by using it, this won’t influence the workflow!
  • allow quering the user (buttons like OK, Yes, No, i.e. KMessageBox-like)
  • multiple messages should be queued (or stacked?)
  • allow both implementation in the part for messages per view and a fallback provided by the application for messages when no view is available

Load/Save Filter Interfaces

  • preprocessing/postprocessing of text streamed from/to file
  • checking of input/output, warning, error, …
  • allow lazy loading, using .desktop files to describe mime-type + wildcards
  • allow to trigger usage of the plugins via document vars or mode config
  • default: not allow any plugin, user must allow them (!)

KWrite: should be more simple

  • extend the kate part to allow blacklist/whitelist highlightings/plugins
  • remove some advanced actions from ui file, provide simple mode, dummy mode
  • remove hl
  • remove folding option
  • remove bookmarks (menu, settings)
  • remove modus
  • remove almost all of extras
  • all in all: strip down to make it usable for the average user