Image 01


An-Cheng Huang

Network 117 comments

by pach
Score 50.0%
Jan 01 2005
I've just released an experimental version that supports connecting to a network specified by the user. Please test this feature and let me know if it does not work. Thanks! - Jan 01 2005
There was an ebuild for an earlier version, but there isn't one for the current version...

The current version is a monitor that can also change the bit rate and power management settings. The next version (coming soon) will add the ability to connect to a specified network. - Dec 28 2004
When you build the application from source, have you tried the following?

./configure --prefix=<your_KDE_base>

This should put all the binaries and icons in the right place when you do "make install". That way, the application should be in your $PATH, and it should be able to find the icons correctly. - Dec 19 2004
It could be a problem with ndiswrapper. I remember some of the earlier comments were about ndiswrapper returning bogus values for quality or something like that. Have you tried the open source driver for the Intel 2100? It's already in stable status. Try here:

Hopefully it will work for you. - Dec 19 2004
Sorry for the late reply. I plan to implement the capability to connect to different networks, so it will probably have something similar to what you want. Thanks for the suggestion! - Dec 19 2004
Yes, of course. In early May, when someone told me about kwifimanager, I sent an e-mail to the kwifimanager developer asking about how I can contribute to the kwifimanager application. Since I haven't heard anything from him, I guess he is probably not interested. By the way, from what I heard, the KiFi (another similar application) developers had similar experiences communicating with him, so I guess it's not just me. - Oct 18 2004
Thanks for the feedback. Are you referring to the icons in the configuration dialog or the systray icons? For the configuration dialog, I just use the system default icons for "Settings", etc., so the icons displayed depend on the distribution. For the systray icons, I browsed the Crystal SVG icons but didn't find anything suitable for this purpose. Let me know if you have any suggestions. - Oct 01 2004
That is certainly a good feature. However, I think it probably makes more sense to support that after the support for changing ESSID is implemented (since otherwise you will have to use another tool to change the ESSID anyway). If you think "read-only" is acceptable, I will consider implementing it first. - Sep 17 2004
It shouldn't be difficult to allow a user to specify a custom script/program. However, I would prefer a solution that is transparent to the user. The problem is that, of course, this would require distribution-specific code to handle, e.g., DHCP stuff. I haven't figured out a good solution yet, and that is why I haven't added support for setting network name (ESSID) yet. Reconnect involves the same issues.

For now, you may want to try kwifimanager. IIRC, it does allow a user to specify custom scripts for some events. - Sep 07 2004
I think kwirelessmonitor is actually more similar to kwifimanager, kwlaninfo, etc. I'm not familiar with the applications you mentioned, so could you describe more specifically how you would like to see these apps merged? Thanks. - Sep 07 2004
Ok, so that explains it. The driver reports quality 0/0, and it is interpreted as "no signal". Since several people have reported similar problems related to ndiswrapper/driverloader, I'll try to implement a workaround, e.g., using the signal/noise values. - Sep 04 2004
If you are compiling from source, one possible problem could be that the versions of your running kernel and your kernel headers don't match.

Otherwise, it could be a problem with ndiswrapper. Could you send me the following to help me determine the problem?

1. Output of 'iwconfig'
2. Output of 'cat /proc/net/wireless'

Thanks. - Sep 03 2004
Thanks! Keep up the good work! - Aug 23 2004
Unfortunately, right now it only supports a single instance. This has actually been on my todo list for a while. I just haven't had time to look at it yet... - Aug 15 2004
So you would like the option to display the information on the panel instead of in the system tray (i.e., only one will be present)? - Aug 15 2004
Could you describe more specifically what you would like to see on the panel? Thanks! - Aug 03 2004
Yes, it seems that if scaling is enabled, anti-aliasing is done even when the pixmap is exactly the same size. Disabling scaling seems to work pretty well. I'll do that in the next release. Thanks. - Jul 12 2004
I believe the reason for the blurring is that the icons are 32x32, and they are scaled to 22x22 for the systray. Please e-mail me a link to your icons so that I can take a look. Thanks! - Jul 11 2004
That's a good point. I'll address the flickering issue in the next release. - Jul 11 2004
Ok, so the result confirms what the driverloader website says, i.e. only "signal" is meaningful. However, these numbers should not cause a "Device error". It seems the only probable explanation I can see is that you are using a kernel with wireless extensions earlier than version 11 or using wireless tools earlier than version 22, but this is unlikely since those versions are quite old...

