KDE Developer Sirtaj Singh Kang Interviewed

highwaytohell writes "Sirtaj Singh Kang is a KDE developer and an official spokesman for KDE in Australia. In this interview conducted by the Sydney Morning Herald he talks about how the KDE project manages to maintain its hierarchy, where he sees KDE in the future, Linux portability issues and the relationship between Trolltech and KDE developers. The article gives a good insight into how maintainers and developers work to maintain one of the more popular window managers for Linux. Certainly worth a read."

Comments

My gripe with KDE (& Gnome)

[Anonymous Coward]

Athlon Thunderbird 850mhz
512mb ram
Matrox G400 video card
Up to half a dozon clicks to open a folder because KDE is so slow and bloated.

I've got no desire to troll, but I know you'll mod this as such.
I just don't have will to upgrade my box every 8 months to the latest whiz-bang equipment just to have KDE (or Gnome for that matter) running at a speed faster than Windows ME on a Pentium. Improving speed and stability are far more important than adding features at this time - I think this needs to be realised.
I think for developers with 2gb of ram and the latest 533mhz system bus, it's easy to forget that all this fun-to-make eye-candy is not what users with sub $3,000 computers want. I'm not sure why I'm writing this. I'm just disillusioned with the direction I've seen Linux's desktop usability efforts go.

Re:My gripe with KDE (& Gnome)

[mao che minh]

Well, KDE 3 with a variety of kernels runs great on my P3 600mhz, 256mB of RAM, and crap video card. This is even when I am performing tests and running Apache (with a ton of mods) and mySQL. I have tried Windows XP on this get up. It wasn't pretty. I think that KDE 3.x.x running over Linux kernel 2.4.18 is the fastest GUI that I have come across.

Fundamental differences will always divide Win/KDE

[Anonymous Coward]

The trouble with trying to demand that KDE and Gnome be as fast as Windows (or Mac, or Atheos for that matter) is that those window managers are built on top of X Windows whereas the GWE subsystem of Windows is built directly into the kernel.

This means higher overhead for GUI work on those X-based windows managers because of the extra library calls and extra complexity that X offers. There is a lot to be said for the stuff that is in X, but much of it is simply not needed by most desktop users (remote windowing, as the most grievous example).

C++ templates and Qt compile speed

[truth_revealed]

I'v been using Qt since 1996, and I think it is the best written set of GUI classes out there. I also think C++ is the best compromise between performance and abstraction for graphical user interfaces. That does not mean there aren't some problems, however...

Does anyone else think that Qt should forward declare more classes than it does? The compilation time of Qt projects has went up five fold since Qt 1.x due to excessive of C++ templates. Sure there are ways to cope with it: distcc, ccache - but this is not addressing the primary problem - C++ compiles are too bloody slow and getting slower all the time.

On another topic, who else thinks C++0x should make provisions to forward declare templatized class instances? Including all these template definitions in every header file is complete death for compilation time: #include <string>, for example. Precompiled headers help a little, but are easily corrupted and the cause of many bad builds.

Re:C++ templates and Qt compile speed

[be-fan]

It's not really a problem with either C++ or Qt, it's a problem with the compilers. In particular, with how compilers implement templates. For example, let's say you have the files one.cpp, two.cpp, and three.cpp. If you use std::string for each one, then gcc will compile the string class in every file that uses it. So one.o, two.o, and three.o will all have the parts of the string class that they use (ie, most of it). The linker then discards the redundant bits when the object files are linked together. Now for heavily used template classes (the STL, for example) you basically have gcc compile large parts of a template class library for each source file, then have the linker throw them away at link time. Now the alternative is already part of the C++ '98 standard. You have this thing called the export keyword. Unfortunately, none of the big compilers (g++, Intel C++, VisualC++) support it yet.

Re:C++ templates and Qt compile speed

[truth_revealed]

...and it does not look like gcc will support the C++ 'export' functionality for a long long time, unfortunately. It would require a complete redesign of the link system to make it smarter. The C++ compiler would also have to defer code generation for all code referencing the exported templates by value to the link phase because it would not necessarily know the size of classes/structs until link time. I agree this 'export' would be good, but I don't see widespread support for it in the next ten years (from GCC, at least). It changes all the assumptions that C++ compilers have made in the last 10 years.

Re:C++ templates and Qt compile speed

[elflord]

Does anyone else think that Qt should forward declare more classes than it does? The compilation time of Qt projects has went up five fold since Qt 1.x due to excessive of C++ templates.

The simplest way to address this is to avoid using too many different instances. The way the QObject model works, you shouldn't need a whole lot of different instances of the same template class.

If you're concerned about the compile load of template instantiations, you can always compile with -fno-implicit-templates. Sure it's a bit of a pain, but it can shave a lot off your compile times.

On another topic, who else thinks C++0x should make provisions to forward declare templatized class instances? Including all these template definitions in every header file is complete death for compilation time: #include , for example.

