The KDE Project today released KDE 3.1 RC2, probably
the last release candidate for KDE 3.1.
A good number of showstoppers in RC1 have been fixed, and the new default Crystal-SVG icon set has been polished based on the valuable feedback received. Nevertheless, please give this RC2 another round of thorough testing to make sure all the major wrinkles have been
ironed out. Please note that the kdebindings package still suffers from
compilation problems in large parts, but this will be fixed by the final
release. Thanks to the community for the feedback so far, let's keep it up
and make the 3.1 release everything that is expected!

I know that Marcus was working on QtC and QtJava just a few days ago. Marcus and David were also working to fix a compilation problem with smoke. Nick, is also working to integrate the latest Qt# into cvs before the release.

Great news. I was afraid kdebindings would be excluded from KDE3.1, after it (smoke, QtC and probably others) proved pretty impossible to compile under Qt3.1 (I even tried fixing the code, but new problems arose time and again). I for one am looking to write KDE frontends to some Java projects of mine, so I'm relieved to hear it's being worked on.

I'm glad somybody is looking at those java bindings! I made an application in Java which is useless now, because the Java bindings where broken.

The qtjava bindings of KDE release 3.0.4 didn't work. Richard Dale, who wrote and maintained the java bindings, has left the scene. Now the javabindings mailing list is afwul quit :(

I wrote some code which made it possible to use DCOP under Java. The DCOP bindings for Java allready made it possible to invoke DCOP ojbects. My additions made it possible to implement a DCOP Object in Java. I added this stuff to the kdejava bindings. Since the mailing list for kdejava only containts spam lately, these additions didn't make it to the CVS repository.

I would like to get in contact with somebody to see how these addition can make it to KDE's CVS

Just to clarify: AFAIK, Marcus was working to make them compile. He was not and is not interested in maintaining them. At this point the KDE/QtJava, KDE/QtC, Objective-C, dcop*, Ruby*, bindings are _not_ being actively maintained.

The only bindings I know which have active developers are Qt#, PerlQt and PyQt. On the Qt# front: we are busy with a full scale refactor of the binding generator. We now have our own c++ parser which produces an XML representation of the Qt API written in C#. We also have a new binding generator called binge which feeds on the XML representation and is thought of as a replacement for kalyptus. The advantage of the XML representation and associated tools is the ability to target the XML representation which only would need to be updated per Qt/C++ release.

IMHO, the different binding projects should concentrate on consolidating. Kalyptus and the different bindings that depend upon it are horribly difficult to update from release to release. My hope is that Qt# will mature and allow the binding developers to concentrate on one binding. Languages would then be added by creating compiler frontends for DotGNU and Mono.

with qtopia running on more and more and being super flexible and workable as a UI in itself ... (i'd rather login to a server via Konqui or Moz and get a java-applet representation of my account that looks like Qtopia and runs in my browser than use VNC etc). Java and Qt are crucial for a good deve environment.

I see gcc's java support helping to convert Koffice from KDE to Qt-java apps that will run on my Zaurus or my Paron

I can see the benefit in using the former, though I'm a little surprised that with so much other XML RPC work it was necessary to create what sounds like WSDL. There are of course already many WSDL binding tools, both Schema->Language and Language->Schema.

As for the latter, the idea that open source developers will converge on some kind of Microsoft CLR clone is naive at best. The reality is that there are today a large number of enterprise-level tools and applications written in Java for Linux, from Eclipse and JBuilder to WebLogic and WebSphere, and to propose neglecting support for this established and complete environment in favour of some half-baked, high-risk Dotnet clone is simply a non-starter.

Currently, Noatun is pretty horribly borked. No other KDE app gives me as much trouble as Noatun. When it isn't segfaulting, it's choking on ShoutCast playlists. And it's still horribly slow to start and very fragile (try loading several thousand songs into a playlist). Anybody working on this for 3.2?

If you have a lot of songs, there is a file system based playlist called Hayes that you can add you mp3 directory and it automatically updates whenever you add songs to the disk. I find it handles large playlists fairly well. here is the url: http://freekde.org/neil/hayes/

I've tried that, and it's still quite unstable at times. It just seems to me that Noatun is a consistantly ignored aspect of KDE. The impression from the Noatun developers themselves, that Noatun is done and finished doesn't help any :(

Have you ever tried to load an mp3 from a network fs like NFS, played it succesfully, then disconnected and loaded noatun again? Noatun will try too much time to load that file even if you simply opened noatun without any particular request.. The only thing that I found to do is to open noatun config file and erase the line where is the call for that file.
This is the reason why MPLAYER is a LOT better (yes it has to do nothing with KDE, but there is no competition).
And yes, It gives the sensation that noatun isn't at the same level of KDE in general.

that will be great! shuffling is its weak point right now. imho :) good work. I havent had too much trouble with its stability. the only real problem i have w/ all 3.x series up to beta2(havent gone further) is that the session management does not work on noatun. it will not start up after saving the session w/ it running.