Since I can't test driverloader, could you check a few things?

1. Just to make sure, what's the output of 'iwconfig --version'?

2. What's the output of 'cat /proc/net/wireless'? It should be similar to iwconfig output.

3. What value does gkrellm display? It's probably the signal value or something derived from it. - Jul 11 2004
The headers seem to be fine. You mentioned that you needed some tricks to make the card work. Could you explain what the tricks are? - Jul 01 2004
My guess is that driverloader probably only has partial support for the Linux Wireless Extensions. Could you use 'iwconfig' and see whether it displays the quality, signal, and noise values? (The driverloader web site says it only provides signal, not the other two.) - Jun 28 2004
In the new version (0.2.4), I re-implemented the way kdesu is used. Now the application doesn't ask for the root password until the first time you try to change the wireless settings (i.e., switching to the "Settings" page in the configuration dialog). Personally, I think it is much less annoying now. I hope you also find this solution better than the previous implementation! - Jun 26 2004
Yes, you are right. It is a bit annoying. At first, I thought about simply installing the binary setuid root, but since most people consider that a security risk, kdesu is the compromise solution I decided to use. Unfortunately, as you said, I don't think kdesu supports the sudoers thingy.

I'm trying to figure out a more convenient way to do this. Hopefully you'll find something better in the next release. - Jun 15 2004
root is needed to change the wireless settings, and yes, if you click "Ignore", you can still see the interface status (you just can't change the settings). - Jun 14 2004
I think I have solved the transparency issue in the latest release (0.2.2). It is done by creating a custom mask when merging two pixmaps, so this should be able to handle both changing panel color and using background image on panel. Please try the new version and let me know if it works for you. Thanks! - Jun 13 2004
I think I have solved the transparency issue in the latest release (0.2.2). It is done by creating a custom mask when merging two pixmaps, so this should be able to handle both changing panel color and using background image on panel. Please try the new version and let me know if it works for you. Thanks! - Jun 13 2004
I'm not sure about gentoo... On Red Hat/Fedora, there's a package called "glibc-kernheaders" that includes everything in /usr/include/linux. Maybe there is something equivalent in gentoo?

In the worst case, I guess you could try copying the "wireless.h" file in your kernel source to /usr/include/linux/ and recompile the application (of course, back up the original file before trying this). - Jun 12 2004
That probably means your glibc kernel headers were not updated when you upgraded the kernel. You can double check this by comparing the file (/usr/include/linux/wireless.h) with the one from your kernel source (i.e., <your_kernel_source_dir>/include/linux/wireless.h).

For 2.6.5, WIRELESS_EXT should be 16, not version 15 as you saw in your glibc kernel header. - Jun 12 2004
Sorry for the late reply. I was on vacation without network access for a week. I just took a quick look at madwifi, and it seems to implement the wireless extensions, so that shouldn't be the problem. Could you do the following:

grep WIRELESS_EXT /usr/include/linux/wireless.h | grep define

and let me know the result? Thanks! - Jun 10 2004
Ok, I think I've found where the problem is. My guess is that you are using a background image for the panel. In other words, the actual color of your panel/systray is white, and what you are seeing on the panel/systray is the background image.

The problem is, the kwirelessmonitor icon is filled with the color of the systray, not the background image. If you go to "Control Center->Appearance->Colors" and change the "Color Scheme", then my systray icon should pick up the color when starting up. However, if you go to "Control Center->Appearance->Panels" and choose "Enable background image", then this background image will be on top of the actual systray color, and my icon will use the actual color.

I guess to support background image for panels, I'll just have to figure out a way to merge two pixmaps together and preserve the transparency. - May 25 2004
Actually, I think it's more likely a Qt problem, but who knows, it might even be an underlying library (though unlikely). It could be due to different KDE/Qt/other libs versions or because of distribution-specific patches.

Unfortunately, I don't think I will have enough time to install gentoo. But I will try to install another distribution (probably SuSE) to see if I can replicate your problem. - May 22 2004
(1) If you are compiling from source, it's possible that your running kernel and your glibc kernel headers (in /usr/include/linux) are of different versions.

This could happen, for example, when you upgrade to the latest kernel without upgrading the headers.

(2) If you are using one of the RPMs, make sure it's compiled for your distribution and version. - May 21 2004
Mm... could you tell me which distribution and version you are using? Since I've tested RH9 and FC2, I guess you are using a different distribution, and somehow (!?) the same function call returns different results on different distributions. If that's the case, I'll have to install the particular distribution to look for the problem... - May 21 2004
Yes, the pngs are transparent. However, the actual tray icon is constructed by merging two pngs together, and currently I haven't figured out a way to do this that preserves the transparency.

Right now, the background color of the icon is set to the color of the system tray when the application is started, so it should "feel" transparent (if you don't change the color theme after it's started).

If the icon background you see is always white regardless of the system tray color, then there's probably a bug somewhere. Could you confirm if this is the case? - May 20 2004
Are you sure it's always white? The background color for the icon is set to the color of the system tray at the time you start the application, so it should "feel" transparent. Of course, if you change the color theme after the application is started, then the color would become incorrect, but it should not always be white. Could you confirm if this is the case?

The current implementation is a temporary solution. I'm still trying to figure out a better way, for example, bitblt two pixmaps together while maintaining transparency (which I haven't figured out how to do), or use the fake transparency but construct the icon on the fly (which would impact performance). - May 17 2004
Could you elaborate on what you mean by "transparent background"? Thanks! - May 17 2004
1. Regarding the icons:
(1) If building from source, you need to do:

