Yesterday the KDE Projectannounced
the release of KDE 3.1beta2, the third (and final) development release of theKDE
3.1 branch. On top of the large number of improvements over KDE 3.0 which have already beenannounced, this release offersa
number of significant improvements, such as a new Exchange 2000®
plugin for KOrganizer and a KVim plugin for KDevelop
(screenshot).
In addition, release coordinator Dirk Mueller notes thatover 1,000 bugreports on bugs.kde.org
have been fixed in the last 4 weeks.
Please run this release through its paces so that KDE 3.1 will be the best
we can make it! Thanks to all for the hard work in getting this release out.

Comments

I've written some plugins for Konqueror to display details of Java, Python, Lyx, abd Bibtex files in the filemanager popups and property tabs. I'd like some wider testing and feedback. The source is downloadable from http://users.uk.freebsd.org/~grrussel .

i'm afraid you need kdevelop 3.0, which has not seen even an alpha release yet. it seems this code has a long way to go :O/
(disclaimer: never tried the code, i just give a mere *impression*)
however i use daily this component to have konqueror open text files embedded in the vim component :O)
and it even works with kde 3.0, don't need 3.1b2 :O)
(it's the vimpart project of kdeextragear-1).

what i expect too is "a detailed list view with meta-information about files in the side-bar".
i saw screenshots a long time ago, it looked great and seemed useful too. i hope it's really what i think it is :O)

what i expect too is "a detailed list view with meta-information about files in the side-bar".
i saw screenshots a long time ago, it looked great and seemed useful too. i hope it's really what i think it is :O)

the vim kpart is scheduled to be distributed in KDE 3.2 (kdeaddons pkg),
but for now it's available in the kdeextragear-1 module of KDE's CVS and it's not in 3.1.
But the current version of the kpart works fine, so you can give it a try anyway :) (I use it every day), it's known to work with kdevelop, kwrite, konqui and some other apps. In 3.2, hopefully we will have it in kmail too :)

Hi Girish,
This Nag from Bapatla, hope you can recognize me ...I am trying to find you from different sources but finally today I got your Name in KDE.NEW. If you are not Sapta Girisa and not studied in Bapatla College of Arts and Sceince then please ignore this email.

The problem with embedding emacs is it's like embedding GNOME or something. You get a mail client, tetris game, web browser, psychologist, file manager, etc, all at the same time. Emacs isn't exactly suited for embedding.

That's why there is a difference between the kvim application and the kvim part. Only one is used for embedding. While many people would prefer using the kvim part in applications, I think people would generally prefer a kemacs application.

