finkandreas

It depends on what you mean by "saving" the plasmoid dimensions.
If you place the plasmoid on your desktop and restart KDE, then it is KDE which will save the size.
However if you close the plasmoid, and add it again on the desktop, then yasp-scripted will have its minimum size by default.

So what exactly do you try to achieve? Over restarts the plasmoid size should not change (and it's KDE's job to ensure this)
- May 20 2011

I think KDE-4.6.2 screwed up something. Watching the sensors with plasmaengineexplorer there is no systemmonitor:partitions/root/usedspace:value. The best you can do: Write a bugreport to KDE (and change your script in the meanwhile to not show used disk space, until it's fixed in kde)
- Apr 07 2011

The systemengine is part of KDE and not part of yasp-scripted. I have no idea why it does not recognize your root partition anymore, but your home partition is recognized correctly.
Maybe you find sth in the kde bugzilla (search for systemmonitor dataengine), and if nothing is there, you could file a bug there.

I have no idea, why it does not work for you, but you could workaround it, by using the command "df" and parse the output... - Mar 03 2011

I have no idea what happened there.
Can you start plasmaengineexplorer and check the systemmonitor dataengine? That's a good starting point to find the cause of your problem. - Mar 01 2011

Thx for report, I uploaded a 1.0.8a.
Unfortunately I had to pick a new version, coz kde-look.org does not allow to replace with the same filename... - Feb 25 2011

How about just resizing it? hover over the plasmoid, then the kde-plasmoid-bar should appear next to the plasmoid. Resize it. Finished.

I just realized, that there seems to be a bug in my plasmoid. After reparsing the script the kde-plasmoide-bar does not appear again. So you maybe need to restart your kde (or remove the plasmoid, and add it again, or restart plasma-desktop, or ...) - Feb 13 2011

Some additional information to what duncan has already said:

- Try compiling it in debug mode, and get a backtrace. This is some information, I can work with. Telling me that it crashes on reparsing, is not really helpful, since I don't even know, if it always fails, or just from time to time.

- I think that starting with KDE-4.5 all plasmoids work in their own thread, so a stalling yasp, shouldn't stall your desktop (maybe you can configure it somewhere, I don't know exactly)

- Feb 13 2011

As duncan already mentioned it, you first need to find out, how you can get the temperature information on your computer. Yasp-scripted is in no way a magic box, which does work for you. It is a program which prints information on the desktop, but how the information is obtained has to be regulated by the user.

That said, you can try if you have lm_sensors installed, and execute the binary "sensors" and watch its output.
On modern kernel (and I think you as arch user, are on a modern kernel), you can look in /sys/class/hwmon, if you finde something that has temperature information.
For example this command-line will get the core temperatures on my laptop:
'cat /sys/class/hwmon/hwmon[01]/device/temp1_input'
The commandline can be very different for your computer, just checkout what directories you have in /sys/class/hwmon. - Feb 13 2011

Short answer: You cannot make it smaller than the widest element.
What exactly gives you trouble? Cut the value which is too long with the awesome command "cut". - Feb 10 2011

fixed in version 1.0.7. Thx for reporting the issue ;) - Jan 31 2011

finally I've managed to upload the right file ;)
Had to rename it to yasp-scripted-1.0.4a.tar.bz2 but it is the real 1.0.4... - Sep 19 2010

Thx for report --> fixed in 1.0.4 - Sep 19 2010

Ok guys I just tried KDE-4.5 in my virtual machine and it seems like kde screwed something. At least I cannot find what I'm doing wrong.
Anyway there is a temporary fix with an additional parameter for meter. You can set min_height to ensure that the meter will have this as minimal height. So a line like:
meter min_height="30" use="CpuLoad" min="0" max="100" value="$1"
maybe solves your problem.

Can anyone confirm that this helps? - Aug 18 2010

I do not install a release candidate, so it's hard to verify right now. But as soon as kde-4.5 is released I'll have a look to the problem (you can also write as a reminder again to this comment, otherwise I'll maybe forget it) - Jul 18 2010

What happens if you write a bashscript with exactly the command you need, and invoke the bash script as the yasp command?

Another chance is to add to your bash script something like:

#!/bin/bash
export TERM=xterm
HERE_COMES_YOUR_COMMAND


Maybe this will help - May 30 2010

you could start a fork because that would make the merging easier...
http://bitbucket.org/jocker16/yasp-scripted
- May 30 2010

Sounds like a nice idea, but unfortunately I neither have much time nor I have an installed KDE for testing it ;)

Maybe I'll implement it in approx half a year when I have finished my studies but before that I cannot promise you anything... - May 29 2010

Sorry that's not possible. You can only have a line of icons with no text or a line of one icon on the left side and then some text....

And at the moment I do not have that much time, for implementing this.
- May 14 2010

sensor name="HddTemp" type="program" cmd=%hddtemp /dev/sda | sed -e "s/.*: \([0-9]*\).*/\1/"%
value key="Hdd Temp:" use="HddTemp" - Mar 19 2010

sorry, in my command before you should of course replace 'cat temp' by 'sensors' (I copied your output to a file called temp, to test my own command ;) )

To have all informations in one line, define your two sensors (Core0Temp and Cpu0Load) and add this line to your script:
value key="Cpu0: " use="Cpu0Load" use="Core0Temp" format="$1 % $2"

How can you get hdd-temp in a console, and how does the output look like? - Mar 19 2010

It depends how you want to have the output (one line with all 4 temperatures, 4 lines with the temperature for each core, the mean value of all temperatures, etc)