./configure --prefix=<your_KDE_base>

where <your_KDE_base> can usually be found using "kde-config --prefix". (For SuSE, it seems to be "/opt/kde3" or something like that.)

(2) If using one of the RPMs, make sure it is built for the distribution (and version) you are using.

2. Regarding "no signal":
(1) If building from source, make sure your glibc kernel headers (those in /usr/include/linux) and your running kernel are of the same version.

(2) If using one of the RPMs, make sure it is built for the distribution (and version) you are using.

3. Regarding "run on start-up":
If you don't close it when you logout/reboot, I believe it will be started automatically the next time. (I haven't looked at how exactly this works, but this is the case on my machines.) - May 13 2004
You need to do:

./configure --prefix=<your_KDE_base>

where <your_KDE_base> can usually be found using "kde-config --prefix". (For SuSE, it seems to be "/opt/kde3" or something like that.) - May 07 2004
That's weird. I mean, how could ethtool.h possibly be included? Could you tell me which distribution you are using and your kernel version? Also, could you do the following:

grep WIRELESS_EXT /usr/include/linux/wireless.h

and let me know the result? - Apr 30 2004
One possible explanation is that your glibc kernel headers (the glibc-kernheaders package on Red Hat systems) and the running kernel may be of different versions. Could you check if this is the case? - Apr 28 2004
Were you using the RH9 RPM on FC2 test2? Because I saw exactly the same problem when I tried that at first, and that's why I had to build a separate FC2t2 RPM. For 0.1.0 the RH9 RPM worked on FC2 test1, so it seems that something changed in test2. - Apr 26 2004
That would explain why it failed. However, in that case, there still seems to be something wrong with the uic since the generated cpp file is supposed to have the "#include <klineedit.h>" line.

One possible explanation I can think of is that the particular version you are using actually generated a header file (which includes klineedit.h) that is then included by the generated cpp file. If that's the case, then it would seem to be a bug in the build system (I'm using the one provided by KDevelop), which automatically generates the test in "configure". Maybe I should switch to a new version and see if they have fixed it. - Apr 26 2004
Could you try the following:

(1) create a file "test.ui" containing the following lines:

<!DOCTYPE UI><UI version="3.0" stdsetdef="1">
<widget class="QDialog">
<widget class="KLineEdit">
<property name="name">

(2) at the command line, do

/opt/kde3.2.1/bin/uic -L /opt/kde3.2.1/lib/kde3/plugins/designer -nounload -impl test.h test.ui > test.cpp

(on a single line)

(3) check if "test.cpp" is generated by uic (based on your output, it should be

(4) if it's there, do

grep klineedit test.cpp

and see if any lines contain the word "klineedit"

(5) if no lines in "test.cpp" contain "klineedit", then there's something wrong with your uic, and that's why configure failed. (based on your output, this seems to be the most probable explanation)

I don't see why uic is needed for this application anyway, so maybe I can try to remove that test in the future. - Apr 25 2004
Ok, thanks! It's probably due to different versions of g++/Qt etc. Could you also tell me the distribution you are using and g++/Qt versions? Thanks! - Apr 13 2004
Could you take a look at the directory
to see if anything is there? Thanks! - Apr 13 2004
Could you take a look at the file config.log (generated by configure) to see what the command line was for the UIC test and what caused the UIC failure (search for "UIC" in that file)? Thanks! - Apr 13 2004