Yasp-Scripted (Systemmonitor) v1.0.8a

Plasma 4 Widgets

Source (link to git-repo or to original if based on someone elses unmodified work): Add the source-code for this project on opencode.net

24
7.6
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 ;)
Last changelog:

8 years ago

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

Franksuse64

9 years ago

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 :)

Report

cialdo99

9 years ago

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?

Report

DuncanKDE

9 years ago

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"

Report

Franksuse64

9 years ago

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

Report

C

finkandreas

9 years ago

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...

Report

Franksuse64

9 years ago

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.

Report

DuncanKDE

9 years ago

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.

Report

Franksuse64

9 years ago

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

Report

C

finkandreas

9 years ago

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 ;)

Report

Franksuse64

9 years ago

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. :)

Report

patkoscsaba

9 years ago

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!

Report

C

finkandreas

9 years ago

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...

Report

patkoscsaba

9 years ago

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.

Report

C

finkandreas

9 years ago

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)

Report

patkoscsaba

9 years ago

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.

Report

C

finkandreas

9 years ago

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.

Report

Franksuse64

9 years ago

Ok well I am compiling it, after installing dependencies and doing symlinks from my lib64 to lib folder, when I load the widget it says:

Could not find requested component: yasp_scripted.

I have copied systemmonitor.script to .yasp.script as a FILE and I also tried as .yasp_scripted and also without the dot (.). No success. What is that error?

tnx

Report

C

finkandreas

9 years ago

did you really follow the install instructions in the file INSTALL?

these files have to be installed:
yasp-scripted.desktop --> $KDE_PREFIX/share/kde4/services/yasp-scripted.desktop
yasp_scripted.so --> $KDE_PREFIX/lib/kde4/yasp_scripted.so

KDE_PREFIX you can find out with 'kde4-config --prefix'
However the install routine should do all the work for you, if you follow the instructions in INSTALL...
Afterwards either restart your KDE or execute 'kbuildsycoca4' (otherwise KDE will not be aware of the new installed package).

Report

Franksuse64

9 years ago

The INSTALL file says the following:

===
IMPORTANT:
Copy the file yasp_scripts/systemmonitor.script to $HOME/.yasp.script (if not available yet)
Otherwise, nothing will happen with this applet...
Or choose while running this applet a scriptfile of interest.

Install instructions:
#Release
mkdir build
cd build
cmake -DCMAKE_INSTALL_PREFIX=`kde4-config --prefix` -DCMAKE_BUILD_TYPE=release ../
sudo make install
kbuildsycoca4
===

I did that. No mention of:

yasp-scripted.desktop --&gt;
$KDE_PREFIX/share/kde4/services/yasp-scripted.desktop
yasp_scripted.so --&gt;
$KDE_PREFIX/lib/kde4/yasp_scripted.so

So I will try what you said. :)

tnx

Report

C

finkandreas

9 years ago

because 'make install' installs this two files automatically for you... So if you followed the install instructions you do not need to copy them manually... I just wanted to point out which files need to be where (so you can check if they are where they should be)

Report

Franksuse64

9 years ago

Well, both files are located exactly where you told me. Except that since I have a 64-bits OS, the .so needs to be in /usr/lib64 and not /usr/lib. Now it loads.

I get "Waiting for Wlan0Down" and it shuts down one of my case fan. Weird.

So now that nothing shows, I have to play with the scripts to get something? It's blank plasmoid only with what I wrote above inside.

tnx

Report

C

finkandreas

9 years ago

default title:color="white" title:font="Dejavu Sans, 13" title:shadow="Sunken" title:alignment="Center"
default value:color="white" value:font="Dejavu Sans, 8" value:alignment="Left"

title text="System"
default interval="single"
sensor name="KernelVersion" type="program" cmd="uname -r"
sensor name="KernelMachine" type="program" cmd="uname -m"
sensor name="KdeVersion" type="program" cmd=$kde4-config --version | grep KDE | sed -e "s/KDE: \([0-9.]*\).*/\1/"$
sensor name="QtVersion" type="program" cmd=$kde4-config --version | grep Qt | cut -d" " -f2$
value key="Kernel" use="KernelVersion"
value key="Machine" use="KernelMachine"
value key="KDE / Qt" use="KdeVersion" use="QtVersion" format="$1 / $2"
default interval="60000"
sensor name="UptimeSecs" type="engine" cmd="systemmonitor:system/uptime:value"
sensor name="UptimeDays" type="math" use="UptimeSecs" math="int $1 86400 /"
sensor name="UptimeHours" type="math" use="UptimeSecs" use="UptimeDays" math="int $1 86400 $2 * - 3600 /"
sensor name="UptimeMinutes" type="math" use="UptimeSecs" use="UptimeDays" use="UptimeHours" math="int $1 86400 $2 * - 3600 $3 * - 60 /"
sensor name="LoggedUsers" type="program" cmd="users | sed -e 's/ /\n/g' | sort | uniq | xargs"
value key="Uptime" use="UptimeDays" use="UptimeHours" use="UptimeMinutes" format="$1 day(s) $2 h $3 m"
value key="Users" use="LoggedUsers" interval="10000"



