Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
KDE GUI

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."
This discussion has been archived. No new comments can be posted.

KDE Developer Sirtaj Singh Kang Interviewed

Comments Filter:
  • by Anonymous Coward
    Does anybody know if NetBSD has been ported to this yet?
  • by Graspee_Leemoor ( 302316 ) on Monday November 04, 2002 @01:23AM (#4592401) Homepage Journal
    From the article:

    "There are always people who would rather talk about it than actually help with development."

    So we can take it he reads /. then...

    graspee

    • So we can take it he reads /. then...

      Does it count to the "between zero and perhaps 24 hours a week working on free software"?

    • by Anonymous Coward
      I see the problem with that statement. It should have read: "KThere kAre kAlways kPeople kWho kWould kRather ktalk kAbout kIt kthan kActually kHelp kWith kDevelopment." babelfish should have a KDE translator so that they kan all talk/write the way they really should.
    • jokes apart, what do you think are the ways someone can contribute if he wanted to ?

      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!)
      • by Arandir ( 19206 ) on Monday November 04, 2002 @03:44AM (#4592848) Homepage Journal
        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.
        • You forgot the most important one:

          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.
    • Damnit man quit bitching about what he says and DO SOME WORK. Jesus if you dont put out at least 500 lines of new code or debug 5,000 lines of code a day its your fault the company isn't profiting. Recently it has been figured out that the "..." step before "profit" is actualy "push your developers to the limit and back becuase somehow when they are pushed the code is BETTER".
  • by Anonymous Coward on Monday November 04, 2002 @01:30AM (#4592430)
    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.
    • by Anonymous Coward on Monday November 04, 2002 @01:36AM (#4592455)
      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).
      • That's a good point, and it's well known.

        It's damn near time someone decided to scrap X and write KDE directly on top of the kernel.
        • We have problems making cut/paste work between applications when they should simply work. We have problems making distros work with eachother, with rpm built for multiple distros when they shouldn't need to be, they should be standardised. Now you want to fork the linux kernel! Atleast on the most basic kernel level, let us pick something and keep it throught thick and thin!
          • Well, welcome to the world of *bsd.

            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.
        • It's damn near time someone decided to scrap X and write KDE directly on top of the kernel.

          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?

      • by be-fan ( 61476 ) on Monday November 04, 2002 @02:37AM (#4592693)
        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.
        • by Anonymous Coward
          "X is actually faster than the GDI for most things. "

          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 ?
          • I'll refer you to my reply to a post of similar nature, in which another troll (such as yourself) stated the same thing without backing it up with fact.

            Enjoy... [slashdot.org]
          • 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.

      • X11 performs well on my Maxine, a 25Mhz R3000 processor. It's not the CPU that makes the performance, it's the video card and how well written the driver is.

        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.
      • I've done a bit of research on this - the X architecture is not fundamentally flawed - it's just that some things are implemented poorly.

        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.
        • 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."

          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).
          • I was gonna mod you, but I figured I'd reply instead...

            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.
      • You may find remote windowing "grievous" and bloaty, but I know many people like myself who use this feature everyday. You have to remember that X is often actually run on servers (without heads, even). Sure, it might make more sense to have the remote server in a different package... oh, wait, it is. If you take responsibility for your own pacakage management it's not hard to slim X down (or any other *nix program, for that matter).
    • KDE ran fine on my 366MHz PII laptop w/128 megs of ram and a neomagic video card. You're smoking crack.
      • I don't understand how people consider KDE 3 to be slow when 128 MB of RAM is not a significantly large amount by any means. What do they expect- should a modern GUI run on 32 MB of RAM still? I don't think so.

        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.
    • here's the thing, right. I deploy and run kde on 32meg p133 systems (don't believe me? check up on me - our website is at http://www.computerbank.org.au, that should give you a good start).

      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.
    • You might try compiling KDE/Gnome and X. You'd be surprised at the speed difference. I have an athlon 750 w/256megs of ram and they are both quite fast. I'm not saying I use either of these regularly (I don't like the desktop metaphor), but I've seen a tremendous speed increase by compiling rather than using the standard binary of KDE.
    • I run:
      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.
    • I'm sure the performace is really bad for you - but I have no idea why. I'm not a linux guru by any means, but I'm running debian unstable on a 350 MHz pentium 2, 256 megs of ram cause I had it lying around, some POS onboard 2 meg ATI Rage card, and both KDE and Gnome are perfectly usable - about the same as win95 on the same hardware. This is with no custom X tweaking or anything, and RH and Mandrake both ran about the same on the same machine. I did turn off pretty much all the eyecandy using the standard KDE control panel, though. On a machine with the specs you mention, you should't be having any trouble, even with the eyecandy turned on.
    • I am willing to bet that your problem is bad configuration, in particular hard disk configuration. Check out hdparm, and make sure your disks are using DMA, etc.. (LinuxGazette has a write-up [linuxgazette.com])
  • by extrasolar ( 28341 ) on Monday November 04, 2002 @01:38AM (#4592463) Homepage Journal
    Its confusing enough for new users and irritating to everyone else. Why do we need the K's and the gears to proclaim "We own your computer!" Thats what Microsoft does and is one reason I have turned away. Let us brand our own computers, or better yet, leave the system unbranded. They are only tools, after all.

    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.
    • Calm down! It's not like the KDE people get upset when others change they look and feel of KDE. After all the code is GPLed.

    • Hmmm.. It is not too bad. Granted, We do not like marketing tactics that kill other companies (or products). Promoting their own brand is okay, as long as it is GPLed. For that matter, Apache and Linux "brand" have more penetration. :-D
    • "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"

      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.
      • And people wonder why coders who work long hours on free software projects don't want to deal with end users.

        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.
        • "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."

          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.
    • " De-brand the desktop to make for a more useful system."

      Exactly hoe does that make anything more useful?
    • by Synn ( 6288 ) on Monday November 04, 2002 @02:08AM (#4592597)
      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.
      • I'm not disagreeing with your publicity point, but I really hate the K-naming convention. If I'm looking for some tool that I haven't used before, say I want to find the printer configuration GUI tool for the first time, I have to look for something that starts with a P and something that starts with a KP. Why KP? It's just a gimmick and it hampers my ability to intuitively find what I'm looking for.

        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.

        • Oh yeah, I forgot to mention stuff like Kalendar and Kalculator. Call my insane, but if I'm searching for a C alculator, I'm looking under C. What need is served by gimmicking it up with a K?

          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.

    • Not only your posting is a troll, but you got modded all the way up, this is a double annoyance:

      To me, KDE isn't a software development project but rather, a parade.
      Have you even bother looking at the source code at least ? You'll notice it IS a software project. High quality software. You may prefer some other desktop environment, fine, but no need to flame.

      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.

      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 ...

      • My God. I post a simple comment one day (I don't post to Slashdot a whole lot, if you read my user info) and the next day I see fifteen messages in response to my post, many of them simply saying I'm a troll.

        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.
    • nice troll

      please think before you mod, thanks!
    • by Dr. Awktagon ( 233360 ) on Monday November 04, 2002 @02:42AM (#4592709) Homepage
      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 [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....)
      • 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?

      • I can't stand that "K". You can always use the program description instead of the program name in the menu. Good for non-english users too.
      • (What do non-English native speakers think of the "K"?)

        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...

        • 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'.
          "That nobody cared"? It's not as if the K was a typo initially or something. KDE originally was the "Kool Desktop Environment", as opposed to the "Common" one. Kool obviously is not a german word, and I strongly doubt that you'll find anyone who would spell it that way by mistake.

          BTW, what the heck does "Kopete" mean?

          • BTW, what the heck does "Kopete" mean?

            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?

        • 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.

    • Apps written for the following projects:

      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!"
      • 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!"

        Hah...that's EXACTLY the reaction I had :) Luckily I have a large & mainly empty hard drive and a fast internet connection...otherwise I would have just given up on Evolution. It would be nice if they would include a little disclaimer along the lines of "Warning! Installing this program will install virtually ALL of the *other* desktop manager!" Of course, calling it gEvolution would be even MORE annoying...Gevolution? Gnomvolution? Evolome? (Nice sound to that last one...)
    • "Its confusing enough for new users and irritating to everyone else. Why do we need the K's and the gears to proclaim "We own your computer!" Thats what Microsoft does and is one reason I have turned away. Let us brand our own computers, or better yet, leave the system unbranded. They are only tools, after all."

      Are you suggesting that 'KDE' project should change its name to 'DE' and 'Sirtaj Singh Kang' should change his name to 'Sirtaj Singh Ang'? ;)
  • by truth_revealed ( 593493 ) on Monday November 04, 2002 @01:55AM (#4592551)
    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.
    • by Anonymous Coward
      Yes, the compile time for most Qt/KDE projects is a nightmare. Perhaps you want to check out Qt# [sourceforge.net] 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.
    • by be-fan ( 61476 ) on Monday November 04, 2002 @02:30AM (#4592668)
      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. [corfield.org] Unfortunately, none of the big compilers (g++, Intel C++, VisualC++) support it yet.
      • by truth_revealed ( 593493 ) on Monday November 04, 2002 @02:43AM (#4592712)
        ...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.
        • C++ was a noble idea, a worthy goal and a wonderful experiment. Sometime around '91-'95 the C++ community should have smartened up and realized that the language was growing so many tumerous work-arounds for the basic problems in its design that it wasn't worth the effort.

          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.
          • You'll take away C++ when you can pry it out of my cold, dead hands. I tend to be a mindless C++ advocate, so I disagree heartily with everything you say. But as for your complaints, I think Stroustrup heard them all before designing things into the language.

            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.
            • 1) C++ is a low-level language with a small number of high-level extensions that are much harder to use than in any truly high-level language. No run-time instantiation of code, no closures, no eval. C++ is not a high-level language, all advocacy asside.

              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.
              • The first 5 arguements basically boil down to this: You propose that C++ is less clean because of certain problematic features it has. My reasoning is that I couldn't care less how "clean" C++ is. C++ has all those features because it allows you to write code that uses the most elegant constructs available at a given time. The language itself is more powerful for that, just as natural languages (if I wasn't an engineering major, I'd be an English major :) are more powerful because of all the different mechanisms they include. It's sad that people abuse the power of C++ (just as people abuse English) but that's no reason to castrate the language, and (in contrast to the ideas of the original poster) no reason to declare C++ dead. In my opinion, the code you can write with a language is the most important thing, overall feature-set aside. C++ allows you (assuming the programmer isn't the bottleneck) to write clean code for a wide variety of situations. Other language (Java in particular) forces you into a dogma (OO in that case) that forces you to write sub-optimal code in many situations. The Java container classes, again, are a good example. The STL is clean, natural, and orthogonal (and type safe!). The Java container classes feel like they tried to shoe-horn a non-OO concept into an OO implementation.

                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.
                • You made the mistake of assuming that I was not the original poster. I was. Other than that, you seem quite happy with C++, and that's cool. Most people who don't have to maintain other people's code for a living are.

                  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!
                  • The second post you posted was far less flameworthy than the first :) As for me not maintaining code, that's correct. I also don't edit other people's writing. I guess I'd be less happy with English if I did. I hope you realize that neither example suggests anything more than the majority of people cannot handle complexity and power, which was something we knew anyway. And neither example makes any comment on either C++ or English other than point out they are complex and powerful, which we also knew anyway.

                    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.
          • Qt doesn't even use C++ -- they have this MOC preprocessor dealy to handle their signals-and-slots connections (delegates in C# speak), so they have invented a new language (C+++) which they handle with a macro processor (as C++ once was implemented as a preprocessor to C).
      • by WhoDaresWins ( 601501 ) on Monday November 04, 2002 @05:35AM (#4593135)
        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 [cuj.com]
        (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.
      • A good way to tackle this is to move as much code as possible out-of-line. I have a custom template container library where all of the major functions are implemented out-of-line - they work with void* pointers rather than a specific type. These void* containers are wrapped in a template class that just casts to/from void* and the templated type.

        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)
    • Everyone's benchmarking machines for framerates in games, but what I'd like to know is this: What is the smallest/cheapest machine that can compile KDE 3 (kdelibs, kdebase, kdenetwork and koffice) in one night (say 7 hours)? And: Have the OpenBSD folks fixed their toolchain so that linking KDE doesn't need 800 megs of virtual memory anymore?
    • by elflord ( 9269 ) on Monday November 04, 2002 @05:49AM (#4593167) Homepage
      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.

      • The simplest way to address this is to avoid using too many different instances.

        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 .cpp file that declared all the explicit template instantiations. It is impossible to track by hand due to templates instantiating other templates and so on.

        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?)
    • I'm just sharing this information because it may be useful to others in a similar situation:

      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)

    by Anonymous Coward on Monday November 04, 2002 @02:16AM (#4592626)
    I like KDE3 better than KDE2, because when I swap from a console, it doesn't throw my mouse into the top right corner, but it's so bloated.

    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.
    • "Better documentation means that you don't have to dumb down the product, you just end up with smarter users"

      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.

  • by twener ( 603089 ) on Monday November 04, 2002 @02:26AM (#4592659)
    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.
    • And why did they interview them?

      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?

To the systems programmer, users and applications serve only to provide a test load.

Working...