NOV
5
2002
|
KDE 3.1 RC2: Ready For A HammeringThe KDE Project today released KDE 3.1 RC2, probably |
![]() |
Comments
Great !!
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 !
Re: Great !!
After you finish dl-ing the cvs version, just do cvs update -d in kdelibs, kdebase .... dirs ...
kdebindings
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.
Re: kdebindings
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.
Re: kdebindings
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
QtJava
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.
Qtopia - [WAS: Re: QtJava]
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!
Re: QtJava
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.
Noatun fixes
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?
Re: Noatun fixes
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/
Re: Noatun fixes
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 :(
Re: Noatun fixes
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.
Re: Noatun fixes
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.
Re: Noatun fixes
Hayes look cool. Any plans for including it in KDE?
Re: Noatun fixes
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.
Re: Noatun fixes
That sucks... I think it was really great!
No more XMMS for me! :=)
Re: Noatun fixes
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.
Re: Noatun fixes
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.
Re: Noatun fixes
Perhaps you can put it in kdeextragear-1.
some application in kdeextragear are very good.
k3b comes to mind !
regards
Re: Noatun fixes
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.
Re: Noatun fixes
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.
Binary Packages ?
Is there going to be a binary package release for this version ?
Re: Binary Packages ?
No.
Re: Binary Packages ?
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
Re: Binary Packages ?
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.
Re: Binary Packages ?
Wrong view: No binaries => no packaging related bugs. :-)
Re: Binary Packages ?
> 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.
Re: Binary Packages ?
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.
Re: Binary Packages ?
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.
Re: Binary Packages ?
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.
Re: Binary Packages ?
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.
Re: Binary Packages ?
> 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. :)
Re: Binary Packages ?
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...
Re: Binary Packages ?
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...
How does one go about packaging this ?
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 ?
Couple of Requests for Future KDE Releases
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?
Re: Couple of Requests for Future KDE Releases
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?
Re: Couple of Requests for Future KDE Releases
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.
Re: Couple of Requests for Future KDE Releases
heh, gnome and kde seem to be focusing on mostly the same thing
Re: Couple of Requests for Future KDE Releases
Why don't we have Window shadows?
like the Menue shadows?
Re: Couple of Requests for Future KDE Releases
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.
Re: Couple of Requests for Future KDE Releases
when is the transparency extention to X going to be written.. i've been hearing about it for nearly 2 years now :-(
KInda Funny
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.
Re: Couple of Requests for Future KDE Releases
Hmmm.. My No1 Look&Feel problem with Konqueror (as file browser) is the background pattern. It doesn't look very good, especially with Keramik.
Re: Couple of Requests for Future KDE Releases
"View/Background Image..." allows you to change it.
Re: Couple of Requests for Future KDE Releases
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.
Re: Couple of Requests for Future KDE Releases
I plan to work on a scalable file-sharing solution in 3.2...
Re: Couple of Requests for Future KDE Releases
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.
Re: Couple of Requests for Future KDE Releases
Yes...
http://www.advogato.org/person/tjansen/diary.html?start=14
Re: Couple of Requests for Future KDE Releases
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
Pages