Last November, KDE 3.5.0 was released. Since then, many users have been waiting for the next big steps. While most of the core developers are working on the first iterations of KDE 4, the KDE 3 developer platform is more vital than ever, resulting in new and exciting applications. "All About the Apps" puts the spotlight on the classics of KDE's applications as well as new and promising applications from the KDE community that can make your KDE desktop more productive. We will also keep you informed about development in current KDE 3.5 series.
New rules in the KDE 3.5 release cycle
Until KDE 3.5, when a KDE release was frozen in preparation to be released, new features, and new user-visible text (strings) were not allowed in the later releases in the series, in order to make sure that no new bugs were introduced and no translations were broken. For KDE 3.5 this has been changed slightly.
Since the KDE 4.0 development cycle will take longer than usual due to the
scope of the changes and improvements being undertaken, the developers want
KDE 3.5.x to be the best possible KDE for users in the meantime. Therefore, KDE 3.5.1 and 3.5.2 not only fixed a lot of bugs (see 3.5.1-fixes and 3.5.2-fixes), but the developers were also allowed to change some strings in KDE so that many usability-improvements and updates in documentation found their way into KDE 3.5.x.
KDE 3.5.3 will even include some new features. When a new feature is already in the upcoming KDE 4 code, well tested and known to work in KDE 3.5, the author of the code can ask for inclusion in KDE 3.5.3. If no other developer objects, the new feature can be added. Therefore, you will see some new stuff in KDE 3.5.3 (this list is constantly being updated and not yet complete).
Artwork
KDE-Look.org features many new themes, colour schemes, KDM themes, new icons, improvements to Kopete styles and many other artworks. If you want to pimp your desktop, kde-look it is the place to go!
Fast Forward with amaroK
Many people already know that amaroK is the best audio player available. Version 1.4, of which Beta 3 was just released, takes this even further. With the help of a new artwork team, amaroK has a great new look, including new icons, and introduces moodbar: the first audioplayer to support this new way of representing your music!
The improved media device system allows many more devices to be supported, as well as vastly improving the handling of iPods and iRivers. There have also been major improvements in all supported audio engines, including support for extra codecs such as WMA, MP4/AAC and RealMedia (RA,RV,RM).
Tellico: Keep your collections in Order
In February 2006, Tellico 1.1 was released. Tellico is a KDE application for organizing your collections, be they CDs, films, files or books. Version 1.1 brings you many improvements over 1.0 which was the latest version when KDE 3.5 was published.
Version 1.1.4 is quite an improvement compared to version 1.0.x which was the
stable one when KDE 3.5.0 was released.
RSI-Break: Stay fit
Repetitive Strain Injury is an illness which can occur as a result of working with a mouse and keyboard. With the new tool RSI-Break your are reminded to take a break now and then. In the last month, development has really picked up speed, so now you can enjoy version 0.6 with many new features.
Kaffeine: Multimedia all around
Kaffeine is the Xine-based media player. The authors just released Kaffeine 0.8. Compared with the previous version (0.7), many new features have been added and the user interface has been revised. Of course, Xine itself is constantly improving, so that you can expect an even better multimedia experience!
K3B: Hot stuff
What is the tool for burning DVDs and CDs in Linux? Most will probably agree that this is the famous K3B! In the past few months the author has published several new versions of K3B to provide you with the most stable burning tool ever. The changes included are far too many to be listed here, so just have a look at the extensive ChangeLog
That's it for this week. If you have a favorite application, please propose them in the comments section. If you want to stay up to date with new cool KDE applications, look at the list of latest KDE applications.
Comments
It's sad to see my loved amarok doing it so totally wrong to include an iconset own its own. That is so contraproductive in order to get a good desktop experience.
Welcome to the Windows world, where every application delivers its own icons.
I don't want that, listen!
> I don't want that, listen!
Stop your Gnomish FUD and read the amaroK changelog:
"amaroK now has a custom icon theme, and an option to switch back to the
system icons, if preferred (in the General settings section)."
You really don't get it, do you?
It doesn't have anything to do with FUD...
Please consider reading:
http://amarok.kde.org/blog/archives/80-Arrrr...-Artwork!.html#c1685
You really don't get it, do you?
AmroK has a cool design consisting of custom colors, custom widgets, custom layout and custom icons. If someone wants to switch back to the KDE-standrad-icons he can do so. Same as with amaroK's color theme.
In short: It doesn't match the desktop. Exactly the custom stuff (e.g. the vertical image on the popup menu, the mouse-over effect on the sidebar tabs,... is, what makes Amarok a playground, than a nicely (graphically) integrated application.
To some, this is cool design, to others it simply sucks.
well, personally i am torn between these two reactions. on one hand, i think it's cool. on the other hand, i don't like it if amarok looks totally different. i don't use the custom colors, nor custom icons. that's too much for me.
I like it both ways. On the one hand, amaroK is a great way to try out new graphical schemes before you build stuff for the whole of KDE. On the other hand, it can be a bit of a pain having those different icons.
I think that amaroK should have the default KDE icons, and then let you change the icon theme to whatever you want.
Why not make the amaroK's eye-candy available to all KDE apps by integrating them into KDE-artwork?
In fact, Sadro Giessl, author of KDE's Plastik theme and of the new SVG-based coKoon theme is thinking about doing just that. Read what he had to say in a message to the Compiz mailinglist:
"""
Currently, the library [coKoon] is based on Qt4 and I aim to integrate it into KDE 4 (window decorations, widget styles, maybe replace "hardcoded" stuff like the Amarok eyecandy). A theme editor application is planned as well.
"""
http://lists.freedesktop.org/archives/compiz/2006-April/000019.html
> Why not make the amaroK's eye-candy available to all KDE apps by integrating them into KDE-artwork?
Because it's looking ugly. Matter of taste. :p
Or to phrase it more politcal correct: As long as it remains optional...
Although I do like the new icons for amarok. I find it annoying that they've included their own icon set. One of the reasons why they don't want skin support for amarok is because they want consistency with kde, or at least they did. Although a custom icon set isn't as drastic as skin support, it still goes against one of their so called goals and reasons to not include other certain features.
Stop calling usability on things that have nothing to do with it! Go read a HCI book, please!
And now, to be more on topic - If you have ever used an icon theme that is not Crystal SVG, Noia or one such shiny icon set, you will have surely noticed that the icons included are utterly and totally out of place. This way it is ensured that the application is consistent WITHIN ITSELF!
There is an option to turn on system icons, which will cause the icons to be wrapped and existing icons to be used. Trust me on this - we are taking every care in the world to make sure that these icons make sense; as an example we spent a couple of hours yesterday trying to find two icons, for podcast and new podcast, that would make sense. We gave up then, but we shall try again later today.
P.S.: If you named yourself, we might consider your points. Anonymous Cowards are useless - we have no way of considering who you are and why you make these statements. Context, my good man/woman/person/entity/nothingness! (see? even that bit is impossible to do when you don't know who you're talking with)
you do not really want to say that you weigh arguments by who gives them? this can get ridiculious. sources are a hint, but no proof.
Pseudonymity is just annoying.
And who the heck is "Dan Leinir Turthra Jensen" anyway? And how do I even know you are it/he/she?
Names are useless without digital signatures.
I find it shocking that so many amaroK core developers agree with having those custom icons by default. I already made my points on the blog, so I won't repeat them here.
Just a question: As you can clearly see, there is quite a bit controversy about this topic. So, as I would do it if I wasn't sure if this is a good idea (given the opposing statements you must not be sure about it): have you asked the KDE Usability Team for input?
If you haven't, please do so. I'll be quiet when I read a statement from Ellen, Celeste or someone else there that actually agrees with this move.
Please see (and vote for) bug #121715 regarding the icons-topic.
After you've read my original text, please read the first comment as well, as it is important to the whole thing.
Although I'm not fine with those custom icons, I'd like to thank the amaroK-developers for this fine piece of software.
Keep rocKing!
That bug is about the moodbar.
Sorry, I had the wrong number in the clipboard...
The bug number is wrong, it is http://bugs.kde.org/show_bug.cgi?id=125295
Let's vote for it and show the amarokkers that we do not want this!
Agreed.
It's very sad that one of the up-and-coming best known *KDE* applications is going against a few vital KDE principles (this is totally regardless of whether it has the "option" to go to KDE's normal icons). Having it on by default (and this is the key point) is palpably directly detrimental to the internal consistency of KDE (which ships Crystal icons by default).
One thing KDE primes itself on is integration; it's very sad and unfortunate to see that one of the popular examples of KDE software breaks such a principle.
As aseigo put it: http://amarok.kde.org/blog/archives/80-Arrrr...-Artwork!.html#c1685
KDE has so much potential if it can clean up its UI more. I think the best route here is first-run wizards that set important options like these, but really, the defaults should be a simple, consistent, uncluttered default.
I don't think it's so bad. I liked my music application looking different and that's why I used XMMS for so long, it's like saying Karamba themes are bad, because they are inconsistent, well eye candy won't be, because nobody can produce whole desktop in Linux environment so easily. On the other hand those icons just suck, please don't take it personally, because they are monochrome and they handicap usability, that's why I turned them off.
That is a fine initiative, and it's well done.
For the next editions, I suggest to let KDE users discover good but not very well known applications. I know three of them :
* Basket (wow, innovative and useful http://basket.kde.org . Don't cover the stable version 0.5, but the much better 0.6a1)
* KPhotoAlbum (see http://ktown.kde.org/kphotoalbum/videos/ )
* KIO from a user point of view (why you don't need a clumsy FTP/SSH client in KDE)
Basket: Yes, that is a good tool. http://basket.kde.org/development.php looks like 0.6 will take quite a while, though. Not sure if it fits here... Perhaps for the last issue.
KPhotoAlbum: Not to much activity in the last few month (beside its renaming from Kimbdaba)
KIO: Not sure if this fits into this series of articles. Perhpas this is more for something like "poweruser tipps for KDE 3.5"?
Great idea, and so true 3.5 is all about the apps:-) And looking at the commits to svn 3.5.3 are going to be one solid release.
Anyway, for future edditions what about:
Ktorrent
DigiKam
KMyMoney
kdissert
KTechlab
Digikam (0.9) is already written. Thanks for the other suggestions.
Is it ? Then, can its plugins (libkexif, kipi-plugins) be compiled with the visibility flags now ?
Because the "stable" versions are very old, and they will just not provides all the API if compiled with gcc-visibility flags, which I have to disable by hand (as there is no configure flag to disable the visibility flags).
Learnt this the hard way when my wife said she lacked lots of functions in Digikam.
Don't get me wrong, Digikam is a wonderful app, the dependancies are just lagging behind.
Ah, also, some french guy said he had done the fench translation of the doc, but I never found it in 0.8. Is it there in the 0.9 ?
Thanks
0.9 is the next stable release, it is already working very well and should be released soon (not next week or so, but soon, read http://www.digikam.org/?q=node/116). Here is a gallery showing new things in 0.9
http://www.digikam.org/?q=image
And even more:
KAT
kBeagleBar
Kerry
KMPlayer
Krusader
Scribus
Kile
Ktorrent
I'd rather see it disappear and be replaced by a torrent:// KIOslave, so you can just use kget for torrents. Or at least merge Ktorrent into kget, as for the users perspective there's no difference.
I beg to differ, it's a rather big differnce both from a users perspective and from implementation and thecnical point. You don't make KGet handle your ftp uploads either.
There are no particulary good way to solve the upload/seed functionality, in a simple userfriendly way fitting with the userpattern of KGet. Either keep it seeding for some time, and have the users wonder and complain why it don't shut down like with all other forms of download it handles. Or have it shut down after the dowwnload is complete, and end up being baned by most torrent tracers.
Personaly I don't get peoples obsession with merging everything remotly similar into the same application. Some tasks are better left to specalized tools or separate tools due to different usagepatterns.
Well, the users klicks on a torrent and expects the file (xgl demo cd in this case) to be downloaded. Kget could do that via ftp or torrent. When it's done just keep seeding the file until the user moves it away or unlinks it, inotity should be able to handle that, or deletes it from the download list of kget.
And you're right, ftp or fish uploads are smth else, they should still be shown by the normal kfile transfer status, just like local actions.
It's just I don't like to have two apps with nearly similar functions and most users don't care about the upload part of torrents so this should be handled automatically (but of course still be configurable). You could even include jigdo downloads into kget, so it just acts as frontend to jigdo.
No, the user should knowingly decide how much he wants to upload in return. Maybe he's short on bandwidth or he pays for the amount of data transferred: in this case, he could choose to upload very little.
Maybe, OTOH, he's got a nice bandwidth and wouldn't mind helping during the night, when he's asleep anyways.
Finally, maybe the torrent he got came from a community that enforces good upload:download ratios. In this case, he'd better stay close to 1:1.
None of those options are available in KGet/KIO nor will ever be. They are really torrent-specific and should stay in a torrent-specific client.
Yes, Basket is certainly not yet ready for regular user consumption. When it is ready though, it will be quite the app.
As for KIO, I've always felt that the way KDE implements it is somewhat troubling. There is all sorts of functionality in there that most people would never know existed. Fish is of course the killer ioslave, but would ever know to type fish://user@localhost into their location bar, or a save dialog for that matter? This stuff is great, but only if you can discover it. I can't tell you how many times I would've loved to have a list of the ioslaves that I could use. You can find a list in the protocols screen of konqueror, but not all of those are user accessible. Anyway, there is so much great functionality in KDE, I just wish it was more obvious.
Just out of curiosity, why use fish rather than sftp?
No reason, other than I know about fish and didn't know about sftp. Also, sftp doesn't seem to be installed on my system.
The point was, how would somebody find out about this?
you could google it, but that would require that you know it exists in the first place. KDE is great on functionality, it can just be kinda hard to find out about it.
fish requires ssh + a shell on the remote side. sftp requires the sftp subsystem to be enabled on the remote side's /etc/ssh/sshd_config.
I have seen issues with it from time to time. It is now last resort. Instead the sftp always works if ssh is on the system (rarely have I seen an install include ssh, but not sftp).
That's why, if you go to system:/ and click "Remote Places", you'll see an "Add a Network Folder" wizard that lets you create that kind of URL.
But it's intended for the novice user: not many features are possible in the wizard. If you're advanced enough to notice what's missing, you already know how to type them in URLs.
Unfortunately, I don't see any improvement for the media KIOSlave.
This is very important : will the next KDE support the latest hal version, which does not provide mount points (through modifying the fstab) ? Or is pmount/gnome-mount the only way to go ?
Kde media:/ kio support pmount/hal since months...
yes, but nothing else supports the media:/ protocol correctly, all the stuff downloads media:/ content to temp, but that's not smartiest way thru imho..
(or perhaps one? very rencent kaffeine?)
if kio downloads stuff to /tmp, in stead of opening it directly in the appropiate kde-application, you should check the mime type or kmenu entry of that kde application: make sure that the command that launches the kde application contains the argument '%U' to tell kio that it can handle URL's by itself.
(e.g. make sure that the kmenu entry of kaffeine has 'kaffeine %U' as startcommand, not just plain 'kaffeine')
The KIOslave does not support the last hal : when you click the icon, it can't mount it itself, it complains that the device is not in fstab nor in mtab.
Which is a big problem to see the content of data CD and DVD.
pmount/gnome-mount are external programs.
yeah, hal breaks compatibility every now and then. so you'll have to wait for a new KDE minor release (3.5.x) to fix it.
>>Unfortunately, I don't see any improvement for the media KIOSlave.
Try KIO-FUSE:
http://wiki.kde.org/tiki-index.php?page=KIO+Fuse+Gateway
Pretty on the website but don't work in amarok because they are not defined when small. The pause button resembles the stop button too much for example.
Yeah, we're aware of these issues. The icons will be reworked to provide higher contrast.
The colors in the moodbar look horrible.
I think that you really need to choose better colors for it. And of course it would make sense to "filter" the view. Right now it just looks noisy due to its appearance. As defining the mood by exact values is a rather "ambigious" attempt and as the whole graph can only be a good well-founded guess it wouldn't harm to noise-filter the graph to make it look more beautiful.
Of course eventually it should be the aim to have some icon or label instead that translates the graph into something a common user understands instantly.
There is an option to change "moodbar theme" in the configuration dialog. At least there was one when I last checked. The reason it's unthemed by default is because an unthemed moodbar makes more sense (I.E. it's easier to get something out of it, if anything...).