Skip to content

Kernel Cousin KDE #16

Wednesday, 4 July 2001  |  Numanee

This week in KC KDE, Aaron and Rob bring us news about SOAP and DCOP, KMonop vs Capitalist, a new Cervisia KPart (2), print services integration into Konqueror, the KDE CVS Geek of the Week (you may now use PrintScreen for those KDE snapshots), and more.

Comments:

Re: Kernel Cousin KDE #16 - Brian Ewbank - 2001-07-04

Sounds like some more sweet stuff from the KDE team! Keep up the great work guys!

FTP via proxy - Walter - 2001-07-04

I read about the FTP problem in KC. It was said that when the control connection is idle for too long while you are downloading a big file, it will be droppen from the masquerading table in the router. This is indeed the problem, but the solution is not to try to artificially keep up the connection. Instead you need to load the Linux FTP masquerading module into the router's kernel. This will make Linux reset the timeout on the control connection whenever data flows over the data connection. Walter (The list archive is down and I'm not subscribed to the KDE list in question anyway, so I would appreciate if someone forwards this.)

Re: FTP via proxy - DavidA - 2001-07-05

For some reason my Cisco router won't load a Linux kernel module and how come other clients on other platforms work?

Re: FTP via proxy - Walter - 2001-07-05

I was assuming that a linux transparent proxy was used. If your Cisco doesn't have a similar way to prevent dropping of NAT entries file a bug report with Cisco! Walter

Has anyone tried the KDE2.2 beta1? - Andi - 2001-07-04

Today I installed the KDE2.2 beta1, but experienced problems with KSycoca and some none existing MIME types. The packages are the SuSE 7.1 rpm´s and were installed completly. KSycoca said something like wrong Version number ... expect version 28... Actually I couldn´t do anything. Kicker didn´t display any app and via Alt+F2 commands didn´t function. As I started Konqueror it just come up with a message like:"http is not supported" Maybe the rpm´s are broken?

Re: Has anyone tried the KDE2.2 beta1? - Adrian - 2001-07-05

try this: 1. logout 2. killall kdeinit 3. killall dcopserver 4. rm -rf /tmp/ksocket-* and try again...

Re: Has anyone tried the KDE2.2 beta1? - Andi - 2001-07-05

Thanks Adrian, the remaining ksocket files were the reason. Good Build, it runs quite stable for more than 8 hours!Once there come up a klaunch problem, which I can´t reproduce either.

Re: Has anyone tried the KDE2.2 beta1? - Justin - 2001-07-05

I haven't tried the new 2.2 beta, but I have a tip for any KDE upgrade: You should try logging in with a new user, or delete your ~/.kde folder if you don't mind starting fresh. Often times, old settings files clash with new versions of programs. -Justin

Re: Has anyone tried the KDE2.2 beta1? - Inorog - 2001-07-05

Hmm... I never do this. I think I have my .kde dir since some pre 1.95 version. Is there a technically sound reason behind this advice?

Re: Has anyone tried the KDE2.2 beta1? - Aaron J. Seigo - 2001-07-05

unless you are interested in seeing how KDE starts up the first time its run, this is usually not necessary. in the past, it has happened that certain config files have become corrupted to the point of crashing some app (hopefully this weakness is being fixed with a new check summing class to piggyback on the reading of the file) and that particular config file needed to be removed. sometimes when it is especially difficult to figure out which file is the offender or the user is particularly lazy/not attatched to their settings they will remove all of .kde ... i have a rather ancient .kde, run KDE2 from CVS and the worst i've had to do is rm a file or two that got corrupted... and as a "bonus" it was always pretty obvious which file it was that i should delete =)

Re: Has anyone tried the KDE2.2 beta1? - Jason Katz-Brown - 2001-07-05

try running kbuildsycoca Jason

GPL KDE Apps for Windows - Raymond Fingas - 2001-07-06

The GPL does prohibit distributing binaries linked to proprietary libraries such as free-beer QT for Windows. One solution would be to distribute source only. A user is allowed to link GPL'd code against whatever she wants, so long as it is not redistributed in binary form. Someone could even write a wrapper app to do the compilation and installation and release it under LGPL or some other license that permits linking against the libraries. Of course, that only works for someone with all the stuff necessary to compile it, but still... it would be nice for the coolness factor of having KDE running natively under Windows, even if it wasn't tremendously useful for end users. Having the sources available might also help companies who could afford QT licenses and wanted to standardize on a KDE desktop internally, even on their windows boxes. Again, as long as they don't distribute it, the GPL doesn't care.