the written word remains

Prologue

I didn't expect the previous part of this review to be so popular. Huge thanks to everyone who read, linked and commented it!

I know I promised you to write about KDE4 applications, so without further ado, here is the continuation.

Table of Contents:

1. Dolphin
2. Konqueror
3. Konsole
4. KMail
5. Akregator
6. KGet
7. Gwenview and Okular
8. Grand Conclusion

Dolphin

I'd like to start my applications review with Dolphin, as it was the most prominent change in the applications area. It was planned to make Dolphin the default file manager since KDE3, but I never tried it then. I got Dolphin with 4.1 and started using it.

Probably I'm too old, but I always liked two-panel console Norton Midnight Commander-alike file managers. They always worked for me in the most efficient way, or at least I felt so. Maybe this was the reason I never liked to use Konqueror in KDE3 for file management, maybe no. I don't know now. What I know now is that for file management today I use Dolphin. What convinced me to do that?

First, it's Dolphin itself. It's freaking fast. It starts in a moment, it never pauses to read the directory (even my photo archives, without previews of course). Dolphin's performance is convincing.

One more convincing argument for Dolphin is its simplicity and focus. Extreme focus on just file management - nothing extra but plain file management. I adore this approach. Konqueror 3.x as a file manager used to have this bad habit of opening some files as a preview inside the same window, embedding an external application. I always had to go to mime type settings and explicitly tell Konqueror to never use these embedded viewers. Thankfully, this is not an issue now with Dolphin - it simply won't embed anything :)

Those who remember NC, Far, MC and brethren, will remember how useful F3 (quick file preview) was. In the good old days when computers were slow and file formats simple enough to parse - quick preview rocked. In 2009 when computers are too fast for the ordinary user and file formats are damn complicated, you can't have the quick preview. You need the whole application to do the preview for you. Konqueror in KDE3 tried to emulate previews by embedding apps in read-only mode inside. But that didn't quite work. Why would I need a preview when I can launch the full blown application with read-write access in the same time? This is why I like Dolphin for not trying to do previews at all. I double click - and I open the app. No dreaded embedding anymore.

Second reason for me switching from old school panel file managers was that these days I rarely need the file manager. In 1990's your computer session started in the file manager where you'd search for your files to start working on something and ended in the file manager where you'd type the command to shut down the machine. It's 2009 and I prefer more "application and document" oriented approach. I usually launch an application then work with my stuff directly inside it. For instance, I manage my projects with KDevelop, my music with Amarok and so on.

Here is my Dolphin window, nothing fancy really:


Note that I don't have the "Information" panel shown. In fact, I'd advise everybody to avoid it at all cost. Most of the time it will just sit there and eat your CPU and pull your disk trying to make previews and get file stats exactly when you don't need it. So turn it off and make your Dolphin fast. When you need stats - press "Alt-Enter" or choose "Properties" from the popup menu. When you need previews - switch to the "Preview" mode.

Speaking about "Preview". Did I mention that this mode is gorgeous in Dolphin? No? Then see for yourself:


Preview mode is quick and smooth and the magnifier slider below is an awesome addition to it. I do believe this slider was designed for previews. I don't need Gwenview to quickly review my photos now. I can just use Dolphin. By the way, one hint for those who have modern DSLR cameras or high-megapixel compacts. Go to Dolphin Preferences => View Modes => General and increase the maximum file size for file previews to 10-15 MB. Without this, pictures from your camera will not have previews which would be a real pity ;)

There are more nice things about Dolphin. The Ctrl-I (Filter Bar) feature is exceptionally useful to look for files in the directory. Like most things with Dolphin, it's fast. I'm typing 10 times slower than Dolphin filtering the directory with 4 thousands of files!

But I wish the filtering worked like the search bar in MacOS's Finder. Filtering there recurses into the subfolders. Recursive search + filtering would be a nice addition to Dolphin. I personally will buy a beer or two to the first person who implements that :)

Breadcrumbs-based navigation is another nice file management concept implemented in Dolphin. It doesn't sound groundbreaking for me, but I do use it when my hand holds the mouse. I also like that Ctrl-L shortcut still works as it did with Konqueror, replacing the breadcrumbs with an URL input field and letting me type, for example, the sftp server address. What I really don't like though, is that that input field doesn't remember URLs I've typed. Also Ctrl-L should preselect the URL for me. The most common case is me replacing the URL, not appending to it. I've committed exactly this fix some time ago to the KDE file dialog. Looks like I'll have to do the same with Dolphin :)

Being so simple, Dolphin has only a few problems. But one of them annoys me quite a lot. Split view is not keyboard-navigatable. You can't use Tab and Shift-Tab to switch between views because the focus switches to the magnifier widget. One way to fix that is make magnifier widget not focusable, another - to have one more shortcut to switch between split views. Until this change is done, split view is the feature only for mousers.

Another issue is the questionable value behind Nepomuk (aka "semantic desktop") related functionality, namely commenting, tagging and rating files and folders. I never ever commented any file, I never wanted to as well. I would rate only the audio tracks to make a playlist like the "My Top Rated" that exists in iPod's. But even then, I'd do that in Amarok directly and as I've discovered Amarok and Dolphin do not share the rating. This essentially voids any value of the rating for me.

Tagging? Ok, I can tag my file. What's next? I can't filter for tags in Dolphin, I can't find files by tag with "Find Files/Folders". I'd really like to see the tag-aware operations like these in Dolphin, but they are not there.

I suppose to get some value from tags I need to use the Strigi Desktop Search. For this review I tried exactly that. I enabled Strigi in System Settings => Advanced => Desktop Search. Then I had my folders indexed. Then I spent half an hour to understand what to do next and how to actually search. As it turned out, to search for tag called "test" you need to type "nepomuksearch:/tag:test" in the URL bar in Dolphin. And that finally worked :)


What I can say? Not only there's low value in new Nepomuk functionality, but there's actually no way for the user to discover and use it. What Dolphin needs is a search box. Search box will be immediately obvious for the user and a little "?" button near it would let people know what search syntax to use. In addition to that, I have a feeling that filtering by tag (preferably recursive) should work in Dolphin right away without any Strigi index from the filter bar.

Conclusion:
Dolphin is an excellent illustration for the "less is more" principle. Simple, focused just on file management and exceptionally fast, Dolphin is a joy to use.

My only complaint about Dolphin is the absence of the advanced search. In particular, I'm looking forward recursive search/filtering features and more close integration of the Strigi search into the file manager.

In any case, Dolphin is definitely one of the reasons to switch to KDE4 and even should you decide not to use the desktop itself, do try Dolphin. It's worth it.

Konqueror

Konqueror from KDE4 for me is now only a web browser. I know it still can be used for file management, but with Dolphin in my hands I'd never use Konqueror for that.


As a web browser, Konqueror 4 is surprisingly good. Its primary goodness is the performance. The application starts and works fast, takes 3 times less memory than Firefox (under the same conditions), the javascript engine and renderer are definitely quick as well. Konqueror may not outperform Safari in terms of speed, but it is definitely on par with any other modern browser.

To make Konqueror even faster, go to Settings => Configure Konqueror => Performance and turn on preloading after KDE startup and set the memory usage setting to "Always". These days I don't use these options because Konqueror is light enough and my PC is fast enough for me to never notice its startup time. Another thing I recommend is to configure browser cache. I always enable "Use cache whenever possible" mode myself. With this option enabled, you have sometimes to reload the page to invalidate the cache, but that is not necessary too often.

The UI in 4th version is simple and succinct. It doesn't have anymore all that bloat that ruined user experience in KDE3 times and it actually has most of the basic web browser features implemented.

For example, I like the tabbed browsing features that come by default in Konqueror. The essential tab management features for me are: opening new tabs in the background, opening tabs right after the current tab and undoing tab close. Konqueror by default has all these features, including the nicely implemented "undo close tab" which works like regular "undo" and is even bound to the same Ctrl-Z shortcut.

Bare Firefox right after installation misses the "open after current" function. But, Firefox has this indispensable Tab Mix Plus extension that easily outperforms Konqueror. I wish Konqueror had Tab Mix Plus' features like "Closed Tabs List" menu and the "Change opening order" mode that opens new tab after the last unread tab.

