-
 KDE-Apps.org Applications for the KDE-Desktop 
 GTK-Apps.org Applications using the GTK Toolkit 
 GnomeFiles.org Applications for GNOME 
 MeeGo-Central.org Applications for MeeGo 
 CLI-Apps.org Command Line Applications 
 Qt-Apps.org Free Qt Applications 
 Qt-Prop.org Proprietary Qt Applications 
 Maemo-Apps.org Applications for the Maemo Plattform 
 Java-Apps.org Free Java Applications 
 eyeOS-Apps.org Free eyeOS Applications 
 Wine-Apps.org Wine Applications 
 Server-Apps.org Server Applications 
 apps.ownCloud.com ownCloud Applications 
--
-
 KDE-Look.org Artwork for the KDE-Desktop 
 GNOME-Look.org Artwork for the GNOME-Desktop 
 Xfce-Look.org Artwork for the Xfce-Desktop 
 Box-Look.org Artwork for your Windowmanager 
 E17-Stuff.org Artwork for Enlightenment 
 Beryl-Themes.org Artwork for the Beryl Windowmanager 
 Compiz-Themes.org Artwork for the Compiz Windowmanager 
 EDE-Look.org Themes for your EDE Desktop 
--
-
 Debian-Art.org Stuff for Debian 
 Gentoo-Art.org Artwork for Gentoo Linux 
 SUSE-Art.org Artwork for openSUSE 
 Ubuntu-Art.org Artwork for Ubuntu 
 Kubuntu-Art.org Artwork for Kubuntu 
 LinuxMint-Art.org Artwork for Linux Mint 
 Arch-Stuff.org Art And Stuff for Arch Linux 
 Frugalware-Art.org Themes for Frugalware 
 Fedora-Art.org Artwork for Fedora Linux 
 Mandriva-Art.org Artwork for Mandriva Linux 
--
-
 KDE-Files.org Files for KDE Applications 
 OpenTemplate.org Documents for OpenOffice.org
 GIMPStuff.org Files for GIMP
 InkscapeStuff.org Files for Inkscape
 ScribusStuff.org Files for Scribus
 BlenderStuff.org Textures and Objects for Blender
 VLC-Addons.org Themes and Extensions for VLC
--
-
 KDE-Help.org Support for your KDE Desktop 
 GNOME-Help.org Support for your GNOME Desktop 
 Xfce-Help.org Support for your Xfce Desktop 
--
openDesktop.orgopenDesktop.org:   Applications   Artwork   Linux Distributions   Documents    LinuxDaily.com    Linux42.org    OpenSkillz.com   
 
Apps
News
Groups
Knowledge
Events
Forum
People
Jobs
Register
Login


Sponsoring


-
- Content .- Fans (26) .- Knowledge Base (1) . 

Yasp-Scripted (Systemmonitor) v1.0.8a

   1.0.8a  

Plasmoid Binary

Score 86%
Yasp-Scripted (Systemmonitor) v1.0.8a
zoom


Yasp-Scripted (Systemmonitor) v1.0.8a
zoom


Yasp-Scripted (Systemmonitor) v1.0.8a
zoom


Minimum required   KDE 4.x
Downloads:  10535
Submitted:  Jul 31 2009
Updated:  Feb 25 2011

Description:

Yes, Yet another systemmonitor plasmoid.
But still different from the others.
The only useful plasmoid systemmonitor i have found was Yasp. The problem with it was that it was not configurable enough.
So I came up with the idea, that everyone has its own imaginations of what belongs into a systemmonitor and what not. The birth of Yasp-scripted.
The name is similar to Yasp, because I use some modified code from that project.
The biggest advantage is that you can add things to the monitor or remove some, by just changing the script file and reparse it again...) No recompilation or something like that needed...
The scriptfile which comes with this applet is a scriptfile which fits exactly my system. You probably need to change it to fit your system (e.g. if you do not have a wireless lan card, you need to remove the wlan stuff from the script file).

