Bug 158672 - Progress bar in "Updating system configuration" window has no meaning
Summary: Progress bar in "Updating system configuration" window has no meaning
Status: RESOLVED FIXED
Alias: None
Product: kdelibs
Classification: Unmaintained
Component: ksycoca (show other bugs)
Version: unspecified
Platform: openSUSE Linux
: NOR wishlist
Target Milestone: ---
Assignee: David Faure
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-03-02 12:49 UTC by Grósz Dániel
Modified: 2015-09-20 17:36 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.15
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Grósz Dániel 2008-03-02 12:49:15 UTC
Version:            (using KDE 4.0.1)
Installed from:    SuSE RPMs
OS:                Linux

The progress bar in the "Updating system configuration" has nothing to do with the status of the progress. It should be removed, or it should report the real status of the progress.
Comment 1 Ben Cooksley 2009-04-30 09:49:14 UTC
Which modules does this affect in particular?
Comment 2 Alvaro Manuel Recio Perez 2009-09-02 11:17:12 UTC
I'm not the original reporter but I think I know what he is referring to.

The problem with the status bar is that it shows a percentage and that percentage has nothing to do with the progress of the task. Indeed, when it reach 95% it goes back to 5% and starts again, always growing at a fixed interval. That progress bar should be "indeterminate", only showing a busy indicator. It seems Qt progress bar supports this, setting its maximum and minimum to 0. The effect is that a small bar is shown, bouncing back and forth, instead of a percentage.

This problem affects several modules and I suspect that what the current progress bar is masking is the execution of kbuildsycoca. So, every module that needs to rebuild the cache would be affected, for instance "Regional & Language". The KDE menu editor is also affected, as it shows the same progress dialog when saving changes.
Comment 3 Alvaro Manuel Recio Perez 2009-09-02 11:20:09 UTC
By the way, I think this bug shouldn't be assigned to "systemsettings". I suspect it belongs to core KDE functionality. Perhaps "kdelibs"?
Comment 4 Alvaro Manuel Recio Perez 2010-10-14 13:11:51 UTC
I see this module is finally assigned to systemsettings but I don't understand why its status is still WAITINGFORINFO. What kind of info it is needed?
Comment 5 Ben Cooksley 2010-10-14 21:47:52 UTC
Information being waited for is the control modules in System Settings being affected. If applications outside System Settings are affected by this, it can be reassigned to kdelibs ( as that is where the actual functionality comes from ).
Comment 6 Alvaro Manuel Recio Perez 2010-10-14 22:13:53 UTC
Then I think it should be reassigned to kdelibs. As I already noted, KDE Menu Editor, for example, displays the same window and it has the same wrong behaviour.

If you think that a comprenhensive list of control modules affected by this issue is still neede I think I could provide that.
Comment 7 Ben Cooksley 2010-10-14 23:15:20 UTC
Reassigning, as occurs in other applications also.
Comment 8 David Faure 2015-09-19 22:53:00 UTC
https://git.reviewboard.kde.org/r/125318/
Comment 9 David Faure 2015-09-20 17:36:48 UTC
Git commit 4c01cfa9bc20b1420ac8113676ebfb66363a3c82 by David Faure.
Committed on 20/09/2015 at 17:36.
Pushed by dfaure into branch 'master'.

KBuildSycocaProgressDialog: use Qt's builtin busy indicator.

This makes the code much simpler and looks better to the user
than a fake progress.

Also removed the 1s delay before closing the dialog.
Users like fast, not slow ;)
Change-Id: I4a5cc975239d5c2998cdc3079890834c23ae677d
REVIEW: 125318
FIXED-IN: 5.15

M  +2    -30   src/widgets/kbuildsycocaprogressdialog.cpp
M  +0    -2    src/widgets/kbuildsycocaprogressdialog.h

http://commits.kde.org/kio/4c01cfa9bc20b1420ac8113676ebfb66363a3c82