However, nice set of tab management features comes with an irritating tab switching behavior. Upon selecting the tab, the toolbar flickers. Being a developer, I know why this happens, but the knowledge doesn't satisfy me :) Internally each page is a KHTML component with its own menu and toolbar actions. When you open another page, Konqueror hides menu and toolbar actions for the previous page and shows actions for the new page. Hence the flickering. Understandable, but extremely irritating.

Apart from tabs, another essential web browsing feature these days is ad block. Konqueror's implementation is called "AdBlocK" and is built into the browser. AdBlocK comes without filters, but you can import them. I use the lists for Ad Block Plus Firefox plugin. I recommend importing EasyList first, and then looking for the local list for your country. I add RU AdList and UA-IX banlist. All those lists work fine, but I do miss the Ad Block Plus' ability to update them automatically. Another annoyance is that in Konqueror you cannot have exceptions from ad blocking. Some web sites and applications (like typepad.com) are broken with adblock, so you want to be able to exempt them. Unfortunately, with Konqueror you can't.

In the Firefox land when somebody says that Firefox doesn't do something, the usual answer is "install extension". In Konqueror land things aren't this bright. Konqueror does have an extension interface and even comes with 13 extensions but... unlike Firefox, you need to write extensions in C++ and compile. It's not like this task is extremely complicated, but it does set the high entry barrier for plugin writers. Also it complicates plugin distribution, because you have to cater for various flavors of Linux and also for MacOS and Windows. People who write Konqueror plugins simply distribute them from kde-apps.org site in the source form leaving the burden of plugin compilation and installation for the user which is never a good solution.

If you read up to this point and already think I criticize Konqueror too much, then I'm going to disappoint you. Criticism barely started :) Because Konqueror as a web browser application is fine, but Konqueror (or rather its KHTML engine) as a web page rendering engine is not.

It will render web pages just fine 98% of the time. But even on those pages usually there are glitches. Nothing serious - hidden borders may be visible, buttons and comboboxes may be too big or not focusable from keyboard, fonts may have the wrong size, div's may have wrong positions and so on and so on.

These minor problems tend to sum up together and radically harm the impression from web pages. Usual apology for having such problems is that KHTML/Konqueror's user share is too small for web designers and developers to test pages against the browser and fix the problems. That is of course true, but even if you do want to fix the look of your website with Konqueror, there isn't much what you can do.

I've been developing web applications for almost 3 years and I know the simple fact. As you develop, first you get your site work good with Firefox. Then you tweak some minor things to fix Safari. Then you do some more work and fix Opera. After a week of frustrations and tricky hacking, IE7 will work fine. Another such week and you'll fix IE6. And only after that you go and check your website in Konqueror and fix that.

I hear you screaming "What? Konqueror is worse than IE6"? Believe me, it's true. Even after you get everything to work with IE6, there are usually some things still to be fixed with Konqueror. Also Konqueror doesn't make it easy to fix problems. Javascript debugger is rudimentary and DOM tree explorer is useless. There's no Firebug, no Web Inspector, so it's no wonder web developers don't check their work against Konqueror.

Conclusion
While Konqueror is a nice and fast web browsing application, it is just not good enough for everyday use. Since KDE3 Konqueror definitely improved, but not radically enough. You'd be better off with Firefox or Safari for both everyday use and web development.

I think for Konqueror to be a better browser, two things should be done.

First, QtWebKit should be used as rendering engine instead of KHTML. I want that not because WebKit is technically superior (it's not), but because it's exhaustively tested and because web developers develop and check against it. Also with WebKit on board it will be possible to have so badly needed development tool - the Web Inspector.

Second, Konqueror should have extensions API for Ruby and/or Python. It should be much easier for people to write and distribute extensions written in those languages, therefore it will be much easier to build a developer community around Konqueror similarly to Firefox.

Konsole

Konsole is like a good old workhorse. It just works. Correct terminal emulation, tabs, unlimited history, copy and paste, support for unicode, total keyboard navigation through the interface. What else do you need?


Apart from things I listed, I need and like Konsole's neat monitoring features. First, it highlights the tab where some change happened. This really helps me when I work on several tasks simultaneously (and I do that 90% of my day :)). If you think this notification is too subtle, there's a way to ask Konsole to report activity or silence with the system notification. I personally don't use this often, but silence notification does help to find out when a long-running task completes.


In KDE4 Konsole became even faster (both at startup time and rendering). The UI was improved to increase usability. Also there are now split views, but with a bit strange implementation. When you split, you will see the duplicates of all your tabs in the new split container. I still haven't figured yet how to make use of this feature, but at least unlike Dolphin, I can switch between split view containers with Shift-Tab and even resize them from the keyboard.

From other things that changed recently, I'd like to mention that Konsole tabs in KDE4 are finally named after the program that is running or after the remote host I'm logged into with ssh.


Conclusion
Konsole is still as awesome as it was ever before. With KDE4 it only changed for good so the only thing I have to say here is "Thanks" for Konsole developers! Konsole was one of the reasons I started using KDE back in year 2000 and it's still a compelling reason to switch to KDE4.

KMail

Unless you want to hear the endless flow of praise, please skip this section altogether because I'm just going to say that KMail is awesome :) I'm with KMail since 2001. It was version 1.4 IIRC. Now it's version 1.11 (how conservative, don't you think?) and I'm still with KMail.

My email archive is also still with KMail. I was able to import it from Outlook Express storage back in 2001 and since then kept it in the maildir format without any breakages. I still keep about 3 gigabytes of archives and KMail had never any performance problem because of that.


Historically KMail is an excellent tool for those who reads tons of mailinglists. Of course you can put mails from different lists into different folders using the most powerful filtering system I ever saw in mail clients. Proper threading is always a plus. The killer feature is the ability to bind a folder to one your email accounts such that all replies from that folder automatically use the specific address and smtp server. My work-related folders are set up to use my company's email account and my KDE-related folders are set up to use my personal address. This is really convenient.


Some of you could ask why do I mention folders, filtering and threading, aren't they supposed to be the standard in all email clients. That's only because there is GMail now - one of the most popular email "clients" with limited filtering capabilities and with no support for folders. Don't even bother telling me about labels. I receive so much emails, that without proper hierarchical organization into folders and subfolders my mailbox is simply not manageable. Also GMail doesn't do the correct threading. It threads only by subject ignoring "in-reply-to" and "references" headers. Not really useful I'd say.

However, KMail and GMail together make almost a perfect match. You can get all your mail from all your accounts into the GMail and then fetch it with KMail. This way you get the decent spam filtering and still use the right email client, which is of course KMail :)

KMail in KDE4 kept all the goodness it always had, added many of new features and became even faster. My personal KMail hero of the last year is Szymon Stefanek, who gave the new birth to the application during his summer of code project.

As a result of that GSoC project, KMail got new message list with tabbed interface and customizable look, new thread aggregation capabilities, message list themes, new sorting orders and much more. You have to explore the KMail yourself because my blog is just not large enough to present you all those various ways your message list can look like.

I'm conservative. I continue to use "Standard Mailing List" aggregation and "Classic" theme for message list. But what I really really like is how fast KMail is after Szymon Stefanek's refactoring. No, it's not "fast", it's "FAST"! I have huge folders with several thousands emails in them and never notice any slowdowns. The startup time doesn't depend at all from the size of the mailbox. I could easily have 15G of mails and I'm sure KMail would be just as fast as it is now with 3G.

Conclusion
KMail is amazing! It's a pleasure to use - excellent performance, great feature set for mailinglist lovers, single-key keyboard shortcuts for keyboard addicts. I simply can't think what else to ask from it. It will surely please both old-timers and newcomers. Try it, you won't regret!

Akregator

I'm subscribed to the horde of RSS feeds and therefore I frequently use Akregator, the KDE RSS reader. Unlike web-based tools, it's good for organizing your feeds into the tree-like structure just as I like. It's also fine for reading feeds. I wish it used Webkit instead of KHTML to display contents though.


That said, I have to admit Akregator has quite some flaws. For example, it has potentially great "Combined View" when you have the list of feeds on the left and the single page with the complete article contents on the right. This view would be the most convenient for reading if only it wasn't too slow. It will attempt to show all articles in the feed which of course will take ages if you like me have 2000 articles sitting there. I think it should really show only unread articles in that mode.

Another potentially cool feature is Google Reader synchronization, but it also suffers from immaturity. The UI for the feature is not finished and I couldn't log in to my GMail account at all. I'm not even sure whether the synchronization is supposed to work. I wish it worked because that would be the killer feature for me. When I'm away from my computer I want to have my feeds in Google Reader. When I'm back, I want them in the Akregator. That would be really cool, but alas, I couldn't make it work.