You can send me your script, such that I can upload a whole bunch of scripts, the user could choose of later (maybe with a screenshot to see directly what the script does)

The scripts can be found in the directory yasp_scripts.
The 1st screenshot is systemmonitor_by_mtr.script, the 2nd screenshot is systemmonitor_by_patkoscsaba.script
and the 3rd screenshot is the script collection by duncan
(thx for the scripts).

If you want to align things, you should either use a monospace font, or use a \t in the value.

If you are familiar with svg you maybe will create your own svg's for the bar-meter. Send them please to me to have a wider range of look and feel for the system monitor ;)




Changelog:

1.0.8a - wrong folder prefix ;)

1.0.8 - bug fixed when reparsing (the kde-plasma-handle was deleted, but we should not delete it)

1.0.7 - bug fixed if engine-sensors contains a colon
- Added script by joseph (thx for the script)
- New script by aldo (thx for the script)

1.0.6 - stack keyword added to plotter (thx Chris99 for the patch)
- Script by mtr added (thx for the script)

1.0.5 - fix crash on reparsing in kde-4.5.2 (with 4.5.2 reparsing works again, but 4.5.1 and 4.5.0 have a bug)

1.0.4
- Label preferredSize setting correctly + sizePolicy changed

1.0.3
- meter sizePolicy changed (works now better in KDE-4.5)
- bugfix for KDE-4.5 such that it does not crash on removal

1.0.2
- workaround for problems with KDE-4.5 and meters (min_height parameter added)
- added script by aldo to the package (italian labels)
(- known issue: yasp-scripted crashes on reparsing in kde-4.5. This will be fixed in a later release)

1.0.1 - bug fixed if yasp is closed while parsing the script

1.0: - Reparsing should be more stable




LicenseGPL
Source(Yasp-Scripted v1.0.8a)
Arch(Arch Linux PKGBUILD)
Send to a friend
Subscribe
Other  Apps  from finkandreas
Report inappropriate content



goto page: prev   1  2  3  4  5  6  7  8  9  10  11  12  13  14  15 

-

 Selecting a script - request

 
 by patkoscsaba on: Jan 24 2010
 
Score 50%

The MRB project (http://mrb.mandrivausers.ro) packaged your plasmoid for mandriva as RPM, we very much like your plasmoid.

However, this packaging opened a situation which led me to write you this feature request.

As you offer different scripts for YaSP (and I will send you more in the near future) you should reorganize them so that packaging can be done easily.

What I am thinking of is offer a file dialog for the user to select a specific script file. Also, you should offer a very basic default script, so that when the user first starts the plasmoid he/she can see something other than an empty box. The best would be just a simple memory+cpu monitor which is available on all systems.

The other thing for this to be more organized is that you should make a folder ~/.yasp.scripts and put all the scrips in there. In setting offer a file selection which defaults to that folder and users cans see all the other script files.

If you do this, packaging your program for different distributions will be much easier, and unexperienced users, who don't want to write their own scripts, will find out easily about the scripts and they will be able to test them without modifying/copying files.

Thanks. And very good work!


Reply to this

-

 Re: Selecting a script - request

 
 by finkandreas on: Jan 24 2010
 
Score 50%

The file selector was implemented in 1.0.1 so it is already there (but the default directory is not .yasp.script)
Installing the files is kind of hard (because I was too lazy to read how to install files only when they are not available yet).
If I install the scripts always a user compiles this plasmoid the user will use its changes. And installing only when a file is not available yet, I did not find how to manage with CMake. So I decided to not install any script file at all...

If I install the scriptfiles it will be in /etc/yasp, because Gentoo for example has protected files in /etc, and you explicitly need to decide whether files should be overwritten there. I don't know if Mandriva has some similar protected directories, but otherwise the package management system needs to be smart enough...

For the .yasp directory with the script files in it: Should work with the current version, with only one minor modification
yasp-scripted.cpp:72 m_sScriptPath = sHome + "/.yasp.script";
should be
yasp-scripted.cpp:72 m_sScriptPath = sHome + "/.yasp/default_script";

This only changes the default script file to be in $HOME/.yasp/default_script...

How is the mandriva system working? Do you offer precompiled packages or is the plasmoid compiled by every user?
If you offer precompiled packages you can change this one line and offer the binary.
I maybe will change it next weekend (not much time before), but I still have to think about it, if this is some kind of expected behaviour...


Reply to this

-

 Re: Re: Selecting a script - request

 
 by patkoscsaba on: Jan 24 2010
 
Score 50%

On Mandriva RPM packages contain precompiled binaries.

So, your instructions should be enough. Sorry for the file-selector request, it wasn't mentioned in your changelog, and I didn't tried the last version, yet.

Putting the script files in /etc/<something> I don't thing is a good idea because users may not have access to /etc/ ... may /usr/share/<somethnig> ... I will talk with the guy responsible for compiling it for MRB and I'll be back to you.


Reply to this

-

 Re: Re: Re: Selecting a script - request

 
 by finkandreas on: Jan 24 2010
 
Score 50%

yeah, I didn't mention it in my changelog because it basically was always there but hidden (because it did not work with KDE 4.2). I've tried it once again with 4.3.4 and it did work so I unhided it again, but forgot to mention it in the changelog ;)

