View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0011712ScribusInternalpublic2013-08-29 11:522013-09-12 10:52
Reportercezaryece Assigned To 
PrioritynormalSeverityminorReproducibilityalways
Status newResolutionopen 
Platformall 
Product Version1.5.0svn 
Summary0011712: Multiple updates of PP
DescriptionI have notice that many updates are forced to PP members when I only change selected item or while writing text.

1. PropertiesPalette object is connected to selectionChanged() and docChanged() signals. While handling these signals by handleSelectionChanged() for each member of PP (each tab) its own handleSelectionChanged() is called.
BUT each PP member has connected handleSelectionChanged() to these signals as well and each signal is handled twice - first by PP call, second as signal handling.
2. I have found that many widgets in PP have not blocked signals while its values are changed on handling signals, not by user. In result other signals (like docChanges()) are emited and all update of PP starts again and again. I have found that update fo XYZ tab can run even 5 times while I only change selection in document.
3. Almost each PP member invokes its repaint function after selection changes. I think it is not necessary as PP run this function too and I don`t see any wrong effects after removing these calls.
Steps To Reproducerun Scribus in debug mode with trap in void PropertiesPalette_XYZ::handleSelectionChanged()
Additional InformationI think there is big possibility to make Scribus more responsive for user after fixing those things.
I dont provide any patch for that as PP is going to be refactored, so patch can be unusable soon.
But I want to share simple function I have wrote. It is very usable function for blocking signals for even quite complicated UI structure. I have placed it in util.cpp and I use it for block/unblock signals for widget with all it childrens.

void blockSignalsWithChildrens(QWidget * w, bool block)
{
    w->blockSignals(block);
    foreach (QWidget* obj, w->findChildren<QWidget *>())
        blockSignalsWithChildrens(obj, block);
}

Advantage of this function it is not sensitive to changes in UI. Disadvantage is it blocks signals even for labels or other not interactive widgets.
TagsNo tags attached.
Patch

Activities

jghali

2013-09-04 22:31

administrator   ~0030558

Last edited: 2013-09-04 22:32

 The blockSignalsWithChildrens() implementation is incomplete. Correct use of blockSignals() is normally like this :

// Signals may already be blocked for widget
bool sigBlocked = widget->blockSignals(true);
... Do something with widget ...
// Set signal blocking to initial state
widget->blockSignals(sigBlocked);

So blockSignals() implementation make recursive use possible :

bool sigBlocked1 = widget->blockSignals(true);
// Code then call another function ...
bool sigBlocked2 = widget->blockSignals(true);
... Do something ...
// After that call signals are still disabled
widget->blockSignals(sigBlocked2);
// Return to first function ...
widget->blockSignals(sigBlocked1);
// Signals are now enabled again

So for correctness blockSignalsWithChildrens() should have same capabilities...

JLuc

2013-09-05 07:03

developer   ~0030560

Last edited: 2013-09-05 07:03

 Could be usefull for 0011144

cezaryece

2013-09-06 13:32

updater   ~0030566

Last edited: 2013-09-06 13:33

 void Jean::doItThisWay() {

bool sigBlocked = widget->signalsBlocked();

widget->blockSignalsWithChildrens(true)
.. Do something with widget ...

// Set signal blocking to initial state
widget->blockSignalsWithChildrens(sigBlocked)
}

JLuc

2013-09-06 16:10

developer   ~0030567

cezariece i think the issue is still there with the children's state because of :
  foreach (QWidget* obj, w->findChildren<QWidget *>())
        blockSignalsWithChildrens(obj, block);

solution might depend on how complex the block situations possibly are...

cezaryece

2013-09-09 05:58

updater   ~0030576

I dont think childs of widget can have different blocking signals state than its parent in real life.
I am happy with this as is, if you (and team) are not than close and forget that report.

cezaryece

2013-09-12 10:52

updater   ~0030585

To be clear: I am using blockSignalsWithChildrens() only in case when many child widgets will be changed by set new values (mostly when selection changes) and is very easy to forget to block signals for some widget - that is what I notice here and there in PP, so I just provide simply and efficient solution for that bug.

Issue History

Date Modified Username Field Change
2013-08-29 11:52 cezaryece New Issue
2013-09-04 22:31 jghali Note Added: 0030558
2013-09-04 22:32 jghali Note Edited: 0030558
2013-09-05 07:03 JLuc Note Added: 0030560
2013-09-05 07:03 JLuc Note Edited: 0030560
2013-09-06 13:32 cezaryece Note Added: 0030566
2013-09-06 13:33 cezaryece Note Edited: 0030566
2013-09-06 16:10 JLuc Note Added: 0030567
2013-09-09 05:58 cezaryece Note Added: 0030576
2013-09-12 10:52 cezaryece Note Added: 0030585