KDE Developer Sirtaj Singh Kang Interviewed 255
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."
KDE interview (Score:1, Funny)
hehe- this raised a laugh (Score:3, Funny)
"There are always people who would rather talk about it than actually help with development."
So we can take it he reads
graspee
Re:hehe- this raised a laugh (Score:1)
Does it count to the "between zero and perhaps 24 hours a week working on free software"?
Re:hehe- this raised a laugh (Score:1, Funny)
Re:hehe- this raised a laugh (Score:2)
I am a java developer and I got started with Linux (Red hat 8.0) only 2 days ago & yeah, although its hard to admit - the huge mouths here did play a role in the switch. I want to get hacking - if not for specific tasks, just for the fun of it. What do you think would be the best place to start ? - ideally not too overwhelming for a nubee.
(P.S: I already want to change the way some RPM installations work - they dont friggin create shortcuts on my start menu!)
Re:hehe- this raised a laugh (Score:5, Informative)
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.
Re:hehe- this raised a laugh (Score:2)
Money! Giving money requires absolutely no skill, and doesn't force you to spend time doing boring tasks. All it takes is compassion and willingness to help out in a project.
Re:hehe- this raised a laugh (Score:2)
My gripe with KDE (& Gnome) (Score:4, Insightful)
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.
Fundamental differences will always divide Win/KDE (Score:4, Insightful)
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).
Re:Fundamental differences will always divide Win/ (Score:3, Funny)
It's damn near time someone decided to scrap X and write KDE directly on top of the kernel.
Re:Fundamental differences will always divide Win/ (Score:1)
Re:Fundamental differences will always divide Win/ (Score:2, Interesting)
Having separate userlands and kernels is a mess, and only linux is willing to deal with it. The rest of the unix world seems to realize that the kernel maintainers should also handle the basic userland applications.
That said, it's still time for someone to build a new UI server that isn't X. X is big, and X is nice for serving to a bunch of terminals, but it's a mess for desktop machines.
Re:Fundamental differences will always divide Win/ (Score:2)
small kernel good, vga drivers in kernel bad (Score:3, Insightful)
That's odd because the developers of Unix went on to write plan9 and that moves even more stuff out of the kernel and into the user space.
Re:Fundamental differences will always divide Win/ (Score:2)
Give your machine a proper installation. Give your machine proper drivers for accelleration. Then come back to me and tell me what is wrong with X. I'll be waiting.
Re:Fundamental differences will always divide Win/ (Score:3, Insightful)
But which kernel? Solaris? FreeBSD, IRIX? Linux? Probably the latter, I suppose. Not that you've excluded everyone else from using Linux, are you going to insist that GNOME and GNUStep be put in the kernel as well? What about XFCE? What about Blackbox, Windowmaker and IceWM?
And after Linus has a heart attack, who is going to revive him?
Re:Fundamental differences will always divide Win/ (Score:5, Insightful)
Re:Fundamental differences will always divide Win/ (Score:1, Troll)
Bullshit. Both of them result in a call to graphic driver which , generally, is better optimized on Windows.
"The main problem is that the toolkits (ahem, Qt) don't really use X all that well."
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 ?
Re:Fundamental differences will always divide Win/ (Score:2)
Enjoy... [slashdot.org]
Re:Fundamental differences will always divide Win/ (Score:3, Informative)
>>>>>>>>>
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.
Performance myths... (Score:3)
Most XFree86 drivers aren't as good as they could be. But that's obvious to most people.
If you haven't noticed the trend in computer science, it's that we trade performance for managability. C over assembler, C++ over C, Java over C++, etc. I'd rather have more logical overhead that freeping creaturism on the part of my X server.
Re:Fundamental differences will always divide Win/ (Score:3, Insightful)
Current X applications do not sync with the window managers well enough. e.g. on Windows, window resizing is synchronous with repainting, whereas on X it is asynchronous - leading to a slow, "sticky" feeling and painting artifacts.
Same thing with mouse tracking - the X display refresh is not synced in any way with mouse position updates, so moving a window around feels "sticky."
I claim that it is possible to achieve as good a "feel" as Windows/GDI without any modification of the X architecture. However, window managers and GUI toolkits will need to communicate better in order to reach this goal.
Re:Fundamental differences will always divide Win/ (Score:3, Insightful)
This is actually fairly fundamental to the X paradigm, which is network-oriented. There needs to be no logic on the display device, so things like mouse movements are transmitted over the network for the remote application to see and deal with. It doesn't matter to X if the network is TCP/IP over a WAN or your localhost loopback adaptor. Therefore, it has to be asynchronous, or X would appear to just "freeze" while it was waiting for the network - better that it gives you some feedback and lets you keep working while it sorts itself out than to make you wait for proper synchonization of all GUI updates.
Sun solved this with NeWS which actually does put some interactivity on the display device - for example, you could click a button and the animation of it being "pressed" would be processed on the display and just the button-pressed event sent back over the network (X will have to send mouse-moved and button-pressed events one way, and drawing instructions to display the button pressing over the network). But NeWS never caught on because other workstation vendors weren't prepared to let Sun control the standard.
X is powerful, but it was never made to be fast, and never will be without sacrificing some flexibility. From the Windows perspective the opposite is true: it was made to be fast, and can't be made as flexible as X without sacrificing speed (try using an XP remote desktop over a WAN, for example, or PC Anywhere).
Re:Fundamental differences will always divide Win/ (Score:2)
Windows perspective the opposite is true: it was made to be fast, and can't be made as flexible as X without sacrificing speed (try using an XP remote desktop over a WAN, for example, or PC Anywhere).
This argument is pretty ordinary. PC anywhere, years and years ago, was much faster than X now. PCAnywhere could actually be usable over a 33.6kb modem connection, and the same can definitely _not_ be said for X. It wasn't wonderful, but it was usable.
Re:Fundamental differences will always divide Win/ (Score:2, Interesting)
Re:Fundamental differences will always divide Win/ (Score:2, Insightful)
This is NOT insightful it is false. (Score:3, Insightful)
> related libraries) in its file navigator.
> Having a browser in memory is resource wasteful
> - this is why Win 3.1 and Win95 are so much faster.
Bullshit. Konqueror the filemanager does NOT I repeat NOT use an html renderer at all. Your statment was true for kfm. This was KDE-1.x, about three years ago.
If you do not use Konqueror for viewing html, khtml or kmozilla will not be loaded.
The speed difference comes from several factors.
1) Features. KDE has unicode support, i8n support, previewing, theming, is network transparent, loadable plugins....
Windows 95 is just crap compared to it.
2) Compiler and Linker. GCC is slow. The Linkers are slow. gcc favours correctness above speed. This is changing already with gcc-3.2.
3) Optimization pressure. There is noone willing to optimize for P100 with 8 MB ram, when a machine with Duron 800 and 256 MB ram costs less then 250 . Time is better spent on removing bugs and adding features than for optimizing for obsolete hardware.
Finally, KDE has become faster and faster. Optimizing too early gives shitty design. It is the last step.
KDE-3.1.x is a lot faster than KDE-1.x or 2.x or even 3.0 on a slow PC with enough (dirt cheap) memory. KDE3.x is more than fast enough on a PII-300 with 128 MB ram.
Re:My gripe with KDE (& Gnome) (Score:1)
Re:My gripe with KDE (& Gnome) (Score:2)
My experiences are the same as yours. 128 MB of RAM with a properly accelerated videocard will let you run KDE 3 just fine on a lower end CPU (we're talking as low as 200+ MHz). I've run it on a notebook with 32 MB of RAM, and granted, it's slow, but with 128 MB of RAM the swap file work is cut to a minimum. Really, you couldn't run Windows XP (or 2000) on the same system with better results.
Re:My gripe with KDE (& Gnome) (Score:1)
Of course, theres nothing stopping you if you wanna run KDE 1.x right now...
Re:My gripe with KDE (& Gnome) (Score:2)
Re:My gripe with KDE (& Gnome) (Score:1)
Some distros are bad at packaging, admitedly, but sometimes it's just that you turned on something stupid - yes, file preview *will* need to read all 100,000 files in your home directory. solution: don't have 100,000 files in your home directory, or turn off file icon preview for complex file types.
Re:My gripe with KDE (& Gnome) (Score:2)
Re:My gripe with KDE (& Gnome) (Score:2)
450MHz PIII
384M ram
Voodoo3 2000
1 click to open a folder in KDE3
Some programs take some whirring and panting to get started, but it isn't oppressive. Sounds like you have something going seriously wrong on your box, since I have a processor that's almost half as fast as yours, a $5 video card, and apparently 10x the performance you have with the same software. All signs point to -> You've got something screwed up.
Re:My gripe with KDE (& Gnome) (Score:2)
Check you disk settings (was Re:My gripe with...) (Score:2)
Re:My gripe with KDE (& Gnome) (Score:5, Interesting)
Re:My gripe with KDE (& Gnome) (Score:2)
Re:My gripe with KDE (& Gnome) (Score:2)
Re:My gripe with KDE (& Gnome) (Score:2)
How about de-branding KDE? (Score:3, Insightful)
To me, KDE isn't a software development project but rather, a parade. They see how Apple and Microsoft like to throw parties and festivals for their releases, all in the name of marketing, and KDE sees this and gets the awful notion that this is an area they need to compete in. That marketing somehow matters to them. From this they get strange ideas that its wrong to change this branding, that every computer the software gets installed on is thiers.
I like the system for some parts, and not so for others: but I use it and appreciate it for the freedom it grants me. So my appreciations is noted. De-brand the desktop to make for a more useful system.
Re:How about de-branding KDE? (Score:1, Funny)
Re:How about de-branding KDE? (Score:1)
Re:How about de-branding KDE? (Score:1)
Re:How about de-branding KDE? (Score:3, Insightful)
Yea I can see how you could confuse a dictatorship, a convicted monopolist, and a bunch of coders who have worked for free for years now to provide us with a great free easy to use desktop.
You don't like the branding? Tough Fscking cookies. Feel free to create your own massive software development project and then give a a very bland name like "a".
And people wonder why coders who work long hours on free software projects don't want to deal with end users.
Re:How about de-branding KDE? (Score:2)
People also wonder why coders who work long hours on free software projects which are licensed in a manner that allows people to do whatever they want with any part of the code as long as the changes are released, would give a damn about the branding someone else wants or doesn't want on it.
What he really should do if he doesn't like the branding is to go through the KDE code and make all the de-branding changes he wishes. Hell, I'm sure there are plenty of people who would love to get on that bandwagon with him. However, as was mentioned in the interview this was all about in the first place, people like to talk about this stuff far more than to do it.
Re:How about de-branding KDE? (Score:2)
Actually, this is the point I was trying to make that seemed to be missed by all. Why would people who devote their free time to writing code brand their software? Why do they want to use these marketing tactics to attract users? That these people care about the end users a great deal is obvious to anyone but those who are aghast by my post.
"What he really should do if he doesn't like the branding is to go through the KDE code and make all the de-branding changes he wishes."
This is really silly. I'm not forcing anyone to do anything by my opinion, and having an opinion does not mean that I am forced to cause it to happen. If you look at my post closely, you'll see the suggestion as constructive where "If you want X, then you should do Y." If they don't want X, then they needn't bother with Y. And the assumption is that some of the KDE coders also want X. Do you see?
"However, as was mentioned in the interview this was all about in the first place, people like to talk about this stuff far more than to do it."
This is true. I just consider myself a voice from the audience. Apparently others in the audience disagree with me. But do you think the players care any more for your disagreement than my comment?
I know with free speech comes responsibility, but this is insane.
Re:How about de-branding KDE? (Score:1)
Exactly hoe does that make anything more useful?
Re:How about de-branding KDE? (Score:4, Insightful)
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:How about de-branding KDE? (Score:2)
It's even worse if I'm hunting for a GUI tool via the command line, since I tend to completely forget that I must always search through Kcrap as well as the old fashioned alphabet. To what ends? A banner waving gimmick that I can surely do without.
I'm not against having some unifying theme to the bread and butter apps, but I hope beyond hope that they will choose a less interfering gimmick in the future. Put the K on the end, perhaps? Is NoteK not Knote, except that I could actually find a simple note-taking text editor under N instead of KN? I don't loathe the gimmick, only that the gimmick is annoying and ever-present.
Re:How about de-branding KDE? (Score:2)
Obviously these complaints aren't show stoppers, but this is the type of annoyance, when repeated 500 times for all the Kapplications, that frustrate new users and make them feel like they can't find their new OS's ass with both hands.
Hm, maybe there's a script somewhere that would symlink Crap to Krap through the entire box. I'd donate $1 for that improvement.
Re:How about de-branding KDE? (Score:3, Interesting)
Look, I think it is you who is having strange ideas. KDE is the default desktop in most of the top Linux distributions. It is extremely well integrated. It includes one of the best file/web browsers. It comes up as the preferred desktop in most polls. And all of this is because they provide a great desktop based on a great development platform. They didn't get where they are by marketting, they got there by coding damn well.
But I am wasting my time, the fact that you compare them to microsoft tells more about the intentions of your post than whatever I may say ...
Its not a troll!!! (Score:2)
I'm not trolling!
Guess what I've done. I run ratpoison now. The branding is far less apparent now with the lack of window decorations, but I still have that gear throbbing in the corner of Konqueror. I go to the help menu, and at the bottom is "About KDE".
Now don't get me wrong, it really isn't *that* important to me. I can live with some of the branding, I don't use many KDE applications anyway. But it would be nice to do without...
But I gather a lot of people disagree with me. That's fine, I like independent thinking. But that doesn't make me a troll.
Re:Its not a troll!!! (Score:2)
I think you've just flipped the concept of troll backwards.
I think people read my post as a troll because of their own prejudices, not my "accusations". My only accusation was of an infatuation with branding; the comparison with Microsoft and Apple was only incidental because they do the same thing--only they have a reason.
I suppose what I should chalk up to experience is using "Microsoft" as anything other than a symbol for evil, the connotation is most damning for any argument otherwise expressed.
Re:How about de-branding KDE? (Score:1)
please think before you mod, thanks!
Re:How about de-branding KDE? (Score:5, Funny)
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 [tuxedo.org]. 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....)
dr. awKtagon (Score:1)
So why have you chosen for your name a word that doesn't normally have a 'k', and put a 'k' in it? Or are you the son of a Mr and Mrs Awktagon?
Re:How about de-branding KDE? (Score:2)
Re:How about de-branding KDE? (Score:3, Informative)
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...
Re:How about de-branding KDE? (Score:2)
BTW, what the heck does "Kopete" mean?
Re:How about de-branding KDE? (Score:2)
Good question. I thought it was German, but apparently it's not (according to the Duden), although it sounds familiar...
I have some wild association with a posthorn in my head (which would match the application), but I couldn't find anything about it on the net.
Anyone knows?
Re:How about de-branding KDE? (Score:2)
This post [kde.org] shows the K of KDE to stand for "Kool". I remember reading elsewhere that the K was used due to its proximity to the L of "Linux", therefore making the assertion that KDE is closely linked to Linux. Unfortunately, after a brief Google, I haven't managed to find it.
Re:How about de-branding KDE? (Score:2)
GNU: gcc, g, g, g, g, g, g, g...
GNOME: gedit, g, g, g, g, g, g...
Windowmaker: wmmon, w, wm, w, wm, wm, w...
Blackbox: bbkeys, bb, bb, bb, bb...
Slashdot: Slashcode, slash, slash, dork, slash...
I prefer the branding. I had heard about Evolution. People said it was great. So I tried it. Ten seconds later it was "Oh my God it's installing all of GNOME! Stop stop stop! I didn't want GNOME! Aaargh!"
Re:How about de-branding KDE? (Score:3, Funny)
Hah...that's EXACTLY the reaction I had
Re:How about de-branding KDE? (Score:1)
Are you suggesting that 'KDE' project should change its name to 'DE' and 'Sirtaj Singh Kang' should change his name to 'Sirtaj Singh Ang'?
C++ templates and Qt compile speed (Score:5, Interesting)
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 (Score:1, Informative)
Re:C++ templates and Qt compile speed (Score:1)
Re:C++ templates and Qt compile speed (Score:4, Informative)
Re:C++ templates and Qt compile speed (Score:4, Interesting)
Re:C++ templates and Qt compile speed (Score:3)
Can we all just send Bjarne a thank-you note for the effort and go back to C? If you want a high-level language, use one (Scheme, Python, Perl, CL, it really doesn't matter a whole lot) and write the code that you need to be efficient in C (and in some cases, even assembly).
Problem solved.
BTW: In case anyone thinks I'm just a mindless anti-C++ bigot, I really do like the basic idea. I think if it had stopped at adding classes to C, it might have been workable. But there were too many places in the design where the old C tradition of giving you enough rope to hang yourself was extendted to hights undreamed. Overloading was the first and most obvious mistake. Nice feature, but let's face it: even the core libraries found themselves seduced into turning the bitwise shift operator into an IO method. Then there was C++'s unfortunate foray into multiple inheritance. But, I knew it was truly over the day I learned that there were now *four* different casting operators!
It's too bad, but I think we learned a lot. Time to shut off the lights and move out.
Re:C++ templates and Qt compile speed (Score:2)
1) C++ isn't a high-level language, and it isn't a low-level language. It's both. And that's why it kicks ass.
2) Operator overloading is terribly useful. The whole idea of C++ is that you can implement user-defined types that act like built-in ones. Operator overloading is meant for mathematics-style user defined types (for scientific programs). If you're using operator overloading in a place where it doesn't make sense, then that's your own fault. I hate the Java way of doing things, where everything that could potentially hurt you is illegal. It's the programming language equivilant of Ralph Nader. And > are not just bitshifting operators. They serve double duty as streams operators. I have yet to see anybody ever confuse the two, because it's obvious in most cases that you're not bitshifting the integer 'cout' by "Hello World" or something of that sort. And like printf(), in all it's type unsafe, variable parameter glory is any better!
3) Multiple inheritence can also be useful. Mixin classes, for example, are real nice. Again, if you abuse it, it's your fault. That holds for drug abuse, why not language abuse?
4) There are four casting operators for a reason. You're not supposed to cast in C++. The casting operators are long and ugly and verbose to make the point that you're not supposed to do that. But if you do it, at least the four different casting operators make it clear exactly what you're trying to do.
And templates are mana from heaven. Templates give you the efficiency (yeah, I said efficiency, take that, Java-heads!) of coding custom data structures for each type, while letting the compiler do the actual dirty work. For data structures, the STL beats the Java container classes to a pulp. If you take a look at the equivilent data structures in C, you'll realize how much better the STL is.
Re:C++ templates and Qt compile speed (Score:2)
2) Operator overloading is terribly useful You are absolutely right, and I would never question that. It's also one of the easiest things to do to your language to make it deadly to maintain. I've seen C++ programs that use * to access encapsulated objects, () to reverse order items, and all sorts of other heinous things that have made me cringe whenever I have to debug someone else's C++. In C, macros are bad enough, but at least they don't change the basic semantics of the language.
3) Multiple inheritence can also be useful Again, of course it can. That's not a good enough reason to slap it on the language. It needs to fit cleanly and without causing more problems than it solves.
4) There are four casting operators for a reason. You're not supposed to cast in C++. That's got to be one of the funniest things I've ever heard about any programming language. Thanks.
5) And templates are mana from heaven. Templates are a work-around for not having high-level language constructs. I would like templates if my goal were to write a high-level language, but it would be torture to have to use them all the time. Just look at the contortions you have to go through for iterators. In a high-level language, you just iterate because integers and database connections aren't all that different.
6) take that, Java [...] beats the Java [...] Java is a somewhat cleaner C++. It has a much nicer object model, but ulitmately Java's problems are more crippling than C++'s. Please don't use Java as a counter-example of useful high-level languages. Python, Perl, Scheme, CL and their ilk are where I'd go to compare.
7) If you take a look at the equivilent data structures in C, you'll realize how much better the STL is. C is a hard-core low-level language. It's the ultimate roll-your-own and about as low-level as you can ever get and still remain portable (that was, after all the goal). Libraries like glib (which have many of the things you're used to in STL) add on some very nice features, but ultimately C always remains low-level. If you want high-level constructs, you program in a high level language and use C to write the bits that need to be efficient. Best tools for the job. A useful motto.
Re:C++ templates and Qt compile speed (Score:2)
Please don't use Java as a counter-example of useful high-level languages. Python, Perl, Scheme, CL and their ilk are where I'd go to compare.
>>>>>>>>>
I don't really consider Python, Perl, and Scheme to be in the same league as C++. First, C++ is by all means a lower level language, and more appropriate for systems programming tasks. Beyond that, C++ is a far more generic language. If you're working on a very specific task, Python, Perl, and Scheme might very well be extremely useful and productive. But as a base-level, widespread language, C++ fits much better. In other words, it's important to use the best tool for the job, but if I could only know one language, it would be C++.
7) If you take a look at the equivilent data structures in C, you'll realize how much better the STL is. C is a hard-core low-level language. It's the ultimate roll-your-own and about as low-level as you can ever get and still remain portable (that was, after all the goal). Libraries like glib (which have many of the things you're used to in STL)
>>>>>>>>>
glib has nothing on the STL. The original poster suggested ditching C++ and going back to C. I used the STL as an example of something where a C++ and C library try to do the exact same task, but the C++ library accomplishes the task (thanks to templates) in a much cleaner and more elegant way.
I think you took the arguement slightly out of context. I wasn't claiming that C++ is the be all end-all of languages. I was responding to a claim that C++ was a "bad" language, and that we should ditch it and go back to C. My claim is that C++ is a damn good language in its own right, and its complexity is justified by its expressiveness.
Re:C++ templates and Qt compile speed (Score:2)
Woefully, I've had to, and while C allows you to cause any number of problems, and so do high-level languages, C++ practically dares you to.
C's very simplicity is its strength, and C++ has thorwn that away in favor of being a hand-optimizable almost-high-level language.
You said "if I had to learn just one language".... I suggest that you should learn two. Learn a high level language (C++ programmers tend to be happy wiht Python, where I'm a Perl guy, but both are good) and learn to really use C to its fullest. If you do that, you will be able to program tens if not hundreds of times faster than you do in C++, because a) you will have truly high-level tools at your disposal and b) you will be able to debug your code much more reliably.
Good luck, and happy programming!
Re:C++ templates and Qt compile speed (Score:2)
As for using multiple languages, I agree. So far I've got Perl and Python down pretty well. I know Java, but refuse to use it, and get hives from languages like Lisp. Even then, I must admit that both have their uses. But C++ is still my language of choice, because in all honesty, a jack of all trades is a master of none. It's not just about using the right tool for the job, but a combination of the right tool and the skill with that tool. For most of the stuff I do, C++ is the right tool, so even for cases where C++ is just a mediocre choice in terms of tools, I tend to use it anyway because my experience with it outweighs any benifets another language might have. As for using C as a low-level language, I'd hold that C++ can be used as just a better C. I'm doing an OS kernel in C++ (as a hobby project) and I've found that templates in particular are very helpful (OS kernels are highly datastructure intensive), virtual functions and abstract base classes are perfect for modeling things like driver APIs, and exceptions are a nice way to keep error handling code out of "hot" code paths. If you take a look at real kernel code, you'll see that there are a lot of C++-isms. In the driver API example I gave above, often kernels use the exact same code a C++ compiler would generate for an abstract base class (table of function pointers). I've also used C++ for higher level tasks like scientific simulation. Using C++ and the STL allowed me to write the simulation extremely quickly (because I didn't have to worry about memory allocation and whatnot) while still getting the performance of low-level code.
Oh, if Qt only used C++ (Score:2)
Re:C++ templates and Qt compile speed (Score:2)
I agree with your point in part, but it's worth noting that I frequently use parts of KDE like its dock applets and applications under Fluxbox since I want to avoid the performance hit that comes from the worst of KDE like konqueror and kicker. It does load some of KDE's shared libraries which imposes something of a performance penalty but nothing like running the whole KDE panel and file managers. So just though I'd point out that you can easily use parts of KDE from another environment (you can even run kicker under Fluxbox, though there's not much point in not just using KDE if you're willing to accept the sluggishness that will bring).
export has turned out to be a sort of misfeature (Score:4, Informative)
(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.
Re:C++ templates and Qt compile speed (Score:3, Insightful)
I've found that this approach is almost as flexible as the fully templated STL, and it compiles anywhere from 2-5 times faster and binaries are usually 2-5 times smaller than with STLport. (the improvement is even more dramatic in comparison with the inefficient GNU STL)
Re:C++ templates and Qt compile speed (Score:2)
Now can someone please convince TrollTech to implement this same compile-time optimization technique with their hundreds of Qt header files?
Re:C++ templates and Qt compile speed (Score:2, Interesting)
Re:C++ templates and Qt compile speed (Score:4, Informative)
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:C++ templates and Qt compile speed (Score:2)
It's not me that's the problem - the Qt headers themselves are the cause of the problem - they pull in the entire world. You have no choice but to include these files in most circumstances. I'm trying to forward declare classes and include the minimum number of headers wherever possible.
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.
A pain to put it mildly. I am guessing that Qt itself generates hundreds of implicit templates in the most simplest of programs. I would consider using -fno-implicit-templates if I had some sort of script that could generate a
I have heard that TAO (ACE CORBA ORB) uses -fno-implicit-templates. I wonder how they track the hundreds of implicit instantiations?
(off topic: why is Slashdot so slow today?)
GCC 3.2 compiles Qt code 20% faster than GCC 2.95 (Score:2)
GCC 3.2 compiles Qt C++ code 20% to 30% faster on average than GCC 2.95 with the exact same compiler flags.
for example compile times for $QT_DIR/examples/table/statistics/main.cpp:
g++ 2.95: 11.59user 0.15system 0:11.74elapsed
g++ 3.2: 8.32user 0.10system 0:09.04elapsed
every little bit helps.
For the record, the use of the -fno-implicit-templates g++ compile flag did not improve Qt C++ compile times at all in my tests. I guess Qt does not use as many templates as I had previously thought.
My Druthers (Score:3, Interesting)
Even worse, there are now way too many configuration utilities...I can't keep them straight. Instead of adding features and bloat to make things easier for stupid Windows users, how about ganging together and documenting how I can to Task X from a console? Better documentation means that you don't have to dumb down the product, you just end up with smarter users.
Re:My Druthers (Score:2)
Great Idea. Do it. What is stopping you. I presume you have been hanking around with KDE and know some quirks which annoy end users. DID YOU document them... If not.. why not. Remember those guys are giving you "free software" with much fewer bugs and oddities than some closed source alternatives. They are not deliberately making it tough for you. So help if you can. If you dont like something, go to the site. Very prominent is "contact us". I have done that and if you are polite they get back to you and try incorporate the changes you request. So why whine. Ask them for it. They will try to do it.
KDE is no window manager (Score:3, Informative)
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.
Re:KDE is no window manager (Score:3, Insightful)
Ummm, because it was the Sydney Morning Herald, and those two were the Australian representatives of KDE.
Maybe they wanted an article on local open source developers?
Re:offtopic KDE question, PLEASE HELP ME!!! (Score:1)
Re:As far as lay out and UI goes..... (Score:2)
Say, can you open up a different virtual desktop from bluecurve? Oh that right redhat took that off. How about those nice "ok" and "cancel" buttons located in the wrong place? How about all those nice apache 1.3x mods which are now useless thanks to the removal of apache 1.32x.
Re:As far as lay out and UI goes..... (Score:2)
....(that's a simulation of me waiting and contemplating).....
Well, the virtual desktop thing sort of applies. Apache mods and a relation to UI? Hmmm, obviously, no connection there. "Ok" and "Cancel" buttons in the wrong place? Maybe I'm missing something, please elaborate their Billy.
Re:As far as lay out and UI goes..... (Score:1)
Re:As far as lay out and UI goes..... (Score:2)
All above things will be released as stable Real Soon Now.. Very soon ALL distros' desktops will look as good!
Re:As far as lay out and UI goes..... (Score:2)
Like this one [upinthispiece.net]?
Oh and I know you don't want us seeing this one [upinthispiece.net], since it shows your screen name and the length of your password.
I don't see any conversations with people pissed off about Windows XP, although I do see a Digital Blasephemy wallpaper that you probably downloaded illegally.
Here's his image folder [upinthispiece.net] by the way.
Re:Whats happening with gnome? (Score:1)
Re:Mono must come first (Score:1)
Re:Mono must come first (Score:2)
For Gnome switching will be much more difficult because their current C with GObject style can not be easily converted without a major rewrite. (You can, of course, still write wrappers, but it's not much fun to go back to such a low-level system each time you want to enhance the core libraries)
Another problem for Gnome will be that they have attracted many old-school hackers with their pure C policy. Do you think that they will they happily switch to C# for new developments?
Re:Another KDE Haiku (Score:1)