

Network
Screensavers
System Software
The repo is here:
https://projects.kde.org/projects/extragear/network/knemo/repository
If you're not able to push to it, just email me the git patches, and we can take care of it that way.
Maintenance shouldn't seem too involved for someone who's interested in the app: just the usual bug reports and feature requests. And I already did a big chunk of the work getting it ported to KF5, including some breeze style icons. See the "frameworks" branch.
It's nice to know someone is at least tempted to take over maintenance. Feel free to send me an email if you want to discuss it further. - Mar 07 2016
https://projects.kde.org/projects/extragear/network/knemo/repository
If you're not able to push to it, just email me the git patches, and we can take care of it that way.
Maintenance shouldn't seem too involved for someone who's interested in the app: just the usual bug reports and feature requests. And I already did a big chunk of the work getting it ported to KF5, including some breeze style icons. See the "frameworks" branch.
It's nice to know someone is at least tempted to take over maintenance. Feel free to send me an email if you want to discuss it further. - Mar 07 2016
Yes, it would be useful. But there's a couple of things getting in the way.
The first is personal. I've finally come to admit that I'm just not interested in KNemo anymore. I'm willing to do bugfixes, but not add new features. To that end, I'm going to do a release in a couple of weeks to take care of one last minor request and then see if anyone wants to adopt the program.
The second is technical. Right now the statistics/accounting side of KNemo gets the most feature requests. People want it to limit traffic accounting to a specific wireless network (like you do), or offer a breakdown of traffic by connections (work, home, ...), or exclude specific IP ranges from accounting, etc.
KNemo COULD only log traffic when connected to a specific wireless network but it would only know about traffic that happened during the session. If you log out and download a large file from a console, KNemo won't know about it. It would tend to underreport traffic. As an X based program running with ordinary privileges, it's just not the right solution for anything beyond basic traffic logging.
I tried to get around some of this by having KNemo check vnstat's logs on startup. That way it can catch up with traffic that went over the interface since the last time you logged in. But vnstat only logs by interface, so we can't get any more detailed info from that.
A better solution would be for a kind of supercharged vnstat--maybe a daemon that listens for network connection changes via D-Bus? It could log the info that people want, it'd be more accurate than KNemo, and it wouldn't suffer the limitations that KNemo has. And then any app could poll it.
Unless I'm missing something, it doesn't look like the current vnstat, darkstat, ntop, etc. would do all that'd be needed. Someone might need to write something new, but it's not going to be me :) - Jul 16 2013
The first is personal. I've finally come to admit that I'm just not interested in KNemo anymore. I'm willing to do bugfixes, but not add new features. To that end, I'm going to do a release in a couple of weeks to take care of one last minor request and then see if anyone wants to adopt the program.
The second is technical. Right now the statistics/accounting side of KNemo gets the most feature requests. People want it to limit traffic accounting to a specific wireless network (like you do), or offer a breakdown of traffic by connections (work, home, ...), or exclude specific IP ranges from accounting, etc.
KNemo COULD only log traffic when connected to a specific wireless network but it would only know about traffic that happened during the session. If you log out and download a large file from a console, KNemo won't know about it. It would tend to underreport traffic. As an X based program running with ordinary privileges, it's just not the right solution for anything beyond basic traffic logging.
I tried to get around some of this by having KNemo check vnstat's logs on startup. That way it can catch up with traffic that went over the interface since the last time you logged in. But vnstat only logs by interface, so we can't get any more detailed info from that.
A better solution would be for a kind of supercharged vnstat--maybe a daemon that listens for network connection changes via D-Bus? It could log the info that people want, it'd be more accurate than KNemo, and it wouldn't suffer the limitations that KNemo has. And then any app could poll it.
Unless I'm missing something, it doesn't look like the current vnstat, darkstat, ntop, etc. would do all that'd be needed. Someone might need to write something new, but it's not going to be me :) - Jul 16 2013
I think I see what's happening. A new release will happen in about 2-3 weeks after I work on a few other things.
For now, close KNemo. In knemorc under the Plotter_* group, delete the MinimumValue & MaximumValue entries. Then restart. That should bring back the original auto range behavior. - Nov 12 2012
For now, close KNemo. In knemorc under the Plotter_* group, delete the MinimumValue & MaximumValue entries. Then restart. That should bring back the original auto range behavior. - Nov 12 2012
I don't know what's causing the problem or exactly what it looks like -- haven't run across anything like it, and Debian successfully uploaded 0.7.4 to experimental.
Would you email me the full console output starting with the cmake command? That might give us some clues. Also, you mentioned multiarch. Are you building for a non-native architecture? - Nov 12 2012
Would you email me the full console output starting with the cmake command? That might give us some clues. Also, you mentioned multiarch. Are you building for a non-native architecture? - Nov 12 2012
Possibly. KNemo doesn't store interface statistics by default.
Go in the config dialog and look in the "Statistics" tab for each interface whose statistics you want to store. Is "Activate statistics" checked?
You will also want to make sure that you have the Qt4 sqlite3 backend installed. On Debian / Ubuntu it's the libqt4-sql-sqlite package.
- Nov 04 2012
Go in the config dialog and look in the "Statistics" tab for each interface whose statistics you want to store. Is "Activate statistics" checked?
You will also want to make sure that you have the Qt4 sqlite3 backend installed. On Debian / Ubuntu it's the libqt4-sql-sqlite package.
- Nov 04 2012
Sorry about the confusion. I'm looking for where the KNemo's icons and theme files are installed. Example: find /usr -name knemo-monitor*
If they're installed in /usr/local you could try adding this to ~/.profile:
Quote:export KDEDIRS=/usr/local:/usr - Dec 06 2010
If they're installed in /usr/local you could try adding this to ~/.profile:
Quote:export KDEDIRS=/usr/local:/usr - Dec 06 2010
KNemo installs all its icons in the hicolor icon theme, which should work no matter which theme you're using. I suspect that they're installed in /usr/local, but KDE is only looking in /usr. Can you confirm that?
About the translation bug, I don't have much control over that. Would you mind filing a bug report here: bugs.kde.org Product: i18n Component: it - Dec 06 2010
About the translation bug, I don't have much control over that. Would you mind filing a bug report here: bugs.kde.org Product: i18n Component: it - Dec 06 2010
The screensaver uses a lot of point sprites. I noticed a while back that it would take up more and more memory if the point sprites were given non-integer sizes, but this only happened with the Intel driver. So I just rounded to the nearest integer.
I think the Intel driver--or maybe it was mesa--has been fixed since then, but I kept that workaround in kcometen4 in case people were still using whichever version was causing the problem. It didn't affect the appearance anyway.
I'm not sure what problem mfillpot was dealing with. I used to see other problems with the Intel driver but they've since been fixed. - Dec 05 2010
I think the Intel driver--or maybe it was mesa--has been fixed since then, but I kept that workaround in kcometen4 in case people were still using whichever version was causing the problem. It didn't affect the appearance anyway.
I'm not sure what problem mfillpot was dealing with. I used to see other problems with the Intel driver but they've since been fixed. - Dec 05 2010
Quote:Maybe doing plasma widget allows better control... it should be simpler to write these now days... I really don't know, hate UI programming :)
I'm not very interested in doing a plasma widget, though I might accept a patch if someone sends it along. And if it pops in the tray, it will still have the same problem.
Quote:And no, playing with the colors does not help, it colors the icon in any state...
Would you mind emailing a screenshot to me?
- Nov 30 2010
I'm not very interested in doing a plasma widget, though I might accept a patch if someone sends it along. And if it pops in the tray, it will still have the same problem.
Quote:And no, playing with the colors does not help, it colors the icon in any state...
Would you mind emailing a screenshot to me?
- Nov 30 2010
As far as I know, I can't do anything reliable with the icon order. KDE's system tray has complete control over that.
Regarding the netload icon, I agree that can be irritating. What about changing the "disconnected" and "unavailable" colors? Doesn't that do the trick? - Nov 29 2010
Regarding the netload icon, I agree that can be irritating. What about changing the "disconnected" and "unavailable" colors? Doesn't that do the trick? - Nov 29 2010
Sorry about the delay. You don't need to modify the source. But in addition to the knemo-monochrome-* icons, you'll need to create a desktop file that gets stored in apps/knemo/themes. The important keys:
Name=Name of Theme
X-KNemo-Theme=monochrome
Once those are in place, the icon theme will be available in the config dialog.
Feel free to PM me if you have questions. - Oct 09 2010
Name=Name of Theme
X-KNemo-Theme=monochrome
Once those are in place, the icon theme will be available in the config dialog.
Feel free to PM me if you have questions. - Oct 09 2010
I'd be happy to add such a theme if someone else makes it, but my icon skills suck. That's partly why the icons haven't changed since Percy created them back in 2004!
Another alternative would be to support the network-* Standard Status Icons in the fdo icon naming spec (table 12).
http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html
For KNemo, that's just a matter of uncommenting one line. However, none of the KDE themes have those icons, so KNemo would only get the fancy question marks if it tried that.
Other ideas? - Oct 05 2010
Another alternative would be to support the network-* Standard Status Icons in the fdo icon naming spec (table 12).
http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html
For KNemo, that's just a matter of uncommenting one line. However, none of the KDE themes have those icons, so KNemo would only get the fancy question marks if it tried that.
Other ideas? - Oct 05 2010
Sorry about the delay. I got bogged down in some non-KDE related things over the last few months.
I do still plan to contact the knetworkmanager list, but I first want to get 0.7.0 final released. That will take care of a feature request and should significantly improve how knemo handles traffic notifications and custom billing periods. - Aug 27 2010
I do still plan to contact the knetworkmanager list, but I first want to get 0.7.0 final released. That will take care of a feature request and should significantly improve how knemo handles traffic notifications and custom billing periods. - Aug 27 2010
So the interface is up and has the carrier, there's just no ip address assigned to it.
Testing for an ip address has already proved to be too restrictive for ethernet devices. Maybe there should be an exception for pointopoint? Not sure. I'll look into it. - Jun 29 2010
Testing for an ip address has already proved to be too restrictive for ethernet devices. Maybe there should be an exception for pointopoint? Not sure. I'll look into it. - Jun 29 2010

