Time-Shift: Veritas liberabit vos
The truth shall set you free

KWatchman – An Idea given Birth

First of all: Thank you everyone for you comments and suggestions. They really got me on the road and showed my that there indeed is interest enough to do some more serious work. So I sat down and made myself a little planing and even some (small) coding today. Here’s what I got so far:

The project will consist of mainly 3 Parts:

  1. Part one being the kwatchman-service (in what manner I’ll realize this I’m not sure yet). Its basically just an empty rack to manage and run part 2 (maybe this will even be a daemon so it can run under higher privileges).
  2. Part two being Plug-ins that can be loaded by kwatchman-service. There will be (for now) 4 kinds of Plug-ins:
    • Sensor Plug-ins (they collect the data from a specific source e.g. libsensors-plugin, hddtemp-plugin, nvclock-plugin, etc.. )
    • Interface Plug-ins (they provide interfaces for all apps that like to access the collected data e.g. dbus-plugin, network-plugin, nagios-plugin?, etc… )
    • Database Plug-ins (they provide storage for long term data collection e.g. mysql-plugin, postgresql-plugin, nepomuk-plugin?, etc… )
    • Alert Plug-ins (they do something in case an alert is issued by crossing some threshold e.g. knotify-plugin, phonon-lugin, log-plugin, shell-plugin, etc… )

Apart from the database Plug-ins all Plug-ins can be used or not used at will. So the user can ultimately decide what gets refresh and which alert is being send if a threshold is crossed. Concerning the Database Plug-ins I guess its much easier if only one is allowed at a time. All other use cases can be handled by Interface Plug-ins (e.g. if you want nepomuk as your db but want to access the data via php on a webserver a php friendly interface Plug-in would be the solution).

  1. The last part are GUI’s that access the data and configure the Plug-ins via the interface Plug-ins. Those can be a very wide variety of apps and applets ( e.g. native KDE4 apps, plasmoids, KCModules etc.). Im not completely sure how the initial configuration of the service should be made so that at least the correct interface Plug-in for your favorite App is activated.

The first implementation will (most likely) contain:

  • The kwatchman-service (whatever it will be)
  • A lm_sensors sensor Plug-in
  • A nepomuk or MySQL database Plug-in (not sure yet)
  • A native (ksensors like) KDE4 app
  • A interface Plug-in for the native app (maybe via dbus?)
  • A knotify Alert Plug-in

As soon as I’ve got those components in working order I’ll concentrate on more sensors and Alert Plug-ins. After I that database Plug-ins will be my attention and finally I’ll write some more apps and Interface Plug-ins.

As for now I’ve got a (very rudimentary) cmake concept for detecting libs and deciding what gets compiled, a (also rudimentary) file structure for the code and some template for the KDE4 App.

So.. now to it: What do you think about THAT concept? Crazy? To big? Super? If you have any supplementary suggestions to the concept don’t hesitate to comment!

9 Responses to “KWatchman – An Idea given Birth”

  • mutlu says:

    Hmm… unfortunately, I don’t understand what KWatchman would be. Is there a short introduction into the service? Was there a discussion on a mailing list somewhere?

  • Aaron Seigo says:

    if your goal is to create a fun and extensive project involving creating a sensors GUI, then it looks like you’ve got everything planned out nicely.

    if your goal is simply to provide a nice sensors GUI for people to use, then your plan consists essentially of “re-implement a whole lot of things that already exist”. ksysguard already provides a system information daemon (network transparent, portable, well tested, etc). the “alert” plugin concept is essentially knotify for one application. plugin interface for UI’s is something plasma provides quite nicely already, including for stand-alone applications.

    so as a “fun project with lots of stuff for me to spend time on for the next several months” it sounds great. making it portable, stabilizing it, getting buy in from other KDE project communities .. probably more difficult than it really needs to be.

    • ksysguard already provides a system information daemon (network transparent, portable, well tested, etc)

      The main problem with KSysguard is the representation of the data. It uses the same idea behind the sensor stuff of course but it can only display this data. And only in a very limited way. The data can not be monitored in the background over a long period. They can not be displayed by different apps at the same time. And the can not be propagated in different ways at the same time (network, local gui, nagios, etc.). But especially KSysguard can not issue alerts if thresholds are crossed.

      the “alert” plugin concept is essentially knotify for one application.

      Not really. KNotify can not monitor thresholds. It can only be called by something else if a threshold is crossed to notify the user. KNotifiy is also very limited in WHAT the actual alert looks like. It cannot run a script for you with arguments it gets from the notification for example. However KNotifiy would be usable in an alert Plug-in of course.

      plugin interface for UI’s is something plasma provides quite nicely already, including for stand-alone applications.

      Like with ksysguard the view of plasma is to limited here. I never said the interface plug-ins would only provide those interfaces for guis, but also for network, other apps (via dbus for example) or things I didn’t even dream of. The Idea behind the plug-in concept is to open the available data up to EVERYTHING anyone can dream of. Just write a plug-in for you super cool XXX usage and the data are yours.

      So as you can see there are a lot of apps that cover parts of what I’m planning to realize. But there is nothing that makes it all possible and nothing to connect those apps. But especially those apps are not extend able enough to simply write some plug-in to get the functionality.

  • yoda says:

    please, can we have a name without K?

    I love kde but that naming pattern is annoying, e.g. Kalzium, Krita, Kate, Kopete etc. that’s OK however Kwrite, Knotes, Kwatchman…. that doesn’t sound good and it’s little silly

    It’s new KDE not everything need to be Knamed (look at: Dolphin, Plasma, Blogilo, Gwenview)

    PS. idea of creating high class system monitor is great, it would be nice to have something like cpu-z, gpu-z in kde also

    • There are two basic problems I have with That:

      1. Kwatchman is already mentioned in quite some blogs etc in the Internet. So the Name is gaining popularity. I’m not sure I should change it again.

      2. KSensors also had a K in Its Name and the similarity is better for association.

      So changing the Name now that I mentioned it on Planet KDE could be Bad.

  • Ernest N. Wilcox Jr. says:

    I think your fundamental concept is good. It will let Kwatchman be very flexible. This is a true hallmark of a good Linux applet. If you let the user decide which plug-ins to use, then the app will be a different thing for each user. As an example, my main interest in this new project is in having an icon in the system tray to show me the CPU core temperature. I may also want to be able to show a second icon with the system temperature, so it would be good for me if the application will be able to do that). That is how I used Ksensors prior to KDE4. Desktop widgets are OK, but they get covered by application windows, and I want to be able to see the core and system temperatures at any time.

    My2cents,

  • Alan Prescott says:

    Are you anticipating kwatchman monitoring sensors remotely?
    I’d certainly appreciate a utility which can automatically monitor the status of my server from my desktop workstation. In which case the kwatchman-service must be able to run without KDE, preferably without any graphics requirements at all as remote machines (such as servers) will probably be running without X and possibly headless.

    • I most definitely though about that. I’m not completely sure yet how or in what manner monitoring over network would be made possible. Maybe it would be a better approach to write a Nagios-sensor Plug-in. That way you could read the Nagios service status into kwatchman to show it locally. As Nagios already covers the server field extensively I’m not sure I should intrude there but rather use the services available. After all my App will aim towards making (already available data) as readable as possible and provide alerts (of all manners) in case of uncool behavior.