You do not need to have write access in /etc/something because you try out the scripts, and the interesting one you copy to ~/.yasp/my_script and adapt it... That's how usually packages which offer customization work...
Maybe also /usr/share/something. I did not think much about where to install it (I'll have a look where other packages install their files)


Reply to this

-

 Re: Re: Re: Re: Selecting a script - request

 
 by patkoscsaba on: Jan 25 2010
 
Score 50%

I talked with the packager. It is irrelevant where you will keep/put your scripts since he already made the spec-file for the RPM to package it in ~/.yasp.script (or something like that).

So, don't worry, we are good.

However, as a next evolution of your script, you should make an interface for selecting sensors and auto-magically generate the script. Something like "gkrellm" can do.

This is an extremely good plasmoid for technical people (like me), but most of the users are "afraid" of, or just too lazy to modify files and build their own scripts.


Reply to this

-

 Re: Re: Re: Re: Re: Selecting a script - request

 
 by finkandreas on: Jan 25 2010
 
Score 50%

The automatic script creation is a nice idea, but I do not see much use in it, because there are only two different sensor types, namely Plasma DataEngines which can be easily queried with the plasmaengineexplorer, and arbitrary shell commands where a GUI cannot be built for... Gkrellm offers much more internal functions where it makes sense to build a GUI, because some people don't like to read all the different commands that are available.

Another thing is that you are building a scriptfile very rarely, but the plasmoid is always running, so if there would be a GUI for creating scriptfiles it should be a program for itself (otherwise you are wasting memory usage for the functionality you probably need once a month)

Sure it would be nice for some people to have a drag 'n drop solution but to be honest I don't want to waste time to build a GUI for that... If anyone wants to build that program s/he is free to use my official mercurial repository:
http://bitbucket.org/jocker16/yasp-scripted
But as I mentioned it should be in my oppinion a separate program to safe resource consumption of yasp-scripted.


Reply to this

-
.

 Bravo + potential of scripts

 
 by Franksuse64 on: Feb 2 2010
 
Score 50%

Hi,

I mentioned in another post how a huge fan of gkrellm I am. But how sad it looks so ugly cuz based on GTK2 engine which doesn't fit well KDE4 (not blaming GTK for that! It's the way it looks, that's all).

I tried your script cuz it's fully plasmoid, which of course fits KDE4.

I have some very good points to tell about your script. I think you have found a way to have a very customizable monitor, which is what I need to get all my gkrellm functions and displays into a plasmoid.

I am no developer, though, so the only downside of your great customizable script is, for me, the coding of the scripts I want. lolll

Sure I can manage a few things, but there are other things I really have no knowledge for. Now if I want to learn, what do you suggest? Should I ask you the questions and you guide me into building the scripts or is there a better way?

Lemme explain :

For examples,

-I want to add the FANs speed from lmsensors (sensors command). I believe I can do so using grep. I have tried copying and adapting the coretemp line for fans, but it didn't work. Maybe I need to dig more into it, a simple grep of sensors did not work.

-My CoreTemps are blank by default. So I have modified your default line which looks for "CoreTemp0" I think for "CoreTemp 0", or just a very small change like that. It works, but it returns the whole line from sensors, with maximum degrees and everything. I need to CUT the result of grep, I think I have to use CUT, so MAN CUT or google on CUT should help me and then pipe it in grep. I can probably do that.

-I want to have 4 Core load displays, not 1 for the whole CPU. Not sure how to do that.

- I would like to merge the Core Temps at the bottom of the each Core load display (or right in the middle, centered H and V into a big colored font). That I have no idea.

-I would like to have the total d/l and total u/l of the day and the month for network (eth0), having the month being automatically reset at a specified date. I think I can grep | cut ifconfig to get the day's total (I was able to create a new line for that, but got no blank data so far), but for the month I don't know...

-I would like to have each selected partition's read/write I/O, both graphical display (with selectable time to show the graphic I/Os, for 30sec, 60sec, etc.) and in K/bytes/M/bytes. I think you mentioned how to do it in another post, I have to re-read it to better understand, google a few things, but again my non-dev knowledge causes me some problems. I am unsure where to start and what to google for to know how to write your script.

-As a nice to have, to have a progress bar for each TOP procs based on the % load would be great too, it's visually much easier to identify load consuming procs as you don't need to read a number. so where the % of each proc is mentioned, I would have a progress bar just under each proc, from left (0%) to right (100%).

As you can see, there is a lot of things to do. I am pretty sure with enough knowledge it's doable, after looking at your scripts. But it's up to me to do it, I understand that.

If I can manage to do all this, god nothing can beat your script! :) It's just a matter of having development knowledge, whereas gkrellm let's you do this by clicking in the gui config panel. This is why I have a lot of work to do, but I unfortunately need a lot of help as well...

