Bug 184893 - Plasma DataEngine "systemmonitor" not updating sources list automatically
Summary: Plasma DataEngine "systemmonitor" not updating sources list automatically
Alias: None
Product: plasma4
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: Plasma Bugs List
Depends on:
Reported: 2009-02-19 07:49 UTC by Shantanu Tushar
Modified: 2009-03-12 09:35 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:

Crash backtrace (7.85 KB, application/octet-stream)
2009-02-27 13:16 UTC, Shantanu Tushar
Crash backtrace (7.85 KB, application/octet-stream)
2009-03-03 18:09 UTC, Shantanu Tushar
Crash backtrace (6.54 KB, application/octet-stream)
2009-03-03 18:37 UTC, Shantanu Tushar
Log for plasmoidviewer sm_net 2>sm_net.log (435.92 KB, application/octet-stream)
2009-03-05 20:23 UTC, Shantanu Tushar

Note You need to log in before you can comment on or make changes to this bug.
Description Shantanu Tushar 2009-02-19 07:49:29 UTC
Version:           KDE 4.2.63 (using Devel)
OS:                Linux
Installed from:    Compiled sources

I noticed that The System Monitor - Network applet did not
automatically update its network interface list, i.e. if I connect a
dial-up modem, the interface ppp0 is not shown in the applet's
settings. However, if the applet is restarted, the list is updated.
I've examined the source (
kdebase/workspace/plasma/applets/system-monitor/net.cpp ) and found
that it uses "systemmonitor" as the data engine, and whenever a call
to engine()->sources() is made ( in the function
SM::Net::parseSources() ), the list returned back doesn't contain
"ppp0", if the interface was connected after the applet was started.
This means that the data engine is not getting properly updated.

Further, there are no public member functions of Plasma::DataEngine
which can force a update/refresh.
Kde devel mailing lists reply suggests that this is a bug in DataEngine.
Comment 1 Aaron J. Seigo 2009-02-24 10:34:28 UTC
"Kde devel mailing lists reply suggests that this is a bug in DataEngine."

that would be incorrect.
Comment 2 Shantanu Tushar 2009-02-24 12:38:14 UTC
My sincere apologies for having used an incorrect term. What was meant that I received replies to a mail I sent to the kde-devel mailing list saying that the engine was not updating the sources. I had no experience at that time, so just accepted it. But, I am now starting to grasp things in Plasma, so I'll confirm where the problem exactly lies. Regret for the inconvenience caused.
Comment 3 Aaron J. Seigo 2009-02-24 17:57:19 UTC
no inconvenience; i just wanted to clarify that point for the next person who comes along and reads the report, perhaps even attempting to fix it. it's a somewhat common misunderstanding that the widget can't kick the engine; another common misunderstanding is that widgets _should_ do such a thing (almost always they should *not*).

in this case, the problem is that the engine itself isn't updating in response to changes in the hardware environment. the widget shouldn't be doing anything but responding to the engine, and the engine should be responding to signals from sysguard or solid, whichever it uses in this case.
Comment 4 Shantanu Tushar 2009-02-24 18:56:51 UTC
Yes, I observed now with kDebug() outputs that its really the engine not refreshing. So, what could be a solution? I mean to say where to look for the cause of the problem, so that it can be fixed? I've noticed that closing and restarting the applet causes the engine to refresh. I think not being aware of system changes isn't a good thing for a System Monitor.
Comment 5 Aaron J. Seigo 2009-02-24 19:38:10 UTC
"Yes, I observed now with kDebug() outputs that its really the engine not
refreshing. So, what could be a solution?"

i'm not overly familiar with how ksysguard does thing, but SensorManager has an update() signal that looks like it might do the trick. perhaps connecting to that signal, getting the new list of sensors and altering the current list according to that would do the trick. if that doesn't work, we can ask John Tapsell about it.