That is a very basic script file which should work on every PC. Otherwise you can comment all lines in your scriptfile which contain something with WLan0 (because you probably do not have a network with wlan0).

I do not know why it was installed in /usr/lib, instead of /usr/lib64. It is a KDE bug, because I ask KDE where the plugins should be installed...

Report

vi3dr0

9 years ago

Hi,

First of all - absolutely excellent work! Really, it's awesome ;)

However is it possible to show more than one command per line? I'd like to adjust it to show data horizontally in the panel, like:
"download: xx | upload: xx | cpu: xx | ram: xx |".

I hope you know what I mean.

Report

DuncanKDE

9 years ago

Quote: More than than one command per line? [L]ike:
"download: xx | upload: xx | cpu: xx | ram: xx |"

Yes. See the README.syntax file, value section.

Basically, you define your separate sensors, then in your value line, you use multiple use= parms, and a format= parm listing them all with $1, $2, etc, at the spot where the values for the respective positioned use parms would go. There's even a multi-sensor example. =:^)

As documented, the default format is only "$1", so don't forget to add a format= parm, or it'll only show the first sensor value. As the example demonstrates, you can fill in text between the substituted values, so yes, your given line with four sensor values on the same line, complete with labels (which would be part of the format string), is quite possible.

There are a couple caveats, unfortunately. It seems the whole line takes the same color, so you can't multi-color the line. That's actually what prevented me from using it, as in most cases, my value lines corresponded to an element in a plotter as well, with the value lines serving the dual purpose of plotter color key and text readout. That was the big issue here, but a lessor one is that while I used a monospace font to maintain alignment, being very careful to allow spacing for the variable number of digits so the alignment wouldn't get screwed up, that's pretty much impossible with multiple value readouts per value line, because in most cases, each one can be variable digits wide, and multiple variable digits just doesn't allow for the possibility of proper alignment.

So yes, you /can/ have multiple output values per line; but the caveats may or may not be something you're willing to live with. If you have one long line of readout and thus don't need vertical alignment, it's possible, but you'll still lack the ability to color-code the individual outputs, and that was a deal-breaker for me.

Report

C

finkandreas

9 years ago

Duncan said basically everything. However I would recommend you to use the "text" keyword instead of the "value" keyword (because it uses the full width of the plasmoid), i.e. add a line like this:

text use="CPU" use="RAM" use="NetworkUp" use="NetworkDown" format="CPU: $1 RAM: $2 Up: $3 Down: $4"

of course you first need to define the sensors CPU, RAM, NetworkUp and NetworkDown

Report

8 years ago

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

12345678910
123
product-maker domryba Apr 16 2015 8 great
product-maker LeifErikson May 29 2013 8 great
product-maker XenoPL Nov 01 2012 8 great
product-maker Sweyn78 Aug 27 2012 8 great
product-maker matafleur Mar 05 2012 8 great
product-maker gerstavros Jan 15 2012 8 great
product-maker Heart Nov 14 2011 8 great
product-maker momonster Jul 02 2011 8 great
product-maker superpepo Jun 18 2011 8 great
product-maker yield65 May 29 2011 8 great
product-maker marcotangaro Mar 24 2011 8 great
product-maker theZest Feb 28 2011 8 great
product-maker bugmenot1234 Feb 27 2011 8 great
product-maker rangerGR Feb 25 2011 8 great
product-maker schleby Feb 14 2011 8 great
product-maker phiga2 Feb 11 2011 3 bad
product-maker srog Feb 01 2011 8 great
product-maker opera1818 Dec 17 2010 8 great
product-maker cialdo99 Nov 18 2010 8 great
product-maker deabru Nov 07 2010 8 great
product-maker schnelle Nov 05 2010 8 great
product-maker Vzlom Oct 27 2010 8 great
product-maker vatsok Oct 21 2010 8 great
product-maker SeaJey Oct 07 2010 8 great
product-maker Count:67 Rating: 7.46

domryba

Apr 16 2015

xrooters

Jul 13 2013

LeifErikson

May 29 2013

XenoPL

Nov 01 2012

despot77

May 28 2012

Fred6681

Jul 02 2011

yield65

May 29 2011

marcotangaro

Mar 24 2011

extra

Nov 09 2010

Contrast

Aug 21 2010

poelzi

Feb 25 2010

hellblade

Feb 16 2010

Franksuse64

Feb 02 2010

DaiVied

Dec 19 2009

nicollivier

Dec 02 2009

Droopy159

Nov 18 2009

SeaJey

Nov 03 2009

Sibob

Nov 03 2009

DuncanKDE

Oct 22 2009

kanutron

Sep 18 2009

t3ddy

Sep 04 2009

Montblanc

Aug 28 2009

NForce

Aug 10 2009

Havoc65

Jul 31 2009
File (click to download) Version Description Downloads Date Filesize DL OCS-Install
Pling
*Needs ocs-url or ocs-store to install things
Details
license
version
1.0.8a
updated Feb 25 2011
added Jul 31 2009
downloads today
0
page views today 7