The upside is I am quite convinced your script-oriented idea can do all of this and many more, which is great cuz you are the only solution for monitor plasmoids with so much customization. :)

All thumbs up for that!
And shame on my I don't have the knowledge I need. :)

tnx


openSUSE 64-Bits
Reply to this

-

 Re: Bravo + potential of scripts

 
 by finkandreas on: Feb 2 2010
 
Score 50%

I would say, that we take it either per mail, or by IRC (the channel #yasp on freenode seems to be free). IRC is definetly the faster way (and more people can help), but it's up to you what you prefer...
So anybody who also wants to explain some stuff can join there too ;)


Reply to this

-

 Re: Re: Bravo + potential of scripts

 
 by Franksuse64 on: Feb 3 2010
 
Score 50%

Sounds good to me. I'll go on IRC, ask 1 question at a time, work on 1 question at a time and once everything is in place, I'll send you my complete script. :)


openSUSE 64-Bits
Reply to this

-
.

 Difference between 2 lines

 
 by Franksuse64 on: Feb 3 2010
 
Score 50%

Hi again,

I don't quite understand the difference between 2 sensor name lines and the use of sed command. I post here cuz I think it will help others.

What is the difference between these 2 lines:

sensor name="Core0Temp" type="program" cmd=%sensors | grep -A1 'Core 0' | xargs | sed "s/.*Temp: \(+[0-9]*\).*Temp: \(+[0-9]*\)../\1 \2/"%

vs

sensor name="Core0Temp" type="program" cmd="sensors | grep 'Core 0' | cut -c 15-20"