Conclusion
Akregator is definitely useful for RSS reading, but so far it doesn't give any compelling reason to use it. Two killer feature candidates (Combined View and Google Reader synchronization) are already there, but they don't work yet. If you used Akregator in KDE3, you'll find the same feature set in KDE4. If you already use another RSS reader, keep an eye at Akregator. Maybe at some point in the future it will have something interesting to offer you.

Update
As draugdel kindly pointed out in the comments, the Combined View mode obeys filtering. So if you set status filter to "Unread", it will no longer attempt to download all articles. This radically changes my experience for better and gives one bonus point for Akregator.

KGet

KGet is the KDE downloader. It was there in KDE3, but it really matured since then. KGet that comes with KDE4 is very useful. Not only it has reworked interface that is actually usable, but it has the solid number of features. I'll name only multithreaded file download and and Bittorrent support. Both are not very critical however, but surely nice to have.


Another nice thing is the web interface that lets you control your downloads when you're away from your computer. While I like the idea, I don't quite like the implementation. The web interface doesn't work well with both Firefox and Konqueror - the numerous popups tend to stay on the page and force you to periodically refresh the page.

Conclusion
It's hard to say that downloader can be the application to convince people to use the KDE desktop. But should you need a downloader, you have it in KDE4. And unlike tons of other downloaders out there, this one is good and usable. KGet has all the features and is simple to use at the same time. I like such applications, I like KGet and I hope you will like it as well.

Gwenview and Okular

Now it's time to review the sweet pair of KDE viewer applications - Gwenview, the image viewer and Okular, the document viewer.

Usually, image and document viewers are the indispensable desktop tools. I can't imagine myself using the desktop without them. Both Gwenview and Okular are newcomers in KDE. Gwenview has been in extragear in KDE3 times and Okular grew from KPdf. Both replaced the horde of viewing tools from KDE3 that never worked well. Both do their job and do it really really good.

Gwenview is gorgeous. It has everything the image viewer needs to have - browsing and viewing modes, full screen playback, customizable Metadata/Exif display (very useful for DSLR camera owners because you can set up it to show exactly the information you need), basic image editing like mirroring, cropping and red eye reduction. Just as other KDE4 applications I've reviewed, Gwenview is fast and is pleasure to use. During the development a lot of efforts were spent to increase the usability and it now clearly shows off. The application is definitely easy to use. As a nice bonus, it also looks good:


My only wish for Gwenview is the more advanced fullscreen playback. I rather like how iPhoto does slideshows with effects and music and I hope Gwenview will be able to do that as well.

Okular is a great improvement over "KPdf + KDvi + brethren" viewer combination we had in KDE3. First, it's good that now we have the single viewer to open all possible document formats. Second, Okular supports many more formats now and manages annotations for all those formats.

The greatest strength of Okular is of course PDF reading with the support for contents and fast and correct page rendering. I really like to have Djvu and Fb2 (Fiction Book) on board. As a (former) scientist, I have lots of Djvu books. As a literature addict, I also got the large collection of Fb2 books that I keep for my e-book reader. Now I can read all these books in Okular without having to install the dedicated software. Nice, isn't it?


Of course, Okular has also its share of problems. While PDF files looks great, pages from ODT and Fb2 documents don't look as good mainly because of missing font antialiasing. I only wish we could have antialiasing for all possible document formats.

Conclusion
Gwenview and Okular are the results of the serious rework in image/document viewing department that was done during KDE4 development. Both are well-done, usable applications, they support all required image and document formats and are pleasure to use. My kudos to the Gwenview and Okular developers - they did a great job.

Gwenview and Okular can easily speak for itself. Once you try them, you won't look back. I would definitely switch to KDE4 only to get these two applications. Or, just use them with any other desktop. Like I said in the conclusions about Dolphin above, it's worth it!

Grand Conclusion

While writing this review I caught myself repeating the same things about every KDE application, namely excellent performance, usability and great features.

It is so good to see that a lot of work during KDE4 development went into improving the quality of the user experience. Unlike their KDE3 counterparts, the best KDE4 applications are definitely more user-oriented. Despite being a developer, I enjoy this as much as every other person would.

It is equally good to see almost all KDE4 applications being fast. The optimizations behind the scene in Qt and KDE frameworks already showed up, but I think that this is only a start. We will definitely see even more performance improvements in the future.

The KDE "Gang of Five" (Dolphin, KMail, Konsole, Gwenview and Okular) sets the new standards of performance, look, and usability without sacrificing essential features of file manager, mail client, terminal and viewer. If you aren't convinced by the bare KDE desktop, please take a look at these applications, let them speak for themselves!

---

KDE comes with a lot of good applications and I barely scratched the surface this time again. I haven't said a word about KWrite/Kate - an excellent text editor, Digikam - the ultimate digital photo processing software, Kaffeine - the video player and of course Amarok - my beloved music player. Looks like I have to write yet another part or two :) Come back again!

Prologue

It's probably the first time in my life when I'm writing a post with a word "Review", but looks like it's a perfect time to start doing that. Right now I desperately need to tell the world about KDE4, or to be precise, soon to be released KDE 4.2. This is going to be the first "real" release targeted not only at KDE developers and enthusiasts, but at general public - all the people who eagerly waited for the next KDE desktop to arrive. With this review I'd like to let people know that the KDE 4 is ready and to once again celebrate the hard work of all the people who put tremendous effort creating this great desktop.

Now you may think that because I'm a KDE developer, this is going to be one more "fan boy" article about KDE4, but I hope I'll prove you wrong. There are things I like, things I hate and things I miss in the new desktop and I am going to write about all those things. Of course everything that is written below is just my own opinion. Feel free to agree or disagree with me :)

Also note, that I'm going to review only the functionality and applications that I actually use. Surprisingly enough that is a fairly small subset of what KDE4 provides, so for example if you want to learn about the new KOffice you're going to need another reviewer ;) But enough of introduction, let's start.

4.2 is 4.0

There was a lot of controversy about KDE4 release schedule. There was a hard decision to ship 4.0 last year in January in the highly unstable state. I still think it was a wrong decision and we (being the open source project) could delay 4.0 for 9 months or an year. From the other side, the experimental .0 release wasn't so much a disaster. Thanks to the efforts of people from Marketing Working Group, people got the message about experimental nature of the release.

4.1 was the desktop I could start using myself and I did exactly that. Still I never recommended it to my friends (or to be more precise, I recommended against using it ;)). But the year passed by and now we're ready to release the "real 4.0" which is for the reasons described above called 4.2. So, let's see what we have now.

General Look and Feel

In comparison with KDE3, the 4.2 desktop looks modern. What's important is that it certainly doesn't copy neither Windows Vista, nor Mac OS. It has its unique identity in everything - in icons, widget theme, panel and desktop theme, window decorations, etc.


I have an impression that it's during KDE4 development artists became a team and started thinking about consistency and coherence in visual appearance. Let's take icons for example. I usually don't care much about them, unless there is an icon that stands out of line and annoys me. In KDE4 so far all icons look consistent for me.

Oxygen theme for Plasma makes the desktop feel right. Dark blue and black decorations match perfectly. Those people who install KDE4 from OpenSUSE packages should really change the desktop theme from the OpenSUSE default grayish theme (was it called Aya?) back to Oxygen. It's not that Oxygen theme looks better (that's highly subjective), it just looks "right" because all parts of the decorations fit together.


Things aren't as bright with Oxygen window decorations and widget style. The window decoration features cartoonish minimize/maximize/close buttons which give almost no feedback when you press them. But that's fairly minor issue. The major issue in the window border which is annoyingly think. I hate when decorations take my screen space. First, I don't want to see 5 pixel borders from each side, even on my 1920x1200 screen. Second, the rounded window corners are aliased and therefore look ugly and "unprofessional". In Mac OS, for example, windows have no border at all which contributes to the nice and professional look and feel.

What I'd love to see at least, is a configuration option to make window borders tiny. We had this option with Plastik in KDE3 and we have this option with other KDE4 styles (like QtCurve). I simply can't understand why the window border thickness is not configurable with Oxygen.

