KDE-CVS-Digest for December 26, 2003

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.

Dot Categories: 


by David (not verified)

I'm really looking forward to use kapture instead of synaptic!

and... ofcourse KDE 3.2!

by Hein (not verified)

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

by Alex (not verified)

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.

by Hein (not verified)

Afaik GTK+ binding will be supported in future versions.

by Haakon Nilsen (not verified)

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?

by Arend jr. (not verified)

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

by Niek (not verified)

Speaking about GTK+, I saw this tarball on Zacks webpage:
Nice example of integrating GTK+ and KDE :)

by Niek (not verified)

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.

by Haakon Nilsen (not verified)

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).

by anon (not verified)

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. :-)

by Derek Kite (not verified)


Rob Kaper mentions kio_fuse with some links.


by Simon Edwards (not verified)

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.


by aleXXX (not verified)

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.


by KDE User (not verified)

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

by JohnCabron (not verified)

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!

by Derek Kite (not verified)

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.


by ac (not verified)

What exactly is the project "icecream" in kdenonbeta?

by Kurt Pfeifle (not verified)

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

by Derek Kite (not verified)

Is that what was used at the conference in August?


by Anonymous (not verified)

No, that was Teambuilder.

by ac (not verified)

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.)

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
Maybe better fix libyahoo's "horrible memory management"...

[1] http://libyahoo2.sourceforge.net/

by Jason Keirstead (not verified)

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.