then in the widget, it would need to connect to the sourceAdded and sourceRemoved signals to get notified of these changes.

"I've noticed that closing and restarting the applet causes the engine to refresh."

but i bet that if you have two of these widgets running on your desktop and you close only one of them and then start a new one the engine doesn't refresh. my (educated) guess is that when the applet is closed, the engine is no longer in use so it is deleted. when the applet is started again, the engine is re-loaded and it re-initializes itself and so shows the current network configuration properly.

"I think not being aware of
system changes isn't a good thing for a System Monitor."

agreed ;)
Comment 6 Shantanu Tushar 2009-02-27 13:13:15 UTC
I connected a slot for the update() signal as you said. Now the next step is to update the list accordingly. I'm using void SystemMonitorEngine::updateSensors() [in kdebase/workspace/plasma/dataengines/systemmonitor/systemmonitor.cpp], as the slot for the update() signal. Now, If I build and run the applet, whenever there is some addition/removal of interface(s), it crashes. Is the slot I'm using for updating the current list correct? Anyway, I've attached the backtrace.
Comment 7 Shantanu Tushar 2009-02-27 13:16:12 UTC
Created attachment 31678 [details]
Crash backtrace

I tried to figure out where the problem is, but couldn't find it.
Comment 8 Shantanu Tushar 2009-03-03 18:09:03 UTC
Created attachment 31754 [details]
Crash backtrace
Comment 9 Shantanu Tushar 2009-03-03 18:37:10 UTC
Created attachment 31756 [details]
Crash backtrace
Comment 10 Shantanu Tushar 2009-03-05 20:14:09 UTC
I've done some research on the engine, and ksysguard SensorManager and SensorAgent sources. By using some kDebug statements in

kdebase/workspace/plasma/dataengines/systemmonitor/systemmonitor.cpp -

void SystemMonitorEngine::answerReceived(int id, const QList<QByteArray> &answer)

and connecting and disconnecting my modem, I found out that in the above function, ksysguard sends a list with id = -1 which is then processed by the function to build up the sensor list. But, ksysguard sends this list (for id=-1) only ONCE, regardless of any change in the system state. ( A kDebug log is attached ).

When I tried the file

to locate this behavior, I found it difficult to analyse the source as I don't have much experience. I find that you mention John Tapsell, but I could not find where to contact him. Can you please bring this to his attention, if I'm right about this? I really want to fix this somehow.
Comment 11 Shantanu Tushar 2009-03-05 20:23:52 UTC
Created attachment 31805 [details]
Log for plasmoidviewer sm_net 2>sm_net.log

Lines 10-509 -> lists of the sensors
Line 2895 -> displays pppd running
1219 - 1395 -> information about network interfaces
3637,3638 -> KSGRD::SensorMgr::update() occured (the slot for which I've given updateSensors() )
3642 - 3670 -> information about network interfaces after dialup connection, but still doesn't contain ppp0
Comment 12 Aaron J. Seigo 2009-03-05 20:38:16 UTC
i believe you need to do this:

KSGRD::SensorMgr->sendRequest("localhost", "monitors", (KSGRD::SensorClient*)this, -1);

to trigger the listing of the available monitors. it's currently only done in the constructor of the SystemMonitor DataEngine, but it would need to be done whenever ksysguard says the monitors have changed.

as for John, his email address is in the license headers at the top of various files in ksysguard :)
Comment 13 Shantanu Tushar 2009-03-07 16:47:57 UTC
Patch at http://reviewboard.kde.org/r/246/ please review.
Comment 14 Shantanu Tushar 2009-03-12 09:35:18 UTC
SVN commit 938556 by shantanu:

added functionality for system monitor data engine to update the monitors list when SensorMgr sends update()
BUG: 184893

 M  +14 -2     systemmonitor.cpp  
 M  +1 -0      systemmonitor.h  

WebSVN link: http://websvn.kde.org/?view=rev&revision=938556