While the KDE4 default Oxygen widget style generally looks good, it's not without problems. It is certain and fortunate that we didn't screw up with default style like we did when KDE 3.0 was released with Keramik :) Oxygen is a good style, but there are a few things I dislike about it.

First, and most importantly, the scrollbars have an usability problem. Scrollbars are visually separated from their scrollable view. When you have two scrollable views sitting one alongside another, you'll see the scrollbar right in between them and you never can tell which view has this scrollbar - the one to the left or the one to the right. After a millisecond of thinking you remember that views usually have scrollbar on the right side and solve that problem. Remember the book "Don't make me think"? I always remember it when I see Oxygen scrollbars.


The scrollbar ownership problem combined with visually indistinguishable resize grips on splitters (just 3 subtle dots for the whole splitter) make for example Akregator unusable. Just look at the screenshot below and tell me without thinking where you'd grab to increase the height of the bottom view ;)


I haven't seen a single widget theme that has such "orphaned" scrollbars, neither or Linux nor on Mac or Windows. There are other minor issues with the style such as tabs that take too much screen estate and comboboxes that don't react visually (push down) on clicks. What I'd like to say here is that it's really unfortunate that those 3-4 problems radically impair the user experience with otherwise nice and well done Oxygen style.

For myself, I've solved all those problems for now by using QtCurve style. QtCurve resembles Plastik from KDE3 (which is fine with me as I really liked Plastik), it has little visual glitches (at least none of the described above) and its window decoration can be made thin. As a bonus, with QtCurve you can get uniform desktop look if you like me frequently use Gtk/Gnome and KDE3 applications. I still depend on KDevelop3 and Konversation. I frequently use Gimp and I have Firefox as my primary browser. All those applications look great and consistent with QtCurve.


The last thing from the "look-n-feel" department I'd like to mention is the overall desktop performance. I don't need any numbers to tell that performance hasn't changed much from KDE3 times. On my hardware (which is Core Duo 4600 based PC) KDE3 was fast. KDE4 feels the same, after all, it's not Vista :) Certain applications (like Dolphin, Konsole or KMail) even improved their startup time.


Conclusion:
If you just need one reason to switch to KDE4 - it's the look and feel. The modern polished and stylish look makes your desktop experience as pleasant as possible. None of the issues I've described above is a showstopper for the user. In the worst case you'll end up like me using non-default widget style, but that's hardly a problem.

KWin Window Manager and Desktop Effects

I can hardly say anything about KWin itself. That's the amazing piece of software that never stands on your way and this is exactly how the window manager should work in my opinion.

KWin is highly configurable and customizable. This review is too small to even list all the things you can do with your windows. But there are two advanced KWin features that I actually use.

First feature is the window geometry/position saver which is handy for those applications that don't remember those settings themselves. Some time ago Konversation used to forget its position on the screen. Now KWrite has sclerosis. With KWin I'm always able to fix that myself.

Second feature worth mentioning is window shortcuts for quick switching. If your like me always have a certain number of windows opened, you'll find this useful. For example, my session starts Konsole, KMail, KDevelop and Firefox. Normally I keep them opened 100% of the time and no matter how many other windows I open, there are always Win-Alt-K, Win-Alt-M, Win-Alt-L and Win-Alt-O shortcuts to switch to and between them. The more windows you opened - the more you like window shortcuts.

I'd advise you to give those features a swing. You'll find them in Window Menu (Alt-F3) => Advanced => Special Window Settings, Geometry and Preferences tabs.


KWin shines when it comes to the desktop effects. Compiz Fusion, the traditional solution to desktop effects is actually a compromise between appearance and window management features (and also stability as Compiz developers admit). With KWin you don't need to compromise neither stability nor features. Compositing and desktop effects come as an integral part of the window manager.

As a MacBook owner and Mac OS user I certainly like to have things like Exposé (called "Present Windows") and Desktop Grid in KDE as well. Window shadows would also be familiar for the Mac OS user. From the tons of other effects I saw the value in "mouse mark" thing. Usually you'd use mouse cursor to show off things on your screen to other people. With mouse mark you can also draw directly on the screen highlighting important areas.



Desktop Effects (aka "compositing") do require more or less modern graphics card. I used desktop effects on my Macbook Pro with ATI X1600 card and their performance was ok. On ATI 3450 there's nothing to complain about wrt effects. Other people report that integrated Intel graphics is ok. With newest drivers NVidia should work fine as well without any performance penalties for the rest of the desktop (see my previous post for the detailed discussion of problems with previous NVidia drivers).

No matter how much I like the idea of desktop effects, I still don't use them. With compositing enabled Firefox is slow as a hell at rendering and scrolling web pages. Current Webkit based browsers for Linux are not yet as good as Firefox so there's no way I'm switching from it. Firefox 3.1 beta has better performance with composite, but not much. Another known compositing problem is that with ATI proprietary driver video doesn't work (it flickers).


Conclusion:
KWin is awesome. Do spend a couple of minutes and look through all its features to find some that you will like. I personally recommend window shortcuts and geometry saver.

Desktop effects with KWin do not just look cool, but instead provide usable features like "Present Windows", "Desktop Grid". If you have the right graphics card/driver combination or Firefox and video problems don't happen (or don't matter) for you, enable the desktop effects.

Plasma Desktop

Plasma is the complete redesign/rewrite/rework/re...etc. of the desktop in KDE4. I've mentioned how great it looks before, now it's time to look at the functionality.

Panel

From user's point of view not much has changed since KDE 3.x in the panel. It's still the good old K-menu + app launcher icons + desktop switcher + task manager + system tray + clock thing. Works fine - no complaints.

In 4.2 panel finally has one of two important features I need, namely the "Windows Can Cover" mode which I always use. Another one is still missing though. I very much liked the MacOS-alike menubar mode in KDE3. You could place the menubar panel on the top and add menu, application launcher, systray and clock there while leaving the task manager panel at the bottom (in "Windows Can Cover" mode). Such setup saved me some precious vertical screen space. Precious because I'm an widescreen monitor addict and on my 1920x1200 display I hate anything that takes my pixels from that "1200" side.

There are two implementations of the menubar for KDE4 already. One lies in the playground and another comes with the Bespin widget style. I tried the the later which is called XBar. It mostly works, but doesn't look good even with Bespin. With other styles it's just plain ugly. I guess the code needs some more love to make the XBar ready for general consumption.

Desktop and Widgets

Plasma brings some fresh air to the Linux desktop departments. What I really like is this new and default "no f*g folder/file icons on the desktop" mode. Before KDE4, my desktop was always filled with all that garbage that I download with the web browser, files I temporarily save and so on. Because of that, the desktop had only one purpose - to be the trashcan that you need to sweep out periodically. Plasma by default won't let you do this and instead brings some value to the desktop with Widgets (aka Plasmoids).

KDE4 comes with 60-70 widgets you can place on your desktop, but after a year of using KDE4, I refined my selection to just 4 widgets.

The most useful addition to the desktop is the Picture Frame. I like to put the photo of my girlfriend into the nice frame right onto the desktop without having to change the wallpaper. In general, people faces and pets don't look good as wallpapers, so with Plasma you can have them as picture frames floating over the background.

Comic Strip is the another widget I'm totally in awe of. What can be better than getting the most recent strip from PhD Comics series right after login? :) Yeah, I know, I'm a pervert and you'll most likely be following Dilbert or XKCD, but I'm sure you get the idea ;)

Having used Notes in the Mac OS dashboard, I liked them in Plasma. Desktop just feels like the right place to put some random notes and now you can do that with KDE4. The good old KNotes application from KDE3 is still there in KDE4, but I just don't need it anymore. My notes are now on the desktop.

And finally, the last widget I use is called "Luna" which is a nice way to show the phase of the moon. I like to take my camera with a long lens, go out and shoot moon so it's good to know that there's a full moon day approaching. While I'm writing this review, Luna tells me that tomorrow is the full moon. How sweet :)

Here's how my desktop looks with all those widgets:


I was amazed how such a simple idea of having widgets on the desktop changes your experience for good. Also now I'm totally convinced that KDE4 implementation of this idea is the best out there. Vista's gadgets occupy only the small part of the desktop leaving you with those annoying icons for the rest of the desktop space. In Mac OS you need to go to the Dashboard for widgets. And only in KDE4 widgets are exclusively on the desktop, in fact they "are" a desktop.

