KDE convert Diego Calleja explains Why KDE Rules by showing off some of its power features. He starts by dismissing some myths about KDE then tells us about the application that brought him to KDE, amaroK. Power features explained include KParts, DCOP and KIOSlaves. "I wrote this document to tell everybody why KDE is great, why it's worth using (great functionality), supporting (great development platform) and hacking (great design) and why you can expect many other awesome features from KDE 4."
Dot Categories:
Comments
Having used kde for quite some time, doing some minor development as well, reading this makes me wonder if any glory is still to gain here. Is it time for something new (or how to keep developers interested)?
One word: QtRuby.
Yeah, absolutely. Ruby brings back the fun to coding, it's a perfect match for KDE. It's just a matter of time until we'll see a huge KDE app written with Korundum. In fact it's so tempting that I'd like to participate, just looking for some nice ideas ;)
Thanks for the positive comments about the ruby bindings. I'm looking forward to seeing what people will do with Korundum - it should be possible to write apps which couldn't be done at all in C++. For instance, dynamically accessing SOAP or REST services is much, much easier in ruby - that's one possible 'killer feature' for KDE ruby programming.
You can use QtRuby/Korundum with both the Eric3 (from 3.8 onwards), and Kdevelop. They both have graphical ruby debuggers and integrated support for Qt Designer .ui files to ruby code. The version of PyQt/PyKDE with KDE 3.5 has support for QScintilla ruby syntax highlighting which you need for ruby support with Eric3.
KDevelop has ruby KDE project templates which allow you to write 'proper' KDE apps, that can use resources like icons or .xml KDE gui files, and which you can start from the KDE menu.
Instead, why not make SOAP and REST service
much much easier to program in C++/Qt/KDElib =P
Just my 2 cents.
amaroK 3.0 in Korundum. Let's do it. :)
And another word: PyKDE. If KDE4 still depends on Python (by using SCons and bksys), it would be cool to be able to guarantee the PyKDE/PyQt bindings will be present on a system with a KDE install. I know it's one of the factors that holds me back when i'm thinking about writing a small KDE application.
I can't help but think that KDE would benefit if the barrier required to enter was lower - more focus, promotion, and documentation for development in higher level languages like Python or Ruby. This is somewhere where KDE could really take the initiative.
Bksys/Scons is just a build-time thing, so KDE4 won't depend on python.
But I agree, having like Korundum in kdelibs would truely give developers the freedom to code in the language of their choice.
Good point. Well designed interpreted languages like Python and others are a blessing (or they should be). Why ? Because I think there are many developers who have, say, one hour a day to contribute to an OS project. This is hardly enough with a compiled language, where getting the sources, recompiling, etc. takes a long time. But it should let you make serious contributions if you only need to get latest svn and then start coding immediately, and see the results immediately, and then push the cahnges to svn.
And, for many, many applications, it does not mean a performance penalty, provided that the dirty work is done in c++ (by the Qt/KDE libs).
Cheers!
Sorry but I just can't agree with you here.
Starting out with a new project might be easier in agile languages and of course each language has its strong points that makes certain things really easy to do compared to others, but I think that if you work on an existing project you can fix the same amount of bugs or add the same amount of small features in an hour in C++ as in Python or other interpreted languages.
In my experience as a occassional bug-fixer / small-feature-adder for some OSS projects written in C++ (non-KDE btw) you hardly spend any time compiling after the first time so it's absolutely doable.
So I don't think it necessarily better, easier or faster using agile languages instead of C++, what I do think is that it has a lot to do with using all available resources and knowledge. The fact is that there are a lot of developers out there that don't know C++ and (for all kinds of reasons) have no plans to learn it either. All those developers are basically "lost" to KDE and I do think it could help KDE greatly if we could get some of them to spend their time on making great apps.
he could have used Quanta, another great KDE project.
Only if it doesn't crash for so long!!!
And the bug report number is...
Yes, VPL is not that stable, I know, still we try to fix it. But in source mode (which is the big power of Quanta) I would be interested to see a crash that is
Quanta's fault.
Well, VPL is the most important part of Quanta. Doing things visually with little knowledge of HTML (well, I know some basic html 4.0) is where NVU rocks.
> Well, VPL is the most important part of Quanta.
This is a little hard statement, especially that:
- VPL is here for not a long time (so it never was a central part, nor it is)
- VPL is only for (X)HTML, while Quanta is for much more
- from the feedback we (developers) get, source editing (HTML, XML, PHP), user actions, project management and things like that are more used than VPL.
But I understand why VPL is important for newbies, and we want to make it really usable, so again, report the bugs and we will try to fix them.
> from the feedback we (developers) get, source editing (HTML, XML, PHP), user
> actions, project management and things like that are more used than VPL.
Well, isn't because VPL sucks (so far?) -- I would love to use it, but it is just such bother, that I usually switch to source code. Program which would provide completness of HTML-editing of Amaya with human-useful interface would be most awesome!
Matej
VPL does some things good, like adhering to your DTD and not mangling your entire file to edit one node. As for the rest... Don't forget it relies on KHTML which has also been under heavy development to support VPL. We had to write a lot of code just to find out if some things would even work and the complexity of the procedural discussions will make your eyes glaze over. The first code base of both the KHTML code and VPL was thrown out for the second which is being tossed aside for the third. The third should benefit from some of Apple's Webcore code and it should finally get a contextural interface. Even with the initial benefit of the KHTML rendering engine the task of visual development done right is a MASSIVE undertaking. I really doubt most people have a clue how massive.
BTW I reject the idea that people who are doing little more than paragraphs, italics and links can't learn to push buttons on a toolbar and then click preview. Frankly if you don't know how to write HTML you're not going to know what the hell you're doing when you want to create a stylesheet or advanced layouts. The idea that you can actually succeed without any knowledge or that learning the equivalent of a dozen new words is difficult are both sad. What Quanta does well is helps you learn as you go and takes your basic conceptual knowledge and empowers you to perform with the full power of specific knowledge. I want VPL to be the best tool for newbies, but the idea that you can somehow produce anything of quality with zero knowledge is a myth worthy of Microsoft PR and it's produced a lot of garbage on the web. That garbage is why it's so hard to make a browser that delivers a perfect experience.
FWIW visual tools to date have universal failings.
* They are hard coded and inflexible to the DTD so they could not write XHTML Strict. In fact if they are HTML 4.01 Transitional compliant it's likely only the most recent version.
* They completely rewrite the entire file removing all formatting.
* They are pretty much useless if you use PHP or other scripting.
* They rarely produce finished quality results without some manual editing unless you are not all that particular about visual layout.
Our development of VPL has followed our approach to Quanta, which is DTD independent and easily produces compliant mark up. NVU is a glorified HTML mail composer and they've had way more resources than us. It's foundationally ill equiped for an XHTML future. Of course it's target was MS FrontPage. PHP developers prefer Quanta over Dreamweaver side by side... which is an incredible achievement. VPL is NOT the most important part, but we hope to finally get it right by version 4. When we do we will have accomplished something no other visual development tool has by addressing the bullet points above. I hope it gets more recognition than just "oh, it's easy to use now".
Sadly NVU doesn't seems really impressive to me. Too much Michael Robertson marketing, too little improvements over Mozilla's original code to stand up the claims.
Even more, after releasing 1.0 development stopped, even when it still crashes often and there is a lot of room for improvement.
I like Quanta a lot more, yet visual mode is still beta quality at most.
The only thing really disgust me from Quanta is the huge menu bar and thing like that... Some UI care is needed...
I was released only this summer. And of course NVU is Mozilla Composer+.
However I believe that Quanta's interface for VPL is worse than NVU, esp. on smaller screens.
"I recommend you two things: First, wait for KDE 3.5.1" ... I say first wait to die and then .. speak with God ;)
"Transitions are never easy, radical switchs can be dissapointing no matter what software it is." ...
Tell me why it's "stupid"
When I was a Gnome user I tried to switch to KDE and it failed to do it a few times. The change of "mentality" is there, you need to think in another way and it's NEVER easy. I definitively recommend anyone who switchs to another desktop to do a gradual switch.
>"KDE uses too many resources": Yes, that's true.
>"KDE forces me to install many libraries!": Welcome to the world of code reutilization.
>"C++ sucks": Indeed, C++ is not the greatest language invented...
Why do people like to say "yeah, we suck....but other people suck too". Isn't this meant to be an article about why KDE rules? If so, should we not talk about those things that make KDE rule?
Listing a few accusations that a few fanatic minorities like to shout about, and then defending them on the back foot doesn't help.
If you want to make an admission that "yeah things aren't perfect here...or anywhere else", then do so in the middle of a paragraph or somewhere that people don't care about, PLEASE don't do it in the opening sentences.
If your major battle strategy is based around defense, then you've already lost the war. Just ask the French about WW2, and the Maggeno line.
Ah, pardon me, that should have been "Maginot", rather than "Maggeno".
Why do people like to say "yeah, we suck....but other people suck too". Isn't this meant to be an article about why KDE rules?
It's meant to be an article about why kde rules, but it's not intended to be an article which lies people.
Besides, people LIKES seeing people admiting things like that un public. THey trust you when you look "sincere" and there're more chances that they'll take you seriously than if you write an article saying only the good things of kde
Indeed, every writing class I've ever had told me to acknowledge the counter-agruments in your opinion paper. It makes your agruments stronger.
>"KDE forces me to install many libraries!": Welcome to the world of code reutilization.
Actualy this is completly false, KDE only forces you to install QT, that is ONE library, while any GTK+ based desktop forces you to install 5 (gtk, atk, pango, cairo and glib). So this actually one of the strengths of QT (KDE).
>Actualy this is completly false, KDE only forces you to install QT, that is ONE library
and what about libdbus, libarts, kdelibs,... ?
>while any GTK+ based desktop forces you to install 5 (gtk, atk, pango, cairo and glib). So this actually one of the strengths of QT (KDE).
But at the end it's not more or less. It's just another way to package things. One throw everything together in one large lib and the other divide it in different logical packages.
What is better? I don't know. I just know that Trotech started to divide Qt4 in different packages/libs too.
That's why i like this article a lot. It doesn't try to tell you the great story from the great knight who know everything and can do everything. It's a honest article about the beauty of KDE which doesn't lie about things which some people may consider as a disadvantage but explain it in a objective way.
>"KDE uses too many resources": Yes, that's true.
Indeed, a simple runlevel 1 bash uses far less resources (and i don't wanna miss it in an emergency) but KDE is why I spent some thousand buckazoids to buy a new usparc, so why waste the power? And wouldn't this be a little bit unfair to the devs, who spent years of free time to make it?
>"C++ sucks": Indeed, C++ is not the greatest language invented...
Yeah, lisp rules, we know that. I have used quite some languages, starting with z80 asm for my doctor thesis, but I somehow stuck with C++, it's not perfect, but has that nice-and-everything-is-right feeling. Java is fine, very well designed and nearly perfect, but to be honest, I _hate_ it (although I earn my money programming in it).
the fact java earns your income might very well be the reason you hate it :D
anyway, i agree with you on the use of KDE - i had to run icewm lately, because KDE was broken. well, no fun. i wanted to drag a taskbar entry to another destkop with the pager... yeah, can't do that. then i wanted an 'always on top' button on my windowdecoration (which is ugly in icewm, no matter what theme you choose). no go again. of course, i miss having two panels (i need some space for the media applet, kdict and run command applets, and my favorite applications) and of course i miss the great KDE look.
Hey, I hate Java too!
Actually, I like the language, but I REALLY hate virtual machine, JDK and Sun (yes, I know about gcc-java and all). So I got a similar language (C++) and started coding with Qt4. What can I say? I'm sold.
I belive most people don't like C++ because of the lack of methods/functions, but this is easily fixed if you use some nice toolkit like Qt.
the classpath project enables native compilation. Classpath made great progress this year.
http://www.gnu.org/software/classpath/
>Java is fine, very well designed and nearly perfect
your kidding of course... right? :S
> "KDE uses too many resources": Yes, that's true.
No, that's not true. It is obviously not true, because if it was true, nobody would use KDE.
Would anybody use anything that's "too whatever", especially if there were other alternatives? People who think KDE uses too many resources don't use it. People who do use KDE may perhaps think it uses many resources, but they don't think it's too many - if they use KDE, they apparently think it's worth it.
And, of course, there's also the question whether KDE really uses many resources and what the hell does many resources actually mean.
Agreed
I recently installed the latest Mandriva (compiled with gcc4 ), and KDE is REALLY snappy. Then of course, if I configure every possible kde service, application and applet to run at start up, login is obviously slower, and memory usage is larger. BUT that's because you are getting a zillion features for Stroustrup's sake !
Also, it is INCREDIBLE how many people complain about memory usage, just because they don't know about cached memory. They think it is being used, while this memory is just there to be reused if needed, giving a huge performance gain (since memory access is orders of magnitude faster than _any_disk_ access). Oh well ...
Cheers !
"No, that's not true."
Well, it is. I think what he meant is that "KDE could do the exact same things it does today, but with less resources. But for some reason it needs more resources". And the fact that the developers are still optimizing KDE and making it faster and less resource-hungy, proves that statement. Since KDE is been made faster all the time, it means that currently KDE is consuming more resources than it needs to consume.
then it is true for almost every application, and a very "DUH!" statement for a project as big as KDE.
No, it is not. You may think whatever you want about what he meant, but the fact is that he wrote something, and that's not true. Period. As for the rest, sorry, but that's really naive view of things. Do you expect somebody to snap their fingers and magically make everything suddenly perfect? Perfect things don't exist in reality.
"Do you expect somebody to snap their fingers and magically make everything suddenly perfect?"
No. Where exactly did I say that I'm expecting anything of the sort? The fact that KDE is optimized all the time is a GOOD THING! I have no problems with KDE's performance, but I'll gladly welcome any performance-improvements the devels manage to give us. Yes, KDE could be faster and more efficient. It could consume even less RAM than it does. And if the devels manage to do that, great! But I don't really have any issues with the way things are today.
I personally agree with some of the technical issues put into the spot light as well as some of the "usability" examples mentioned, however, and although Diego, you probably meant well, I think that the text takes a somewhat ...aggressive? ...stand and that can well inspire negative feelings in those that are not KDE users.
That, on a whole is not a positive thing and doesn't serve anyone. What do you think Diego?
I tried to write an article about why KDE rules. I don't flame other desktops.
Yes, I wrote some words about Gnome - but only in the "FAQ" section, and I clearly said they're my opinion, and I clearly said I don't "hate other desktops". I removed some hard words about gnome and other desktops thanks to some suggestions BTW. What's wrong with saying that the embedded video player in the kde file selector rules, and that I switched to kde because Gnome and others don't have it? That's a fact, nothing else.
That said, I'm SURE some people will have negative feelings reading this article. But that's how people behaves, some people can't accept other people's opinion. And some people can't even accept objetive facts. If gnome guys write a example about how great gnome usability is, some kde troll will jump flaming BUT IT DOESN'T HAVE KIO AND KPARTS. Some people is just stupid, and the best thing you can do is to ignore them.
haha, i love your english ;-)
anyway, i agree with you - some ppl never change. they never see other ppl prefer other things. and gnome DOES have several advantages - tough imho the disadvantages outrun them anyway (duh, thats why i use KDE).
but there are still many features you didn't mention. split window in konqueror, drag'n'drop of konqi tabs, autocompletion in every inputfield, to name a few of my personal favorites. ow, and you can re-order and add to the buttons on the windowdecoration (i love the 'always on top' button). and you can give every window a shortcut, and set a universal "window fullscreen" shortcut (i use alt-enter for this - its lovely to have this option in ALL applications).
and what about the great search function in kcontrol in KDE 3.5 (yeah it WAS in 3.4 i know)? makes navigating kcontrol much easier...
btw konqueror supports extentions, just like firefox - for years. quite some extensions are there, like speak-text, translate webpage, auto-reload and a list of pages open when konqi crashed last time.
need i go on? what about a 'edit toolbar' in EVERY kde app? :D there is so much to discover, one can go on and on.. shift-downkey for smooth scrolling in konqi and kpdf (i NEEEEEED this in kmail and the other kontact apps btw). works great with alt-enter/fullscreen if you want to read articles in kpdf. alt-enter to have it full-screen, make it fit with, shift-down (adjust speed with shift down/up again) and sit down & read.
and what about the scrolling that just WORKS? in windoze, you can only scroll in certain applications without first having to CLICK the scrollbar!!! how stupid... you can't scroll in windows that don't have focus, and you generally can't scroll on the taskbar (volume, tasks), not over tabs, you can't increase text size in word (unless you first click) nor zoom factor (try all this in kword or konqueror). and yes, in KDE horizontal scrollbars scroll too - of course, if you mouse over a scrollbar, shouldn't it scroll? well, KDE is the ONLY desktop environment I know of where this works (but i admit, i only tried Mac OS X and windows XP, not gnome or others).
just some ideas for another article :D
I agree with all the "likes" that you mentioned and I'll add a couple favorites:
Right click on maximize makes the window as wide as possible but doesn't change the height. Middle click on maximize makes the window as tall as possible but doesn't change the width. I use this all the time.
And probably my favorite thing in KDE is the "magnetic" windows that align themselves as you drag a window close to another. I find it very hard (annoying is probably a better word) to use desktops without this feature.
BTW - I had a good time playing with the video preview in the file selector last night. What never ceases to amaze me is the comprehensiveness of the tools in KDE. For crying out loud, the file selector is basically a very powerful application in it's own right. For instance, try resizing the preview pane of the file selector window. The video preview automatically resizes without missing a beat. This is a sign of good architecture - when things work like you expect them (hope for them) to.
Somehow the video preview failed, i.e. it shows nothing on videos. Pictures etc work.
Does one need to have a media player installed or something else (Kaffeine here; KDE 3.4)?
You need to first install KMplayer:
http://kmplayer.kde.org/
and then the video preview will work. Most distros (SUSE, Redhat, Mandrake, etc) don't install KMplayer by default, and some don't even offer it as a package for some unfathomable reason.
My own "KDE fan and proud of it history"
Earlier this year I was asked to install a FTP app in a customer computer to send files to the main office.
It was a RHEL 2.1 with an ancient KDE 2.2 (It was also the server for an office wide app and I wan't allowed to touch it too much).
I didn't download anything, just open a Konqui window, split it vertically, set the local folder in one side, the ftp folder in the other one, save that layout as a konqui profile and set an icon to open it automatically.
Voila! Problem solved just with KDE power.
...well balanced.
Thanks and all the best to you & everyone else on the dot for 2006!!
I found it an objective story, but that might just be my opinion. ;-)
No, this is not meant as a troll, but as a cry of despair. Kmail sucks. It has great potential - but there is a tiny little problem.
It's dirt slow on large volumes of email.
I get aprox 800-1000 emails per day through various work-related mailinglists. Most of them automated. I've set up rules to filter them into various folders with kmail.
This works okay.
Then I'm off for a one week vacation...
Between six and seven thousand emails await.
It takes aproximately 60 seconds to fetch and filter 1000 messages.
When trying to filter the 6000 messages, it has only chewed through 200 after 15 MINUTES.
There is something wrong there. It seems like there's an O(n^2) algorithm in there somewhere. Someone has pointed at klistviewer or something like that.. whatever -- in all cases, it's horrible.
Someone has said that it'll be fixed with KDE4.. but that's still a long way off. It would be _Great_ if someone could do something about this in a 3.x update. I feel the urge to move back to mutt more and more every day .. and quite frankly that sucks, as I love the KDE gui. :-)
until now HUGE data cannot be managed by KDE applications easily. Perhaps it was not intended that KDE applications would handle large volume of mails, huge text files, thousands of pages of kword document, etc.,
I hope KDE 4 will be the best Desktop which will handle huge data stuff easily... good luck.
This is the most god-awful troll ever.
Please, back up ANYTHING you just said.