Hello, There are a few things which I've been working on, or thinking about, in the hopes of making CRUX's KDE implementation better. 1. http://marc.theaimsgroup.com/?l=crux&m=114198584022117&w=2 2. get some sort of inotify support. Currently, I'm testing the inotify via gamin solution. At some point, I'm going to see if ./configure --enable-inotify, for kdelibs, provides the same functionality with less overhead/complexity; I will talk to some KDE developers about the merits of each approach. If anyone wants to quickly add inotify support to their current KDE installation, and already has libfam or gamin installed, then he/she has merely to do the following: a) make sure you're running an up-to-date kernel (at least 2.6.14.6, IMHO) b) either copy your /usr/src/linux/include/linux/inotify.h to /usr/include/linux/inotify.h, or else use the 2.6.15.4 version found in ports/sten/glibc/inotify.h, if you subscribe to my repo. Alternatively you can install ports/sten/inotify-utils. c) prt-get remove libfam d) prt-get install -fr gamin OR prt-get remove -fr gamin e) killall /usr/sbin/gam_server f) otherwise, you'll need to rebuild everything kdelibs down, to enable inotify, and to let apps run without libfam... 2.5 Gamin has issues with KDE: (http://lists.kde.org/?l=kfm-devel&m=114209917111095&w=2). From a discussion on kde-packager, I've learned that all applications that use KDirWatch can use inotify through kdelibs. Kat is the sole exception. The kdelibs --enable-inotify approach is said to be a cleaner, more robust solution than Gamin + KDE. 3. Prelink. Many of the "big" distributions have it, and it apparently speeds up KDE quite a bit (I didn't notice anything mind boggling, but it's a nice speed up..maybe 20-40%). I finally got it to work with libelf, instead of elfutils. If anyone is interested, please test it, and email me with your prelink experiences. Until this latest attempt, mine had never been altogether successful, but prelink has worked great for me for the last few weeks. 4. What would you like to see in, or out of, CRUX's KDE? Cheers, Nick
Hi Nick, Let me start with showing my great appreciation for involving the list/users in this :-) On Tuesday 14 March 2006 13:37, Nick Steeves wrote:
Hello,
There are a few things which I've been working on, or thinking about, in the hopes of making CRUX's KDE implementation better.
1. http://marc.theaimsgroup.com/?l=crux&m=114198584022117&w=2
About that: I started removing the doc stripping from my own KDE packages. I quickly discovered that it will add some complexity because we still should strip all the non-en subdirectories. Anybody got a cool way to accomplish that? I'm thinking about asking upstream to support linking to online documentation in some way, perhaps as a compile-time option that will also disable the documetation generation.
2. get some sort of inotify support. Currently, I'm testing the inotify via gamin solution. At some point, I'm going to see if ./configure --enable-inotify, for kdelibs, provides the same functionality with less overhead/complexity; I will talk to some KDE developers about the merits of each approach.
KDE + gamin has proven rock solid here ever since gamin was imported into opt. I haven't had to restart gam_server a single time. Let's see how the native solution works.
If anyone wants to quickly add inotify support to their current KDE installation, and already has libfam or gamin installed, then he/she has merely to do the following:
a) make sure you're running an up-to-date kernel (at least 2.6.14.6, IMHO) b) either copy your /usr/src/linux/include/linux/inotify.h to /usr/include/linux/inotify.h, or else use the 2.6.15.4 version found in ports/sten/glibc/inotify.h, if you subscribe to my repo.
inotify.h is already in linux-libc-headers 2.6.12.0 which is part of glibc from the 2.2 branch :-)
On Tuesday 14 March 2006 19:41, Mark Rosenstand wrote:
I'm thinking about asking upstream to support linking to online documentation in some way, perhaps as a compile-time option that will also disable the documetation generation.
Or perhaps Nick would be willing to do it, as they probably take a packager's request a little more seriously and he'd probably be better at explaining the situation? :-)
2. get some sort of inotify support. Currently, I'm testing the inotify via gamin solution. At some point, I'm going to see if ./configure --enable-inotify, for kdelibs, provides the same functionality with less overhead/complexity; I will talk to some KDE developers about the merits of each approach.
KDE + gamin has proven rock solid here ever since gamin was imported into opt. I haven't had to restart gam_server a single time. Let's see how the native solution works.
It seems a little slower (i.e. opening a directory in konqueror and touch/rm'ing a file will take ~500 ms for konqueror to reflect the change) but pretty solid. I think it's a worthy sacrifice in order to get rid of an additional package and process, so thumbs up for enabling it :-) Nick, do you know what happens if libfam is available and kdelibs itself is inotify-enabled? Which will take precedence?
participants (2)
-
Mark Rosenstand -
Nick Steeves