Summary: | systemmonitor dataEngine has no values on first update | ||
---|---|---|---|
Product: | [Unmaintained] plasma4 | Reporter: | Andreas Fink <finkandreas> |
Component: | widget-systemmonitor | Assignee: | Plasma Bugs List <plasma-bugs> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | aseigo, finkandreas, jetrull |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Gentoo Packages | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
Andreas Fink
2009-08-01 18:44: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... "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. 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. 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. :/ 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. 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. 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. 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) |