Version: unspecified (using Devel) OS: Linux Using marble (library) from SVN (revision r1184939) in my application. My application is doing a programatically zoom in to an area (animated) at the begining. Placing a slider bar for controling the zoom in/out, and making the connections for syncing both widgets, specially the next connection is causing the problem: connect(theMap, SIGNAL(zoomChanged(int)), this, SLOT(changeSlider(int)) ); Instead of directly connecting the signal to the setValue()slot of the Slider, I used a intermediary slot (changeSlider), and i noted that the ui->zoomSlider->setValue(x); code is what is causing the app to freeze for some moments (using 100% CPU) and repeated times. The code was working for some days without the freeze, but at some point i did some updates (ubuntu, and marble's code from svn) and it appeared. Reproducible: Didn't try Steps to Reproduce: described above Im not sure if the bug/problem is marble related or qt related, because the problem happens with qt code (slider->setValue()). If I filter the number of times the slider->setValue() is executed, the problem minimizes but it does not disappears: void MainWindow::changeSlider(int x) { if ((x>1000 && x<1005) || (x>2397)) ui->zoomSlider->setValue(x); }
Just a quick guess (didn't look into it in detail yet): Does changeSlider(int) cause another map->zoomView() call? Then bug 249628 could be related, because there'd be a circular connection that's not broken in MarbleWidget because of the off-by-one error.
(In reply to comment #1) > Just a quick guess (didn't look into it in detail yet): Does changeSlider(int) > cause another map->zoomView() call? Then bug 249628 could be related, because > there'd be a circular connection that's not broken in MarbleWidget because of > the off-by-one error. I also think its a endless loop, and maybe related to the bug 249628. I removed the animations, and before making the connection (signal->slot) of the slider, i call: slider->setValue(2000); theMap->zoomView(2000); .. connect( ..the signal connections.. ); And it works fine the first zoomView, after the signal connection, if i click the Zoom-in button, the zoom changes from 2000 to 1000 and the app freezes. I placed a qDebug() at the MarbleWidget::zoomView(...) and i got this: ZomView newZoom: 2039 ZomView newZoom: 2038 ZomView newZoom: 2037 ... More output ... ZomView newZoom: 1003 ZomView newZoom: 1002 ZomView newZoom: 1000 ..here it freezes.
(In reply to comment #1) > Just a quick guess (didn't look into it in detail yet): Does changeSlider(int) > cause another map->zoomView() call? Then bug 249628 could be related, because > there'd be a circular connection that's not broken in MarbleWidget because of > the off-by-one error. I think its what you say, a circular signals-slot reactions (the slider changes and the map zoom changes in reaction, then as the map zoom changed the slider changes again and the loop is endless) I can see this if I remove the connect(ui->zoomSlider, SIGNAL(valueChanged(int)), theMap, SLOT(zoomView(int)) ); but keep the connect(theMap, SIGNAL(zoomChanged(int)), ui->zoomSlider, SLOT(setValue(int)) ); I does not freezes. This way I can get the slider updated when the marblewidget's zoom changes, but I cannot zoom with the slider.
SVN commit 1185567 by nienhueser: Round, don't cut. BUG: 249628 CCBUG: 254000 M +1 -1 MarbleMap.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1185567
The implementation of our own slider has some interesting notes on this btw. Also notice the blockSignals() calls. // There exists a circular signal/slot connection between MarbleWidget and this widget's // zoom slider. MarbleWidget prevents recursion, but it still loops one time unless // blocked here. Note that it would be possible to only connect the sliders // sliderMoved signal instead of its valueChanged signal above to break up the loop. // This however means that the slider cannot be operated with the mouse wheel, as this // does not emit the sliderMoved signal for some reason. Therefore the signal is blocked // below before calling setValue on the slider to avoid that it calls back to MarbleWidget, // and then un-blocked again to make user interaction possible. d->m_navigationUi.zoomSlider->blockSignals( true ); d->m_navigationUi.zoomSlider->setValue( zoom ); d->m_navigationUi.zoomSlider->setMinimum( minimumZoom() ); // As we have disabled all zoomSlider Signals, we have to update our buttons seperately. updateButtons( zoom ); d->m_navigationUi.zoomSlider->blockSignals( false );
Ok, that works. As is not a marble bug, but mine, i will close it. Thanks!