Planet 

KDE 4.5 will be released in the next days with the most polished Kate/KWrite and KatePart during the KDE 4.x series.

A lot of work went into fixing bugs and cleaning up old code for this release. Many important aspects where redone, just to enumerate a few:

• encoding detection & handling
• the text buffer
• the undo/redo system (thanks Bernhard)
• search/replace (thanks again Bernhard)
• handling cursors and ranges
• improved spell checking (thanks Michel)
• improved indentation (thanks Milian)
• speed improvements (Milian too)
• better JS scripting (Dominik)
• porting of KDevelop to new interfaces (David Nolden)

It will be the most unit-tested release of KatePart ever I guess, but still a long way to go until we have a good test coverage. (we just scratch the surface)

Hello,

today i will show you a new plugin for Kate, called KateSQL.
As you may have guessed, it brings to Kate the basic features of an SQL client, allowing you to open connections, execute queries, and display result data from SELECT statements or stored procedures.
Since this plugin makes an extreme use of the Qt Sql module, most of database drivers are supported..

Said this, let me explain how it works..

Hello,

KDE has three wikis: TechBase, Community and UserBase. The separation has the following meaning according to http://wiki.kde.org:

• TechBase: The primary place for high quality technical information about KDE targeted at 3rd party developers, ISVs and system administrators.
• Community: The working area for the KDE community. It provides a place for sharing information within the community and coordinating community teams.
• UserBase: The home for KDE users and enthusiasts. It provides high quality information for end users on how to use KDE applications.

So TechBase is a source of mostly technical information. This includes step-by-step howtos for all sorts of KDE development as well as the feature plans and schedules for KDE releases and so forth. It’s mainly static content. Think of a howto for a Plasma Widget or a howto for building KDE. The content usually is valid for a long time, mostly even for years. For those of you longer in the KDE project, TechBase is the same as our good old developer.kde.org page (and we’ve never put arbitrary content there). The only difference is, that it’s now maintained as wiki.

The Wheel of Time turns… meaning that the Kate Project has quite along history by now. The Kate Project was started back in December 2000, so it’s almost 10 years old. Development sometimes continues with a fast pace; and at other times there is almost no progress for weeks. But all in all, looking back at those 10 years, we can proudly tell you that the project is very much alive. Let’s take a look at the traffic of our mailing list:

As with any new code, during adoption bottlenecks show up.

For example the rendering of text lines with many ranges inside was quiet slow. This is now partly addressed by Milian Wolff, thanks a lot.

An other bottleneck was the assumption, that it is fast enough to hash the ranges just by their block and iterate over all of them to search the ranges matching a specific line. This does scale well enough for KatePart itself, but KDevelop creates multi-thousand ranges for small documents. To improve this, an internal special mapping was implemented by David Nolden for ranges which don’t span more than one line. For them an efficient line => range mapping is easy and not to costly.

Read More

Dominik already blogged about the issues we have in KatePart with the current SmartRange/SmartCursor/Smart* interfaces that were designed during the early KDE 4.0 release.

Given that large amounts of the internal implementation are exposed to the outside in the interfaces, there was no feasible way to fix the issues with them. The problem with the not thread-safe behaviour could have been prevented by just stating the plain fact that multi-threaded access to the ranges doesn’t work, even thought there is a mutex in the interface exposed which should be locked to gain this safety. Still the real problems of the unchangable bad implemenation and design choices would have remained.

Hello,

As mid-term evaluations have started, I would like to show my current state of GSoC project, because I’ve never found the time to do it.

The swap file feature is implemented, except for the view differences feature and few TODOs. Some more testing need to be done, though. Below are some screenshots of how it works.

When you start editing in a document, a swap file for the document is created (“.swp.originalFileName”). If Kate crashes and the user didn’t save the changes, the swap file remains on the disk.