KDE-CVS-Digest for December 26, 2003

Saturday, 27 December 2003  |  Dkite

In this week's KDE-CVS-Digest: Java bindings are now auto-generated by the build process. You can now mount KIO slaves on the filesystem with the fuse_kio module. Karbon now has snap to grid and curve smoothing. Initial import of the new theme manager. You can now create application configuration files with KConfEdit.

Comments:

Kapture this! - David - 2003-12-27

I'm really looking forward to use kapture instead of synaptic! and... ofcourse KDE 3.2! /David

Re: Kapture this! - Hein - 2003-12-27

Let's hope with Plastik as default. Screenshot, tse tse.

Thanks - Alex - 2003-12-27

Thanks for the updates, I'm suprised Qt has so many bindings, I thought there was only a C++, and Python version until now. =) This is great, before I thought GTK+ was my only real choice for other languages.

Re: Thanks - Hein - 2003-12-27

Afaik GTK+ binding will be supported in future versions.

fuse_kio! - Haakon Nilsen - 2003-12-27

So now there's something called fuse_kio that will let you mount any KIO slave on the *filesystem*? And this is mentioned only casually? If it does what it says it does, it's freaking awesome! Can someone explain how this works? And will it be part of KDE 3.2?

Re: fuse_kio! - Arend jr. - 2003-12-27

And, is this a first step in letting GTK+ apps be able to use KIO slaves?

Re: fuse_kio! - Niek - 2003-12-27

Speaking about GTK+, I saw this tarball on Zacks webpage: http://www.automatix.de/~zack/qtgtk.tar.bz2 Nice example of integrating GTK+ and KDE :)

Re: fuse_kio! - Niek - 2003-12-27

From what I understand, this is just a KIO slave for the protocols supported by FUSE/AVFS. See http://www.inf.bme.hu/~mszeredi/avfs/ for a complete list of supported protocols.

Re: fuse_kio! - Haakon Nilsen - 2003-12-27

I see, oh well. It looks like maybe AVFS is what I'm really looking for anyway, since it lets you mount ssh, webdav and other kinds of protocols too. I still think it would be cool to have some sort of userspace program that utilizes kio slaves to "mount" any kio-supported protocol though, since it potentially could take kio usability to a whole new level (read: ANY program would benefit, be it KDE, GTK, console etc, and with no recompile or porting efforts).

Re: fuse_kio! - anon - 2003-12-27

I don't know about that, the first mention explicitly says that it will allow you to, "...mount KIO slaves with the fuse_kio module." I don't usually say I'm mounting something unless I'm attaching it to the filesystem. Also he writes: ---- I have disabled progress dialogs where I found them activated (it was quite disturbing to have a progress indicator popup on CLI). ---- If we were using FUSE/AVFS --> KIO then would he be worrying about dialogs popping up? To me, this really makes it sound like it's KIO --> FUSE/AVFS. Which would be excellent IHMO. :-)

Re: fuse_kio! - Derek Kite - 2003-12-27

http://capzilla.net/blog/2451/ Rob Kaper mentions kio_fuse with some links. Derek

Re: fuse_kio! - Simon Edwards - 2003-12-27

Short: Yes, the original poster is right. Long: From what I understand, FUSE lets you write filesystems that run as normal userland programs, but can still be mounted like real kernel filesystems. It kind of bridges kernel and user space. Now, fuse_kio is a program for use with FUSE which lets you use any KIO slave. It kind of bridges FUSE and the KIO slave system. String all of that together and you can mount KIO slaves like any other kernel filesystem! KIO slaves of almost all of the AVFS protocols have been around for quite a long time already. -- Simon

Re: fuse_kio! - aleXXX - 2003-12-28

It is a "fuse protocol" with supports kde ioslaves. I tested it until now only by mounting the fish-ioslave. But it's still very early in development. Expect more to come. Bye Alex

Re: fuse_kio! - KDE User - 2003-12-27

Yes this is part of the KDE/Debian/Enterprise work by Alex and Kevin. =)

Too many features/bugs! - JohnCabron - 2003-12-27

I wasn't expecting to see so many new features get included by this time, when we approach a stable release. And instead of the increasing number of bugs, I was expecting to see most bugs get fixed. I like KDE and I used it every day, but I think it is starting to look like MS-Office: too many features you don't need + too many bugs!

Re: Too many features/bugs! - Derek Kite - 2003-12-27

None of the new features are for the 3.2 release. They are in kdenonbeta, which is where developers commit stuff they are working on. Derek

icecream? - ac - 2003-12-27

What exactly is the project "icecream" in kdenonbeta?

Re: icecream? - Kurt Pfeifle - 2003-12-27

building KDE with the help of distcc-like distributed compile machines....

Re: icecream? - Derek Kite - 2003-12-28

Is that what was used at the conference in August? Derek

Re: icecream? - Anonymous - 2003-12-28

No, that was Teambuilder.

Kopete to boil it's own soup? Why? - ac - 2003-12-29

<i> Matt Rogers committed a change to kde_yahoo_backend: kdenetwork/kopete/protocols/yahoo Start of a native KDE backend for the yahoo protocol. I've had this in the works for some time now. The many reasons include libyahoo's horrible memory management and better integration with the rest of KDE (use of KIO, etc.) </i> Instead of reinventing the wheel, maybe some resources should be spend on improving libyahoo [1]. libayhoo seems to be quite feature-complete (it even has webcam support), so I really don't see the point of writing an own yahoo library... And this will certainly take a huge amount of time to reach the features of libyahoo... Maybe better fix libyahoo's "horrible memory management"... [1] http://libyahoo2.sourceforge.net/

Re: Kopete to boil it's own soup? Why? - Jason Keirstead - 2004-01-06

If libyahoo is feature complete, then porting it to the KDE codebase will result in all those features still being supported, along with the benefits of KDE like KIO support for file transfers, better memory management through QObjects, etc. Really, maintaining links to these external C libraries in Kopete has never been anything but a pain in the ass. The code is horrible to maintain because it is all C based, there's constant memory problems, getting things updated in the main tree is often a pain, and you've got all this duplicated/obsoltee code everywhere because algorithms are already present elsewhere in QT or KDELibs. Couple this with the fact that you can't integrate the KDE code into the library because then you lose the ability to update it when new versions come out, and you've got a big mess. Thats why we have our own homegrown support for all protocols now except Yahoo and SMS. It's just not worth the effort to use the other code.