Only with free software you have this power to make a decision to completely replace the old desktop with icons with the new one with widgets. Good to see both Apple and Microsoft still struggling with the old desktop metaphor while we're enjoying the new one :) And by the way, KDE is not Apple. The default desktop setup is not going to be the only one possible. Choose "Folder View" containment as a Desktop Type, and get your icons back. I do advise against that, but it's your choice after all.

When desktop becomes more useful, the old problem how to show it when it is covered by windows becomes more severe. Vista solves this in the most useless way - the Sidebar is allowed to be on top of windows, effectively reducing the screen space. MacOS's solution is to show translucent Dashboard on user request only (with F12 shortcut, with active screen corner or with dock button). In KDE4 you can also show desktop widgets in a MacOS-alike way with Ctrl-F12, but instead of that I just add an extra virtual desktop and keep it always clean without windows. Any time I need the desktop widgets - I just switch to another virtual desktop.

Widgets you place on the desktop can also be added to the panel. Plasma team spend several years redesigning and rewriting the desktop and panel from scratch and now it certainly pays off. The same clock you see on the panel can be added to the desktop and vice versa. But no rewrites comes without consequences. Many places still need polishing. For example, the "Digital Clock" widget has its own implementation of the calendar widget and unlike the standard one from KDE libs, this has some repainting glitches and bugs with popup menu rendering. Also after increasing desktop resolution with xrandr command, desktop and panel resize fine, but you can't move the widget outside of the previous desktop dimensions. Such small problems exist, but I'm sure they will get all fixed eventually during 4.3 (or even 4.2.x) development.

In general, both the desktop itself and the widgets in KDE 4.2 provide great user experience. But at the same time you shouldn't expect as much polish from 4.2.0 as you would from 3.5.10 for example.

Kickoff Menu

Looks like there can be only "love or hate" with the new KDE4 menu for most people. For most, but not for me. I don't care about the "K"-menu at all as I rarely use it. What I like in the new menu is that by default only "Favorites" tab is shown and that there's a search bar to discover installed applications. This already covers 80% of my needs. Another 20% of my needs is covered by "Recently Used" tab. I visit Applications tab only once after new distribution installation just to check what's new came with an update.


Despite its low value for me, Kickoff menu is a nice change from the traditional one. But, in case you hate the new menu, just switch it to "Classic" style and relax ;)

KRunner

KRunner (Alt-F2) is the natural answer to the question "how to launch applications without fiddling with the menu". In KDE3 KRunner was just the tool to run command. The new KRunner in much more than just a command runner.

While you type, it will search for installed applications, commands in the PATH, bookmarks, contacts, opened devices and so on. For example, this is what you get typing "kon":


You can type whatever you want, and KRunner will ask its numerous plugins to come up with suggestions for you. For example, see what it shows after typing "fonts":


Veteran Mac OS users should have already recognized that KRunner is inspired by Quicksilver - the best application launcher for Mac OSX. Indeed, KRunner developers certainly took ideas from Quicksilver. If you turn on "Task oriented" KRunner user interface mode in the settings, then you'll even have Quicksilver-like UI. Personally, I prefer the command-oriented mode with the input box. First, it is much easier to type things there. Second, it's more convenient with a calculator plugin. Yes, right, KRunner can replace the calculator - just type your expression in the box starting with "=" and get your result:


KRunner doesn't come without problems of course. The minor problem is that sometimes it won't run the command you've typed (doesn't happen too often). The major problem is its discoverability and help.

I think that for the new KDE user it will be hard to discover KRunner itself. The only way to show it without knowing "Alt-F2" shortcut is the "Run Command" entry in the desktop popup menu. It's even harder to use plugins. Some plugins are obvious and do not require usage documentation, but plugins like calculator and unit converter do. For example, there's no description on accepted expression syntax and allowed mathematical functions for the calculator.

Unit converter is even more enigmatic. I spent half an hour trying various combinations of units to find out what it converts and how to do that right. Being a geek, I had some fun, but I wouldn't expect normal people to do that. I think we need to add some help for KRunner plugins. Having an "?" icon next to "i" in the plugin selection dialog appears to be the best place for that. And I don't think we need to write docbook documentation for that - just a window that would show essential usage information is enough.


In any case, do try KRunner. Press Alt-F2 to show it, go to configuration and enable launcher plugins you'd like to use, and spend some time exploring the features. If you used and liked Quicksilver on Mac, you'll like KRunner. If you never used this kind of application, you'll be pleasantly surprised with how useful it can be. I'd say that if you need one more reason to switch to KDE4 - it's the KRunner. It's simply awesome.


Conclusion:
Plasma makes the desktop valuable again. I liked the default uncluttered mode without any icons and I liked the idea of widgets that you can put on the desktop. Unlike 4.0 and 4.1 Plasma in 4.2 is usable and stable (not without minor glitches though).

KRunner is a killer feature. Once you try it, you'll never stop, believe me. In my opinion, KRunner may easily be one of the reasons to switch to KDE4. I only wish it was more prominent and more documented.

As a general conclusion, I should say that after KDE4 I don't want to get back to KDE3. The new Plasma desktop is a huge success and with proper architecture and implementation behind it, I'm sure we'll see even more exciting improvements in the future. And of course, I'm sure that in subsequent KDE releases we'll also see even more polished and ironed out 4.x desktop.

---

I hope you enjoyed this review and I hope I've shown enough to convince that KDE 4.2 is the desktop worth using. It's stable, it looks perfect, it has some killer features like new desktop with widgets, KRunner and window manager with desktop effects built in. No review can cover all goodness that comes with 4.2. Discover it yourself!

Even without all the things that come with KDE4 I would have enjoyed using it. But the real power of KDE lies not only in the desktop. The remaining part is the outstanding set of applications that is shipped with KDE. So, please come back soon for the next part of this review where I'll describe the programs for KDE4 that I enjoy using every day.

I've been running KDE4 desktop since May and I've constantly suffered from poor desktop performance and various graphics card related problems. Now I've solved those problems: I've bought an ATI card. Despite NVidia releasing the new Linux driver and suggesting to tweak several performance-related configuration options, I still decided to go and spend $50 on the new video card. Here is the long story why...

On my NVidia GT8600 KDE4 had several types of performance problems:

1. Slow repainting of windows

When I used KWin as a window manager with disabled compositing (sic!), main windows of KDE4 applications took too much time to repaint themselves upon switching. When I used other window manager (twm for instance :)), the repainting was a lot faster. Measurements showed that KWin suddenly took more than 40% of CPU on window switching. Turning on compositing (aka "desktop effects") greatly improved KWin performance, but compositing was a no-go for me for the reasons I'll explain below.

Status of the problem: could not be solved for me.

2. Slow resizing of windows and plasma applets

That's the problem all people using NVidia cards saw. It was the most severe but NVidia forum's suggestions helped.

I created an autostart script

#!/bin/bash
nvidia-settings -a InitialPixmapPlacement=2 -a GlyphCache=1

and added 3 more configuration options to the xorg.conf:

Option "PixmapCacheSize" "3000000"
Option "AllowSHMPixmaps" "0"
Option "OnDemandVBlankInterrupts" "True"

This all helped to get reasonable performance. Some people report that for them KDE4 flies with such configuration. For me it did not fly. The performance was just bearable, but KDE3 desktop was simply a lot faster.

Status of the problem: almost solved.

3. Slow desktop effects

KDE4 with desktop effects turned on, remind me of running a heavy video game on integrated graphics card :) Slowness, freezes and so on.

Using the newest driver and all options I told about above solved the problem. Once again, almost solved. Virtual desktop switching effects would still freeze times to times.

In any case, I didn't care much because every time I turned on compositing, scrolling speed in Firefox degraded by an order of magnitude. I have to use Firefox a lot these days because I do web development at work so compositing became a complete "no-go" for me. Therefore I didn't really cared much about it being slow. I could be happy if only KWin hadn't got the problems with slow window repainting (the problem #1).

Status of the problem: almost solved.

4. Slow painting in KDE4 apps

This problem didn't depend on window manager or compositing. It was always visible and the most annoying. It was also quite hard to track down and profile.

One example was a listview widget in akregator with a list of posts. I have hundreds of posts there and listview scrolling was too slow for me. Valgrind said that the text painting was a problem. My laptop with old ATI X1600 card (and open-source driver) rendered the same text a lot faster and scrolling in akregator wasn't an issue at all.