Much more suited to a emacs kpart would be something like joe or jed (can't remember which), which is a lightweight emacs.

Come on. The reality is you can strip all of that out by removing the respective .elc/.el files and only provide limited functionality. Did you know that you can do VI bindings via the VIPER module in Emacs? OK, so why don't we use it since it's heavily developed and upgradeable? Religion is probably the number one reason why. Another is language -- everyone thinks lisp is old.

Anyhow, the future is more expandable with a KDE emacs equivalent. I guess you could write a Kate plugin to do this stuff, but why? Why do we keep reinventing the wheel? Maybe I'll write another editor with the Numbers 1 2 3 4 as directional keys just so I can integrate Ruby as an embeddable scripting language.

It's like artsd vs esd vs oss. I mean, come on! I gotta 1.6GHZ machine running nothing but noatun and konsole. And my music STILL skips!! And because I did some funky update to the www.math.unl.edu version of kde for redhat 7.3, the ogg/vorbis stuff got upgraded to where xmms can't use it. So, guess what, I'm using mpg321 ... after killing artsd of course. I hope 250 of the bugs they fixed were centered in artsd.

I've got an 800MHz machine running three simultaenous compiles and I haven't noticed my music skip yet. I have artsd set to run with realtime priority. I am also using kernel 2.4.19 with Robert Love's preemptable kernel patch.

This is such phooey I cannot believe it. Everytime I approach this topic with anyone, they always mention they have Kernel vWhiz.Bang.Baz or some other godsent sound system and it magically fixes artsd. That's so wrong. If esd, oss, et al can handle it with non-preemptible kernels, then artsd has a design problem. Period.

Yeah, artsd is network-transparent, blah blah. No excuse. It's as if they started with the waveform of the sound and tried to objectively describe it using C++. He he, good luck. Maybe when we get beowulfs-in-a-box on the market, it'll be okay and this won't be a discussion any more. How about integrating artsd into Java?

Ok. I'm using aRts on a 700MHz box (overclocked to 770MHz), kernel 2.4.18 without any special patches. I can compile three KDE CVS-modules and still listen to my music, without any hickups whatsoever. Does that satisfy you?

The reason might be that my box has enough RAM (384MB won't be filled during the compile jobs, so no swapping required) and uses a separate harddisk for the KDE-sources I want to compile.

Well, frankly I don't know how much of a difference the kernel actually made. OSS is built into the kernel. I believe esd uses realtime priority. For all I know, things work well because I use realtime priority. Another possibility is the size of your audio buffer (mine is 232 milliseconds). The bigger your audio buffer, the longer artsd can wait before processing more sound. You can change both settings using the soundserver panel in kcontrol.

The preemptable kernel should only make a difference when your machine is busy doing other things. Let's say you're updating the slocate database. Slocate constantly accesses the disk. When a process is accessing the kernel (i.e. reading a directory from disk), the kernel will not switch to another task, so artsd has to wait longer before it can process more sound. The preempt patch allows the kernel to switch processes even when another process is accessing the kernel. The result is an all-around more responsive system. Under heavy load, the preempt patch makes a "Whiz.Bang.Baz" difference.

I don't know how realtime priority works, but like the preempt patch, it tries to make artsd run more frequently.

You guys simply don't understand the problem..
it is kde having a performance problem. If it continues to be so slow Gnome will make it since multimedia stuff simply won't run with KDE as people expect it. It is so much slower than Windows that it is hard to imagine that anyone without having religous reasons will prefer KDE over Windows.
And forget about your stupid patches. If it doesn't work with the standard kernel users won't care. Or do you really think the avarage user is going to patch its kernel for listening to mp3????

I wish you good luck and some professionality! Finally!
just a linux user

I realize I'm more than a month late on this, but aRts doesn't work around OSS bugs. OSS bugs plague chipsets like ess1371. Everyone out there just works around the bugs. But not aRts. Oh, no. The author is above that. aRts is apparently so important that leaving the bug workarounds out will get driver writers in gear and busy fixing their drivers.

I had this problem too, and I can honestly say its not the kde software that caused problems, and my machine is a p3 700 256 mb ram. In my mandrake days playing music was hopeless on kde and less hopeless on xmms but it still skipped on there too. I then managed to install gentoo on my machine and tried playing music and have never had it skip to this day. Often its the packaging thats the problem more than the software.

I'm running an older Knoppix distri from CD (first in August I think, which contains KDE 3.0.2) on my old AMD K6-2 300mHz with 228MB RAM of which afaik 60MB are used as ramdisk etc. And guess what, no skippings at all. Before this I used to have KDE 1.x on my computer until I noticed that I was still using Windows most of the time since KDE was so slow in most regards (and yes, music skipped back then).

Knoppix rocks, and I'll toss it on my harddisk as soon as there's a release which includes KDE 3.1. =)

Actually, when compared to Windows or MacOS, KDE+Linux lacks may features, ranging from telephony APIs to network authentication. Many of them are 'under the hood' or well-hidden somewhere in the application menu. If KDE+Linux really wants to be an alternative, it must have them all (or better: have even more). No company will decide for an operating system that fulfills only 90% of their needs.

What sort of network authentication API is mission. Linux has eks. LDAP, RADIUS, PAM, NIS and tons of different other network autentication API's ! When you talk about API's they are udally well hidden 'under the hood'. API's is ment to be used by programmers not by the enduser. The API's in Windows is not a part of a application menu.

But how are these systems integrated? Can you log in on a workstation, and then access all fileservers, printers, databases, webservers and custom applications without logging in again? Under Windows with Active Directory this is possible. Under KDE+Linux there are implementation for protocols that you could use to build such a solution, but nothing that works right out-of-the-box, is integrated in a desktop environment or easy to set up.

Whereas Active Directory works right out of the box. ALL complex environments will require qualified people to initially configure the systems and generally require day to day maintenance to keeps things sane.

Compared to KDE/Linux it is pretty easy to do. On Linux systems you are on your own, you can be happy if you find a few scripts to configure the directory. The KDE libs do not support network authentication (yet :).

KDE does not need network authentication support. I'm logged into a workstation with no local user accounts at all right now. All the user accounts are stored in a LDAP server, and I use libpam-ldap and libnss-ldap to authenticate against it. KDM doesn't know anything about this, it just calls the lower-level getpwent() & friends and works.

I'm able to access file shares via NFS with autofs, and printers via CUPS. I really don't see the problem here.

Whereas Active Directory works right out of the box. ALL complex environments will require qualified people to initially configure the systems and generally require day to day maintenance to keeps things sane.