Why using sed instead of cut? Yes I have read the README.SYNTAX, it just says "cuz you can re-use sensors". Not sure why you can't with cut?

Ok, some sed documentation can be found here http://www.grymoire.com/Unix/Sed.html

But how long would I need to read until I would understand why you use sed? :)

Thought a simple question would yield to a simpler answer than reading all the doc. :)

tnx


openSUSE 64-Bits
Reply to this

-
.

 Re: Difference between 2 lines

 
 by DuncanKDE on: Feb 3 2010
 
Score 50%

That's an interesting trick...

sed is "stream editor". Do you know regular expressions (regex)? That's one of sed's strengths. In this case we're using the sed s/original/replacement/modifiers command, where the s stands for "substitute". So, it says, substitute for a given string, some other string.

Quick review of some regex basics: "." means "any character" and "*" means any number (zero or more) of the preceding symbol, so ".*" in regex is equivalent to the "*" wildcard in shell patterns (as used in filenames and the like, *.txt, for instance). The backslash is used as it commonly is, as an escape character, meaning treat the next character other than you normally would, and the combos \( and \) enclose a segment of the expression for two purposes, grouping (treating the group as a single unit, \(at\)* means one or more "at"s, but won't match a string of only "a" or only "t", or ata, for that matter as it's lacking the final t, but it would match atat or atatatat), and saving to a buffer for use later in the expression. Here, they /are/ used later, in the replacement string, as \1 and \2.

So what the sed is doing, is taking a string of the format <anything>Temp:<single-space><numbers><anything>Temp:<single-space><numbers><exactly two characters of anything>, and returning /just/ the two strings of numbers (which are saved in buffers 1 and 2 by the \(\), then used in the replacement), separated by a single space. (Note the spaces between the :s and the number strings, and the two terminating dots, matching exactly two characters. I almost missed those.)

That (yasp.s) sensor won't be used directly, but rather, it'll be reused by presumably two additional (yasp.s) sensors, one of which uses the first number, the second of which uses the second.

The strategy is to avoid running the (lm_)sensors command (well, the whole string of commands) twice, thus making it perhaps more efficient than a script that repeatedly calls the (lm_)sensors command. It should run in a fraction of a second either way, but when you're running the script repeatedly every second or two, saving the overhead of another command call in the pipe is a significant savings. Additionally, both temps are read at the same instant, instead of calling (lm_)sensors twice, with perhaps the value changing between.

grep and cut could indeed be used instead, but it'd take a pipe of a couple additional commands to do it, since there's a (regex) ".*Temp: " in between them if it was reduced to the same string in the first (yasp.s) sensor. To avoid that, the first (yasp.s) sensor would then probably simply grep the string including the junk in the center, with the sensors building on it doing cuts or greps off the beginning and the end, ignoring the garbage in the center.

So it's a matter of style whether one uses sed in the initial (yasp.s) sensor, stripping the string down farther initially, or grep or cut, leaving a bunch of garbage in the initial result, which is then stripped by the later (yasp.s) sensors that use the result of the first one. But I do appreciate the insight of just running the (lm_)sensors command once, storing multiple data values in a result to be used by additional (yasp.s) sensors later. Presumably, yasp-scripted is more efficient at that, then bash is at running the extra commands, with the result being a savings of (for argument) say 1% over running two separate (lm_)sensors calls, each one doing its own piping to filter the garbage to the specific value it wants.


Duncan
Reply to this

-

 Re: Difference between 2 lines

 
 by finkandreas on: Feb 3 2010
 
Score 50%

Duncan said again everything.
Of course you could also use cut to do the job...

But maybe you did not really understand how yasp-scripted works, because your question is strange...
We first define sensors (imagine a sensor as a variable with some value), and later we use the sensors to produce our graphical output.
Why do we first need to define sensors? Because you maybe have two lines in your graphical part which want to use the same sensor. So you define a sensor (again imagine it as a variable) which holds some value and your two graphical lines use this sensor...