Second example was kate also having problems with painting text (see bug report for details). The painting algorithm in kate part may not be ideal, but my system was supposed to be fast enough to counterbalance that. In reality, painting text with the nvidia driver was just too slow and non-optimal algorithm just merely increased the annoyance.

Status of the problem: I was unable to solve it.

5. Corruption of system tray icons

Almost always icons in system tray were rendered with some weird background consisting from parts of other system tray icons. No driver updates and config options solved this problem

Status of the problem: I was unable to solve it.

Conclusion

After several months of self-torturing I decided that it was enough for me. I went to the local shop and got a cheap ATI Radeon 3450 card for $50. It's inferior to my 8600GT but I don't care much because KDE4 just flies on it. And by "flies" I do mean that it's really really fast. All 5 problems I've listed above are gone now. Period. Finita la commedia :)

It's not like things are all that shiny with an ATI. I miss the brightness setting in the driver (with nvidia you could do something like nvidia-settings -a Brightness=-0.4) and Firefox is still slow with compositing enabled. But in any case my desktop doesn't bother me anymore and I can just enjoy using it.

Update:
If after reading this post you think of selling your NVidia card and buying ATI, please note that proprietary ATI driver has at this moment (October 2008) several problems I know and can confirm:

• video (xv and gl) doesn't work with composite turned on - it flickers
• Xorg may fail to properly shutdown leaving only blank black screen
• scrolling is still slow in Firefox with compositing turned on

For me desktop effects are not important at all, I turn them off. Be aware of the problems listed above if you intend to use X composite extension and desktop effects in KDE4.

The PhD saga is officially over today! In April I've got my Candidate of Sciences diploma and today I've received my PhD diploma. Yeah, one of the pros of defending your dissertation in Ukraine is that you get two diplomas for one dissertation ;) And of course the cons side is that you have to wait for governmental approval. The wait time for me was more than 7 months. Anyway, it's finally over now :)

Today was finally the day of my PhD thesis defense! The defense went very well, the scientific council of my university approved my work with 10 votes "for" and 0 votes "against" and was overall pleased with my research :)

So now I need only to do nothing but wait for state examination board to approve the work and issue the PhD diploma.

It's been a long time since I last used Kugar. It's been even longer time since I last developed Kugar. But today was the Kugar day...

Yes, today I had to address 95 envelopes (I'm about to send printed abstracts of my PhD thesis). I had addresses written in the text file and I had to print them on envelopes. What was my solution? Of course to use the report generator and of course Kugar was that report generator ;)

2 minutes I spent writing a simple 10 line awk script that transformed text to Kugar xml format. 5 minutes were necessary to design the template in Kudesigner. And finally 10 more minutes I was figuring out how to properly insert the envelope to my printer ;) Overall, about 20 minutes for the task.

I remember my colleague telling me recently that he went to bed at about 5am because he was printing addresses. I can imagine him copying and pasting from one Word document with the list to another Word document with the envelope :) The fact is that it's only midnight here and I've already printed everything I wanted and can go to bed!

Anyway, I'd like to say that Kugar is pretty cool despite being unmaintained for 3 years. Yes, the software (especially Kudesigner) has now lots of bugs that weren't in the code 3 years ago, but it still remains highly usable.

Kugar's biggest problem is still actual though - nobody knows when to use it. So remember: If you have any data in the format translatable to xml and you want to print it using the template, Kugar is your tool. That simple! No databases (they are supported but completely optional), just two xml files - one with the data generated by you or your program and another one with the template generated by Kudesigner.

PS: if you would like to contribute to Kugar, kick me hard and ask for the recent sources. I've ported portions of the source code to Qt4 already. Also my own copies are more stable and usable than ones in KDE svn. I never committed them because they don't have dependency on KDE libs (they just depend on Qt)

Maybe you know, maybe you don't, but Ukraine is approaching another round of parliament elections. As we didn't have enough elections recently! And once again, three major forces participate and again as arrogant and hostile they are, they try to be good now and evince at least some care about Ukraine and Ukrainians:





But look at the pictures, look carefully, look closely. Maybe you'll see what I can't see there. Maybe I'm blind, but what I see is only lots, lots of white, orange and blue flags that belong to our celebrated political parties. And what I don't see is Ukrainian flags! There're none. No flag of the country and people they are so selflessly fighting for.

These pictures alone clearly show how much our parties care about Ukraine... Imagine how many other proofs we have here ;) Do we need these guys in parliament? Several years in a row my answer was "no!". This year I say "stay away from this country!".

Photos are copyright UNIAN. Links: 1, 2, 3

Sorry for another Scala-related post, but I simply couldn't stand. This language is an unique combination of interesting language features and clear and concise syntax which is so rare in the world of programming languages.

Scala is truly object-oriented. This does mean that everything is an object, even functions. Err, functions you'd ask? Yeah, functions are indeed objects but that wasn't a surprise for me because I've seen and used that in Javascript. But function inheritance indeed was a surprise.

How can that be possible? Martin Odersky gives an example that functions with one argument in Scala are objects that mix¹

trait Function1[-A, +B] {
  def apply(x: A): B
}

Here "-A" means that function that has AnyRef as an argument inherits a function that has a String argument. Take a look at this magical example: ;)

object MyProg {

    def doSmthStr(a: String): Int = a.length
    def doSmthAny(a: AnyRef): Int = a.hashCode

    def compute(function: AnyRef => int) = {
        function("Haha")
    }

    def compute2(function: String => int) = {
        function("Haha")
    }

    def main = {
        // not possible because doSmthStr is of type String => int
        // which is supertype of AnyRef => int
        compute(doSmthStr)

        // possible because doSmthAny is exactly of type AnyRef => int
        compute(doSmthAny)

        // possible because doSmthStr is exactly of type String => int
        compute2(doSmthStr)

        // possible because doSmthAny is of type AnyRef => int
        // which inherits String => int
        compute2(doSmthAny)
    }
}

MyProg.main

Isn't that cool, the function doSmthAny with AnyRef (aka Object in Java) argument inherits the function doSmthStr with String argument and therefore can be used whenever we need doSmthStr. Amazing!!!

Even more amazing is when the return types in those functions are different. For a function to be the subtype of another function we not only require its argument to be a supertype, but its return value to be a subtype. Citing "Scala by Example" book, function S=>T² is a subtype of S'=>T' if S' is a subtype of S and T is a subtype of T'.

¹
Traits are the Scala implementation of mixins. For C++ guys mixin is just a multiple inheritance. For Ruby guys trait is more like a module (the difference is that in Ruby you'd "include" the module into your class and in Scala you'd "extend" the class with a trait).

²
S=>T is a function defined as:

def function(arg: S): T

I've been reading more about Scala discovering more and more nice features the modern language with static typing can bring. Some of those features look to me just as an syntactic improvement over what we already can do with another statically typed languages like C++. For example, pattern matching example from my last blog is definitely what you can do with several AST classes (they need to have type() or rtti() method) and your own implementation of visitor pattern in C++.

But there're some language features in Scala I didn't expect and didn't think about before. The perfect example IMHO is covariant and contravariant subtyping I discovered for myself just a couple of days before.

Think about this example, if we have class B that inherits class A then we can use objects of type B whenever we need objects of type A. So far so good. But what if we have template class X with A and B as parameter types? C++ tells us X<A> and X<B> are unrelated:

class A {};
class B: public A {};
template class X {};

int main()
{
    B *t1 = new B;
    A *t2 = t1; //ok because B inherits A

    X<B> *x1 = new X<B>;
    //error!!! because C++ has non-variant subtyping
    // so X<B> and X<A> are different types
    X<A> *x2 = x1;  
}

Contrary to that, in Scala you can declare that X[B] inherits X[A] and have covariant subtyping or even declare that X[B] inherits X[A] and have contravariant subtyping:

class A {}
class B {}
class X[+Type] {}   // +Type means "covariant"

val t1 = new B
val t2 = t1 // ok, B inherits A

val x1 = new X[B]
val x2 = x1 // ok too because X[B] inherits X[A]

return

Not that some elements of covariance and contravariance of types didn't exist before in familiar languages like C++ and Java. Contrary to that they did, but most likely I woulnd't have learned about them if I didn't start learning Scala which directly exposes those things as language features. Cool language Scala is... I must say, very cool ;)

