Slashdot Mirror
KDE Developer Sirtaj Singh Kang Interviewed
highwaytohell writes "Sirtaj Singh Kang is a KDE developer and an official spokesman for KDE in Australia. In this interview conducted by the Sydney Morning Herald he talks about how the KDE project manages to maintain its hierarchy, where he sees KDE in the future, Linux portability issues and the relationship between Trolltech and KDE developers. The article gives a good insight into how maintainers and developers work to maintain one of the more popular window managers for Linux. Certainly worth a read."
From the article:
/. then...
"There are always people who would rather talk about it than actually help with development."
So we can take it he reads
graspee
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.
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).
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.
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.
Mooniacs for iOS and Android
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.
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.
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.
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.
A deep unwavering belief is a sure sign you're missing something...
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.
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
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?
A Government Is a Body of People, Usually Notably Ungoverned
Actually export has turned out to be a sort of misfeature. Most C++ gurus have now realised that it doesn't really do what it was hoped it would do. See this - http://www.cuj.com/current/index.htm?topic=current
(Scroll down to bottom)
"Sutter's Mill -- 'Export' Restrictions, Part 2 Until further notice: the tariffs on export are too high for everyday use."
(The whole article is only available in the print version)
In fact the very first implementation of export has turned out to be a very pyrrhic victory as said by the developers themselves. Turns out that export will need some serious redisign before any of the other C++ vendors will use it. Certainly the intent was good and one needs something like export. But export as it stands today doesn't quite cut it. The basic problem. Its too complex to implement and use and it breaks some other very basic C++ rules when you use it. Also its implementers say that it would be very difficult to give the users a consistent set of rules/advice on how to use it without getting shot in the foot. So looks like we can all forget export for a while. No need to worry about GCC or others not supporting it. Lets all wait for export v2 for that. In any case the C++ comittee agrees that they did too much of an invention with that feature without having the requisite expereince inspite of C++ compiler vendors warnign against it.
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.
The rest of the unix world seems to realize that the kernel maintainers should also handle the basic userland applications.
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.
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
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).
> KDE uses an html renderer (and hence - the
> 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.
Moritz
Bullshit. Both of them result in a call to graphic driver which , generally, is better optimized on Windows.
>>>>>>>>>
First, the graphics driver doesn't do all that much these days. For example, with Xft2 and sub pixel anti-aliasing, the graphics driver doesn't even handle blitting of text anymore. Second, it depends on the drivers. The NVIDIA drivers I use, for example, are just as good as the Windows version. That said, if it's a driver problem, it's not X's fault, is it?
They use it the way it was intended.
Every fucking Qt call of say QPainter maps almost directly to Xlib function.
What else would you have them to do ?
>>>>>>>>
Do you really believe that? Qt and GTK+ use X as basically a blit engine. They do all the drawing in pixmaps (in software) then blit the results to the screen via the X server. That's most definately *not* how X was designed to be used. There are also numerous issues about not using the protocol properly. Thus, I refer you to the recent thread on the X Render mailing list about XFree86's performance.
A deep unwavering belief is a sure sign you're missing something...