Take a look at the following screenshots:
This demonstrates one of the problems I have with KDE, there’s no consistency in the implementation of tabs in the user interface, unlike in GNOME where the comparable applications all use the same widget for implementing tabs. More precisely, KDE’s web browser and it’s file manager, respectively rekonq and Dolphin, implement them correctly. The text editor Kate uses a different widget and Konsole places them on the bottom of the window. That is very uncommon, besides Konsole I’ve only seen some IRC clients do that, so it breaks with the user’s expectations. In Kate tabs aren’t even enabled by default, but they’re an optional plugin shipped with it. Kate uses the annoying ‘Documents’ sidebar as a replacement for tabs.
One wonders if this design of Konsole and Kate is intentional. After taking the screenshot for KDE I figured out that there is a second plugin for Kate for tabs which is also included by default. For the screenshot the ‘Tab Bar’ plugin was used, but the ‘Tabify’ plugin implements a tab bar widget identical to the one in rekonq and Dolphin. I filed bug #254596 to request that the old ‘Tab Bar’ plugin be removed and is replaced by ‘Tabify’ and I filed bug #254599 to request that the Tabify plugin is enabled by default. The Kate developers don’t agree with both of my requests, but if I consider the use cases they are targeting I can understand. While I still think it’s not ideal because the default settings should be sane – the minority (I assume) of users which need the document list instead of the tab bar because they have a lot of document opened should change the default settings, not the other way around – at least it’s possible to configure Kate the way I want. At that point you’ll stumble on bug #156330 which is about Kate forgetting settings unless you save the session. That should be solved in the future according to the developers.
My last gripe is the split view feature of Kate, which allows you to split the view so you can display more than one document in one Kate window. Ideal for the common wide screen monitors of today , and it allows you to read multiple documents at the same time without switching windows or opening multiple instances of Kate. However, to change the document displayed in the different views, you have to place the cursor inside the view (document) first, then switch to another document with the document list or tab bar to make that view display that document. This is also different from split views in Dolphin for example. In Dolphin, the split view is a property of the tab, I can have one tab open with a split view and the next tab can display just one view. So that’s the other way around compared to Kate, where the split view is not connected to the tab but is independent of it. See the screenshots to understand. I don’t necessarily want Dolphin and Kate to behave identically, but what would work best for Kate would be that each split view would have it’s own tab bar. I noticed that Konsole does exactly what I described, as you can see in the screenshots. I have filed a feature request as bug #255096.
So Konsole does use the default tab bar widget but places the tabs on the bottom. Here a three year old discussion can be found on the merits of placing tabs on the bottom or the top for a terminal emulator application. While at first I thought it would be better for the sake of consistency to have tabs on top of Konsole’s window, tabs on the bottom do make more sense if you consider that text scrolls downwards on terminals. I’ve come to the conclusion that the latter argument is the better. Consistency after all is only a means to work more efficiently, not a goal in itself. While I don’t use Konsole intensively, I’d probably experience that tabs on the bottom are more efficient if I’d work more with it. Also note that it’s possible configure Konsole to display tabs on the top of the window.
Besides that, I was affected by an annoying bug on Ubuntu, so I started searching on Launchpad if it had already been reported. I found bug #631664, but I also found three other bug reports about the same problem. So I, as a good citizen and aspiring bug triager, I marked those as duplicates of the aforementioned bug. Can you imagine the shortage of human resources if those duplicates don’t get noticed? I’m not dissing Ubuntu or Canonical here, but even though this is relatively common bug, there must be a lot more potential duplicates to be found. Some people don’t search for existing bug reports before they file their own (duplicate) bug report, sometimes they do but they use the wrong search terms so they don’t find the existing bug report (the latter happens most often to me). With all those potential duplicates, you can see the bug reports database getting clogged up. This made me remember that some people proposed all bugs to be closed in KDE’s Bugzilla around KDE 4’s first release. This didn’t happen, yet in general the number of bug reports is still growing, stable, but certainly not decreasing fast according to the statistics of KDE’s Bugzilla. I wonder for how long it can continue?