I've recently became quite confident that choosing programming language is a process that is very similar to choosing what to cook. First you taste something. If you like it, you eat it. If you really really like it you look for a recipe and try to cook it. Same for the programming language. First you see some code in that language. If you like it, you read more about the language, learn its concepts and ideas. If you really really like what you found, you start programming in that language.

What's interesting is that your consciousness is not usually involved in the tasting phase. On the surface it's simple - you either like new thing or not. But I do believe that there's a serious subconscious process involved here that takes into account all your previous experience and tells you "yes" or "no" to this new thing.

I've made several failed attempts to ignore this subconscious decision and force myself into learning things I don't like. Ironically, such first attempt was Lisp and the last one was Haskell. Needless to say that Lisp still means to me nothing more than lots of isolated, sil^^^... (you know what ;)) and Haskell is still for me nothing more than a pure product of pure mind. Once again, no offense to these languages and people using them. That's just my mind that doesn't allow me to like these great languages ;)

Contrary to that, I made quite a success learning languages I liked. The best examples would be Prolog and Ruby. And yesterday I discovered for me another language I liked from the first look - Scala. So instead of working hard on my projects and my PhD, I spent last two days reading about Scala.

And I should say the language is very cool. It implements an interesting mixture of functional and object-oriented programming paradigms but keeps static typing and very clean syntax. For those familiar with Ruby, I'd say Scala often feels like Ruby that is statically typed, has C-ish syntax and implements more functional programming goodies. I think next time I'll come up with a side-by-side Ruby vs Scala comparison.

And finally a little code snippet for you to taste ;) (from excellent Martin Odersky's "Scala by Example" book)

abstract class Tree
case class Sum(l: Tree, r: Tree) extends Tree
case class Var(n: String) extends Tree
case class Const(v: int) extends Tree

type Environment = String => int

object MyProg {
    //uses pattern matching to evaluate the expression
    def eval(t: Tree, env: Environment): int = t match {
        case Sum(l, r) => eval(l, env) + eval(r, env)
        case Var(n)    => env(n)
        case Const(v)  => v
    }

    def main {
        val env: Environment = { case "x" => 5; case "y" => 10 }

        //(x+x) + (7+y)
        var expr: Tree = Sum (Sum(Var("x"), Var("x")), Sum(Const(7), Var("y")))
        //(5+5) + (7+10)
        println(eval(expr, env))    //prints: 27
    }
}

MyProg.main

Today the scientific council in my university approved my work for defense :) so I have only two steps left - defense itself and state examination board approval. Looks like the five-year work finally comes to its end. Whew :)

RailsConf this year was huge. About 1600 people were there who paid incredibly high amount of money for the entry. And (like last year) it was again a show with Chad Fowler playing balalaika (or what was that instrument), Ze Frank amusing auditorium with his keynote and of course Dave Thomas again talking nonsense ;)

What is really noticeable is that Rails community became bigger and more pragmatic. We've got only two talks of "is Rails ready for the Enterprise" kind and both of them were not really about the subject. That's surely a good sign, but that's also a sign that the whole Ruby/Rails grew and will start loosing this aura of cool hacker's toolchain.

Not that I care about that much because I still think Ruby and Rails are powerful technologies that allow us to enjoy what we're doing but... this year is about time to start looking at others. People following Reddit might already have the impression Haskell is going to be the new hacker's toy. And maybe it will, who knows... It looks like in the next year we'll see some articles about "is Haskell ready for the Enterprise?" :) Heh... I'd better start fighting with my distaste for functional programming ;)

I'm sitting here at one of the boring talks at RailsConf and have nothing to do, so I decided to blog a bit :)

Basically Ruby/Rails people are great Mac fans (this Flickr picture). Some of them use Windows. But what's really interesting that there's a number of people who're using Linux here and all those people I've seen have KDE on their desktops. I don't know what is the most popular distro among them, but two Kubuntu addicts are sitting near me at this moment. And that's cool, isn't that :)

Uh, I have discovered I haven't blogged since March. Not that nothing happened, contrary a lot of cool things were in those two months.

First, there's a lot things done in KDevelop. I was overloaded with work and PhD so didn't do any hacking but other guys worked really hard. Dukju continued his crusade against svn ;) Andreas and Matthew dug into version control interfaces and infrastructure like mad.

In fact, they sent so many emails to the kdevelop-devel mailing list so I believe now we beat the nosiness record on what was renowned as a very silent list :) And that's actually great. It indirectly indicates the amount of energy and potential in KDevelop community. We're keen, we're eager and we're kicking :)

Oh, and there's one more thing I forgot to mention about. Andreas got KDevelop working on Windows (see the obligatory screenshot below). So KDevelop is now as multiplatform as possible. Unix, Mac OS native, Windows native is all possible with Qt4 and KDE4! So, if you're still using Eclipse or something like that just because it works for you on Windows, tune up and keep an eye on KDevelop4. We will be multiplatform once we release ;)



Among the cool things happened last time is that I finally visited US :) I never had the chance to go there before, but it looks like my chances grew a lot after I became Ruby/Rails developer at Pluron company. So now I'm sitting at the Oregon Convention Center in Portland listening to the one of the RailsConf 2007 talks! I think I'll blog about RailsConf soon.

Btw, have I already mentioned that Pluron is a cool place to work? ;) If you read this, live in Ukraine and is a cool programmer/sysadmin/designer/QA specialist, drop me a note, we're hiring.

As Thiago noted, the deadline for Google Summer of Code applications is approaching. And I'd like to note that we have not many applications for KDevelop related projects yet. Last year there were about 7-8 (or more), 3 of which were accepted. This year we have 2 applications filled and 1 pending. What does that mean? This means that you have a chance to get your KDevelop-related project accepted. Go ahead!

IDE's are usually created to make things easier and faster for developers. And most of them achieve this goal to some extent. But there is one group of people that has always suffered from IDE's. Those people are application template developers.

Tons of subtle application template formats were invented to bend to submission those miserable souls who wanted to add their little template!

Anjuta requires you to write a nice xml file with template description including wizard page layout options, list of template files, directories and of rename rules. To do substitutions in the template files you have to spend a week learning extremely powerful but also extremely complicated autogen format so you could write something like this or this.

Eclipse makes the process even more interesting. There's no application wizard, there's no template format. When you want something like that, you just have to code it in Java by yourself. Easy, isn't it? Choose between org.eclipse.cdt.ui.wizards.NewCProjectWizard, org.eclipse.ui.wizards.newresource.BasicNewResourceWizard or org.eclipse.ui.INewWizard, subclass/implement, write everything else by hand and get something like I got for KDE-Eclipse

KDevelop3 was not really different. Our first template format required you to write a template description and a perl script with installation instructions. Our second template format combined descriptions with processing/installation instructions to the single file. To make things even more interesting, we did not allow to have subdirectories in the templates, so you had to write special subdirectory creation and file copy instructions when you wanted for example to put the main.cpp into /src.

I created several application templates for KDevelop by myself and found that process too complicated and annoying. So when I was working on KDE-Eclipse I thought of ideal template format and soon figured out that a simple tarball is the format of my dream.

Really, why don't application wizard just extract the tarball and so some variable substitutions? I implemented exactly that: extraction + substitution and that worked better than any of those sophisticated template systems I know about.

So when the time had come to implement the application wizard for KDevelop4 I didn't hesitate and did the same thing again. So from now to create an application template for KDevelop4 you just need to:

• have a directory with your project
• place variables in file names and contents
• write very simple .kdevtemplate file with a description like this one
• and pack it

As an example, take a look at our Qt4 application template in the unpacked form.

Of course, the variables that are not known to the application wizard has still to be declared in .kdevtemplate so that user can be asked at project creation time. But the whole thing is still as simple as possible and I will make sure we will stick to KISS principle and won't harry apptemplate developers anymore ;)

IDE's project management features are what everyone can see. Together with advanced language support features, proper build system support is the most prominent feature that differentiates IDE's from various editors, advanced and not.

And proper project management with proper buildsystem support is hard. KDevelop3 was very good at that. Anjuta only recently got close to what our Automake manager had for 4 years. My KDE-Eclipse autotools plugin did get some attention by RedHat guys after I stopped working on it, but I don't know what happened next. Seems like "fedora eclipse" project now superseded it. So even Eclipse doesn't have something on a par yet.

