Often when I follow discussions on KDE on the internet I see people mentioning that they think that KDE-devs do not care about bugs and only about features. Also often mentioned is that applications aren’t polished. Well in fact then there are also people who disagree on this asseration.

So this time instead of "new features" I show you some polishing work that I did lately. In fact I do that quite often (mostly for KGet) as do most other devs I know. Just because polishing achievments aren’t blogged about that often, doesn’t mean that they don’t happen.

Same is true with bugs. Just take a look at bko and the statistics there, especially compare that with the last few years. You’ll notice that the number of bugs stays mostly constant in total despite all the new features and new programs and that there are people fixing them like crazy.

KGet

First of all after the last blog entry I still improved the speed in some areas, now (4.6) adding many urls to KGet is blazingly fast. The interesting thing is that all the profiling work started because of a bug entry. A user reported that KGet crashed for him when trying to download 602 files, he also mentioned that it was quite slow with that many files.

This rather parenthetic statement — and in fact the hope to reproduce the bug — triggered me to try it myself as I never downloaded that many files at once before. And well I was shocked. So I started fixing that step by step what took many seconds before takes less than one now and is hardly noticeable. Baseline is we do care about our users and that reporting bugs is really important.

Now there was one thing that annoyed me and Lukas to some degree. Adding Transfers to KGet is not always consistent — and still isn’t now, because we have to keep our DBus-Interface — different dialogs would be displayed. And what I did not like is that if you had existing transfers or files you’d get a dialog for every such occurence. When downloading the 602 files this could get annoying if I forgot to delete them before.

So here you go, now you’ll get one dialog for Transfers with the option to "Yes All" or "No All". Now you have to know that KGet does not ask you for a location for transfers if one is specified already (e.g. via settings in a group), so if a location exists already you’ll get the dialog you know already from moving files around in Dolphin.

In the case that no location has been specified you will see a dialog with all the files you want to download and a location pre-selected. Once you come that far you won’t be bothered with any dialogs. Instead all the information is displayed in the existing dialog.

Yes you can’t rename those files now, but you could choose a different location. Still having a little option less in this case is imo better than having to constantly deal with dialogs. Maybe I’ll simply add another column with the filename, there you could specify it and also an auto-rename-button. Though that is something to think about.

General

In the above case I mentioned that I do not really like dialogs — despite using them quite often, yeah not easy to do without them 😀 — but what I like even less are dialogs that make me fear of doing something wrong.

The Dolphin rename-dialog was one of those and many dialogs I created in KGet were such too and many still are. Often you don’t think about the problems and often you don’t have the time to fix them.

So now, what was bad in the rename-dialog? It allowed you to press "Ok" if no name was entered, and if the name was not changed.

Especially the first case is confusing. What would happen if you press "Ok"? Would the file be renamed to nothing and cease to exist? If you tried you’d realize that nothing would happen but you would be informed that renaming to nothing is not possible. Yet why should you try if you are unsure? The whole situation could lead to you being extra careful at this operation and having an uneasy feeling, even though you could basically do nothing wrong. But you’d only know that if you risked doing something wrong.

What I changed is that "Ok" will be disabled if the name was empty or not changed at all. In fact you could argue that the same uneasy feeling applies to if you rename the file to another existing one by accident and I agree though have no solution for that yet.

Spell Check Runner

I was fixing a bug for this runner and then I thought about a feature that I could implement. Now I mentioned above that this is not about features but rather polishing. Though often polishing means adding small features that make the user’s life easier.

Imagine you are me, so you speak German and have your locale set to German. Yet you want to know if you spelled "coding" correctly, So you fire up krunner and press "spell coding" and this is what you get:

Now you’ll realise that it will use a german dictionary by default and not the one you want it to use at the moment. You also wonder what all those suggestions have to do with the term, but that is a different matter. Now you could fire up KWrite, change the spelling locale and then see if it is correct, or you’d search for that term on google and hope that it would recoginse any mistakes. Both cases are not comfortable. What would be great though was if "spell en coding", "spell englisch coding", "spell englisch coding" or "spell en_US coding" would work.

Guess what with 4.6 it will:

You probably have noticed that I wrote "englisch" instead of "English". Simply because "englisch" is the German word for "English" and since I have the German locale set it expects me to enter German words.

Now when you stumble over a different term like "Sackerl" you try it again, though you fail, since that is an Austrian specific term, you change the input to:

In fact if you don’t have the correct dictionary installed it won’t work:

The solution to implement support for language names in the users’ locale is a little hacky, so it won’t recognise any terms you throw it at, e.g. "austrian" or "österreichisch" would not work, in those cases you have to use the iso form "de_AT" for example.

Shell Runner

Here again I was fixing the shell runner and did a small polishing improvement. Now when clicking "run as different user" the focus will directly go to the input field for the user-name. One click less and exactly what a user wants to do when pressing this option in the first place.

Conclusion

So a small feature as in the case of the spell checking runner can make an existing (great) one a lot more useable and makes it more complete. And that is polishing for me. Makeing something existing complete. Be it by little refactorisations of the UI or by adding a small feature that held the original back. All this are things the KDE devs do on a regular basis, they often just don’t report on it.

A way to realise that would be to use the newest KDE version for a long time and then move to an older version, but I am sure you don’t really want to do that. 🙂

Share this: Twitter

Facebook

Like this: Like Loading... Related

Tags: KDE, KGet, Krunner