Posts 

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:

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

Scripting

• 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

Indentation

• 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)

Auto-completion:

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

Highlighting

• 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.

There was some confusion with regard to my last blog about leaking memory. Suppose the ui_mywidget.h files looks like this:

class Ui_Widget
{
public:
   QGridLayout *gridLayout;
   QGroupBox *groupBox;
   QGridLayout *gridLayout1;
   QListWidget *listWidget;
   QSpacerItem *spacerItem;
   QPushButton *pushButton;
void setupUi(QWidget *Widget);
void retranslateUi(QWidget *Widget);
};</pr

                
                
                  Read More
                
              

The KDE codebase often uses a forward declaration in the .h-file to speedup compilation. The code often looks like this:

// header file
namespace Ui { class MyWidget; }
class MyDialog : public KDialog {
  // ...
  private:
    Ui::MyWidget *ui;
};

The impl looks like this:

// source file
#include "mydialog.h"
#include "ui_mywidget.h"
MyDialog::MyDialog() : KDialog()
{
  QWidget *w = new QWidget(this);
  setMainWidget(w);
  ui = new Ui::MyWidget(); // allocation
  ui->setupUi(w);
  // ui->...
}Read More
                
              

Kate’s highlighting capabilities are amazing. If you want you can highlight really complex syntax, without having to hardcode rules in C++. As an example, we’ll take a look at how Lua comments can be realized:

• –[=[ starts a multiline comment (the ‘=’ chars are optional)
• ]=] ends the multiline comment
• the number of ‘=’ chars in ]=] must match the number of –[=[

That means: When the highlighting processor matches the end of a multiline comment, it has to know how many ‘=’ chars started the comment. Thanks to the concept of dynamic rules and contexts Kate is able to do that. The highlighting file looks like this. First comes the header