<div>I may not be understanding this right, but what if the CollapsedEntry, when it got the signal, checked if it was actually going to have to change the jobject, and if it was already kept, it would just abort? This would quash the signal the second time around - one step more than strictly necessary/ideal, but I don't know how to convince gtk not to send the signal if it was already pressed, which is what would be necessary to quash it exactly the first time.</div>
<div> </div>
<div>Either that or on this step:</div>
<div> </div>
<div>and updates the<br>entry as required. This includes setting the keep property </div>
<div> </div>
<div>you check the keep property before you set it, and do not touch it if you are not going to change it. <br><br> </div>
<div><span class="gmail_quote">On 4/24/08, <b class="gmail_sendername">Eben Eliason</b> <<a href="mailto:eben.eliason@gmail.com">eben.eliason@gmail.com</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Hello, my name is Eben Eliason, and I have a problem...<br><br>Symptom: The keep buttons in the Journal (the stars) take 1 second or<br>
so between being clicked and visually reflecting that change. This<br>is, admittedly, a rather minor problem, but as you'll see, it spells<br>out a larger underlying ugliness. I expect the feedback to be instant<br>
both because it's better that way, and also because the identical<br>(well, nearly so, as shown below) favorite icons used in the list view<br>of the new Home already function perfectly, and quickly.<br><br>Diagnosis: Upon inspection, the KeepIcon class used in the Journal<br>
differs from the FavoriteIcon class used in Home in one crucial way.<br>The former does not connect to a button-release-event at all, and<br>instead depends on the code which uses it to do so for it, take the<br>necessary actions based on the toggle, and then tell the KeepIcon<br>
itself that it has been clicked on in order to update its internal<br>state and reflect that with visual changes. This is obviously the<br>incorrect approach to the problem, as the KeepIcon should abide by all<br>the wonderful properties that makes object oriented programming<br>
useful, manage its internal state so that, if nothing else, it remains<br>consistent when clicked (it's basically a checkbox....a boolean<br>toggle), and notify anything that may happen to care about its value<br>when it changes.<br>
<br>Treatment: Take the object oriented approach above, which works nicely<br>in Home, and should also work nicely in the Journal. This cleans up<br>the code, and allows the KeepIcon to update its internal state<br>immediately before emitting the signal, thus redrawing before anything<br>
which wishes to be notified of its state has a chance to waste lots of<br>time, slowing feedback.<br><br>Side-effects: This is where things get ugly. The above changes were<br>trivial, but they create an ugly signal loop which makes the treatment<br>
worthless in its purest state as described above. Here's what goes<br>down:<br><br>When a KeepIcon is clicked, its button-release-event handler updates<br>its internal state, including its keep property, which thus emits a<br>
notify::keep signal. The CollapsedEntry object which contains the<br>KeepIcon connects to this signal in order to update the value of the<br>keep key in the metadata of the associated JObject. So far so good.<br>The DS then emits an updated signal, which includes a reference to the<br>
JObject which has been updated. Off in Never-Never-Land, query.py is<br>listening for the update signal from the DS, and the handler for this<br>signal replaces the JObject in its internal dict, and then emits its<br>own modified signal. The listview.py connects to the modified signal,<br>
and its handler then calls self._do_scroll, which in turn calls<br>self._refresh_view. The latter of these functions takes it upon<br>itself to loop over all of the CollapsedEntry objects visible on<br>screen, updating a match for the changed JObject by setting its<br>
corresponding jobject property. The method responsible for handling<br>the setting of this jobject property within the CollapsedEntry then<br>reads all of the info out of the newly passed JObject, and updates the<br>entry as required. This includes setting the keep property of the<br>
KeepIcon within the entry, which cannot assume that it has previously<br>been set, since this is also the function that gets called to<br>initialize the CollapsedEntry in the first place. This, of course,<br>triggers the do_set_property of the KeepIcon, which in turn emits a<br>
notify::keep signal. Hooray.<br><br>Treatment of side-effects: Anyone know the best way to handle this<br>issue? I'm fairly convinced that the fundamental changes to the<br>KeepIcon class suggested above are the correct approach logically and<br>
semantically. I'm unsure about the correct way to sever the recursive<br>loop, however. Any thoughts are very much appreciated, since I've now<br>spent considerable time messing with an issue that I thought would<br>
have a 10 minute fix.<br><br>- Eben<br><br>PS. Thanks for listening!<br>_______________________________________________<br>Sugar mailing list<br><a href="mailto:Sugar@lists.laptop.org">Sugar@lists.laptop.org</a><br><a href="http://lists.laptop.org/listinfo/sugar">http://lists.laptop.org/listinfo/sugar</a><br>
</blockquote></div><br>