In recent KDE releases up to version 4.4 Kate unfortunately very often selected the wrong encoding. The result is that e.g. german umlauts (öäü) show up as cryptic signs in the text editor. What I’ve seen lots of times is that in this case people start to fix those characters manually for the entire document. In other words: They totally do not get at all that the text document simply was opened with the wrong encoding. In fact, the users usually do not even know what encoding is at all. While this is of course kind of sad, this certainly won’t change…
Given this fact, the only correct “fix” is a very good automatic encoding detection, such that the encoding is usually chosen correctly. In the rewrite of Kate’s text buffer for KDE 4.5, Christoph also rewrote the file loader including the encoding detection. The detection now works as follows:
- try selected encoding by the user (through the open-file-dialog or the console)
- try encoding detection (some intelligent trial & error method)
- use fallback encoding
In step 1, Kate tries to use the encoding specified in the open-file-dialog or the one given when launching Kate from the console. On success, we are done.
The encoding detection in step 2 first tries unicode encoding by looking for a Byte Order Mark (BOM). If found, it is certain that the text document is unicode encoded. If there is no BOM, Kate next uses a tool from KDElibs (KEncodingProber) to detect the correct encoding. This is basically trial & error: Try encoding A, if there are characters in the document the encoding is not able to represent, try encoding B. Then C and so on… Unfortunately, this also doesn’t always work, because a byte sequence might be valid in several encodings and represent different characters. This is why it’s more or less impossible to get the encoding always right. There is simply no way…
If the encoding detection fails, Kate uses a fallback encoding. You can configure this fallback encoding in the editor component settings in the “Open/Save” category. If the fallback encoding fails as well, the document is marked as read-only and a warning is shown.
What about Kile and KDevelop?
One of the applications that heavily suffered of the wrong encoding detection in the past was the LaTeX editor Kile. The same holds probably for KDevelop (although it’s usually less critical with source code). The good news is, that with KDE >= 4.5 the problems with respect to wrong encoding should be gone. So it’s certainly worth to update if you are affected by this issue.
Looking back at the last month, migrating our Kate homepage over to WordPress was a vast success. The useful content we had on our old Drupal was copied over. The benefit of WordPress is that we now have a nice blog software as well with which we even aggregate some external blogs related to Kate. The new homepage is also more structured by having a list of featured articles showing useful resources, such as links to user or developer documentation.
The idea behind of the featured articles is to provide links to blog entries explaining in more depth what you can do with Kate. There are lots of useful tricks probably even some KDE developers aren’t aware of. If you have further hints of how to efficiently use Kate, please contact us and write a blog entry on kate-editor.org.
Besides that, thanks to all contributors for our awesome release in 4.5! 🙂
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.
UserBase is the same thing for users. It provides information about tips and tricks for KDE application, links to further pages an so on. It’s also rather static content. This is also why TechBase and UserBase both feature the “high quality” term.
This leaves us with the youngest of our wikis: the Community wiki. The purpose of the Community wiki is to give the KDE community a place where to coordinate. Think of leaving notes for thoughts. Or a list of contributors attending a conference. The current todo-list of a KDE project. In other words: The community wiki is a scratch pad for all sorts of content that does not really fit into TechBase or UserBase. If you are unsure, the community wiki is most likely the right place.
Currently, there is a lot of content on TechBase that never was supposed to be put there. This is because the Community wiki did not exist earlier. So what should be moved from TechBase to the Community wiki? All the articles in the Projects page without exception belong in the Community wiki. Just read through the list and you’ll get the impression that it’s more a dumping ground for some project related content. This is exactly what we NOT want on TechBase. However, people keep putting content there. So this is an appeal to the KDE community: Please use the community wiki! You are free to do there whatever you want 🙂 We have to take care to keep TechBase maintainable (this is also why techbase uses the subpages to structure the content). Sometimes less is more, so please take the time to remove Projects pages no longer needed, or move them to the community wiki. And especially put new content to the Community wiki instead of TechBase. Thanks!!!
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:
The traffic itself does not say much about the development. It probably tells us that there are quite a lot of people using Kate and reporting wishes and bugs. This is a good thing 🙂 The commit statistics for Kate, KWrite and the KTextEditor interfaces look like this:
Before 2000, Kate did not exist yet. Instead, so these commits come from the KWrite days. The commit rate is quite constant according to this statistic. In fact, there usually are always several developers working on Kate. Some only for a short period to implement single features or fix some bugs, and some long-term contributors. A very nice trend is given by the fact that the core team of Kate grew from about 4 to 7 developers over the last two years. So the Kate Project is very healthy – nice! And of course we are happy for every single contribution. So if you want to get involved in Kate development, join us!