Unlike Duncan mentioned you cannot split the value of a sensor in further processing... So if you want the temperature of every core specifically you need to define different sensors...


Reply to this

-
.

 Re: Re: Difference between 2 lines

 
 by Franksuse64 on: Feb 3 2010
 
Score 50%

Interesting trick indeed. I see yasp has been created to maximize processing efficiency, which is sometimes lacking in different applications/scripts, so that's another thumbs up.

I'll then have to continue using sed and learn how to tweak it for my sensor output (I get blank temps with the default script, cuz I don't have the same sensors you do).

Yes I want to have 4 core temps, along with 4 core loads and 4 core plotters (maybe I could put 4 lines into one plotter, I don't know yet).

I may try using cut to start with, just to get the look and feel of all my sensors and then tweak the script using sed (with cut I can manage to get anything I want without a learning curve).

I'll print your answers above and keep that along with your readme.syntax, as it was important for me to understand the logic behind all this.

tnx again!

Oh, just a quick one: can yasp-scripted use alarms on sensors? Say if my temps, fan speeds, load, HDD usedspace go over or under a certain number for a certain period of time to say, blink the value, bold it and change it's color? These alarms are very useful in gkrellm, cuz you don't have your eyes always watching the monitor (or windows are over it), but you love to know when something goes beyond a normal limit.


openSUSE 64-Bits
Reply to this

-

 Help

 
 by cialdo99 on: Feb 4 2010
 
Score 50%

Hi, I want to add some lines to monitor battery status, charge, time left ... I know I could use acpi sensors for example.
Could anyone help me adding this lines to yasp with the correct syntax?


Reply to this

-

 Battery sensors Was: Help

 
 by DuncanKDE on: Feb 4 2010
 
Score 50%

Sure. I didn't include anything like that in the set of scripts I sent in earlier, because that was for my desktop/workstation. But I recently replaced the Linpus that came on my Acer Aspire One netbook with Gentoo, using KDE 4.3, just as on the main machine, and rejiggered my yasp-scripted scripts for it. Of course I needed battery info, and I happen to have that all setup already, here. Of course you may have to change commands and paths slightly for different hardware, but here's what I have. (To solve wrapping issues, I'm formatting each line as a paragraph, with a blank line between. So a single line might appear as several here, but everything between the blank lines is a single line. I'm omitting colors, etc, which you can choose and add as desired. The below is read off the script on my laptop, retyped on the browser on the main machine, so there may be typos, missed quotation marks, etc.):

For a battery percent plotter and text readout:

sensor name="batt.pct" type="program" cmd="acpi -b|cut -d' ' -f4|cut -d% -f1"

plotter use="batt.pct" plot="$1" max="100"

value key="Battery " use="batt.pct" format="$1 %"

Adding to that a battery status indicator (full, charging, discharging...):

sensor name="batt.stat" type="program" cmd="cat /sys/class/power_supply/BAT1/status"

text use="batt.stat"

OK, what about time remaining on battery or to charge?

sensor name="batt.time" type="program" cmd="acpi -b|cut -d, -f3|cut -c 2-9"

text use="batt.time"

Now the AC Adapter status (on-line/off-line, you'll note the .. in the name. I try to keep my names of uniform length so the fields line up easier and it's easier to edit, no other significance, just personal preference):

sensor name="acpi.ac.." type="program" cmd="acpi -a|cut -d: -f2"

value key="AC Adapter" use="acpi.ac.."

Finally, if you have laptop-mode-tools installed and configured on your machine, you may find its status useful to know as well. In particular, I noticed here that with just AC plug event detection, if I suspended with the machine plugged in, then unplugged and later resumed, the unplug event would have been missed as it happened while suspended, so laptop mode wouldn't activate. Having a display specifically for it allows me to double-check that, and issue the appropriate command manually to start or stop laptop mode, if needed. So here's a simple monitor for that, displaying either 2 (laptop mode enabled and on battery) or 0 (disabled and on AC):

sensor name="laptop.md" type="program" cmd="cat /proc/sys/vm/laptop_mode"

value key="Laptop mod" use="laptop.md"


Duncan
Reply to this

-
.

 Sensors Alarms

 
 by Franksuse64 on: Feb 4 2010
 
Score 50%

Ok great, I have modified considerably the original script to fit what I need, a few things remaining now, the most complex, so I will start with one I absolutely need.

Sure I could go on IRC, but I am at work now. :) Yes I am working on the script at work. lolll It's interesting. I also think other people would like to know the answer as well.

