
Katarina Machalkova napsal(a):
Hola! ... Every series of Progress::NextStage() calls in your Read() function should be properly terminated with Progress::Finish() after the last stage. The same basically holds true for Write() function, but there it does not hurt so much.
If you fail to do so, Progress module does not clean up the stack by itself (because it does not know that you actually want to finish). Thus, when your Write() function wants to display a new progress, it thinks there are some progresses on the stack, wants to be nested into existing progress and tries to update (non-existing) progress bar. This throws a libyui exception and causes evil red popup to appear.
I was thinking about adding some check whether progress bar WidgetExists into the function checking whether we already have some progress running, but that's not 100% correct solution. It just prevents libyui from throwing ex. after an attempt to update non-existing widget. Someone/something must reset progress counter. An ideal candidate is Progress::Finish() - but in that case the module maintainers must take care of proper nesting of the progresses, not Progress.ycp module itself. Any ideas?
From installation point of view, not solving this issue in general might break the installation workflow in case some plug-in module is broken. There are many Read() and Write() processes called but installation can't control them, it just calls them and evaluate their return value. Every single plug-in can break it. In my opinion, if (UI::WidgetExists (...)) would be sufficient (with error in y2log if it goes wrong). L.