KOceanSaver
Screensavers by jboss1995 91 comments
You're right. KOceanSaver.pro hardcodes the install paths, but those can vary between distributions. For instance, it looks like Mandriva is using /usr/share/apps.
To fix it, I'd use cmake instead. Since that's what KDE standardized on, it'd be the best way to make sure that the screensaver uses the right paths, no matter which distribution you're building on. - Apr 13 2010
To fix it, I'd use cmake instead. Since that's what KDE standardized on, it'd be the best way to make sure that the screensaver uses the right paths, no matter which distribution you're building on. - Apr 13 2010
This seems to be a pretty frequent issue for those who do local installs, so I'm adding a note to the install directions of the next release.
Add this to the bottom of your ~/.profile
Quote:export KDEDIRS=/usr/local:/usr
Then restart your session. Does that work?
- Mar 23 2010
Add this to the bottom of your ~/.profile
Quote:export KDEDIRS=/usr/local:/usr
Then restart your session. Does that work?
- Mar 23 2010
I think I see what's happening. By default KNemo compiles the tray icon as a KSystemTrayIcon because the new KStatusNotifierItem does not show tooltips in other desktops like GNOME or Xfce.
Recompile, but this time use "./configure -n" The tray icon will now be a KStatusNotifierItem, and it should resize like kmix and kopete. - Mar 20 2010
Recompile, but this time use "./configure -n" The tray icon will now be a KStatusNotifierItem, and it should resize like kmix and kopete. - Mar 20 2010
If you don't see the Network Monitor module in KDE's system settings, follow the directions about KDEDIRS in the thread just above this one.
As for knemorc, move it anywhere but KDE's config directory :-) If your connection is up, you should see something in the tray when you next start the app.
- Mar 01 2010
As for knemorc, move it anywhere but KDE's config directory :-) If your connection is up, you should see something in the tray when you next start the app.
- Mar 01 2010