DEC
27
2003

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.

Comments

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

and... ofcourse KDE 3.2!
/David


By David at Sat, 2003/12/27 - 6:00am

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


By Hein at Sat, 2003/12/27 - 6:00am

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 Alex at Sat, 2003/12/27 - 6:00am

Afaik GTK+ binding will be supported in future versions.


By Hein at Sat, 2003/12/27 - 6:00am

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 Haakon Nilsen at Sat, 2003/12/27 - 6:00am

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


By Arend jr. at Sat, 2003/12/27 - 6:00am

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


By Niek at Sat, 2003/12/27 - 6:00am

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 Niek at Sat, 2003/12/27 - 6:00am

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 Haakon Nilsen at Sat, 2003/12/27 - 6:00am

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 anon at Sat, 2003/12/27 - 6:00am

http://capzilla.net/blog/2451/

Rob Kaper mentions kio_fuse with some links.

Derek


By Derek Kite at Sat, 2003/12/27 - 6:00am

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


By Simon Edwards at Sat, 2003/12/27 - 6:00am

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


By aleXXX at Sun, 2003/12/28 - 6:00am

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


By KDE User at Sat, 2003/12/27 - 6:00am

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 JohnCabron at Sat, 2003/12/27 - 6:00am

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


By Derek Kite at Sat, 2003/12/27 - 6:00am

What exactly is the project "icecream" in kdenonbeta?


By ac at Sat, 2003/12/27 - 6:00am

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


By Kurt Pfeifle at Sat, 2003/12/27 - 6:00am

Is that what was used at the conference in August?

Derek


By Derek Kite at Sun, 2003/12/28 - 6:00am

No, that was Teambuilder.


By Anonymous at Sun, 2003/12/28 - 6:00am

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

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


By ac at Mon, 2003/12/29 - 6:00am

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.


By Jason Keirstead at Tue, 2004/01/06 - 6:00am