This all means KDevelop's features are still unique. Especially unique is QMake manager which has no alternatives I know about. After Andreas Pakulat took my qmake parser and vastly improved the manager in KDevelop 3.4, we can open and manage the most complex qmake project - the whole Qt library (both 3.x and 4.x versions).

But the time doesn't stop and KDevelop development doesn't stop either. We always wanted to change two things in 3.x - make it possible to open more than one project at a time and avoid code and UI duplication between buildsystem plugins.

As for today, in KDevelop4 we managed to realize our plan. First, Andreas Pakulat implemented support for opening several projects at a time. Second, we used Roberto Raggi's project management architecture with one user-visible "Project Management View" which displays information from various build system managers. That all grants the popular wish to open many projects and solves code maintainability and complexity issues at the same time!

You can see the current state of things in the screenshot below where I've opened two QMake projects using QMake Manager and KDevelop4 project using Generic Manager (CMake Manager is not yet ready). Looks cool, doesn't it? ;)

"Scripts" menu has been a dark horse of KDevelop since it first appeared. Almost nobody knew what it was and understood what hides beneath it (myself included until recently). But in fact the menu is the only visible hint KDevelop3 has some scripting features.

Those features are not so powerful as in Emacs, but they solve different problem. Emacs has Emacs Lisp to:

• extend the environment
• and automate common tasks.

All modern IDE's I know about use different approach. They have:

• extension system with plugins written usually in the same language IDE was created
• and scripting language or scenarios to automate tasks within the IDE.

You can write plugins in C++ for KDevelop and or course you can write scripts. KDevelop exposes its internals via DCOP therefore the choice of scripting language is virtually unlimited. Either your language has DCOP bindings (like Perl, Java, Python, Ruby, KJS) or it can execute dcop command via shell.

Imagine a C++ project with some parts written in Python or Ruby. You naturally want it to be opened as C++ project to have nice integration but you also want a way to easily run your Ruby and Python programs. When working on Ruby projects, you are able to run currently edited programs. But there's no such option when a C++ project is opened. So why don't we implement that with a script?

KDevelop automatically loads all scripts it can find into the "Scripts" menu. The search path by default is $KDEDIR/share/apps/kdevelop/scripts, $KDEDIR/share/apps/kate/scripts and their user-editable equivalents ~/.kde/share/apps/kdevelop/scripts and~/.kde/share/apps/kate/scripts.

Script has to be an executable file and needs to have a .desktop file with a short description. Our script menu item will be called "Run Ruby Program" and the actual script will be a shell script called runrubyprogram.sh. Below are the sources for runrubyprogram.desktop and runrubyprogram.sh I wrote today:

runrubyprogram.desktop

[Desktop Entry]
Encoding=UTF-8
Name=Run Ruby Program
Type=ShellScript/bash
X-KDE-ScriptName=runrubyprogram.sh

runrubyprogram.sh

#!/bin/bash

#get the name of active file and project
file=`dcop $1 SimpleMainWindow caption`
projectdir=`dcop $1 KDevProject projectDirectory`

#strip "KDevelop" from the window caption to get the real filename
file=`echo $file | sed 's/ - KDevelop//' | sed 's/file:\/\///'`

cwd=`pwd`

if [ ! -z $projectdir ]; then
    #strip projectname
    file=`echo $file | sed 's/^[^-]*- //'`
    cwd=$projectdir
fi

#run current file with ruby in KDevelop
dcop $1 KDevAppFrontend startAppCommand "$cwd" "ruby $file" "false"

As you can see, two DCOP calls are made to get the name of currently opened file and project directory and one DCOP call to execute a command inside KDevelop. Each DCOP call is a call to some part of KDevelop which exposes methods via interfaces. For example, startAppCommand is a method of KDevAppFrontend interface. There's no documentation about what is exposed, but just run kdcop tool to explore the complete list of interfaces and their methods and check how they work.

When you save your script in ~/.kde/share/apps/kdevelop/scripts and restart KDevelop, you'll be able to run your ruby programs having a C++ project opened like shown in the screenshot below.


PS: this post was inspired when I was reviewing the KDevelop wishlist named "Unable to execute Python scripts in a C/C++ project".

PPS: I do believe we can make scripting more powerful and easier with KDevelop4 and we have two great technologies - QtScript and Kross for that... but this is another story ;)

I know I promised to blog often about KDevelop4 progress, but I did not intend to write one more post today ;) The reason I'm doing this is that someone came today to #kdevelop IRC channel and asked whether we can open more than one embedded Konsole toolview in KDevelop. Of course my answer was "no sorry" because in KDevelop3 the usual modus operandi is 1 plugin => 1 view.

But this is not the case in KDevelop4 anymore. During architecture rework that was done by yours trully and Andreas Pakulat we introduced so-called "toolview factories". So each KDevelop4 plugin now registers a toolview factory and then the shell application uses the factory to add toolviews when necessary.

Until today, factories were used by mainwindow only once and only one toolview was visible on the screenshots from my previous post. Today I though that nothing prevents me from implementing a nice dialog to add new toolviews. After several minutes of hacking (actual view creation is only 2 lines of code thanks to Sublime library, everything else I committed was the UI for the feature) I got this:




As you can see, there's no restriction anymore to the number of toolviews. You want 10 konsole's - you'll get them! Also Qt4 dockwidget management system allows to group dockwidgets in tabs so some toolviews can be nicely kept together.

Ok, that's all for today. Next time I'll leave UI and tell you about project management in KDevelop4. Stay tuned...

It's been a long time since I last talked about the progress on KDevelop4. This has to change ;) I'll try to keep everyone informed about recent developments in KDevelop4.

Last time our new user interface concept ("Sublime") was covered in commit-digest article. At that time only the sublime user interface library code was available. Today we have two major UI design decisions implemented.

First was the support for areas (the KDevelop's name for perspectives). Area in KDevelop is the set of views (documents) and toolviews (docks). At this moment KDevelop has only "coding" area, debugger and design areas will be used once respective plugins are ported to KDevelop4.

Second major design decision was multi-mainwindow operation. KDevelop3 with its only one mainwindow and non-detacheable toolviews was hardly optimal for dual monitor setups. KDevelop4 allows to have as many mainwindows as necessary.

The interesting thing is how multiple mainwindows and areas work together. Of course, different mainwindows can have different areas. Basically opening one more window with "debug" area will be the default way to do debugging. Same for Qt UI design - you will have new mainwindow with "design" area to work on Qt .ui files.

But that's not all we can do. Eclipse pretends it can show one perspective in two or more mainwindows. KDevelop4 now does that as well, except that it doesn't pretend the area is the same in all those mainwindows. You can duplicate mainwindow with "coding" area but what you get is cloned area called "coding (copy)" shown in the new mainwindow. This means all view/toolview layout and settings belong to the new cloned area so no confusion happens when you close your windows and save areas.

In the screenshot below, you can see one KDevelop program with three mainwindows. The background window shows "coding" area, two topmost windows show the clones of "coding" area with different view/toolview layout. So nothing will prevent from using KDevelop in dual-monitor setups anymore. "New Window" action from the window menu will duplicate the mainwindow and clone its area as necessary. The cloning operation is relatively cheap, resources are used just to create a new mainwindow and views inside it. No KDevelop plugin is loaded for the second time.

Toolviews that use plain Qt4 dockwidgets with no hacks are handy as well. Unlike KDevelop3, you can dock/undock and close them completely.

Splitting is of course in place too, but with slightly different logic than in KDevelop3. Now it behaves more like Kate when current view under the cursor is splitted rather than the whole region with views.

Don't bother looking at combobox that we currently have as a way to switch between views because it's our temporary replacement for a tabwidget. Everybody knows that tabwidget doesn't scale when lots of files are opened and everybody hates QTabWidget for extra bevel and border. We hated tabwidget too so we had to avoid it ;)

All that is implemented in KDevelop4 shell in <200 lines of code ;) Ok, ok, another 3k loc reside in Sublime library :) Sublime is the fourth UI library KDevelop uses and the third one I wrote. And I do hope it will be the last one. This time I believe I got it right. At least the code is surely better than infamous KMDI library and Sublime certainly is more capable than my previous NewD aka SimpleIdeal and Ideal libraries. Also this time the I wrote an extensive test suite to guarantee that UI is stable and bug-free.

So, enjoy the screenshot and don't just wait for KDevelop4. It is high time to do an IDE right and we know how to do that this time. What we need is you :) Join us to create the IDE of your dream!