Yes, Noatun always seems to behave in an odd way, even for the simplest things. For example, loading of playlist files from xmms seems to result in the comments in such files appearing as track entries in the playlist in Noatun.

> Wrong view: No binaries => no packaging related bugs. :-)
Yes, I understand your point, that way developers can concentrate on actual kde bugs instead of waisting their time tracking bugs that end up beeing distro related. I understand but I don't agree. Most people will install 3.1 using distro specific binaries, for them it doesn't really matter wether bugs related to packaging or not.
If I recall correctly there were quite a few packaging problems in Beta2. No more testing means that we don't really know how the final packages will turn out. Yes, I know binaries would slow down the process, but still, I think it would be worth it.

Maybe a possible strategy could be, releasing the final version of the sources with a preliminar version of the binaries. Release a final stable binary version only one or two weeks later.
I really don't like the fact the binaries for the stable kde release are in fact, not (IMO) sufficiently tested and potencially buggy.

Perhaps cooker will get binaries, we got some for RC1.
I think that only having sources doesn't help to have a lot of beta testers.
On the other side, people who get and compile sources will probably send better bug reports.

i would happily give it a try and report bugs, but i won't mess up my system with a self-compiled kde. there was a time, when i compiled all my programs myself. but not anymore. if i ever find a non-packaged program i just package it before installation.

no time and resourced to do so for kde. conclusion: no testing on my side. just waiting on the final release without my contribution...

and i'm quite sure, there will be package-related bugs on the "final" version, as we didn't test it in an rc...

Don't be silly. The only pre-release testing that takes place on most Unix world software is by developers and experienced users who know how to compile from source. And you wonder why KDE (or any other number of complex systems) is so rough at the edges, despite the _appearance_ of sensible release management...

I have often wondered as to how does one package kde for a distribution. I can compile KDE (not very well - need lots of luck). But how does one do the packaging trick ? I figure that you need to create a bunch of rpms with the correct distribution specific locations etc. But isnt there more in terms of code changes to be done for a distribution. For eg, Mandrake has this unified menu system. How do I support that ?

Yeah, I know, RTFC, blah blah, read the code. Is there any other way ?

If any of you people who know how this works and can send some info or even better write an FAQ, I would be more than willing to do the actual task.

One thing I really like about Nautilus are the smooth, rounded boxes around the name of an icon when it has been highlighted. It gives Nautilus a very polished, pleasing look. The boxes in Konqeror just don't look as good. The worst part is that icon names (in Konqueror) are NEVER centered in the "highlight" box.

I was also wondering if the kasbar could have an option to look more like a standard taskbar. By this I mean the icons for minimized windows would be longer and thinner (allowing more of the name of the window to be shown). I really (and I mean really) love the thumbnail of minimized windows that pop up from the kasbar. However, the kasbar won't be adequate replacement for a standard taskbar (for me at least) unless you have a better idea what each icon is BEFORE moving the mouse to bring up the thumbnail. Maybe it's just me?

As for the desktops icons, I noticed that too when I played with Nautilus recently. I was like why does this feel so nice, when it doesn't really do anything special. I think you are right, it's thinks like the icon highlighting and font shadows.

probably the reason for all projects missing features. Noone has coded it yet ;-).

Congrats to the KDE-team, this looks like a very nice and polished desktop.

Personally I use GNOME, but I'm happy that there is also a KDE-project that does very well, because this means that the two projects can focus in different directions and that way make more *NIX/people happy than any single project could do on it's own.

It's not feasible. Menus are only around for a short time so if their shadows don't change when the stuff under them changes, you won't notice. Also, menus never resize. Windows are around for a long time, so their shadows need to update when things change under them to look consistent. However, there is no efficient way to tell when the shadow needs to be updated. Also, when resizing a window smaller, the uncovered parts of windows underneath haven't been painted yet so there is no way to know what they will look like to calculate the shadow. When X gets a transparent window extension it will handle all this internally, which is much more efficient since it knows everything there is to know about how the screen looks at all times. Then we can have window shadows and translucent noatun skins and all that good stuff.

It really took me a long time to figure out why I liked GNOME so much. I spent a week switching back and forth from KDE to GNOME (after installing RedHat 8). Nautilus really is beautiful... Unfortunately GNOME is missing a few things (like a real file selector and show desktop button) which are difficult for me to live without.

I'm hoping the Konqueror guys will spend less time on browser features and more time on the file manager.

Then _only_ think I like about Nautilus is that smb:// works.
Wish Konquereor would get better support for that. Currently,
it krashes, hangs, uses 100% CPU, fails, and its idiotic
to start lisa by hand first. Lisa is also too idiotic in its scanning of the local
network. Not funny having a few thousand clients do that on a class B net.

Great. Remember security and authentication.
I'm dreaming of an (optional) data encryped filesystem with
Kerberos authentication. Looks like NFSv3/4 with gss-rpc might solve that,
but I would also like ordinarey users easily browse them from something
like Konqueror.