Slashdot Mirror
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."
Yes, the compile time for most Qt/KDE projects is a nightmare. Perhaps you want to check out Qt# It is still rough around the edges but the platform looks nice and you won't believe how rapidly apps can be developed. Cutting down on the compile time alone is worth it, IMHO.
Repeat, KDE is no window manager but a desktop environment - kwin is the window manager.
And why did they interview them? He has nothing new to say likely due to that he is not much involved in today's KDE development (3 CVS commits until today this year). The second representive stepped back from the interview because of low involvement but with 7 CVS commits this year he has even contributed more lately.
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.
A deep unwavering belief is a sure sign you're missing something...
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.
A Government Is a Body of People, Usually Notably Ungoverned
I think, one of the reasons for the 'K' could be, that KDE was started by a German developer (and then joined by a lot more). In the German language the 'K' is much more common. There are many German words, which are similar to their English translations, only with the 'c' substituted by a 'k'.
"Kalender" is an actual German word (ok, the 'e' is different, too), as is "plankalkül". Other examples would be "Konfiguration" (although not used in KDE), "Kopete" or "Karbon". So maybe the initial predominant quota of German/European (don't know about other European languages) in the project was the reason, that nobody cared about the 'k'. I (native German) don't particularly like it much, but I don't think it sounds bad either...
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.
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.
Copete is an alcoholic beverage much appreciated by the (Chilean) developer.
Yes, I know this because I'm a KDE developer.
Bullshit. Both of them result in a call to graphic driver which , generally, is better optimized on Windows.
>>>>>>>>>
First, the graphics driver doesn't do all that much these days. For example, with Xft2 and sub pixel anti-aliasing, the graphics driver doesn't even handle blitting of text anymore. Second, it depends on the drivers. The NVIDIA drivers I use, for example, are just as good as the Windows version. That said, if it's a driver problem, it's not X's fault, is it?
They use it the way it was intended.
Every fucking Qt call of say QPainter maps almost directly to Xlib function.
What else would you have them to do ?
>>>>>>>>
Do you really believe that? Qt and GTK+ use X as basically a blit engine. They do all the drawing in pixmaps (in software) then blit the results to the screen via the X server. That's most definately *not* how X was designed to be used. There are also numerous issues about not using the protocol properly. Thus, I refer you to the recent thread on the X Render mailing list about XFree86's performance.
A deep unwavering belief is a sure sign you're missing something...