Bug 202225 - systemmonitor dataEngine has no values on first update
Summary: systemmonitor dataEngine has no values on first update
Status: RESOLVED FIXED
Alias: None
Product: plasma4
Classification: Plasma
Component: widget-systemmonitor (show other bugs)
Version: unspecified
Platform: Gentoo Packages Linux
: NOR normal
Target Milestone: ---
Assignee: Plasma Bugs List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-08-01 18:44 UTC by Andreas Fink
Modified: 2010-05-21 02:56 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas Fink 2009-08-01 18:44:34 UTC
Version:            (using KDE 4.2.4)
OS:                Linux
Installed from:    Gentoo Packages

If i connect a source to the systemmonitor dataEngine via

dataEngine("systemmonitor").connectSource("system/uptime", this, 60000)

i get directly a dataUpdated(...), but the data itself is empty. So only after 60 seconds i get my first data packet which is not empty.
Comment 1 Andreas Fink 2009-08-01 18:46:34 UTC
Forgot to mention that i check of course first if the source is available, and if not, i connect first to the sourceAdded(QString) signal, and connect as soon as the source is available...
Comment 2 Aaron J. Seigo 2009-08-02 21:19:02 UTC
"i get directly a dataUpdated(...), but the data itself is empty. So only after
60 seconds i get my first data packet which is not empty."

bug in the dataengine. it should say that it's got a delayed update in this case.

"check of course first if the source is available, and
if not, i connect first to the sourceAdded(QString) signal, and connect as soon
as the source is available..."

that's unnecessary.
Comment 3 Andreas Fink 2009-08-02 21:42:57 UTC
Why is it unnecessary to wait for the source to be available? If I connect (at least this is true for the systemmonitor data engine) a source which is not yet available (checked with the sources() command), then the connection will never be established, i.e. I will never end up in the slot dataUpdated(QString, DataEngine::Data).
So I do not think that it is unnecessary to wait for a source.
Comment 4 Aaron J. Seigo 2009-08-02 21:46:29 UTC
hmm... the engine rejects otherwise valid sources on request if the connection to the local ksysguardd hasn't been set up yet. that breaks with the DataEngine design, and is why you have to do the connect-to-sourceAdded thing. :/
Comment 5 Aaron J. Seigo 2009-08-02 22:04:49 UTC
do you build kdebase from sources? if not, would you be able to build the systemmonitor plasmoid from sources if i gave you some pointers? alternatively, if you could point me to the source code for your widget so i could test locally that might also work out.
Comment 6 Andreas Fink 2009-08-02 22:49:22 UTC
I am using gentoo, so yes I build from sources, but maybe not in the way you are asking for ;)
But it would be no problem to build it also by myself from sources, instead of a gentoo emerge.
But actually I have used a workaround for my plasmoid (yasp-scripted: http://www.kde-look.org/content/show.php/Yasp-Scripted?content=109367). I am connecting the source first with a 50 ms interval and after 3 updates i connect it to the desired interval. Ugly hack, but it works (and not the only hack, to get it working as I want it to work).

I just wanted to report this, that it will maybe fixed in further releases, and that I maybe one day, can remove my hack from the sources.

But I also willed to test if you can tell me, what I should test.
Comment 7 Jeff Trull 2010-01-04 00:46:09 UTC
Andreas, I've downloaded and compiled yasp_scripted, and I find that the first call to dataUpdated does provide data - at least in KDE trunk.  However, the data hash contains only "type" information and not "units", "value" etc.  In KDE 4.3.2 (my desktop) the behavior is somewhat different, so I think this code has recently changed.

If you can supply a test case I can run it against KDE trunk to see if it's been fixed - just indicate what you expected the debug output to be vs. what it actually is in your build.
Comment 8 Andreas Fink 2010-01-04 16:48:45 UTC
I'm not using kde myself anymore, so I cannot write a simple test case myself, but a simple testplasmoid would be:

connect to the systemmonitor engine -> register for the sensor system/uptime with an update interval of 60 seconds -> watch if the first update contains already the desired value
If the value is not there on the first interval it will be there on the second update, but this is 60 seconds later and this is not the desired behaviour, because I want to have the value on the first update...
I think the systemmonitor engine should only raise a dataUpdated, if and only if there is a value field (because the type information is not the main information we need)