fix no-display of CPU bars per core (and fix some warnings)

Review Request #129838 - Created Jan. 15, 2017 and updated

Information
Martin Koller
kdeplasma-addons
5.8
373776
Reviewers
plasma
sars

See bug #373776
The CPU bars do not show a value when using separate bars per CPU, and the tooltip never
shows a value per CPU, since the data sources per CPU are not subscribed.

AFAICT this could never have worked.

yes

Issues

  • 2
  • 0
  • 0
  • 2
Description From Last Updated
I think we want: connectedSources: sources() otherwise if cores doesn't change we don't add all the other important sources. Given ... David Edmundson David Edmundson
this doesn't match anything in the commit description. David Edmundson David Edmundson
David Edmundson

seems mostly fine.

I think we want:

connectedSources: sources()

otherwise if cores doesn't change we don't add all the other important sources.

Given libksysguard has a tonne of backends, and the main linux one has this guarded in _SC_NPROCESSORS_ONLN this seems it could happen.

  1. No, what you suggest is what I tried first, but that gives a "property loop" warning.
    I asked on KDE-devel ML how to solve this and Kevin Krammer suggested to solve it similar to this.

    AFAI understood, the values are polled, so there is no need that anything changes.

this doesn't match anything in the commit description.

  1. This is the "and fix some warnings" part of the summary.
    There were warnings like "can not use .value from undefined" or similar

Kåre Särs
The current/old version uses "connectSource(source)" to add the CPUs when they are added in onSourceAdded, but that is not good if the sources are added before SystemLoadViewer.qml (a problem when adding a second SytemLoadViewer)

I'm fine with this change, but it seems indeed strange that you first only connect "system/cores"

What happens if you use connectSource(...) in onNewData in stead of setting all of connectedSources again?
  1. Sorry, I don't understand your question.
    I'm first connecting to the system/cores only to know how many cores there are since this information is needed to know (calculate) what is the effective sources array I want in the end.
    Therefore:
    step 1) get #cores
    step 2) get list of all needed sources including those which are indexed by the core-idx
    step 3) connect this final list of sources

    What is wrong with this approach ?

  2. Anything I need to clarify ?
    or can this path be applied, please ?

Marco Martin

any update on this?

Loading...