The KDE Project today (OK, yesterday now)announced
the release of KDE 3.0Beta1. The announcements contains the typical
package locations and summary of changes (visit thedeveloper's website for
a more detailed list of planned feature additions for
KDE 3.0 and the current progress). Since beta releases always
provide an ideal opportunity for newcomers to get involved and make a difference, the release also provides intriguing suggestions to
those of you who may in the past have pondered, "I really want
to contribute to KDE and help make my favorite desktop even better, but
what can I possibly do?".

One Question about the SuSE RPM's. Do the SuSE RPM's replace the KDE2.2.2 system or is a parallel installation of KDE3beta and KDE 2.2.2 with this RPM's possible? I couldnt find a readme about this on the ftp server.

Does that mean that if I install it on my primary, working, daily use, desktop machine, I should have no problems? In other words - can I just install the RPMs, add a new user, and login from KDM, picking on the dropdown "KDE3", and try it out, and then go back, log in as my normal user, and continue working as normal?

I don't know what the problem is, rlan:/ works great here. Remember to set the reslisa binary to suid root and delete /tmp/resLisa-username and you're set! That's about all the setting up you need to do.

Most rpms do not ship with suid binaries (rightly so, but this one should be safe as it drops privileges soon) so you'll have to do this once.

Some other problems though, like plugins not working, and CUPS not being detected at all are keeping me from running it all the time, are these things issues or am I messing something up (SuSE 7.1 RPMS)? Very stable, no crashes yet.

I don't know what the problem is, rlan:/ works great here. Remember to set the reslisa binary to suid root and delete /tmp/resLisa-username and you're set! That's about all the setting up you need to do.

Most rpms do not ship with suid binaries (rightly so, but this one should be safe as it drops privileges soon) so you'll have to do this once.

Some other problems though, like plugins not working, and CUPS not being detected at all are keeping me from running it all the time, are these things issues or am I messing something up (SuSE 7.1 RPMS)? Very stable, no crashes yet.

I don't know what the problem is, rlan:/ works great here. Remember to set the reslisa binary to suid root and delete /tmp/resLisa-username and you're set! That's about all the setting up you need to do.

Most rpms do not ship with suid binaries (rightly so, but this one should be safe as it drops privileges soon) so you'll have to do this once.

Some other problems though, like plugins not working, and CUPS not being detected at all are keeping me from running it all the time, are these things issues or am I messing something up (SuSE 7.1 RPMS)? Very stable, no crashes yet.

I never got KDE to build on Debian 2.2 (Potato) after KDE 2.2, KDE 2.1 builds fine.
Debian (dpkg-buildpackage) always complained dependencies were missing or outdated, when I upgraded all the dependecies I again broke other depedencies.
That's the reason I'm running Sid/Woody by now (only to get the latest KDE
packages).

Due to a slow machine, kdelibs hasn't finished compiling yet (PIII-550, 128 MB RAM, SCSI disks). I started to complile Qt 20 minutes after I posted the former message, so I can't give you a complete answer.

But anyway, the Debian 2.2 I use isn't vanilla (as you might expect :) ).
Qt 3.0.1 compiled without problems, but for kdelibs, Potato required some "minor" updates.

I have installed OpenSSL and PCRE from source instead of using the Potato ones. I use the two day old PCRE 3.8. Potato provides 2.0.8, which is from 1999 :) Other dependency problems are libxml2 and libxlst, but they are not mandatory, so I skipped them. Of course, if you have your old prce installed, and not want to install the newer pcre, just use --disable-pcre.

Good luck!
Mats

BTW: Thanks KDE for updating the configure script with the following information:

As far as I know, the bug number 23205 is not theirs - it's fault of Xfree86. XRender extension that provides antialiased fonts, requires separate configuration file with separate directory list, and doesn't work with fonts provided by font server. As simple as that. GNOME just doesn't use antialiased fonts by default, it should be configured very special way. Offtopic,but anyway - this font management thing has always driven me just crazy - why should I maintain two configuration files with two directory lists for antialiased fonts and for non-antialiased fonts? XRENDER for this, regular X don't know what for that... Add to that CUPS/ghostscript with yet another one font list, and the picture is perfect. Why can't there be one font server for it all, antialiased by request or by configuration, the same for display and for printing? Why create a "font hell" with our own hands?

Ok, on topic. I completely agree with your point - bugfixes before, features after. Bug number 33254 - the developers declared the feature working, and it doesn't work. And the bug is there since KDE 2.2 untouched as of KDE 2.2.2.
Or bug number 33152 - it is there since KDE 2.0. Little thing, but not so pleasant nevertheless.

>Provide the "still doesn't work with KDE x.x" information to the bug system.
That's exactly what I did :-) I've provided bug numbers, as you see.
They declared some feature working, and then I submitted the bug.

And it would all be so much more worth it if only they could have the default AA be in 256 shades instead of just 5. The freetype library actually includes an alternate smoothing algorithm which is far superior to the default one. It produces 256 shades of gray in one pass, and is suposedly faster than the default renderer for font sizes under 20 points. It seems that Nautilus and the GNOME desktop (but none of the other apps, of course) use this alternate module, but KDE still uses the crappy method.

For an example, look at the difference between Times New Roman (or probably any roman font) at sizes 12, and 14. At 12 it looks skinny and blury, and at 14 it looks fat and bold. However, if Nautilus is configured to use Times New Roman, it scales very nicely. I think the text produced by GIMP is another example.

Both WinXP and OSX have finally gotten AA right, and for Linux to be a contender on the desktop, this is a must.

You know what the biggest shame of all is? The kmail developers are completely unwilling to fix their message threading problems. Want to see it for yourself? It's extremely easy to replicate...

1. Subscribe to a mailing list.
2. Use procmail to filter your list into a folder
3. Use kmail via IMAP to read the folder on the mail server.
4. Turn on threading for the mailbox for your list
5. Start reading.

Presumably you'll have several threads. Suppose the first two threads, A and B came in in this order:

A: 1,5,6,7
B: 2,3,4,8

When you first start reading the folder, you hit thread A first. Suppose you delete the first message. Kmail immediately removes this message from your view, then proceeds to re-order your mailbox, leaving this:

B: 2,3,4,8
A: 5,6,7

I filed a bug on this, only to be told this isn't a bug, and in fact, I'm somehow reading my mail incorrectly, since I deleted a message. I suggested they take a look at how threading works in mutt or even Evolution. They still think they're right, and there's no problem. Nothing like closed-mindedness, huh?

I would try thinking harder, or at least present them with more descriptive errors. I know that I have had two bugs fixed by them only after actually telling them the problem and provideing test cases and screen shots. Chances are it is your config.

Well, I do know the problem. When sorting by date, the threads are sorted by the date of the message starting the thread. If the user deleted the first message in the tread, this can cause the thread moving to a different position in some cases, because the date of the message starting the thread can be different now.

I consider this correct behaviour, because this is just how sorting by date works.

To me it is also the correct behaviour. However, it would be nice to have 'Yet Another Configuation Option': "do not rearrange threads when in date sorted view". You could add an easy shortcut to it by having a RMB popup on the date/sender/subject bar with the option.