I am trying to understand how I can set alarm limits on sensors. There is no value key for alarm, so do I need to write something with math?

Low or high or low and high limits (only 2 alarms to start with) on:

-CPU load;
-Core/CPU/GPU/HDD/System temps;
-CPU/System Fans RPMs;
-Voltages;
-HDD free space per partition.

I am totally lost on that one. :) But I know if it works for one, it will for the others.

I think any good monitor should have alarms, cuz its purpose is to monitor sensors. :) I hope it's possible with your scripts?

tnx :)


openSUSE 64-Bits
Reply to this

-

 Re: Sensors Alarms

 
 by finkandreas on: Feb 4 2010
 
Score 50%

No alarms possible... And it's not the job of a systemMONITOR to have alarms.


Reply to this

-

 Re: Re: Sensors Alarms

 
 by Franksuse64 on: Feb 4 2010
 
Score 50%

Is there a technical reason why alarms cannot be incorporated within the scripts?


openSUSE 64-Bits
Reply to this

-

 Re: Re: Re: Sensors Alarms

 
 by finkandreas on: Feb 4 2010
 
Score 50%

the only reason why it's not possible is because I've never needed it, so I've never implemented it...


Reply to this

-

 Re: Re: Re: Re: Sensors Alarms

 
 by Franksuse64 on: Feb 5 2010
 
Score 50%

Good. :) So it's technically possible. Since your monitor deserves to expand, I will try to find someone with the knowledge and time to look into the alarms.

tnx :)


openSUSE 64-Bits
Reply to this

-

 Sensors Alarms

 
 by DuncanKDE on: Feb 5 2010
 
Score 50%

[AF: Could you put a note at the top to take care and erase extra Re:s in the subjects? They crowd out the subject after awhile. =:^( Plus, people might pay more attention to the subjects then, and change them if the subject of a (sub) thread changes. =:^)]

I was sick from yesterday and so slept a lot, then slept a lot again today, too. You know the free association, strange ideas and stuff that happens when you're kind of floating between sleep and awake? Well, I was there, and while a lot of the stuff was crazy, as usual, I did realize something... which I've made a bit more sane as I woke up and am writing this.

No, yasp.s doesn't have alarms per se, but there's no reason the script feeding yasp.s the values to monitor couldn't also check them, and trigger either a beep, or the playing of a short audio file, if they go out of range. One would need to do so in the background, so the script can finish and it won't hang yasp.s, but that's no big deal.

Actually, probably the best way to handle it would be to put the alarm handling in a secondary script, that could be called with say four parameters, the current value, the high-trigger value, the low-trigger value, and the command to play the alarm, if necessary. That way, the alarm script could be reused in any script without having to rewrite it in each.

Having it take the entire command, not just the audio-file, would allow people to change the player easily, if necessary because they don't have a particular player on their system. The command would include the audio file to play, which could then be customized so different alarms played different files.

Now you'd want to keep the audio clip short, a second or two, so as it's repeatedly triggered, it finishes playing before the next sensor update triggers it again.

Alternatively, some non-audio cue could be given as the command, say to flash the screen or whatever. I don't really know the sort of command that would do that, but I'm sure there's something.

There should probably be a check of some temp file, say $KDETMP/yasp.s.alarms-disabled, which if present, would disable the alarms, as well. That way, one could simply touch that file to hush the alarms and allow one to get on with fixing the problem.

