I personally like being able to launch stuff with a single click, but there are enough barely computer-literate Windows types that think you have to doubleclick everything everywhere.

At very least, KDE should *ignore* the second click if it falls within the doubleclick timeout rather than launch a second copy of whatever is being clicked. Actually, this should probably be handled by QT. If a 2nd click comes within the doubleclick interval, a doubleclick signal should be generated, not a second click signal. The app is free to ignore the doubleclicks.

Launch feedback makes it less likely that a savvy user will click twice, but those reflex-doubleclickers out there totally freak when they get multiple windows opening.

Actually, that is a great idea. Every so often, I am forced to help somebody on Windows. When that happens and I come back to heaven, It takes a bit of time for me to get back to single-click. It would be nice to have an ignore double click in a number of areas. (desktop, kicker, taskbar, etc).

>>P.S. I wish there was a way to replace GTK filedialog with KDE one ;)

Sodipodi 0.32 can do this, you have to compile Sodipodi with --enable-kde or something similar, I wish that others non-kde apps such OpenOffice.org could do the same, which is very pleasent for a KDE user.

"Freedesktop.org has made drafts and standards for desktop, and more of these standards should be in KDE. I think that has been done with menus, but should be done in icons and themes also."

There is another, more pragmatic way to achieve what you wish for.
Stop using non KDE apps, and port missing ones to KDE. Are there really
that many reasons to use a non KDE app instead of its KDE counterpart?

The only case where I can see this justified is with Open Office, just
because it has better MS import/export filters right now.

But I do think that it shouldn't be any rush to get KDE 3.2 out before new year... It's better to polish it until it really shines =)
I'm looking forward to this new release and as always, I'm astonished by the skill on how this great project is running.

KDE 3.2 should not be rushed and I would actually prefer a 2004 release, so that KDE will seem even more recent. It's a lot better for marketing IMO and makes the user feel he is using the absolute state of the art technology.

In addition, as every poll has shown the majority of KDE users get KDE from their distros and as you know distos won't ship until mid April 2004 earliest, so as long as it's not postponed past late February everythign is great.

Currently KDE 3.2 is shaping up to be a great release, but according to the feature plan http://developer.kde.org/development-versions/kde-3.2-features.html just a little less than half of the planned features have been implemented. This si why I think post poning is necessary, and also let's heep up a tradition which GNOME has recently adopted too, quality vs features.

It would mean a big improvement and would push korganizer one (important) step further to the enterprise level... Could somebody with an uptodate cvs head or alpha1 take a look wether it's implemented or not (and post a reply)?

Some of us use laptops. Some of us dual-boot. Some of us like to install new kernels. And some of just just prefer to shut down the machine when we are not using it. Saying "just don't shut it down" is not helping. It's just avoiding the issue.

With an OS that would suspend well enough, we would not have the problem. You would suspend then turn off. Install new kernel, continue userspace (I know, likely a dream). Suspend then boot something else.

Suspend should be the normal way of turning off IMO. It just isn't because the OS support is hard to do. But I expect GNU/Linux to be able to after 2.6.

I already said it, but I guess it would have been more appropriate to write it here.
Multiple users? At my house I have 3 accounts (me, my sis, my mother). I'd say that most people with a home computer do that, no? So even if it's always on they still have to login to their account.

I have solved that by using two X sessions and switching between them. I understand it doesn't scale well for several users. With recent kernel changes that share pages among processes better (i.e. running KDE 2 times needs only 1 time memory for the binaries) it could scale though.

One of the coolest things about the latest CVS is how much smoother the UI feels. Right after kwin_III was integrated, window resizing in KDE became *extremely* smooth. With my laptop's button-pointer, resizing even a complex Konqueror window is as smooth as doing it with IE in XP. I don't know if the speedup is because kwin-III rocks, or because Konqueror rocks, but it makes a very nice little improvement in how smooth the UI feels.

PS> Oddly, resizing isn't as smooth with my USB external mouse. Its much more choppy than the last CVS version (just prior to kwin_III integration) that I used. I have a feeling, though, that the difference might be due to the fact that I used the previous version on kernel 2.4, and the latest one in kernel 2.6

Hmm, I was using rubber-banding as a pejorative to describe bad resize behavior. Anyway, kwin_III doesn't appear to be doing any synchronization, because in some complex cases, the canvas will lag behind the window frame. There just seems to be some good ol' performance optimizations in the codebase.

Yes, different kernels can have a large effect on your mouse movements. The kernel mouse device handling has been changed. The new driver changed certain things such as the mouse update rate and movement speed, at least on my machine. Also, the interactivity improvements in the kernel can have an effect on resizing speed. You should try both versions of KDE on the same kernel before you pronounce one better than the other.

Where can I get the particular features expected in Konqueror? I'm specifically interested in knowing whether tabs will be able to resize [if many] just like in Mozilla, and also whether the menu has been improved so that it's actually a context menu depending on what has been selected.

Indeed, it has been improved quite a bit. The only context insensitive items are now the navigational items in html pages appearing on the context menus of links (there is a patch to fix this, but it breaks on pages like kde.org, where there are links to the same page)

wel,l kde 3.2 seems to be very promising. I really like everything on this desktop except taking my mails. I have been obliged to use a spam filter (spamassassin) and now kmail is just not useable any more when I take my mails. It takes so much time to filter all my messages and I cannot use kmail for anything during the filtering process.
Even not for writing a new message or reading my old mails !

Will filtering be multi-threaded and performed in background in the next release ???
(Please say yes ! :) )

As a first step the pipe-through filter action will be made non-blocking. A proof-of-concept is already working. But the real solution requires some larger architectural changes in the filter manager. Hopefully it will be ready by the time KDE 3.2 is frozen for release.

For now you should
a) use the spamd/spamc combination which is about 5-10 times faster than using spamassassin directly
b) you should not pipe all incoming messages through spamassassin but only messages that are probably spam (like messages which don't come from friends or from mailing-lists you are subscribed to).

I just use this filter for incoming messages that haven't been filtered yet, i.e messages that do not come from a mailing list. But in your reply you mention to filter messages based on my friends' address. I wrote a small bash script that checks if a mail has been sent by someone who has an entry in my kaddressbook and I use this script to filter friend messages. Is there any better solution around ?