You already can do similar to this. Some compilers, like gcc allow you to suppress implicit instantiation. Of course, the compiler still has to parse the extra code, but it no longer has to create instances of those member functions. The compile checking on uninstantiated members is minimal.

Re:How about de-branding KDE?

[Synn]

But parading a brand around is exactly what KDE should be doing. For one, it generates attention for KDE and Linux in general.

If I hear about a KMail update, I know it's KDE related. If I see a lot of K-this and K-that apps, I think about KDE more.

Also it's easier for your Joe Average to grasp the idea behind a brand. They see Windows and they think about everything that comes with Windows. They see Apple and they think about the Apple experience(whatever that is, but hip people say it's cool).

MS and Apple aren't dumb and KDE trying to brand itself like they did isn't a waste of effort.

Re:Fundamental differences will always divide Win/

[be-fan]

X is actually faster than the GDI for most things. Don't believe me? Benchmark it yourself? I've benchmarked it before, and for stuff like line drawing or bitmap blitting, X stands up well even to DirectX. The main problem is that the toolkits (ahem, Qt) don't really use X all that well. That said, a lot of problem is due to the fact that a properly fast KDE/GNOME desktop needs a lot of proper configuration. My KDE 3.1 desktop, for example, is as fast as WinXP for most things (expect app startup speed, but glibc 2.3 and prelinking should fix that) but it required some custom compiling and renice tricks to get it that way.

Re:How about de-branding KDE?

[Dr. Awktagon]

I don't know if you're trolling, but personally, I can't stand that "K". I don't mind Gnome's "G" everywhere, but I don't like KDE's "K" at all.

Visually, "K" is just an annoying, ugly letter, all kinds of sharp edges, and it doesn't brighten my day the way a nice "g" or "i" does. Just take a look at that "g", if you've got the right font, it's like a beautiful woman. You can't even get away from "K" in lowercase: "k" looks just like "K". It's like somebody getting kneed in the crotch, or something. (Kneed - begins with "K", ouch!).

When you say it out loud, it makes everything heavy and hard, like something from another language. Konsole. Konqueror. TheKompany. Though each day I am thankful I don't have to put up with a "Kalendar" or a "Klok", or, heaven forfend, a "Kalkulator". The other day, I found myself thinking of programming in kvikkalkul or plankalkül. Skary!

(What do non-English native speakers think of the "K"?)

Well, yes this sounds incredibly stupid, but I avoided KDE for a long time simply because of my strong anti-K stance. No marketing department would ever overuse "K" the way KDE has. Now that I've been using it since I installed RH7.3, I've gotten a little used to it, but man, I'd kill (kill - begins with K) for a nice soft "o", that would be so nice and comfy, maybe even a little funny, like Santa Claus laughing.

(Can you tell I've been programming all weekend?? You know, after you stare at letters for hours on end, they start to stare back....)

Re:hehe- this raised a laugh

[Arandir]

jokes apart, what do you think are the ways someone can contribute if he wanted to ?

Documentation. This includes writing documentation, going through the existing docs to make sure their current and cover all bases, and contributing to documentation tools.

Testing. Start using the snapshots or cvs and bang away at the daily code. Pick one application you really like (or feel needs a lot of help) and bang away at it from every direction every day. Then submit complete bug reports.

Artwork. Missing some icons for your favorite app? Make one and submit it.

Other areas to help exist as well, and are limited only by your imagination.

P.S: I already want to change the way some RPM installations work - they dont friggin create shortcuts on my start menu!

This is a distro specific problem, but that's no reason not to help out. Of course, working for free for a commercial distribution is not my idea of charity. It all depends on how big of an itch it is.

export has turned out to be a sort of misfeature

[WhoDaresWins]

Actually export has turned out to be a sort of misfeature. Most C++ gurus have now realised that it doesn't really do what it was hoped it would do. See this - http://www.cuj.com/current/index.htm?topic=current
(Scroll down to bottom)
"Sutter's Mill -- 'Export' Restrictions, Part 2 Until further notice: the tariffs on export are too high for everyday use."
(The whole article is only available in the print version)
In fact the very first implementation of export has turned out to be a very pyrrhic victory as said by the developers themselves. Turns out that export will need some serious redisign before any of the other C++ vendors will use it. Certainly the intent was good and one needs something like export. But export as it stands today doesn't quite cut it. The basic problem. Its too complex to implement and use and it breaks some other very basic C++ rules when you use it. Also its implementers say that it would be very difficult to give the users a consistent set of rules/advice on how to use it without getting shot in the foot. So looks like we can all forget export for a while. No need to worry about GCC or others not supporting it. Lets all wait for export v2 for that. In any case the C++ comittee agrees that they did too much of an invention with that feature without having the requisite expereince inspite of C++ compiler vendors warnign against it.