here a possiblity to get all Core values in one line
sensor name="Temp" type="program" cmd=%cat temp | grep Core | sed -e "s/Core [0-3]: +\(..\).*/\1/" | xargs%

value key="Core Temp" use="Temp"

If you want another type of output let me know, then i can give you other possible sensor/value lines ;) - Mar 19 2010

First make sure that lm_sensors works at all, i.e. type 'lm_sensors' in a terminal and look at the output.

Then you need to define sensors in yasp-scripted which parse the output of lm_sensors to get the desired result..

If lm_sensors itself is working and you have no idea how to get the result to yasp, you can post the output of lm_sensors, and I can help you. - Mar 18 2010

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

- Feb 05 2010

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

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

- Feb 04 2010

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... - Feb 03 2010

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 ;) - Feb 02 2010

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...
- Jan 29 2010

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. - Jan 25 2010

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)
- Jan 24 2010

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) - Jan 24 2010

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... - Jan 24 2010

And that should not happen at all because the KDE systemmonitor engine (I guess this is what you are using for your sensors), is smart enough to register the sensors as soon as your Network connection appears, and Yasp is smart enough to continue as soon as the systemmonitor engine registers the sensor...
That is what wonders me. Why does it not work on Mandriva because it works perfectly fine on my laptop (there is written for 2 secons Waiting for WLan0 and then at some point it continues because the WLan connection was established)
I'm using gentoo and here the WM is also started as soon as possible, so network connections are established after the window manager was started.
- Jan 24 2010

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

- Jan 24 2010

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 - Jan 24 2010

check out the scripts by duncan as a good starting point because it seems that he did most of the stuff you need...

for the disk I/O there is in the systemmonitor dataEngine something. Check out with plasmaengineexplorer what there is at all in the systemmonitor dataEngine. - Jan 22 2010

I am not aware of a information you cannot get by a simple shell command?

However if you want to have it in a reasonable performance then the KDE way is to write a dataEngine (the systemmonitor is such an dataEngine).
If you are interested in writing such an engine, you can contact me by mail (mail adress should be somewhere in the README I think)
- Jan 21 2010

very strange... As I said, yasp-scripted waited infinitely long for a sensor to appear, and if it does not appear, it is very likely to not appear on a yasp restart...
So the most likely thing is, that your sensor itself is broken (i.e. it is a sensor which never will be registered).

Could you post the line with sensor name="Eth0Down" and all lines with use="Eth0Down"

- Jan 21 2010

fixed in 1.0.1...
Did you ever try to reparse the script, instead of restarting the whole plasmoid?

But why are you guys having such problems on mandriva??? Is something broken with your KDE?
If I for example disable my Wlan card (with rmmod rt61pci) I get the same message as you get (Waiting for: ...), but as soon as I do modprobe rt61pci, yasp-scripted automatically continues to parse the script and everything just works fine...
I can't understand why it does not work for you that way??? - Jan 21 2010

Open plasmaengineexplorer and check how the sensors are named in kde-4.4 or check if the sensors give correct values. If the values there are wrong go to bugs.kde.org and tell them - Jan 15 2010

In the new version (1.0) the reparsing should work better...
- Jan 13 2010

or, you can edit the source code ;)
hint: line 428 in scriptparser.cpp should be changed to:
p->setShowLabels( true );
- Jan 13 2010

I do not know what to do here because:
It will complicate a lot of things if I drop the assumption, that all values are available as soon as I start drawing the plasmoid. That's the reason why I actually wait for all sensors to appear...
And I'm waiting infinitely long for them to appear and check them periodically every 50ms.
So if it does not work now. It will not work either with your suggestion (i.e. setting a timeout to check if it appears later).
I guess it is a KDE bug, why the sensor never appears in the systemmonitor-dataEngine (but this is just a guess, since I've never checked the source code)

So my result: Unfortunately I cannot change things in this plasmoid (except of checking why the reparsing fails directly???)... - Jan 13 2010

if you do not specify min and max the range is calculated automatically by KDE... - Jan 13 2010

The app you mean is probably conky... And yes it has even more functionality than this plasmoid. And yes it uses far less resources than this plasmoid.
However conky is not a plasmoid and therefore does not have the look of a plasmoid. And it has the drawback that you can plot only one value into a plotter...
But you're right, the idea is quite similar, whereas conky is built for speed (therefore a lot of different options are available and for almost any information there are builtin functions in conky), and this plasmoid was just a little project of mine, with absolutely no optimizations ;)

And I do not think that this plasmoid is waiting anywhere for a process to finish (at least it does not wait actively for it, but in the background), so plasma should not stop working because of this plasmoid? - Jan 02 2010

is $HOME/.yasp.script a file, or a directory on your pc? It should be a file, namely the scriptfile you want to use for this plasmoid. - Jan 01 2010

just download new 0.99b version... It seems like I packaged an old directory with some debug output, which was only for me interesting...
That should work for you... - Dec 31 2009

yasp-scripted.cpp:56
QFont f("Times", 15, QFont::bold);
yasp-scripted.cpp:57
qDebug() << f.toString();

These two lines can be safely deleted... - Dec 31 2009

that's strange... Something is wrong with your compiler... However the lines 56 and 57 (in yasp-scripted.cpp) are irrelevant for this plasmoid (i forgot to delete them). You can safely delete these two lines, and try to recompile. - Dec 31 2009

Since there is no specific reason for text with icon, I will not implement it (because value with icon is more useful, because both icon and value can have different click events). If I would implement it, I would just duplicate code for no additional advancement.

Thx for the script and screenshot. I've uploaded them in the new version ;) - Dec 29 2009