[scribus-dev] The handleSelectionChanged() thing again
Elvis Stansvik
elvstone at gmail.com
Tue Jul 12 08:08:16 UTC 2011
Good morning,
Something Craig said during last night's IRC conversations stuck with
me, and I'd like to get to the bottom of it:
23:27 < jghali> if doc has changed, that means a proeprty has changed
and PP must be updated
23:27 < MrB> sounds reasonable.. assuming the change was not
originated from the PP itself
I must say I agree with Craig here; should the PP really be notified
of changes that originated from itself? Because that's what's
happening right now. Do the other PP palettes rely on this behavior?
Taking the line width in PropertiesPalette_Line as an example, what
will happen when the user presses the "Line Width" spinbox is:
1) QDoubleSpinBox::valueChanged() is emitted.
2) ScribusDoc::itemSelection_SetLineWidth() is called.
3) ScribusDoc::changed() is called.
4) ScribusDoc::docChanged() is emitted.
5) PropertiesPalette_Line::handleSelectionChanged() is called.
6) PropertiesPalette_Line::setCurrentItem() is called.
7) PropertiesPalette_Line::displayLineWidth() is called.
8) ScrSpinBox::showValue() is called with the width taken from the item.
9) QDoubleSpinBox gets its value set by Qt itself (Probably, but I do
not have Qt source to put a breakpoint in it and check).
Seems like quite a roundabout way of updating a spinbox value when the
PP palette already knows what the value will be.
And now that I did that investigation, I actually found in
PropertiesPalette_Line::setCurrentItem():
//CB We shouldnt really need to process this if our item is the same one
//maybe we do if the item has been changed by scripter.. but that
should probably
//set some status if so.
So the whole thing is designed around the palettes getting a "new"
item set each time a property is changed.
Thoughts?
I guess so far it has not been a problem that palettes gets their
setCurrentItem() et.c. machinery called every time a property is
changed through the palette.
But in my case I have that little side selector thing. Think of using
that as a little editing session; after selecting a table item, you
start out with all four sides selected, and then you pick the sides
you want to edit, then you change its properties. With the above, the
editing session will be broken as soon as a property is changed,
because the palette will think it has a new item set, and go back to
the start position with all four sides selected.
This is what I'm trying to work around now in the best way possible.
Elvis
More information about the scribus-dev
mailing list