Just a bit of brainstorming. Maybe I'll hack up such a script, maybe not, and who knows when I'd do it, but anyway, perhaps this points someone in the right direction to implement it if they want it bad enough.

Better yet, if someone with C/C++ skills could create a native code version that could be compiled, taking the four parameters I mentioned above on the command line and checking the shutup file mentioned above (with a sane default path, say /tmp/tmp-<user>/yasp.s.alarm-disable, if $KDETMP is unset), it'd run faster, thus saving CPU time over a bash implementation, which is what I'd be able to do. That's important when the thing is called perhaps every second, by multiple yasp.s sensors!


Duncan
Reply to this

-

 Re: Sensors Alarms

 
 by Franksuse64 on: Feb 5 2010
 
Score 50%

Tnx for that. You are right with last paragraph, I call multiple sensors at the same time every second, so it takes from 3% to 12% (some are each 2 or 5 secs) of each of my cores, they would run under load all the time with the alarms. I'm surprised how great gkrellm is built, as my cpu load is from 0% to 3% on each core every few seconds.

I don't know if yasp is able to call the sensor once and assign the results to every value key, but mine doesn't do it. I probably call the same sensor 30 times+ every second.

As said I'll try to find someone on the alarms, more chances I won't be able to, but I'll try. Or I'll see if I can work without these, as your monitor is ao great.

tnx :)


openSUSE 64-Bits

-

 Re: Sensors Alarms

 
 by finkandreas on: Feb 5 2010
 
Score 50%

For implementing alarms I would use the native KDE notification, because it fits best into the system...
So basically for implementing alarms, we have to define a syntax first (and this is the point, where I have no idea, because I don't know what people want to do with alarms). The rest comes down as a straight forward implementation...



-

 Plasmoid width

 
 by DarkriftX on: Feb 22 2010
 
Score 50%

I have spent days trying to find a suitable replacement for my gkrellm sidebar. I finally came along this plasmoid and it almost looked like it would work. It has a lot of stuff I dont need, but I am pretty sure I can figure out how to get rid of that. My only real problem is that I want this to be on a panel that acts as a sidebar. I want it to be 100-180px wide. The plasmoid seems to want to be 400px or so wide. Where do I edit the max width of whichever items need to be shrunk to make this smaller?


Reply to this

-

 Re: Plasmoid width

 
 by DarkriftX on: Feb 22 2010
 
Score 50%

Nevermind. I fixed a few sed lines (I have a dev version of kde so a sed line was "s/KDE:" and I changed it to "s/KDE Developer Platform" (i think this is what it was) and it shortened up the longest line of text. This then made the rest of the items shorter. Almost makes me wish there was a wrap feature. I now have this sidebar working perfectly.


Reply to this

goto page: prev   1  2  3  4  5  6  7  8  9  10  11  12  13  14  15 

Add commentBack






-
-
How do you like Plasma 5?
 The best KDE Desktop ever.
 Definitely a nice improvement.
 Not decided yet. Haven't tried it yet.
 I do not like some of the changes.
 KDE is taking the wrong way.
 I am still sticking with KDE 3.5.
 I have no opinion, but wanted to vote anyway.

resultmore
 
 
 Who we are
Contact
More about us
Frequently Asked Questions
Register
Twitter
Blog
Explore
Apps
Jobs
Knowledge
Events
People
Updates on identi.ca
Updates on Twitter
Facebook App
Content RSS   
Events RSS   

Participate
Groups
Forum
Add App
Public API
About KDE-Apps.org
Legal Notice
Spreadshirt Shop
CafePress Shop
Advertising
Sponsor us
Report Abuse
 

Copyright 2003-2014 KDE-Apps.org Team  
All rights reserved. KDE-Apps.org is not liable for any content or goods on this site.
All contributors are responsible for the lawfulness of their uploads.
KDE and K Desktop Environment are trademarks of KDE e.V.