new class KBusyIndicatorWidget similar to QtQuick's BusyIndicator

Authored by sitter on Jul 10 2019, 1:06 PM.


new class KBusyIndicatorWidget similar to QtQuick's BusyIndicator

this mimics QQC's BusyIndicator and more specifically our styling of it.

KBIW loads an icon from the icon theme, scales it to the widget size
and rotates it 360 degrees every second for as long as it is running.

the intent here is to give an easy to use spinner implementation that looks
like and feels (to the developer) like the one seen in plasma/kirigami.
this does however somewhat infringe on the business of kpixmapsequence,
so here's why KBIW is better for this specific use case:

  • not pixmap based
  • because it's not pixmap based scaling works much better for SVGs
  • since we paint a QIcon directly we don't have to manually faff about with pixmap copies/segments
  • more robust as themes may incorrectly or not at all implement the animation icon spec (which is rather offhandedly specified really). KBIW takes care of the animation so the theme need only supply a very standard icon and there is no change for things to go wrong more or less
  • because this fully leverages QIcon/KIconThemes we get full advantage of SVG coloring. i.e. when using a dark theme the icon is correctly using a contrasting color
  • users of KBIW no longer need to explicitly use KIconLoader to resolve a pixmap path

Test Plan:
widget works.
not sure an autotest is worth here, there's not much to assert.

Reviewers: cfeck, apol

Reviewed By: cfeck, apol

Subscribers: ngraham, kossebau, broulik, kde-frameworks-devel, apol

Tags: Frameworks

Differential Revision:


sitterJul 15 2019, 2:40 PM
Differential Revision
D22375: new class KBusyIndicatorWidget similar to QtQuick's BusyIndicator
R236:c69eda518007: GIT_SILENT Upgrade KF5 version to 5.61.0.
rjvbb added a subscriber: rjvbb.EditedOct 2 2019, 3:08 PM

Quick question: how would you make this animate once every 2 seconds to reduce the CPU overhead (the test app runs at >12% CPU, too much for a busy indicator IMVHO)? I don't grok the 1s interval duration from the parameters (nor the API documentation).

Just increading the duration doesn't have much effect on the CPU overhead; maybe adding a bit of delay between animation frames would be a better way - but how, other than via QTest::qWait()?

EDIT, to answer my own question:
Adding animation.thread()->msleep(250) after q->update(); in the valueChanged slot does the trick for me (> 10x decrease in CPU load of the unittest).