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!
Dot Categories:
Comments
Too bad i'm over cvs right now, i got desperated and started to dl cvs a couple hours ago, i hope i can get some of those mentioned bugs on kdebindings corrected :-)
Great work KDE team !
After you finish dl-ing the cvs version, just do cvs update -d in kdelibs, kdebase .... dirs ...
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
Gert-Jan van der Heiden
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
http://www.cdlusa.com/products/m-idphone.shtml
ciao and rule!
the different binding projects should concentrate on consolidating
Consolidating on the Binge development or on Qt#?
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.
Yes, Charles thinks Noatun is done, but it's his job.
I think Noatun has room to improve, so that's why I work on Hayes.
If you have problems with Hayes, do mail me about it. I want to improve Hayes. Don't let your impression of Noatun carry over to my Hayes work.
Hayes look cool. Any plans for including it in KDE?
It has been turned on three times by three different people (me, then Rob Kaper, then Kevin Puetz). Charles Samuels turned it back off every time.
He has his reasons, but I'll leave it for him to explain them, for fear of getting it wrong.
That sucks... I think it was really great!
No more XMMS for me! :=)
I'm glad you like it.
I woudln't say was, though. Hayes isn't going to disappear anytime soon. :-)
1.1.6 will see many improvements to shuffling.
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.
Perhaps you can put it in kdeextragear-1.
some application in kdeextragear are very good.
k3b comes to mind !
regards
kdeextragear-* are not part of KDE. In fact, it's one of the few portions of the CVS whose express purpose is to be forever out of the KDE release.
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.
Is there going to be a binary package release for this version ?
No.
no, because kde 3.1 final is right around the corner.. too much work. this is meant for people willing to test anyways, and that means ppl who compile from src :D
Nah, not really. I'd be willing to test it if there were rpms, but I'm not going to compile it. IMO it would be nice to have binaries to get rid of packaging related bugs.
J.A.
Wrong view: No binaries => no packaging related bugs. :-)
> 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.
J.A.
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.
J.A.
Yeah, I remeber when I used redhat... KDE packaes where buggy as hell.
Mandrake even have a policy to update their packages iwth bug fixes if any, even that some time have passed sinse release.
Maybe a rc_rc_kde-3.1 could be made just to test packaging, and then (one week later) when the bugs where fixed, release final? It would be really good, at least for distros that do care about kde.
Binary packages for what? Solaris? Debian GNU/Linux? i386? PPC?
Why don't you make binaries available for your favorite platform,
and others can use 'em? That's construcutive and helps the testing.
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.
> On the other side, people who get and compile sources
> will probably send better bug reports.
Yeah, or they'll send invalid ones due to their inability to compile things properly, or simply having a shafted environment. :)
i guess not, but that's bad.
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.
Any thoughts ?
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.
Why don't we have 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.
heh, gnome and kde seem to be focusing on mostly the same thing
Why don't we have Window shadows?
like the Menue shadows?
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.
when is the transparency extention to X going to be written.. i've been hearing about it for nearly 2 years now :-(
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.
Hmmm.. My No1 Look&Feel problem with Konqueror (as file browser) is the background pattern. It doesn't look very good, especially with Keramik.
"View/Background Image..." allows you to change it.
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.
I plan to work on a scalable file-sharing solution in 3.2...
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.
Yes...
http://www.advogato.org/person/tjansen/diary.html?start=14
Probably we are using different Konquerors:
mine is fast, clean, stable and supports smb:// pretty fine.
and lisa works fine too (otherwise -- who else would browse the hetwork looking for available nodes and their resourses?
;-D